Why does my page return 200 instead of 404?

The status code is the only part of a response every automated client agrees on. The body is for people.

A link checker sees 200 and reports the link as healthy, so broken navigation stays invisible in exactly the report meant to find it.

Caches and CDNs store the response as a successful page, and may serve it long after the real content returns.

Search engines may index it. Google detects many of these and reports them separately as soft 404s, which is a signal you are producing pages that claim to succeed and do not.

Monitoring is affected too: an uptime check asserting a 200 passes while the site serves nothing useful.

Client-side routers. A single-page application receives any path, the server returns the shell with 200, and the router renders a not-found view in the browser. The server never learned the route was invalid.

Catch-all rewrite rules that map every unmatched path to the index document, which is the configuration that makes client-side routing work and produces this side effect.

Content management systems configured to redirect missing pages to the home page or to a custom page, turning an absence into a successful arrival somewhere else.

Application code that catches a lookup failure, renders a friendly message, and forgets to set the status.

Search and filter pages that return an empty result set with a 200, which is correct for a search and a soft 404 when the URL was meant to be a product.

A 301 from a missing page to the home page replaces a truthful answer with a false one: it says the content moved there, which it did not.

Visitors lose the information that the page is gone and are left wondering what happened to what they asked for.

It hides broken links from everyone, including you, because nothing reports an error.

Search engines treat it as a soft 404 anyway, so the tactic does not even achieve what it was adopted for.

Where a genuine successor exists, redirect to the successor. Where none exists, return 404 or 410.

Request a URL you know is invalid: `curl -sI https://example.com/definitely-not-a-real-page`. A correct configuration answers `404`.

Do this on each distinct part of the site. Applications frequently return 404 correctly for static routes and 200 for application routes, and the difference only appears when you test both.

Test a path under each section — a product path, an article path, a category path — because each is usually handled by a different route.

In Search Console, the Page indexing report separates soft 404s from real ones, which is the fastest way to find the ones only crawlers see.

Decide the status on the server. In a framework with server rendering, that means the route handler setting 404 when the lookup fails, before any HTML is produced.

For a client-rendered application, the server has to know which paths are valid. That usually means rendering on the server for real routes and returning 404 for everything else.

Keep the friendly page. A 404 response can carry any body you like — the status and the design are independent.

Never redirect to the home page. Offer search and the main sections on the 404 page instead.

Use 410 instead of 404 when you deliberately removed something and want it dropped from indexes sooner.

VeriFixScan's `availability.error_pages` check requests a URL that cannot exist and reports the status actually returned, which is the direct test for this.

`availability.status_classification` reports the entry URL's own classification, separating a working site from one answering errors.

`availability.broken_links` reports the status of every link followed, which is where a soft 404 hides: as a link that looks fine.

A scan tests the paths it reaches. A soft 404 confined to one route the crawl did not enter will not appear, which is why testing an invalid path per section by hand is still worth a minute.