404 Errors: When to Fix, Redirect, or Leave Them Alone

A 404 is the correct, expected response for a URL that doesn’t exist. That’s worth stating up front because most anxiety around 404s comes from treating their mere presence as a problem, when the actual skill worth building is knowing which 404s deserve action and which don’t. The decision most site owners get wrong isn’t “what is a 404,” it’s when to redirect a dead URL and when to just let it 404.

404s Are Not a Ranking Penalty

Google’s long-standing, still-current position is that 404 errors on a site don’t drag down the ranking of the site’s other, working pages. Google’s own Search Central blog put it directly: a site having some 404 errors is a completely normal part of running a website, and search engines expect to encounter them (Google Search Central Blog, “Do 404 errors hurt my site?”). Google representatives, including John Mueller, have reaffirmed this position repeatedly since: 404s and 410s on gone pages are not treated as a negative quality signal against the rest of the site.

What Google explicitly does not want is a soft 404: a URL that returns a normal 200 status code while showing content that’s actually a “not found,” thin, or placeholder page. That mismatch, a success status code paired with failure-style content, is what actually causes classification problems, not the honest 404 response itself.

Finding 404s

Three sources cover most of what’s needed:

• Search Console’s Page Indexing report, which lists URLs Google has encountered returning a 404, along with any that are being interpreted as soft 404s.
• Server log files, which show every 404 response actually served, including to crawlers and bots that Search Console doesn’t separately report on, and reveal whether a 404’d URL is still receiving meaningful traffic or backlinks.
• Broken-link crawler tools, which crawl a site’s internal and (optionally) external links and flag any that resolve to a 404, catching links that point to a dead page from within the site itself.

Cross-referencing all three matters: Search Console shows what Google has seen, log files show real request volume, and a crawler shows whether the site is actively linking to its own dead pages, which is worth fixing regardless of what Google thinks about the 404 itself.

Log files in particular reveal a category the other two sources miss: 404s being hit by real inbound traffic, from a search result, a backlink, or a bookmark, rather than just URLs Google happens to know about. A simple filter for 404 status codes in server logs, sorted by request volume, quickly surfaces which dead URLs are actually costing traffic versus which ones nobody is visiting anyway; the former deserve redirect attention first, the latter usually don’t need any action at all.

Soft 404s: What Triggers Them, and How to Fix

Google doesn’t publish a specific numeric threshold, like a word count, that triggers a soft 404 classification, and any content asserting one (a specific “under 100 words” rule, for instance) is presenting an invented number as fact. The real, qualitative signal is a page that looks like a “not found” page to Google’s systems while still returning a success status code: thin or near-empty content, generic “sorry, this page isn’t available” messaging, or duplicate boilerplate with no unique content, combined with a 200 response.

The fix is to align the status code with the actual state of the page: if the page is genuinely gone, serve an actual 404 (or 410) status rather than a 200. If the page has real, substantive content, the soft-404 classification usually means something else is wrong, thin content, a template that looks empty to a crawler, or a page that duplicates another URL closely enough to be miscategorized, and the fix is improving that content rather than changing the status code.

Redirect vs. Leave as 404: The Actual Decision Rule

The rule that actually holds up: redirect a dead URL only when there’s a genuinely relevant destination for it, meaning a live page that continues to satisfy the same intent the old URL served. If no such page exists, let it 404. That sounds obvious stated plainly, but it’s routinely violated by the opposite instinct: mass-redirecting every dead URL to the homepage “just in case.” Google has flagged that pattern as a weak practice, since a homepage almost never satisfies the specific intent behind whatever the original URL was about, and a large volume of irrelevant redirects looks, structurally, like exactly the kind of pattern used in low-quality link schemes.

A practical version of the rule: a discontinued product page redirects to its replacement product or the relevant category page, a merged blog post redirects to the post that absorbed its content, and a page with no reasonable living equivalent (a one-off promotion long expired, a location that closed) 404s cleanly instead of being forced into an unrelated redirect.

A borderline case worth calling out specifically: a discontinued product with no direct replacement, but a still-live parent category. Redirecting straight to the category page is defensible here, since it’s a genuinely related destination rather than an unrelated catch-all like the homepage, but it’s worth being honest that this is a softer match than a true one-to-one replacement, and it should be reserved for cases where no better option exists rather than used as a default shortcut.

410 vs. 404: Honestly Hedged

A 410 (Gone) status explicitly tells a crawler the resource was intentionally and permanently removed, versus a 404 (Not Found), which is more ambiguous, the resource might be temporarily missing, moved without a redirect, or genuinely gone. Both are treated by Google as valid signals that a URL shouldn’t stay indexed. The commonly repeated claim that 410 gets a page removed from the index meaningfully faster than 404 is not something Google has published a documented guarantee for; it’s a reasonable inference from 410’s more explicit intent signal, not a confirmed speed difference. Using 410 for pages that are deliberately and permanently gone is good practice on its own merits (it’s more precise and honest about intent), but it shouldn’t be sold as a faster deindexing trick.

Custom 404 Pages

A well-built custom 404 page (clear messaging that the page wasn’t found, a search box, links to genuinely useful sections of the site) is a legitimate user-experience improvement, since it gives a visitor who hits a dead link somewhere to go instead of a dead end. It is not, on its own, a technical SEO fix; it doesn’t change how the URL is treated by search engines and shouldn’t be mistaken for a substitute for auditing and cleaning up the actual broken links and redirect decisions covered above. One technical detail worth confirming regardless of how the page is designed: a custom 404 page must still return an actual 404 status code in the HTTP response. A nicely designed error page that returns a 200 status is, by definition, a soft 404, the exact problem this guide opens with.

Monitoring 404s Over Time

A one-time 404 cleanup drifts back out of date as soon as the next round of content changes, product discontinuations, or site restructuring happens. Checking the Page Indexing report’s 404 and soft-404 categories on a recurring basis, rather than only after a migration, catches new dead links while the volume is still small enough to review individually rather than facing another large backlog later. A sudden spike in 404s between two checks is also a useful early warning sign of an unrelated problem, a broken internal link introduced by a template change, or a third-party integration generating malformed URLs, worth investigating on its own rather than just redirecting away.

Handled well, 404s are a normal maintenance category, not a crisis: find them, decide honestly whether each one deserves a targeted redirect or a clean 404, fix the soft-404 mismatches where content and status code disagree, and move on.