A Not found (404) report in Google Search Console means Googlebot requested a URL on your site and the server answered with an HTTP 404 status — the page isn’t there. It is an exclusion reason, not a penalty: Google found the address (in a sitemap, an internal link, an old backlink, or its own memory of a once-live page) and confirmed there’s nothing to index. Most 404s are harmless; the dangerous ones are the URLs that used to rank, used to earn links, or used to convert.
Not Found (404)
Not found (404) is a Google Search Console status indicating that a crawled URL returned an HTTP 404 response, so the page cannot be indexed because the server reports it doesn’t exist.
The instinct to “fix all 404s” is where most teams waste a week. We run technical audits on sites with tens of thousands of 404s where the correct action for 95% of them is do nothing. The work isn’t clearing the report to zero — it’s separating the 404s that cost you traffic, links, or crawl efficiency from the noise.
Why 404s Show Up in Search Console
A 404 is the server’s honest answer: “no resource at this address.” That honesty is correct behavior. Problems start when the wrong URLs return it. The report fills up from a handful of sources, and the source tells you the fix.
- Deleted pages — you removed a product, an old blog post, or a campaign landing page and nothing redirects the old URL.
- Internal links — a navigation item, footer link, or in-content link points to a path that no longer exists. These are your fault and your highest priority.
- Old XML sitemaps — a stale sitemap still lists dead URLs, so Google keeps requesting them. Clean your XML sitemaps and the report shrinks on its own.
- External backlinks — another site linked to a page you’ve since killed. The link still passes signals; the 404 throws them away.
- Mistyped or malformed URLs — bots, scrapers, and bad templates request paths that never existed. This is the noise tier.
- Migration debris — replatforming or a redesign changed your URL structure and the redirect map missed cases. Common, costly, and worth a dedicated pass.
Google will keep recrawling a known 404 for a long time — sometimes months — because it doesn’t trust that “gone” is permanent. That persistence is exactly why the report rarely hits zero, and why chasing zero is a vanity metric.
404 vs Soft 404 vs 410: Know the Difference
The most expensive mistake here isn’t a 404 — it’s a soft 404, where a page looks missing (an empty results page, a “product unavailable” stub, a thin error message) but returns HTTP 200. Google flags these separately and trusts your status codes less because of them. Get the response code right and half your “indexing weirdness” disappears. See what is a soft 404 error for the full diagnostic.
| Signal | HTTP status | What it tells Google | When to use it |
|---|---|---|---|
| 404 Not Found | 404 | Page doesn’t exist; status uncertain | Default for non-existent URLs; fine to leave |
| 410 Gone | 410 | Permanently removed, don’t come back | Intentional deletions you want deindexed faster |
| Soft 404 | 200 (wrong) | “Found” but empty/error content | Never on purpose — always a bug to fix |
| 301 Redirect | 301 | Moved permanently to a new URL | Content relocated; preserve link equity |
A 410 doesn’t deindex faster in any dramatic way, but it removes ambiguity. If you’ve truly killed a section and never want it back, 410 is the cleaner signal. For anything that moved, a 301 is the only answer.
How to Triage 404s in Google Search Console
Open Indexing → Pages → Not found (404) in Search Console and export the list. Don’t fix anything yet — sort first. The triage decision is almost always one of four moves, and the data you need to choose lives outside the report.
- Pull the full list from the Pages report and the URL Inspection tool for spot checks.
- Layer in traffic and links. Cross-reference exported 404 URLs against your old top pages (Search Console performance history, analytics) and a backlink tool. A 404 with zero historic traffic and zero referring domains is noise.
- Find the “Referring page.” Search Console shows where Google discovered each URL. If it’s an internal link, that’s a bug you control. If it’s a backlink, that’s link equity leaking.
- Crawl your own site. Screaming Frog or Sitebulb will surface internal links and sitemap entries pointing at 404s far faster than the GSC UI. This is where you catch the self-inflicted ones.
Then apply the decision tree:
- Page should still exist → restore it at the exact URL.
- Content moved or has a clear successor → 301 redirect to the most relevant live page (not blanket-to-homepage — that’s a soft-404 trap).
- Intentionally and permanently gone, no equity → return 410, or leave the 404.
- Bogus / mistyped / zero value → leave it 404 and move on.
Redirecting everything to the homepage feels tidy and is actively harmful: Google often treats irrelevant catch-all redirects as soft 404s anyway, so you get the deindexing and a worse user experience. Map redirects to genuine equivalents or don’t bother.
Fixing the 404s That Actually Matter
Once triaged, the execution is mechanical. Work top-down by traffic and link value.
Restore vs redirect vs remove. Reinstate high-value pages with their original content and metadata. For relocated content, set a single clean 301 — no redirect chains, no loops, straight to the final destination. For dead weight, leave it or 410 it.
Implement server-side redirects. Keep them at the edge or in server config, not buried in a plugin that a deploy can silently overwrite.
# Nginx — single 301 to the relevant live page
location = /old-product-page/ {
return 301 https://www.example.com/new-product-page/;
}# Apache .htaccess equivalent
Redirect 301 /old-product-page/ https://www.example.com/new-product-page/Verify with curl, not vibes. Confirm the status code is what you intended before you call it done.
curl -sIL https://www.example.com/old-product-page/ | grep -i "^HTTP"
# Want: HTTP/2 301 → then HTTP/2 200 at the destination (one hop, no chain)Fix internal links and sitemaps. Update or remove every internal link pointing at a 404, regenerate the XML sitemap so it lists only live, canonical URLs, and resubmit it. This is the single highest-leverage cleanup — see submit sitemap to search engines. Stale sitemaps are the most common reason 404s reappear after you “fixed” them.
Reclaim external links. For 404s with valuable backlinks, a 301 recovers most of the equity automatically. For the highest-value referring domains, it’s worth an outreach email asking them to point at the live URL — the same muscle as broken link building, turned inward.
Preventing 404s From Reappearing
404s come back when the root cause survives the fix. The pattern is always one of these: a redirect got overwritten by a deploy, an old sitemap is still being crawled, a CDN cache is serving the dead response, or an external link keeps re-feeding the URL to Google. Build the guardrails once.
- Keep redirects in version control, not in a CMS UI a colleague can clear. Re-verify them after every deploy.
- Maintain a redirect map for migrations. A pre-launch map plus post-launch curl verification prevents the worst 404 spike there is.
- Purge the CDN after fixes so Googlebot sees the updated response, not a cached 404.
- Add a useful custom 404 page — search box, links to key sections, recent posts. It won’t change the status code, but it salvages the visit. Just make sure it still returns 404, not 200, or you’ve manufactured a soft 404.
- Watch crawl efficiency. On large sites, thousands of recurring 404s quietly burn crawl budget that should be spent on pages you want indexed. Tight internal linking and clean sitemaps are the fix — both downstream of solid SEO site structure.
For migrations, replatforms, and large-scale URL cleanups where 404s become a six-figure traffic risk, this is exactly the kind of technical recovery our AI SEO services handle end to end.
How 404s Fit the AI-Search Era
In the AI Overviews and answer-engine era, the cost of a broken URL compounds. Generative results cite live, retrievable pages; a 404 isn’t just an excluded URL in Search Console — it’s a page that can’t be quoted, summarized, or surfaced in an AI answer. If a previously cited page 404s, you lose both the classic ranking and the citation. The discipline is the same as it’s always been — return correct status codes, redirect what moved, kill what’s dead cleanly — but the downside for getting it wrong is now broader than a blue link.
Frequently Asked Questions
Are 404 errors bad for SEO?
Most 404s are harmless and normal — Google expects non-existent URLs to return 404. They only hurt SEO when the wrong URLs return one: pages that used to rank, earn backlinks, or convert. A 404 on a valuable, linked page leaks equity and traffic; a 404 on a bogus or mistyped URL costs you nothing.
Should I redirect every 404 to my homepage?
No. Google often treats irrelevant catch-all redirects to the homepage as soft 404s, so you get the deindexing anyway plus a worse user experience. Redirect a dead URL only to a genuinely equivalent live page. If there’s no relevant destination, leave the 404 or return a 410 instead.
What’s the difference between a 404 and a 410?
A 404 means “not found, status uncertain” — Google keeps recrawling it for months in case it returns. A 410 means “gone, permanently” and signals you don’t expect the page back, which removes ambiguity. Use 410 for intentional, permanent deletions with no value; use a 301 for anything that actually moved.
Why do my fixed 404s keep coming back in Search Console?
Reappearing 404s almost always mean the root cause survived: a stale XML sitemap still lists the URL, a deploy overwrote the redirect, a CDN is serving a cached 404, or an external link keeps re-feeding it to Google. Verify redirects after every deploy, purge the CDN, and clean your sitemaps to stop the loop.
How long does it take 404s to clear from Search Console?
There’s no fixed timeline — Google recrawls known 404s on its own schedule, often over weeks to months, and may keep listing a URL long after you’ve fixed it. Implement the correct status code or redirect, resubmit a clean sitemap, and use URL Inspection to request validation; then monitor rather than chase the count to zero.