Why does a page return a 200 status yet still behave like a broken link?

Soft 404s pass every basic status check while sending visitors to an empty template or a not found message. Here is how they happen, how to detect them, and how to fix them at the source.

Julien Jimenez

September 7, 2026 · 4 min read

What a soft 404 actually is

A soft 404 is a page that answers with an HTTP 200 success status but has no real content for the URL that was requested. The common shapes are familiar once you start looking: a product page that renders the full template with a small line saying the item is no longer available, an internal search results page that returns zero matches, a CMS catch-all route that draws the homepage layout for any unknown path, and a single page application whose server always returns the same HTML shell and lets client-side code display a not found message afterward.

The reason this matters for link monitoring is simple. Any check that looks only at the status code will report these pages as healthy. A visitor arriving from another site, an old email, or your own navigation lands on a shell page with nothing useful on it, and your team gets no signal. Search engines eventually classify such URLs as soft 404s and drop them from the index, but that classification can lag by weeks, and it never tells you which of your own links pointed there. Related: Why Broken Links Quietly Hurt Your SEO

Keep reading: Why Broken Links Quietly Hurt Your SEO, Internal vs External Broken Links: Which to Fix First, How to Find Broken Links at Scale. See how LinkRotly helps you continuous broken link monitoring for websites.

How soft 404s slip past a status code check

Most soft 404s are side effects of reasonable engineering decisions. Frameworks ship with catch-all routes so a site never shows an ugly server error. Hosting control panels let you set a custom error document, and if that document is configured as a rewrite instead of a proper error response, the friendly page arrives with a 200. E-commerce platforms keep discontinued products live with an out of stock template because deleting them would break the admin's order history. CDN rules that serve a cached fallback for any origin failure produce the same effect.

Single page applications are the largest source on modern sites. The server has to return 200 for the application shell so the JavaScript can boot, and only then does the client-side router decide the route does not exist. Unless the app is server rendered, or a prerender step writes real files and lets the server return 404 for anything without one, every unknown URL on the domain looks alive to an automated check. JavaScript-heavy storefronts and documentation portals behave the same way. Related: Which broken images, PDFs, and embedded files do standard link checkers usually miss?

Detecting them reliably

The most dependable technique is to fingerprint your real not found page. Request a deliberately random URL on the domain, something no page could ever match, and record the status, the title, the content length, and a hash of the main content area. Then compare each real page against that fingerprint. Pages that match are soft 404s no matter what status they carry. Secondary signals help too: very small content lengths on deep URLs, titles that contain phrases like not found or page unavailable, and canonical tags on deep pages that point back at the homepage.

Run the fingerprint check on a schedule rather than once, because templates change and a redesign can silently alter what a not found page looks like. Search console style reports of soft 404s are useful confirmation but arrive late. For external links you cannot fingerprint every destination domain the same way, but you can flag destinations whose title or main content changed to something that reads as an error message, or whose content length dropped sharply since the last successful check. Related: What a 404 Does to a Visitor, and How to Soften It

Fixing them the right way

The fix is to return the honest status. Use 404 when the page is gone for now, 410 when it has been removed permanently, and a 301 only when a genuinely equivalent page exists. For single page applications, add a server side or edge rule that returns 404 for routes outside the known list, or emit a noindex meta tag from the client as an interim measure until the status can be corrected. For discontinued products, decide a policy in advance: redirect to the category when a close successor exists, otherwise serve 410 with clear navigation to related items.

Avoid the tempting shortcut of redirecting everything unknown to the homepage. Search engines treat a redirect from a deep URL to an unrelated homepage as another form of soft 404, and visitors experience it as being dumped somewhere random. Once the status is corrected, re-run the fingerprint check and confirm the URLs now appear in your broken link report where they belong. Then work through the internal links pointing at them, since the corrected status will surface every one of those as a real error. Related: Internal vs External Broken Links: Which to Fix First

Key takeaways

A soft 404 returns a 200 status with no real content, so status-only checks never see it.
Fingerprint your true not found page by requesting a random URL, then compare real pages against it.
Fix the status at the source with a 404, a 410, or a redirect to a genuinely equivalent page.
Never blanket redirect dead pages to the homepage, because search engines treat that as another soft 404.

Written by

Julien Jimenez

Julien Jimenez is an independent software builder based in Paris. He designs, ships, and operates focused SaaS products for small businesses and independent professionals. Read the full author page.