When a Search Console "Not found (404)" validation keeps failing, the cause is almost always one of five things: the report includes junk URLs that should return 404 (robots.txt patterns crawled as literal paths, /wp-admin/ and other bot probes, old spam URLs), you still link to a dead URL from your own pages or sitemap, a real legacy page was removed without a redirect to its true replacement, redirects were added to the home page instead of to an equivalent page, or Validate fix was clicked before every sample URL was actually fixed. The fix is to read the example URLs before you click anything, 301 only the real legacy pages that have a true equivalent, remove your own links to the rest, and leave the junk returning 404 or 410. Google says 404s for URLs that should not exist do not hurt indexing or ranking, so a validation that stays failed on junk URLs is not a problem to solve.
A 404 is the HTTP status code that tells a crawler a URL does not exist. A 410 (Gone) says the same thing more explicitly, and Google treats the two the same way. In Search Console, Googlebot's 404 responses show up in the Page indexing report (Indexing, then Pages) under "Why pages aren't indexed" as the reason Not found (404). Validation is the Search Console flow you start with the Validate fix button on that reason's detail page: Google rechecks the affected URLs and reports whether the issue is gone.
We ran into this on one of our own sites. The 404 validation failed, we fixed the URLs we thought mattered, started it again, and it failed again. When we finally read the example list line by line, most of it was URLs that should never have resolved in the first place.
Why does Search Console 404 validation fail?
Validation fails when Google rechecks URLs in the issue and finds the 404 still present. Per Search Console Help, when you click Validate fix, Search Console immediately checks a few pages, and if the issue is still present on those pages, validation ends without changing the issue state. If the sample passes, it works through the known affected URLs, and if the issue is still present, the state changes to Failed. Google describes Failed as a certain threshold of pages still containing the issue and does not publish the threshold. Every junk URL that correctly returns 404 is, from the validator's point of view, an unfixed instance.
The five causes we find most often.
- Junk URLs that should 404: paths built from robots.txt patterns such as a literal /* or a path with a $ on the end, /wp-admin/ and /wp-login.php probes on a site that never ran WordPress, and old spam URLs that someone else linked to
- Your own links still point at dead URLs: an internal link, a navigation item or a sitemap entry keeps sending Googlebot to a URL that returns 404, which is the kind of 404 Google says you should fix
- Real legacy pages removed without a redirect: a page that earned links or traffic was deleted or moved during a redesign or platform change, and the old URL now returns 404 instead of pointing at its replacement
- Redirects to the home page: many dead URLs were sent to the home page in one rule, which Google says can be treated as a soft 404, so the issue moves to a different row instead of going away
- Validation started too early: the fix was deployed to some URLs, or the cache was still serving the old response, and the immediate sample check found the issue still present
How do you find out what is actually in the 404 report?
Open the Not found (404) row and read the example URLs before you click Validate fix. The example table is limited to 1,000 rows and does not necessarily show every affected URL, so export it and sort it. Three tools, in this order:
The Page indexing report. In Search Console, go to Indexing, then Pages, scroll to "Why pages aren't indexed", and click Not found (404). Export the examples. Group them by pattern: robots.txt fragments, CMS probe paths, spam slugs, and URLs that look like real old pages.
URL Inspection. Paste any URL you are unsure about into the inspection bar at the top of Search Console. The indexed result and the live test show what Googlebot gets and, under page indexing details, where Google found the URL when that is known: a sitemap or a referring page. A referring page on your own site is a link you need to fix.
Your server or edge logs and your redirect map. Confirm the live status code each URL returns today, and check the URL against your old sitemap or CMS export. If it was never a page on your site, it is junk. If it was a page with a clear successor, it needs a redirect.
Diagnose top to bottom.
This is the order we run. Each step sorts one class of URL so you stop guessing.
| Symptom | Likely cause | Fix |
|---|---|---|
| Validation ends right after you click it | The immediate sample check still found 404s | Read examples first; fix or accept them before validating |
| 404 URLs that look like robots.txt rules | Crawler requested pattern text as a literal path | Leave as 404; do not redirect or block |
| /wp-admin/ or /wp-login.php on a non-WordPress site | Bot probes found by Google | Leave as 404; nothing to fix |
| Old spam slugs you never published | Links from spam sites to made-up URLs | Leave as 404 or 410 |
| Old blog post or product URL in the list | Real page removed without a redirect | 301 to the true replacement page |
| Dead URL with a referring page on your site | Internal link or sitemap entry still points at it | Fix or remove the link and sitemap entry |
| 404s move to Soft 404 after your fix | Mass redirect to the home page | Redirect to equivalents only; let the rest 404 |
| Validation Failed again after a restart | Junk URLs still correctly return 404 | Stop revalidating; the report is not a to-do list |
Do 404 errors hurt your site in Google?
Google says 404 errors for URLs that should not exist do not harm your site's indexing or ranking. Its Search Console Help page on 404 errors says 404s for URLs that never existed on your site, including ones found through mistyped links, have no effect on the crawling or ranking of your site, and that you can safely ignore them when you are certain the URLs should not exist. The Page indexing report itself says to fix only 404s that you link to yourself or list in a sitemap.
A 404 on a page that used to rank is a different story. That page drops out of the index and whatever links pointed at it now land on nothing. The 404 is not a penalty on the rest of the site, but you lose what that page earned. That is the case for a redirect, and it is the same mapping work we describe in our website migration checklist.
When should you use a 301, a 404 or a 410?
Use a 301 only when a page has a true equivalent; otherwise return 404 or 410, which Google treats the same. Google's HTTP status documentation says the indexing pipeline removes a previously indexed URL that returns 404 or 410, does not process newly found 404 URLs, and gradually lowers crawl frequency for them. It also says 4xx codes other than 429 have no effect on crawl rate. A 301 or 308 is a strong signal that the target should be processed instead.
| Situation | Status | Why |
|---|---|---|
| Page moved or merged into a page that covers the same thing | 301 (or 308) | Strong signal to process the target; keeps users and links on the right content |
| Page removed with no replacement | 404 or 410 | Google drops it from the index; Google treats 410 like 404 |
| URL never existed (probes, robots.txt patterns, spam) | 404 or 410 | No effect on crawling or ranking per Google |
| Error page that returns 200 | Change to 404 or 410 | A 200 not found page is a soft 404 |
| Many dead URLs, one unrelated page | Do not redirect | Google may treat it as a soft 404 |
Google's site move guidance says to keep redirects for as long as possible, generally at least 1 year. It also allows one exception to the one-to-one rule: if you consolidated several old pages into one new page, you can redirect all of them to that consolidated page.
What is a soft 404?
A soft 404 is a URL that tells the visitor the page does not exist but returns a 200 success code. Google detects these from the page content and excludes them from search results. Google's fix depends on the case: return 404 or 410 if the content is gone, use a 301 to a real replacement if it moved, and if the content still exists, use URL Inspection to check whether resources blocked by robots.txt or slow responses made the page look empty to Googlebot. Soft 404 is its own reason in the Page indexing report, so a bad redirect cleanup often just moves URLs from one row to another.
How long does Search Console validation take?
Google says validation typically takes up to about two weeks, but in some cases can take much longer. As of October 2026, Search Console Help describes these states:
- Not started: validation was never requested for this issue
- Started: validation has begun and no remaining instances have been found yet
- Looking good: every instance checked so far is fixed
- Passed: all known instances are gone
- Failed: a certain threshold of pages still contain the issue
- Other: Google could not reach the URL or the item is no longer found, which Search Console treats like Passed
Only URLs with known instances of the issue are queued for recrawl, not the whole site. When validation fails, the issue details let you see which URL caused the failure, and you restart with Start new validation, which rechecks URLs marked Pending or Failed. Restarting does nothing useful if the failing URLs are junk that should return 404.
What is normal and what is a red flag?
A Not found (404) row that never clears is normal for any site that gets crawled. Google says Googlebot will probably keep trying a 404 URL for some period of time, so junk URLs can stay listed long after you stop caring about them. In our own reports, the robots.txt pattern URLs and probe paths reappeared after we had already confirmed they were junk. That is what we observed, not a documented rule, but it matches Google's description of how 404s are recrawled.
Red flags are narrower: a 404 on a URL in your current sitemap, a 404 with a referring page on your own site, a 404 on a page that had impressions in the Performance report, a jump in 404s right after a deploy or migration, and any rise in the Soft 404 row after a redirect change. If your pages are indexed but still get almost no impressions, the 404 report is not the place to look; see pages indexed but no Google impressions. If new pages are not getting indexed at all, start with new site pages not indexed.
If the report looks empty instead of noisy, check the property setup first with Search Console property showing no data. After a platform change, our HubSpot CMS migration SEO guide covers building the redirect map that keeps real legacy URLs out of this report.
Why did my Search Console 404 validation fail?
Google rechecked the URLs in the issue and found 404s still present. Often those are URLs that should 404: robots.txt patterns crawled as paths, /wp-admin/ probes, or old spam URLs. Read the example URLs, fix only your own links and real legacy pages, and accept that junk URLs will keep the issue open.
Should I fix every 404 in Google Search Console?
No. Google says to fix 404s you link to yourself or list in a sitemap, and that 404s for URLs that should not exist do not hurt indexing or ranking. Redirect real old pages that have a true replacement. Leave the rest as 404 or 410.
Do 404 errors hurt SEO?
Not for the site as a whole. Google says 404s do not harm your site's indexing or ranking. The only loss is the removed page itself, which drops out of the index along with whatever its links were worth, which is why real legacy pages with an equivalent get a 301.
Is a 410 better than a 404 for Google?
Google's documentation says it treats 404 and 410 the same: a previously indexed URL is removed from the index and crawl frequency for it gradually decreases. Use whichever your server makes easy.
Should I redirect all 404 pages to the home page?
No. Google says redirecting many old URLs to one irrelevant page such as the home page can be treated as a soft 404. Redirect only to a page that replaces the old content.
How long does Search Console validation take?
Google says validation typically takes up to about two weeks and in some cases much longer. The states are Not started, Started, Looking good, Passed, Failed and Other.