Not found (404) in Google Search Console means Googlebot requested a URL on your site and the server answered with an HTTP 404 status: there is no page at that address. It is a reason a page is not indexed, with no penalty attached. Google found the address somewhere (a sitemap, an internal link, an old backlink, or its memory of a page that once existed) and confirmed there is nothing to index. Most 404s are harmless and need no fix. The ones that matter are URLs that used to rank, earn links or convert, and those get a 301 redirect to their closest live equivalent.
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.
Where you see it in Search Console
The status lives in Indexing > Pages, in the Why pages aren’t indexed table. Click the Not found (404) row for the list of affected URLs and an export. Google’s documentation is plain about it: a 404 is fine when the page is meant to be gone, Googlebot will keep retrying a known URL for a while and less often over time, and a page that moved should get a 301.
You may meet the same problem under other names:
- Submitted URL not found (404) was the label in the old Coverage report for a 404 URL that your sitemap listed. The current Pages report folds those into Not found (404). Switch the filter at the top from All known pages to All submitted pages to see only the 404s your sitemap is still sending Google to.
- Page fetch: Failed: Not found (404) is what URL Inspection shows when you inspect one of these URLs. Inspection also shows how Google discovered the URL under Referring page and Sitemaps, which tells you where the dead link lives.
- Soft 404 is a separate row for pages that look empty or missing and return a 200 status. It has its own fix (see below).
Third-party crawlers such as Moz, Ahrefs and Semrush report 404s the same way: they found a link to a removed page and requested it. The triage below works for their reports too.
Why 404s show up
A 404 is the server’s honest answer that no resource sits at this address, which is correct behavior. Problems start when the wrong URLs return it. The source of the 404 tells you the fix.
- Deleted pages: a removed product, an old blog post or a campaign landing page with no redirect.
- Internal links: a menu item, footer link or in-content link pointing at a path that no longer exists. These are your own bugs and the highest priority.
- Old XML sitemaps: a stale sitemap still lists dead URLs, so Google keeps requesting them. Clean the XML sitemap and the report shrinks on its own.
- External backlinks: another site links to a page you removed. The 404 throws away the signals that link would pass.
- Mistyped or malformed URLs: bots, scrapers and broken templates request paths that never existed. This is the noise tier.
- Migration debris: a replatform or redesign changed the URL structure and the redirect map missed cases. Common, costly and worth a dedicated pass.
Because Google keeps recrawling known 404s for months, the report rarely reaches zero, and chasing zero wastes time. On large sites the right action for most 404s is to do nothing; the work is finding the few that cost traffic, links or crawl efficiency.
404 vs soft 404 vs 410 vs 301
The most expensive mistake here is the soft 404: a page that looks missing (an empty results page, a “product unavailable” stub, a thin error message) and returns HTTP 200. Google reports these in their own row because the status code says one thing and the page says another. See what is a soft 404 error for the full diagnosis.
| Signal | HTTP status | What it tells Google | When to use it |
|---|---|---|---|
| 404 Not Found | 404 | Nothing at this address | Default for URLs that do not exist; fine to leave |
| 410 Gone | 410 | Removed on purpose, permanently | Deliberate deletions you never want back |
| Soft 404 | 200 (wrong) | “Found”, with empty or error content | Never on purpose; always a bug to fix |
| 301 Redirect | 301 | Moved permanently to a new URL | Content that moved or has a clear successor |
Google treats 404 and 410 almost the same way. A 410 may drop out of the index a little sooner, and its main value is clarity about intent. For anything that moved, use a 301.
How to fix 404 errors in Search Console
Export the list and sort it before you fix anything. The decision for each URL is one of four moves, and the data you need to choose lives outside the report.
- Pull the list from the Not found (404) row, and spot-check URLs in URL Inspection.
- Add traffic and links. Match the exported URLs against your old top pages (Search Console performance history, analytics) and a backlink tool. A 404 with no past traffic and no referring domains is noise.
- Find the referring page. URL Inspection shows where Google discovered each URL. An internal link is a bug you control. A backlink is equity leaking.
- Crawl your own site. Screaming Frog or Sitebulb finds internal links and sitemap entries pointing at 404s much faster than the Search Console interface.
Then apply the decision tree:
- The page should still exist: restore it at the exact URL.
- The content moved or has a clear successor: 301 redirect to the most relevant live page.
- Deliberately and permanently gone, with no equity: return a 410, or leave the 404.
- Bogus, mistyped or worthless: leave it as a 404 and move on.
Avoid redirecting everything to the homepage. Google often treats irrelevant catch-all redirects as soft 404s, so you lose the page anyway and the visitor lands somewhere useless. Redirect to a genuine equivalent or leave the 404.
When the fixes are live, open the Not found (404) row and click Validate fix. Google rechecks the listed URLs over the following days and weeks; URLs that still return 404 on purpose stay listed, which is fine.
Fixing the 404s that matter
Work top-down by traffic and link value.
Restore, redirect or remove. Reinstate high-value pages with their original content and metadata. For moved content, set one clean 301 straight to the final destination, with no redirect chains or loops. Leave dead weight as a 404 or return a 410.
Implement redirects at the server. Server config or the edge survives deploys; a redirect plugin can be switched off or overwritten without anyone noticing.
# 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. Confirm the status code is the one 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. Stale sitemaps are the most common reason 404s come back after a fix.
Reclaim external links. For a 404 with valuable backlinks, a 301 to the closest live page passes those signals on. For the most valuable referring sites, an email asking them to update the link is worth sending, the same skill as broken link building pointed at your own site.
Preventing 404s from coming back
404s return when the root cause survives the fix: a deploy overwrote a redirect, an old sitemap is still crawled, a CDN serves a cached 404, or an external link keeps feeding the URL to Google. Build the guardrails once.
- Keep redirects in version control where every change is reviewed, and re-check them after each deploy.
- Keep a redirect map for every migration. A pre-launch map plus post-launch checks prevents the largest 404 spike a site can have. Our website migration SEO checklist walks through it step by step.
- Purge the CDN after fixes, so Googlebot sees the updated response.
- Ship a useful custom 404 page with a search box and links to key sections. It salvages the visit, and it must still return a 404 status, or you have built a soft 404.
- Watch crawl efficiency. On large sites, thousands of recurring 404s use crawl budget that should go to pages you want indexed. Tight internal linking and clean sitemaps fix it, both downstream of solid SEO site structure.
404s and AI search
AI answers cite pages they can retrieve, and Google’s AI Overviews draw only on indexed pages. A URL that returns 404 cannot be quoted or linked in an AI Overview, a ChatGPT answer or Copilot. If a page that used to be cited starts returning 404, you lose the ranking and the citation together. The discipline stays the same: correct status codes, redirects for what moved, clean removals for what is dead.
When 404s become a business problem
A few hundred 404s from old junk URLs with no clicks and no backlinks cost nothing. Leave them.
They cost money after a relaunch. The Not found (404) count jumps the week a new site goes live, the URLs in the export used to earn clicks or links, and traffic drops in the same week. Usually the redirect map was missing or incomplete, the trailing-slash convention changed, or everything was sent to the homepage. Every week those URLs stay broken, Google has more time to drop the rankings they held.
That is migration work. Our website migration service gives every URL with traffic, backlinks or conversions its old address or exactly one 301, checks the redirects on launch day and watches the 404s for 90 days. On the Prawomat rebuild, redirects were checked at launch and the 404 log read for weeks; the release as a whole, which also rewrote content and pruned URLs, took daily Google clicks up 2.9x within 19 days.
Frequently Asked Questions
Are 404 errors bad for SEO?
Most 404s are harmless: Google expects addresses that do not exist to return a 404. They hurt when the wrong URLs return one, such as pages that used to rank, earn backlinks or convert. A 404 on a valuable, linked page loses that traffic and those signals; a 404 on a mistyped URL costs nothing.
How do I fix “Not found (404)” in Google Search Console?
Export the URLs from the Not found (404) row, keep the ones with past traffic or backlinks, and 301 each of those to its closest live equivalent (or restore the page). Remove internal links and sitemap entries that point at 404s. Leave the rest. Then click Validate fix and let Google recheck the URLs.
Should I redirect every 404 to my homepage?
No. Google often treats irrelevant catch-all redirects to the homepage as soft 404s, so you lose the page anyway and give visitors a worse experience. Redirect a dead URL only to a genuinely equivalent live page. If there is no relevant destination, leave the 404 or return a 410.
What is the difference between a 404 and a 410?
A 404 says nothing exists at the address, and Google keeps rechecking it for a while in case the page returns. A 410 says the page was removed on purpose. Google handles them almost identically, and a 410 may leave the index slightly sooner. Use a 410 for deliberate, permanent deletions and a 301 for anything that moved.
Why do my fixed 404s keep coming back in Search Console?
Usually the root cause survived: a stale XML sitemap still lists the URL, a deploy overwrote the redirect, a CDN serves a cached 404, or an external link keeps feeding it to Google. Check redirects after every deploy, purge the CDN and clean your sitemaps.
How long does it take 404s to clear from Search Console?
There is no fixed timeline. Google recrawls known 404s on its own schedule, often over weeks or months, and may keep listing a URL long after you dealt with it. Set the correct status code or redirect, resubmit a clean sitemap and start a validation from the report, then watch whether the trend falls.