Search Console "Not Found (404)" Errors: Which to Fix and Which to Ignore

Open the Page indexing report in Google Search Console on almost any site that has been around for a while and you'll find a "Not found (404)" row, sometimes with hundreds or thousands of URLs. It looks like an emergency. Most of the time it isn't, but a few of those URLs probably do matter, and the trick is to work out which ones.

This guide explains what Google actually says about 404s, gives you a simple triage to sort the list into "fix", "redirect" and "leave alone", and shows how to stop the list from growing.

What Google says about 404s

It's worth starting from Google's own documentation rather than SEO folklore.

In the Search Console help for the Page indexing report, Google describes a "Not found (404)" URL as one that "returned a 404 error when requested," discovered "without any explicit request or sitemap," possibly "as a link from another page, or possibly the page existed before and was deleted." It then says plainly: "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." It also notes that Googlebot "will probably continue to try this URL for some period of time" and "will crawl it less and less often."

Google's developer documentation on HTTP status codes adds that all 4xx errors except 429 are treated the same way: the URL is removed from the index if it was indexed before, "newly encountered 404 pages aren't processed," and "the crawling frequency gradually decreases."

That gives you two practical conclusions:

1. A 404 is the correct response for a page that's genuinely gone. Returning one doesn't penalize your site.
2. A 404 on a URL that should work is a real problem. It's not a penalty either, but the page drops out of the index and any traffic or link value it had is lost.

So you're not trying to get the 404 count to zero. You're trying to find the 404s that shouldn't be 404s.

Step 1: Export the list

In Search Console, go to Indexing → Pages, click the Not found (404) row, and export the examples. Search Console shows a sample of affected URLs, not necessarily every one, so treat the export as a starting point rather than a full inventory.

Add two columns to the spreadsheet: Category and Action.

Step 2: Sort every URL into one of five buckets

Go through the list (filter by URL pattern to speed it up) and put each URL into one of these buckets.

Bucket A: Pages that moved and still have an equivalent

A product renamed from /blue-widget to /widgets/blue. A blog post whose slug changed. A service page merged into another service page.

Action: 301 redirect to the closest equivalent. This is exactly what Google's help recommends, and it's the most valuable fix on the list, because these URLs often had rankings, backlinks, or both.

Bucket B: Pages deleted on purpose with no replacement

A discontinued product with no successor. An event from 2019. A job ad that has been filled.

Action: leave it as a 404 (or a 410 if you want to signal "gone for good"). Don't redirect these to the homepage. Google tends to treat irrelevant redirects like that as soft 404s anyway, and users who land on your homepage instead of what they clicked get confused. If the deleted page had good backlinks and there's a genuinely related page, such as the category it belonged to, a redirect there is reasonable.

Bucket C: URLs that never existed

Typos in links on other sites, URLs with junk parameters, spam bots probing /wp-login.php on a site that isn't WordPress, paths with tracking garbage tacked on.

Action: ignore. You don't control other people's typos, and these URLs never had value. The exception is a typo'd URL that has a strong backlink pointing at it. A redirect to the intended page recovers that value.

Bucket D: URLs created by your own broken links

This is the bucket people miss. The URL is in Search Console because your own site links to it. Common causes:

• A link edited in one place but not in another (old menu item, footer, sidebar widget)
• A relative link missing its protocol: an editor types example.com/page instead of https://example.com/page, and the browser resolves it relative to the current page, so you get /about/example.com/page
• A template that builds URLs from data that's sometimes empty (/products/ + nothing)
• Links in old blog posts pointing at pages that have since moved

Action: fix the link at the source, and add a redirect if the URL has external value. A redirect alone isn't enough. If your own pages link to a 404, every visitor who clicks it hits a dead end, and internal links pass through a redirect hop for no reason. Find the page that contains the link and edit it.

Search Console's URL Inspection tool can sometimes show you where Google found a URL, but it doesn't reliably list every page that links to it. A crawler that records the source page for every broken link, the "found on" page, is the faster way to find these.

Bucket E: URLs that should work but don't

The URL is correct, the page should exist, and it returns 404 anyway. Typical causes are a deployment that dropped a route, a CMS page set to draft by mistake, a permalink flush that didn't run, or a server rule that's too broad.

Action: fix the page itself. This is a bug, not a content decision. If a Bucket E URL is a revenue page (pricing, checkout, contact, booking), it's the most urgent item on the whole list.

Step 3: Prioritize

With everything bucketed, work in this order:

1. Bucket E on important pages. Broken pages that should be working.
2. Bucket D. Your own links pointing at 404s, starting with sitewide elements (menus, footers), because one fix there repairs hundreds of instances.
3. Bucket A, ordered by value. If you can see which moved URLs had traffic (in analytics or Search Console's performance report) or backlinks (in any backlink tool), redirect those first.
4. Bucket C typos with strong backlinks.
5. Everything else in B and C: nothing to do.

On a typical site, steps 1 and 2 involve a fairly short list and do most of the good.

Step 4: Validate and wait

After fixing, you can use Validate fix on the Not found (404) row in Search Console. Expect it to take a while. Google rechecks on its own schedule, and the help docs say Googlebot keeps trying removed URLs "for some period of time." URLs you intentionally left as 404s will stay in the report for a while, and that's fine.

Don't judge your work by whether the 404 count goes down. Judge it by whether the URLs in buckets A, D and E now resolve correctly.

Why Search Console alone isn't enough

Search Console is a good lagging indicator, but it has gaps for this job:

• It's slow. URLs show up after Googlebot crawls them, which can be days or weeks after a link broke.
• It's a sample. The export won't necessarily include every affected URL.
• It only sees what Google crawls. It won't show broken links in pages Google skips, in noindexed sections, or links to external sites that have died. Your visitors still click those.
• It mixes good 404s with bad ones. You have to do the triage above every time.

A scheduled link crawler fills these gaps. It works from your side: it crawls your pages, checks every link it finds, and tells you which page each broken link sits on, usually within a day of the break. That turns Bucket D from detective work into a to-do list.

Stopping new 404s from building up

A few habits keep the report small:

• Redirect when you rename. Make "add a 301" part of the process for changing any published URL. Most CMSs have redirect plugins or settings.
• Scan after big changes. Migrations, redesigns, permalink changes and bulk deletions all need a crawl before and after.
• Paste full URLs. Train editors to paste links with https://, or use a CMS link picker for internal links.
• Monitor on a schedule. Weekly for most sites, daily for stores and client sites you're paid to maintain, with alerts only for new breakage.
• Check your sitemap. A sitemap that lists 404 URLs sends Google mixed signals. Regenerate it after deletions.

The short version

• 404s for pages that are really gone are normal. Google says so.
• Redirect moved pages to their closest equivalent with a 301.
• Fix your own links that point to 404s at the source. This is the most commonly missed fix.
• Treat a 404 on a page that should exist as a bug, and fix it first.
• Ignore typos and junk URLs unless they carry real backlinks.
• Use a crawler that records the "found on" page, so you can see where the broken links come from without waiting for Google.

Originally published on the DeadLinkPatrol blog. We build DeadLinkPatrol, a scheduled broken-link checker. If you want to see what a live crawl finds on your own site, the free checker scans up to 25 pages without signup.

This article was created with the help of AI and checked for accuracy before publishing.