Skip to content
Science-backed data on why AI says what it says
Access & discovery

Missing-page responses and soft 404s

A missing-page response tells a client that a URL has no available page, usually with HTTP 404 or 410. A soft 404 can occur when an unavailable address instead returns a successful status or an unrelated normal-looking destination.

Checked against BLURSOR’s measurements ·

What it means

A helpful error page and an accurate status code can work together. Visitors can receive navigation and an explanation while the server reports that the address was not found. Showing a polished design does not require calling every request successful.

A catch-all configuration may send many invented addresses to the homepage or serve the same generic page at each one. This can make nonexistent URLs look real. Google describes these patterns as possible soft 404s, but its own diagnosis considers its observations of the page; a BLURSOR finding is not a Search Console verdict.

The right response depends on what happened. An address with a relevant replacement may need a redirect. A genuinely removed page with no replacement can return a missing-page status. A page that should still work needs its delivery or application error investigated.

Illustrative example

Hypothetical example: every mistyped address opens the homepage

A fictional business sends both /made-up-service-one and /made-up-service-two to its homepage. Visitors see familiar branding, but neither address identifies the service they requested. A developer should review the catch-all behavior and preserve intentional redirects separately from responses for genuinely unknown addresses.

How BLURSOR measures it

In the report: Missing-page responses

BLURSOR sends two bounded requests to generated paths that are expected not to exist. If both trustworthy responses report HTTP 404 or 410, it records an explicit missing-page result. It also checks whether the two paths end at one destination or return strongly similar normal-looking HTML.

The repeated-page detector considers text similarity, title and heading agreement, and whether enough readable text was captured. Nearly identical thin application shells are inconclusive because client-side routing may determine what visitors eventually see. Incomplete captures, challenges, or inconsistent probe outcomes also limit the conclusion. Two successful status codes alone do not establish a catch-all problem.

What to do next

  1. Ask your developer to inspect the exact generated paths and the returned status, final destination, and body.
  2. Keep useful error-page navigation while returning an appropriate missing-page status for genuinely absent content.
  3. Test important application routes and intentional redirects separately after changing routing behavior.

What it cannot tell you

  • Only two generated paths were tested; a clean result does not certify every missing-URL pattern on the site.
  • An inconclusive application shell is neither proof of a soft 404 nor confirmation of correct browser routing.

Sources and further reading

The definitions below describe the underlying concepts. The measurement section describes BLURSOR’s own checks.

Related explanations