Published September 1, 2026.
A page that looks correct after redirects may still violate its intended route contract. This check records the direct response, final URL, page identity, and canonical before a release is reported as verified.
Request the exact route
Test the HTTPS URL without automatically following redirects. Record the status, location header if present, and content type. A required direct route should return its successful response immediately rather than passing through an alias.
Detect soft fallbacks
Open the response body and confirm the unique title, visible date, and expected article content. A generic page or custom not-found screen can return a misleading success status. Compare the canonical with the requested route.
| Observation | Meaning | | --- | --- | | Direct 200 | Route responds without redirect | | 3xx | Alias or routing intervention exists | | Generic body | Possible soft fallback | | Foreign canonical | Page identity conflict | | Unique marker | Expected artifact is present |
Connect the check to deployment identity
Perform the same request against the approved production host after the operator confirms the deployment. Save the full commit and deployment record beside the HTTP evidence. Never infer live state from a push alone.
Use the release recovery playbook when the route contract fails and Google’s redirect guidance for search context.
Frequently asked questions
Is one redirect always harmful?
No. Redirects are legitimate migration tools. The issue is whether the explicit release contract requires a direct route.
Does a direct 200 prove the right deployment?
No. Confirm the unique page marker and deployment identity as separate evidence.