Soft 404: What It Means and How to Fix It

A normal 404 page still says "not found" in the one place a crawler actually reads: the HTTP status code. A soft 404 is what happens when a server or CMS shows that same friendly message but answers with status 200 anyway, the same code it uses for a real page. To anything that only reads status codes, a soft 404 looks exactly like content.

What this finding means

Crawl Cove's soft-404-trap check probes two URLs that should not exist: one random path at your site's root, and one nested under a real directory found in the crawl. It only reports a trap when both come back 200. A redirect, a 4xx, a 5xx, a probe blocked by robots.txt, or a site with no real directory to nest under all read as healthy or unknown, never as a trap, on purpose: a single ambiguous result is not enough to make this claim.

A real finding looks like this:

A random nonexistent URL at the site root (HTTP 200) and one nested under a real directory (HTTP 200) both returned 200 instead of a 404 or a redirect.

This is a site-level finding, not a per-page one: it says something about how the whole server handles a missing URL, not about any one page on it.

Why it matters

A server that cannot say "not found" has an infinite crawlable URL space. Every fake path a crawler requests is a request it did not spend on a real page, and this happens to Googlebot exactly as it happens to Crawl Cove's own crawl: real pages on the site get crawled and re-indexed less often because crawl budget keeps wandering into pages that were never there.

How to fix it

1. Confirm the behaviour by hand. Request a path you know does not exist (something like /this-page-does-not-exist-12345) and check the response headers, not just what renders in the browser, for the status code.
2. On WordPress, this is usually a theme's 404 template being served through a route that never calls status_header(404), or a page builder plugin intercepting unmatched URLs before WordPress's own 404 handling runs. Check the theme's 404.php and any "catch-all" rewrite rules added by SEO or redirect plugins.
3. On a custom app or framework, confirm the "not found" view is actually returned with a 404 (or 410, if the content is gone for good) response, not rendered as a normal 200 page by a fallback route.
4. Re-crawl the site once the fix is live to confirm the probe now sees a real 404, redirect, or block, rather than 200.

False positives and edge cases

This check is deliberately conservative, so a false positive in the direction of over-flagging is very unlikely; the more relevant edge case is knowing when it goes quiet rather than clear:

• It never fires on a site with a flat structure and no eligible directory to nest the second probe under. That is read as "unknown", not "healthy", so a genuinely flat small site simply will not get this finding either way.
• A robots.txt rule that blocks the probe path is read as unknown, not healthy or a trap. The check will not claim a result it could not actually observe.
• A redirect to the homepage or a real "not found" page is not a trap, provided the final response is a real 3xx or 4xx and not a 200.

Related reading

For the check that flags a single redirect hop doing nothing but address cleanup, see Redirect Normalisation.