HTTP Status Checks: Find Broken Pages and Misleading Error Responses

Distinguish the displayed message from the server response

A page can show “not found” while the server reports a successful response. It can also display useful content while returning an error status. Inspect both the visible page and the actual HTTP response; checking only the screen leaves an important part of the behaviour unverified.

Include the final destination after redirects. A successful first response that leads to an unrelated error page is not a complete repair. Test the route the visitor actually uses, including older links and typical query-string variations.

For a complementary practical guide, read Website speed and Core Web Vitals: a practical guide for business owners.

Classify missing content before choosing a repair

A mistyped address, a retired article and a temporarily unavailable service are different situations. Decide whether the requested content exists, whether a genuinely equivalent destination exists and whether the failure is expected to be temporary.

Use the appropriate response for the actual condition, following current server and search documentation. Redirecting every unknown address to the homepage can disguise a missing resource without helping the person who followed a specific link.

Test route patterns rather than one isolated URL

Check representative service pages, nested articles, category pages and deliberately unknown addresses. Template or rewrite rules can affect an entire group of paths. One working homepage does not establish that the rest of the site behaves correctly.

Include trailing slashes, old filenames and asset requests where relevant to the hosting configuration. Keep the test list small enough to repeat after deployment while broad enough to cover the site’s distinct routing patterns.

For a complementary practical guide, read Website Redirect Audits: Protect Useful Routes During Changes.

Make the error screen useful without misrepresenting success

A missing-page screen can retain the site navigation, explain the problem plainly and link to relevant starting points. It should still communicate the actual missing condition at the HTTP level. Attractive design does not require a misleading response.

Avoid blaming the visitor or claiming that the requested page has moved when no replacement is known. Offer a route to services, articles or contact, and keep form handling separate from the error response.

Record the cause and the final verification

When a rewrite or deployment rule causes failures, document the affected pattern and the changed configuration. Retest both the repaired routes and an address that should remain missing. A repair is incomplete if it makes every possible path appear successful.

Preserve the migration map for intentional URL changes. It helps future maintainers understand why a redirect exists and prevents a later cleanup from removing a route that still supports legitimate old links.

An illustrative nested-article routing check

A site moves articles under category folders. The homepage works, but an unknown article address returns the homepage with a successful status. The reviewer identifies a catch-all rewrite as the cause and separates existing pages, intentional redirects and true missing routes.

After the change, the old article redirects directly to its replacement, the new article loads normally and the invented address produces the designed missing-page screen with the appropriate response. The reviewer checks the final deployed host because local file previews cannot reproduce the hosting server’s HTTP behaviour.

Keep a compact response matrix for deployment checks

A response matrix can list the homepage, a normal service page, a nested article, an old redirected route, a missing page and a temporary failure case available in the test setup. For each, record the expected visible result and server response. The matrix gives the hosting reviewer a repeatable check that is more reliable than browsing a few favourite pages after an upload.

Run the relevant checks on the final hosting environment because server rules can differ from local previews. Preserve query strings where an intentional redirect is supposed to retain recognised campaign context, and check that the final destination is direct. Do not force a temporary outage on a live customer journey for a routine test. Use a suitable test environment or an existing observable failure case and document the verification limit.