Not found (404) in the Page indexing report frightens people more than any other line in Search Console, and it is the one that most often needs no action at all. I have opened client accounts with four thousand 404s in the report and told the client to change nothing. I have also opened accounts with eleven 404s and spent a day on them. The count is not the signal.
Here is how to tell which one you have.
What does Not found (404) mean in Search Console?
Google’s Page indexing report documentation describes the status precisely, and two sentences in it do most of the work:
Googlebot will probably continue to try this URL for some period of time; there is no way to tell Googlebot to permanently forget a URL, although it will crawl it less and less often.
404 responses are not necessarily a problem, if the page has been removed without any replacement. If your page has moved, use a 301 redirect to the new location.
So the status is a report of a fact, not a complaint. Google asked for a URL, your server said that URL does not exist, and Google wrote it down. The report shows URLs that have returned 404 in the past month, and Google keeps retrying known URLs for a while “in case it’s a temporary error” before backing off.
The part people miss is where the URLs come from. Google’s own note is that it “discovered this URL without any explicit request or sitemap”, which covers the whole zoo: a typo in someone else’s link to you, a URL your old site used in 2019, a broken relative path in a template, a scraper inventing paths. None of those are your ranking problem.
The one thing 404s in the report definitely are not is a penalty. That has been Google’s position since a 2011 Search Central post that has never been retracted:
404 errors are a perfectly normal part of the web
and, in the same post, “If some URLs on your site 404, this fact alone does not hurt you or count against you in Google’s search results.”
When should I fix a 404 and when should I leave it?
Sort every 404 into one of three buckets. This is the whole method, and it takes about twenty minutes on a normal site.
Source: Google Search Central, "Do 404s hurt my site?", and the Page indexing report documentation.
Bucket one, moved content: 301 to the specific replacement. Not the category page, not the home page, the actual replacement. If there is no specific replacement, it is not bucket one.
Bucket two, deleted content: let it 404, or return 410 Gone if you want to be explicit. Google’s line on that is short: “Currently Google treats 410 (Gone) the same as 404 (Not found).” The difference is for your own logs and for other crawlers, not for Google’s speed.
Bucket three, URLs that never existed: Google’s advice on bogus URLs is that “you can safely ignore them.” No redirect, no page, nothing. Every hour spent here is wasted.
The one thing that turns a harmless 404 into a real problem is doing what feels helpful. From the same 2011 post, redirecting “any unknown URLs to their home page instead of returning 404 errors” can “have negative effects on our understanding and indexing of your site”. Which brings us to the status people confuse this one with.
How is a soft 404 different?
A soft 404 is a page that tells a human it is missing while telling a crawler it is fine. Google’s description in the report:
The page request returns what we think is a soft 404 response. This means that it returns a user-friendly ‘not found’ message but not a 404 HTTP response code. We recommend returning a 404 response code for truly ‘not found’ pages.
The distinction is the status code, not the content. A real 404 is a 404 header. A soft 404 is a 200 header with an apology in the body, or a redirect to the home page, or an empty category page that renders a shell with no products.
That last one is the version I run into most on client work. An ecommerce site retires a collection, the collection URL keeps returning 200 with a header, a footer, and zero products, and Google files it as a soft 404. The store owner sees a growing number in the report and assumes an indexing bug. It is not a bug; it is Google reading an empty page correctly. The same pattern shows up on paginated archives that run past their last page and on filtered views with no matches, and it is one of the reasons a store can end up with seven country storefronts and empty indexes. If that is the status you actually have, soft 404 in Search Console works through the three shapes it takes and the fix order for each.
To confirm one, run a live test in the URL Inspection tool and use View tested page to look at the screenshot and the rendered HTML. If the page looks empty or apologetic and the response was 200, you have found it. Either restore real content or return a real 404.
How long until 404s disappear from Google?
Two clocks, and they are different.
Removal from the index is quick in principle. Google’s documentation on HTTP status codes says URLs that are already indexed and return a 4xx status code are removed from the index, and that crawling frequency then decreases gradually. So the page stops being a search result well before it stops being crawled. That is the opposite deal from a server error (5xx), where Google preserves the indexed URL through the outage and slows crawling instead.
Removal from the report is slower and less interesting. The report shows URLs that 404ed in the past month, and Google keeps retrying known URLs on a decaying schedule, so a URL you deleted in June can still appear in August. That is expected, and chasing the count to zero is not a goal worth having.
If you need something gone from results today rather than at crawl speed, the Removals tool hides a URL from Google Search for about six months. It is a stopgap, not a fix: at the end of six months the URL comes back unless the underlying page is actually gone or noindexed. If the goal is permanent removal, the choice between blocking crawling and blocking indexing matters more than the tool, and that is the distinction I laid out in noindex vs robots.txt.
What I actually do on a client account
Export the 404 list, then sort it by whether the URL has inbound links or ever had impressions. Those two columns turn four thousand rows into a list of maybe fifteen that deserve a decision, and the rest get left alone with a note in the report explaining why. Nothing else in Search Console rewards triage this well, because nothing else in Search Console produces this much noise that is genuinely safe to ignore.
The one alarm worth setting: a sudden 404 spike on URLs that used to have traffic. That is not the normal background of a live site, that is a deploy that broke a route or a CMS that changed its slug rules, and it needs an answer today rather than in the next audit. The background hum of invented URLs never needs an answer at all.
The exception is a store clearing dead stock, where a 404 spike is deliberate and healthy. There the question is not whether to worry about it but whether each URL should have been a 404 in the first place, which is the decision behind out of stock and discontinued product pages.
Sources
- Google Search Console Help, Page Indexing report, Not found (404) and Soft 404 status descriptions
- Google Search Central, Do 404s hurt my site?, 2 May 2011
- Google Search Central, How HTTP status codes affect Google’s crawlers
- Google Search Console Help, Removals tool
- Google Search Console Help, URL Inspection tool