404 Page SEO: What It Should Do (and Shouldn't)

A 404 page is not a failure state. It is the correct response when a URL genuinely does not resolve to anything anymore: a discontinued product, a retired blog post, a link someone mistyped and pasted into an email three years ago. The status code is doing exactly what it is supposed to do — telling the browser and the crawler "there is nothing at this address." Treating every 404 as an emergency to be redirected away is one of the more common technical SEO habits, and it usually makes the underlying situation worse, not better.

This is about what should happen the moment a visitor or a crawler lands on a URL that is actually gone: what the page should say, what status code it should return, and the two mistakes — one nearly invisible, one everywhere — that quietly undermine sites that believe they have already handled this correctly.

What a 404 actually signals

An HTTP status code is a contract between server and client, stating unambiguously what kind of response this is before a person or a program looks at the content. A 404 means "not found" — this address does not currently point to a page, whether or not it once did.

Some site owners treat any 404 as inherently bad for SEO. It is not. Search engines crawl a web that is constantly losing pages; one that could not tolerate a missing URL would not function at internet scale. Encountering a 404 is expected and normal, and does not by itself damage the rest of the site's standing.

What actually causes damage is different from simply having 404s. It usually comes down to one of a few patterns:

• A page with real remaining value — inbound links, steady demand, indexed history — disappearing without anyone noticing.
• A page telling the visitor "not found" while telling the crawler "here is a valid page," so the two audiences receive contradictory answers.
• A blanket policy that hides every dead URL behind a redirect, so no one can tell which URLs were actually retired and which were actually moved.

The central error: the soft 404

A soft 404 is a page that looks like an error to a human — "Sorry, we couldn't find that," "This page no longer exists," a friendly illustration and a search box — while the server response header still returns 200 OK instead of 404. The visitor sees "not found." The crawler sees "success, please index this."

The consequence is that crawlers process status codes, not the words on the screen. A 200 is an instruction to treat the response as valid content worth indexing, so a soft-404 template applied across thousands of dead URLs produces thousands of near-identical, low-value pages that all claim to be legitimate. Search Console's coverage reporting specifically flags this pattern as "Soft 404," because Google evaluates the rendered content against the declared status and treats the mismatch as a signal worth surfacing separately from an honest 404.

Soft 404s also poison your own analytics: pageview tracking counts them as visits to real content, so a "top pages" report can quietly fill up with URLs that do not exist — traffic to a page that was never actually seen, only its error message.

Detecting a soft 404 means checking the response header, not the rendered page. Request a known-dead URL and read the actual status line — a command-line request or a browser's network inspector will show it directly. If the header says 200, it is a soft 404 no matter how clearly the page's headline says otherwise.

This usually isn't deliberate. It typically happens because:

• A CMS template routes any unmatched URL to a generic "not found" view without the underlying code explicitly setting the response status, so the framework's default of 200 quietly survives.
• A single-page application always returns 200 from the server, because the server is only ever handing over the app shell — the "page not found" message exists purely in the rendered DOM after JavaScript runs, which a crawler evaluating the raw response never reliably reproduces.
• A load balancer or CDN caching layer serves a generic error page for a missing route but does not pass through the origin's intended status code.

The other common mistake: redirecting everything to the homepage

Worried that 404s "hurt SEO," a lot of sites adopt a blanket rule: any dead URL gets a 301 redirect to the homepage. It feels safer than showing an error. It is usually worse than a well-built 404.

It destroys the specific signal that a particular URL is gone. A crawler encountering a 301 expects the destination to answer the same intent the original URL promised. When hundreds of unrelated dead URLs all redirect to the same homepage, the redirect stops carrying real information — it starts looking like the same pattern a soft 404 produces, because the destination does not actually match what was requested.

It also disorients the visitor more than a clear error would. Someone follows a link expecting a specific product or article and lands on a generic homepage with no explanation. They do not know if the item moved, if the link was wrong, or if the whole site changed — a direct "we couldn't find that page" message, paired with a way to keep looking, is less confusing than an unexplained detour.

And it collapses individually meaningful URLs into a report that no longer means anything. A redirect log full of "old-product-14 to homepage," "retired-campaign to homepage," "typo-url to homepage" cannot answer the one question that matters for each of them: was this content moved, or simply removed? Mass redirection erases that distinction for everyone who looks at the data afterward.

The instinct behind the rule is reasonable — nobody wants a visitor to hit a dead end. The fix for that is a genuinely useful 404 page, not erasing the signal that the page is gone.

When a redirect is right, and when 404 or 410 is right

A redirect earns its place when the content genuinely has a new home: the page was renamed, merged into a broader page, or moved during a restructure, and the destination answers the same question the original URL promised. The test is specific — does the destination actually satisfy what the visitor was looking for, or is it just the closest thing available? "Closest thing available" is not a real match, and treating it as one only delays the moment the mismatch becomes obvious.

A 404 is right when the content is gone with no direct equivalent: deleted, discontinued, or a URL that should never have been crawled in the first place, such as an old parameter combination or a leftover staging path.

A 410 Gone is a sharper version of the same statement. It tells the crawler not just that the page is missing right now, but that its absence is deliberate and permanent — useful for a product line being discontinued on purpose, or a time-limited campaign page you genuinely never intend to bring back. A 410 tends to get a URL dropped from the index faster than a 404, which just keeps getting rechecked in case the page returns.

A short way to decide:

• Moved, with a genuine equivalent already live — redirect (301).
• Gone, and it might come back, or you're not sure — 404.
• Gone, on purpose, permanently — 410.

What belongs on a useful 404 page

A 404 page has one job: help someone who hit a dead end find their way back to something real. That means it needs a specific set of things, not a decorative afterthought bolted onto a default server message.

• A plain statement that the page is not there, in ordinary language — not a stack trace, not the error code presented as the headline.
• Site search, prominent and functional, so a visitor who knows what they were looking for can just look for it directly.
• The site's actual main navigation, exactly as it appears everywhere else — a dead link should not feel like leaving the site entirely.
• A short list of genuinely popular or closely related pages, not a dump of the entire sitemap, which just replaces one kind of overwhelm with another.
• No dead ends: every link offered on the page needs to lead somewhere real, or the page has just moved the problem one click down the line.

What a 404 page should never do

A good 404 page also earns its keep by what it avoids:

• Auto-redirect the visitor to the homepage after a countdown — it removes their choice and, to a crawler, can look like the same soft-404-adjacent pattern described above.
• Get stuffed with keyword-heavy text trying to make the error page itself rank — a 404 is not a page you want competing for search visibility, and content added there for that purpose is wasted effort.
• Disagree with its own status code. However well the page is designed, the underlying response still has to return a genuine 404 or 410. The design is what a person sees; the status code is what a crawler reads — and the two have to agree, or the result is simply a nicer-looking soft 404.

Monitoring 404s: telling a real problem from background noise

A healthy site does not have zero 404s. The web changes, people mistype addresses, old bookmarks go stale, other sites link to pages that have since been retired. The goal is not eliminating every 404 — it is noticing the ones that actually matter.

Background noise looks like this: a handful of hits on an obviously mistyped URL, a stray old parameter combination, a page that was deliberately retired long ago with nothing still pointing to it. These do not need action beyond confirming the response is a genuine, correctly coded 404.

A real problem looks different, and falls into a few recognizable shapes:

• A 404 receiving steady, repeated internal traffic — meaning something on your own site links to a URL that no longer exists. That is fully within your control: find the link and fix it.
• A 404 on a URL that still carries external backlinks from other sites — pages elsewhere on the web that reference it. Letting that URL disappear without a genuine replacement gives up value nothing else on the site recovers in the same way.
• A sudden spike in 404s right after a migration, replatform, or large-scale URL change — usually a sign that a redirect mapping is incomplete rather than that individual pages broke one at a time.
• None of these need the same fix — the discipline is deciding per URL whether to redirect to a genuine match, restore the content, or leave a clean 404, rather than letting a template decide by default.