How to test a custom 404 page before it escapes into production
Test the response, routing, recovery links, accessibility, phone layout, resilience, analytics, and a handful of genuinely impossible URLs.
Filed: · By:Steve Bullis
A custom 404 page is easy to preview and surprisingly easy to ship incorrectly.
The polished /404 route may work while real missing URLs return a host default. The page may look right but answer 200 OK. The home button may point to a staging domain. Treat it like a system behavior, not a poster.
Start with impossible URLs
Create test addresses that cannot collide with real content:
/this-page-should-not-exist-92841
/products/not-a-real-product-92841
/nested/route/with-a-missing-leaf-92841
/NOT-A-REAL-PAGE-92841?source=testExercise static and dynamic route patterns. If the application has localized, tenant-specific, or authenticated sections, test those boundaries too.
Inspect the response
Use browser developer tools or a command-line request:
curl -I https://example.com/this-page-should-not-exist-92841Confirm the final response is 404, including after redirects. A redirect to /404 is acceptable only if that destination actually returns the right status and the behavior does not erase useful context. Serving the error page directly at the requested URL is often simpler.
Check caching headers. A 404 can be cached, but an aggressive long-lived rule may preserve a temporary publishing mistake after the real page appears.
Test the recovery paths
Click every link. Confirm home, search, popular destinations, and report-a-link controls use production URLs and do not lead to another error.
If search is offered, submit an empty query and a plausible one. If a “back” action exists, test a direct visit with no useful same-site history. There should still be a deterministic exit.
Break the optional pieces
Block the illustration, analytics, recommendation API, and third-party scripts. The explanation and core navigation should survive. An error page that requires six healthy services is an unreliable error page.
Test slow connections and JavaScript disabled when the architecture permits. Keep the status and essential copy on the server side.
Check human factors
Use keyboard-only navigation. Zoom text. Try a narrow phone, a short landscape viewport, and a large desktop. Turn on reduced motion and high contrast. Confirm the title and main heading identify the missing page.
Read the copy in context. Is it still appropriate when the broken URL came from checkout, support, or a password reset?
Verify reporting without creating noise
Confirm logs or analytics receive the requested path and useful referrer context under your privacy rules. Filter your own test marker afterward. Make sure a flood of unknown URLs cannot trigger an alert, database write, or expensive API call on every request.
Finally, deploy one real canary test to production and repeat the response check there. Hosting rewrites and edge rules are part of the system, and local success cannot prove they are correct.