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 follows any redirect and only reports a trap when both end at a 200, whether the page was served directly or reached through a catch-all redirect to the homepage. A 4xx, a 5xx, a redirect that ends at a 4xx, a probe blocked by robots.txt (including a redirect into a blocked URL), 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.
When the 200 came through a redirect, the finding says where it went instead:
A random nonexistent URL at the site root and one nested under a real directory were both redirected to https://www.example.com/, which answered 200. Redirecting every missing URL to one page is treated by Google as a soft 404.
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
- 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. - 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's404.phpand any "catch-all" rewrite rules added by SEO or redirect plugins. - 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.
- If missing URLs redirect to the homepage, remove the catch-all rule. Redirect only where a specific replacement page exists, and let everything else return 404 or 410.
- Re-crawl the site once the fix is live to confirm the probe now sees a real 404 or 410, directly or at the end of a redirect, rather than a 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 a real "not found" page is not a trap: the probe follows the redirect and judges the final response, so a 4xx at the end of a redirect reads as healthy. A redirect to the homepage or any other live page is a trap, because the final response is a 200.
Related reading
For the check that flags a single redirect hop doing nothing but address cleanup, see Redirect Normalisation. For the opposite problem, a page that genuinely returns a 4xx or 5xx status, see 4xx and 5xx Errors: Failed HTTP Status Codes.
Google documentation: Troubleshoot Google Search crawling errors: soft 404s
Frequently asked questions
- Is a soft 404 the same as a normal 404 page?
- No. A normal 404 page returns HTTP status 404 even though it shows a friendly "page not found" message. A soft 404 returns status 200, the same code as a real page, so a crawler has no way to tell the two apart except by reading the content.
- Why does the check test two URLs instead of one?
- A single 200 on a random URL could be a coincidence, such as one directory with its own fallback page. Requiring both a root-level probe AND one nested under a real directory to return 200 rules that out: a genuine soft-404 trap answers everywhere, not just at one path.
- Can a soft 404 hurt indexing even if my real pages are fine?
- Yes, indirectly. Every fake URL a crawler fetches instead of a real one is time and budget it did not spend on your actual content, and on a large site that adds up across thousands of crawl requests.
- Does this check flag a site that redirects nonexistent URLs to the homepage?
- Yes. The probe follows redirects and judges the final response, so a site that sends every missing URL to its homepage, which answers 200, is reported as a trap and the finding names the page the redirect landed on. Google treats a catch-all redirect to one page as a soft 404 too. A redirect that ends at a real 404 page is not a trap.