What a soft 404 is and why it is sneaky
A soft 404 is a page that tells the user it found nothing while telling the server it found everything. The visitor sees a message like "product not found" or "this page does not exist," but the HTTP status code the server returns is 200 OK — the code that means success. That contradiction is the whole problem. To a browser and to a search engine, a 200 means "here is a real, valid page worth keeping." To the human reading it, the page is plainly an error. This detector fetches a URL, looks at the status code the server returns, and then examines the actual content to judge whether a page claiming success is really an error page in disguise.
Soft 404s are sneaky precisely because nothing breaks loudly. The page loads. There is no red error in your monitoring. Links to it do not appear broken because, technically, they resolve to a 200. Yet search engines waste crawl budget repeatedly fetching these empty pages, may index them as thin or duplicate content, and can lose trust in your site's signals overall. The fix is almost always simple once you know a page is doing this, but finding them requires looking past the status code to what the page actually says.
How a proper 404 should behave
When a page genuinely does not exist, the server should return an HTTP 404 status (or 410 if the page is gone permanently). That status is a clean instruction to everyone: browsers know not to cache it as content, link checkers flag the broken link, and search engines drop the URL from their index and stop wasting crawls on it. You can still show a friendly, branded error page with helpful navigation and a search box — a good 404 experience and a correct 404 status are not in conflict. The status lives in the HTTP response headers; the friendly design lives in the body. They are independent, and you want both.
The soft 404 happens when the two get decoupled by accident. A developer builds a nice custom error page but serves it with a 200 because the framework or CMS returned the error page as ordinary content rather than setting the status code. Or a route handler catches a missing record and renders a "not found" template without ever changing the response status. The page looks like an error to humans but reports success to machines. A correct setup means the not-found template and the 404 status always travel together.
What this detector inspects
The tool starts with the status code, because that is the contract. It records what the server returned — 200, 404, 410, a redirect, or something else. Then it inspects the response body for the signals that betray an error page wearing a success status. It looks for the language of absence: phrases like not found, does not exist, no longer available, page removed, no results, and similar. It weighs the amount of real content, because genuine error pages are typically thin — a short message and some navigation rather than a full article or product listing.
It also looks for structural tells. A page that returns 200 but has almost no unique body content, that is nearly identical to other "empty" pages on the site, or that consists mostly of boilerplate header and footer with an apology in the middle is a strong soft-404 candidate. The detector combines the status code with these content signals to produce a verdict: a page returning a proper error status is fine, a page returning 200 with substantial real content is fine, and a page returning 200 while clearly communicating that nothing was found is flagged as a likely soft 404 that should be returning a true error status instead.
How to read the results
The clearest healthy result is a real page: a 200 status paired with genuine, substantial content that matches what the URL promises. Equally healthy is a missing page handled correctly: a 404 or 410 status on a URL that does not exist. In both cases the status code and the content agree, which is exactly what you want.
The result to act on is a 200 status combined with error-page content — the signature of a soft 404. When the tool flags this, it is telling you that a page is claiming to be a valid, indexable destination while actually being a dead end. Treat that as a real issue even though nothing appears broken. There are also gray-area results worth a human glance: a thin but legitimate page (a sparse category with few items, a brand-new page with little content yet) can resemble a soft 404 without being one, and a page that redirects when it should 404 is a different but related problem. The detector points you to the contradiction; you confirm the intent and choose the right status.
Where soft 404s come from
Ecommerce is the biggest source. When a product sells out or is discontinued, many platforms keep the URL alive and swap the content for an "out of stock" or "product unavailable" message while still returning 200. Multiply that across a large catalog and you accumulate thousands of soft 404s. Internal search result pages are another factory for them: a search with no matches renders a "no results found" page at a real URL with a 200 status, and if those URLs get linked or crawled, they enter the index as empty pages. Faceted navigation that produces filter combinations with zero matching items does the same thing.
Framework and CMS defaults cause many of the rest. Single-page applications that handle routing in JavaScript often return 200 for every URL by default, including ones that resolve to a client-side "not found" view, so the server never sees that anything is missing. Custom error templates wired up without setting the status code, expired listings on classifieds and job boards, deleted user profiles, and removed blog posts that show a placeholder instead of a proper 404 all fall into the same trap. The common thread is content that disappeared while the URL and its success status stayed behind.
Why soft 404s hurt SEO and AI search
The first cost is crawl budget. Search engines keep re-fetching soft 404s because the 200 status tells them the pages are alive and worth checking, so crawl resources that should go to your real pages get spent on empty ones. On a large site this can meaningfully slow how quickly your genuine content gets crawled and updated. The second cost is index quality: soft 404s are thin, often near-duplicate pages, and a site cluttered with them looks lower quality in aggregate. Google explicitly tries to detect soft 404s and may report them in Search Console, but its detection is imperfect, so some slip through and sit in the index as dead weight.
For AI search and retrieval systems, soft 404s are actively misleading. These systems crawl and ingest pages as candidate sources, and a soft 404 presents itself as a legitimate page worth reading. An AI engine might pull in an "out of stock" or "no results" page as content, then surface or cite something that is really an error state, which wastes its budget and can produce confusing or wrong answers about your site. Returning honest status codes keeps these systems from ingesting dead ends and helps ensure that when they do cite your pages, they are citing real, available content rather than ghosts.
Soft 404s versus the related problems they hide among
Soft 404s rarely show up alone, and it helps to know the neighbors they are often confused with so you fix the right thing. The closest relative is the redirect that should have been a 404: a missing page that quietly forwards the visitor to the homepage or a generic category instead of admitting it is gone. To a person this feels almost as confusing as a soft 404, and to a search engine a flood of unrelated pages all redirecting to one destination looks like another kind of soft 404, because the redirect target does not match what the original URL promised. The detector treats a redirect where a clean error belongs as its own flag rather than folding it into the success column.
Two more cousins are worth naming. Thin content is a page that returns a perfectly honest 200 and really does exist, but carries so little substance that it adds nothing, and while it is not technically a soft 404 it attracts the same low-quality judgment and is worth thickening or removing. Duplicate content is the mirror case, where many real URLs return near-identical bodies, diluting which version a search engine trusts. The detector focuses on the status-versus-content contradiction at the heart of the soft 404, but reading its results with these relatives in mind keeps you from misclassifying a thin-but-real page as broken, or a genuinely broken page as merely thin, and points each issue toward its correct remedy.
What to do after you run the detector
For any genuinely missing or removed page that is returning 200, change the response to return a real 404, or a 410 if the page is gone for good and you want search engines to drop it faster. Keep your friendly, helpful error design — just make sure the not-found template is served with the correct status code, not a success code. In frameworks where routing happens client-side, configure the server to return a proper error status for unknown routes rather than serving a 200 for everything.
For pages that should not be 404s but are thin by nature — internal search results, empty filter combinations — the better move is often to keep them out of the index entirely with a noindex directive and to avoid linking to them, so they never become crawlable dead ends in the first place. For discontinued products with a clear replacement, a 301 redirect to the closest relevant page can preserve value better than a 404; for products with no replacement, a clean 404 or 410 is correct. After making changes, re-run the detector on the affected URLs to confirm the status code now matches the content, and check Search Console's coverage reports periodically, since soft 404s accumulate naturally over time as inventory churns and content is removed.