A generated unknown path returned HTTP 200
ShipReady requested one generated same-origin path and received a 200 response instead of the expected 404 status.
Why it matters
An application can show an error page while still returning a success status. Reviewing how unknown routes respond helps keep route behavior deliberate.
How ShipReady detects it
What it inspects
For an eligible content-serving origin, ShipReady makes one request to a generated random same-origin path and follows redirects.
What triggers a finding
The rule triggers only when that generated path returns HTTP 200.
What the evidence shows
One generated path returned HTTP 200 in ShipReady's bounded probe.
Limits of this check
ShipReady checks one generated path and its status only. It does not inspect every unknown route, determine the rendered error-page content, test search-engine indexing, or establish how users encounter the route. A failed, rate-limited, or unavailable probe produces no finding.
How to fix it
Set the intended status for unknown routes
Configure the framework, edge layer, or server so genuinely unknown paths return the intended not-found response rather than HTTP 200. Preserve deliberate catch-all routes when they are meant to serve content.
How to verify the change
Request a new unknown path after deployment
Request a path that is not handled by the application and inspect the final HTTP status.
Expected: An intentionally unknown path returns the status your deployment policy expects, commonly 404.