Search Console Page indexing: Why pages aren't indexed

Not found (404) in Search Console: fix it or leave it?

Which "Not found (404)" URLs Google says are fine to leave, which to fix, and how: restore, redirect, or remove the links that keep pointing at them.

Googlebot requested a URL and your server said it does not exist. For pages removed on purpose that is correct, and Google says 404s are not necessarily a problem. Fix the ones that matter: restore pages that should exist, 301 redirect pages that moved, and correct internal links and sitemap entries that point at dead URLs.

What "Not found (404)" means

Google: "This page returned a 404 error when requested." Google found the URL through a link from another page, or because the page existed before and was deleted. It keeps trying a known 404 URL for a while, less and less often, and the report lists only URLs that returned 404 in the past month.

Is it a problem?

Depends on the URL

Often fine. Google: "404 responses are not necessarily a problem, if the page has been removed without any replacement." Its advice is to fix only the 404s you link to yourself or list in a sitemap. A sudden jump after a release or a migration is a different matter.

Causes, most likely first

  1. A page deleted or unpublished on purpose, with nothing to replace it. No action needed.
  2. A migration or URL change without a redirect from the old address.
  3. Internal links, navigation or a sitemap still pointing at a URL that was removed or renamed.
  4. A typo or malformed link on another site, which you cannot correct on their side.
  5. A page that exists for visitors but answers crawlers with 404, for example a route that only resolves in the browser.

How to confirm it

  1. Inspect a sample URL from the report. URL Inspection shows the sitemap or referring page Google found it through, when that is known.
  2. Run the redirect chain checker on the URL to see the status and any hops before the 404.
  3. Run the bulk checker on up to 20 affected URLs at once to separate true 404s from pages that load normally.

Redirect chain checkerBulk indexability checker

How to fix it

  1. Moved page: add a 301 redirect from the old URL to the new one.
  2. Page that should exist: restore it, or fix the route that returns 404.
  3. Removed page with no replacement: leave the 404 or return 410, and take it out of your sitemap and internal links.
  4. Do not redirect every 404 to the home page. Google says redirecting many old URLs to one irrelevant page "might be treated as a soft 404 error".
  5. When the URLs you care about return 200 or redirect, click Validate fix.

How long recovery takes

Restored or redirected URLs are picked up on the next crawl, which can take "anywhere from a few days to a few weeks". For deliberate 404s there is nothing to recover: Google crawls them less and less often, and the report keeps only URLs that returned 404 in the past month.

After a fix, Validate fix on the issue asks Google to recheck the affected URLs. Google says validation "typically takes up to about two weeks, but in some cases can take much longer". Without it, the count still updates as Google recrawls, and an issue leaves the table once 90 days pass with no instance.

Would monitoring have caught it?

A monitored URL that starts returning 404 after returning 2xx or 3xx is a critical change. It is re-checked after 60 seconds and alerts if the status holds, so a deleted page or a broken route is reported after the next check rather than when this report updates.

stillindexed checks each monitored URL every 30 minutes on Starter and every 15 minutes on Agency, so the change is found on the next check and confirmed before it alerts, rather than waiting for this report to update.

See what monitoring covers

A migration or redesign losing pages from search, platform by platform

Further reading

Sources

Every claim above about how Google behaves is from Google's own documentation, read on 2026-10-06. If Google has changed a page since, Google's page wins and we would like to know.