Not Found (404) in Search Console: Fix It or Ignore It?

"Not found (404)" in Search Console is not a penalty, and on most sites it is not even a problem. Google's own definition of the status contains a detail almost nobody reads: "This page returned a 404 error when requested. Google discovered this URL without any explicit request or sitemap." That second sentence is the whole story. These are URLs Google went looking for on its own, found nothing, and told you about.

The report still causes panic, because Search Console files the status under the pages that are not indexed, and a mid-sized site can carry thousands of them. This article covers what the status actually measures, why Google's own crawl budget documentation recommends serving the exact response people are trying to eliminate, the five cases where a 404 genuinely needs fixing, and how to tell those apart without spending a week on it.

What does "Not found (404)" mean in Google Search Console?

It means Googlebot requested a URL and your server answered with a 404 status code. Google then dropped the URL from consideration for indexing and listed it in the Page indexing report under that status. Nothing was removed from the index as a result, because a URL that returns 404 was either never indexed or had already stopped being eligible.

The part worth pausing on is where Google says it found the URL: "without any explicit request or sitemap." Google is telling you these addresses did not come from you. They came from links on other sites, from links inside your own pages, from URLs Google saw years ago and still remembers, from parameters it constructed while crawling, and from whatever a scraper published last month. If a 404 URL had been in your sitemap, that would be a different and more embarrassing situation, because a sitemap is a list of pages you are asking Google to index.

Two rows in that table are the ones people confuse. A soft 404 is worse than a 404, not better, because Google has to keep crawling it to keep guessing. And blocking a dead URL in robots.txt is worse than serving a 404, which is the opposite of what most people assume.

Do 404 errors hurt SEO?

No, and the strongest evidence is not a quote from a Google spokesperson. It is that Google's own documentation tells you to produce them. In the large site crawl budget guide, under the list of practices for improving crawl efficiency, Google says plainly: "Return a 404 or 410 status code for permanently removed pages." It then explains why, noting that "a 404 status code is a strong signal not to crawl that URL again."

Read that alongside what the same guide says about the alternative. "Blocked URLs, however, will stay part of your crawl queue much longer, and will be recrawled when the block is removed." Blocking a dead URL keeps it alive in Google's queue. Serving a 404 retires it. Google is telling you which one it prefers, and it is not the tidy-looking one.

The same document is blunt about the middle option people reach for when they want the report to look clean. "Eliminate soft 404 errors," it says, because "soft 404 pages will continue to be crawled, and waste your budget." A friendly "sorry, we couldn't find that" page that returns HTTP 200 is the single most expensive way to handle a dead URL. It costs you the crawl forever and tells Google nothing.

So the "Not found (404)" count going up is, in isolation, neutral to positive. What matters is not the number. It is whether any of the URLs in it were pages you wanted people to reach.

When "Not found (404)" is actually a problem

There are five cases where the status is a symptom rather than a report, and each is worth checking directly.

The URL is in your XML sitemap. This is the one that genuinely embarrasses. You are handing Google a list of pages you want indexed and one of them does not exist. Google notices, and it discounts the sitemap as a signal of what you care about. It also usually means your sitemap is generated from stale data rather than from live routes. Every URL in a sitemap should return 200, no exceptions, and a sitemap that has drifted out of sync with the site is worth fixing before anything else in this list. If you are not sure which of yours currently 404, the sitemap submission tool reports it.

The page used to rank and nothing replaced it. A retired URL that earned traffic is not a 404 problem, it is a lost asset. Before you decide a dead URL deserves nothing, look at what it was ranking for and how much it earned. If there is a genuinely equivalent page live today, redirect to that specific page. If there is not, the honest question is whether the content should come back rather than whether the URL should redirect. Plenty of 404s in a report trace back to a content library that quietly stopped being maintained, which is a staffing problem dressed as a technical one, and one that teams increasingly hand to an agent that keeps the articles current rather than solving with another redirect rule.

Your own internal links point at the dead URL. A 404 that Google found by following a link from your own navigation, footer or body copy is different in kind from one it found on a scraper site. It means a real visitor can hit it too. Internal broken links are the highest-priority entries in the whole report and usually the smallest number, because they cluster around one bad template or one renamed section.

A deploy or migration produced a spike. A count that climbs steadily is the normal decay of the web. A count that jumps by thousands in one day is a change you shipped. Renamed URL structures, a dropped route, a trailing-slash rule that flipped, a category that got a new prefix: all of these turn a working site into a working site with a large hole in it. The tell is the timing, so check the graph shape rather than the total.

