Fetched page announces not found while returning HTTP 200
ShipReady received HTTP 200 for a fetched page whose title or first matching H1 contains a supported not-found signal.
Why it matters
A route intended to be unavailable should return a response status consistent with that decision. Checking the page and route handling together makes failures easier to diagnose.
How ShipReady detects it
What it inspects
ShipReady inspects already fetched page HTML, its final response status, the title, and H1 elements for a maintained set of not-found phrases or a bare 404.
What triggers a finding
The rule triggers only when a fetched page returns HTTP 200, its title or an H1 matches the supported not-found signal, and its path is not a recognised site error-route suffix such as /404 or /not-found.
What the evidence shows
One fetched page returned HTTP 200 while the inspected title or H1 announced a supported not-found condition.
Limits of this check
ShipReady evaluates only pages it fetched and only the maintained title/H1 patterns. It does not crawl every route, determine why the content was rendered, test indexing or monitoring systems, or prove that an unavailable route was reached by a user. A correct HTTP 404 response does not trigger this rule.
How to fix it
Decide whether the route should exist
If the route is intentionally unavailable, configure the framework or server to return the appropriate error status. If it should exist, correct the route, data lookup, or rendering branch that produces the not-found message.
How to verify the change
Verify the affected deployed route
Request the reported URL and compare its final HTTP status with its visible title and primary heading.
Expected: The route's status and displayed state match the intended availability of that page.