Googlebot is 404ing on a URL that loads for you. Rare, and the most interesting case when it happens. It means Googlebot is seeing something you are not: a geo rule, a bot rule at the CDN, a rate limit that fires under crawl load, or an authentication redirect. Use the live test in the URL inspection tool to fetch the page as Google rather than trusting your own browser, because your browser has cookies and a US residential IP and Googlebot has neither.

404 or 410: which should you return?

Both mean gone. The difference is confidence. A 404 says "not found," which leaves open the possibility that it will be found later. A 410 says "gone," which asserts the removal is deliberate and permanent.

Google's crawl budget guide names them together, and in practice Google treats 410 as the slightly stronger signal, retiring the URL a little faster. The difference is measured in crawls, not in rankings, so it is not worth engineering a system to serve 410s if your framework returns 404 by default. Where it does pay off is bulk removal: if you are retiring 50,000 URLs deliberately, serving 410 for that specific set tells Google you meant it, and gets them out of the crawl queue sooner.

What you should not do in either case is block the URLs in robots.txt to stop Google requesting them. That prevents Google from ever seeing the 404 or the 410, which means the URL never gets the signal that retires it. Google says as much in the crawl budget guide, and the same trap catches people trying to remove pages from search results entirely, which is a separate job with its own correct sequence covered in removing a URL from Google.

How do I fix "Not found (404)" errors in Search Console?

Work the list in this order. Most of it is triage, not repair.

1. Export the URLs. Open the status in the Page indexing report and export. Note Google's caveat here: "the list of example URLs in the report is limited to 1,000 items, and isn't guaranteed to show all URLs in a given status, even when less than 1,000 items." On a large site you are looking at a sample, not a census.
2. Cross-check against your sitemap. Any overlap is a real bug and goes to the top of the list.
3. Cross-check against your internal links. Anything reachable from your own templates is next.
4. Check what the rest earned. Pull historical performance for the dead URLs. Ones with real click history deserve a redirect to a genuinely equivalent page. Ones with none deserve the 404 they are getting.
5. Leave the remainder alone. Malformed URLs, ancient parameters, scraper inventions and typos from other sites are supposed to 404. Redirecting them to your homepage converts a clean 404 into a soft 404, which Google explicitly asks you to eliminate.
6. Validate only if you fixed something structural. Google's validation runs against every instance, and "if you missed a fix, validation will stop when Google finds a single remaining instance of that issue." Starting validation on a status that contains thousands of legitimately dead URLs will never complete.

Should I redirect 404 pages to the homepage?

No. It is the most common piece of bad advice in this area and it makes things worse in two directions. Google generally treats a redirect to an irrelevant page as a soft 404, so the signals you hoped to preserve are lost anyway, and now the URL keeps getting crawled instead of being retired. On the visitor side, someone who clicked a specific search result and landed on your front page with no explanation is more lost than someone who got an honest 404 page with a search box on it.

Redirect when there is a genuine one-to-one replacement. Serve 404 or 410 when there is not. A good 404 page with site search and a few relevant links does more for a confused visitor than any redirect rule.

Why does Search Console show 404s for URLs that never existed?

Because Google crawls what it finds, and what it finds is not limited to what you published. URLs get invented constantly: a CMS that once emitted a broken relative path, a badly written link on a forum, a scraper that mangled your query strings, an old app that appended tracking parameters, a competitor's site with a typo in your domain. Google requests all of them, gets a 404, and files it.

This is why the count on an established domain never reaches zero and should not. Google's definition already told you these are URLs it discovered "without any explicit request or sitemap." A permanently non-zero number in this status is what a site with history looks like.

What about "Server error (5xx)"?

Worth mentioning because it sits next to 404 in the same report and is the one that genuinely matters. Google's definition is one line: "Your server returned a 500-level error when the page was requested." Unlike a 404, this is never intentional and never healthy. It means Googlebot arrived and your application failed.

The dangerous thing about 5xx in this report is the delay. Search Console data lags by days, so by the time a spike appears you may be looking at an outage that already cost you a week of crawling. If a page returns 5xx consistently, Google will eventually drop it from the index, and re-earning that position takes far longer than the outage did. A 404 count you can review monthly. A 5xx count you want to know about the same hour.

The short version

"Not found (404)" is a report, not an error list. Google's own guidance recommends returning 404 or 410 for permanently removed pages, and warns that the tidier-looking alternatives, blocking the URL or serving a friendly 200 page, both cost you more crawl than the status you were trying to avoid. Check the overlap with your sitemap, check your internal links, check which dead URLs actually earned traffic, and leave the rest to decay the way the web is supposed to.

If you want to see which of your URLs are currently indexed, which fell out, and which are 404ing without you knowing, the console at the top of this page checks that across a whole site rather than one URL at a time. The related read on soft 404s covers the status that actually does need fixing, and crawl budget explains why Google cares about dead URLs at all.