A good missing-page experience returns the correct HTTP status while giving people a clear explanation and several safe ways to recover. Review the server response, page content, navigation, accessibility, measurement, and broken-link workflow together; a polished design cannot compensate for a false success response.
Verify the response before the design
Request a URL that has never existed and inspect the final HTTP response. RFC 9110 defines 404 Not Found as the response used when the server cannot find a current representation for the target resource or is unwilling to disclose that one exists. The missing-page template should return 404, not 200.
Test direct requests, mixed-case paths, encoded characters, trailing slashes, old extensions, and paths behind the content delivery network. Record every redirect hop. If content moved to a clear replacement, use a direct permanent redirect to that specific destination. Do not redirect every unknown address to the home page because that hides broken links and confuses visitors.
Google calls a page that looks missing but returns 200 a soft 404. Its crawling-error guidance recommends a real 404 or 410 when content has no replacement, and a 301 when a clear replacement exists. Verify both the browser experience and the response code.
Give people useful recovery routes
State plainly that the requested page could not be found. Preserve the site's familiar header, visual style, and primary navigation without pretending the missing resource is available. Provide a home link and a short set of dependable destinations, such as search, contact, product categories, documentation, or popular content.
Use descriptive link text that says where each route goes. Keep the list focused so people are not forced to scan an entire sitemap. If the requested path can be shown safely, display only an escaped, non-executable version and avoid reflecting query strings or sensitive tokens. Offer a way to report a broken link when the organization can actually review those reports.
Check keyboard and screen-reader behavior
Set a specific document title such as Page not found followed by the site name. W3C's page-title accessibility guidance explains that descriptive titles help users identify a page without reading or interpreting all of its content. Use one clear heading, logical landmarks, visible focus, sufficient contrast, and the site's normal skip link.
Navigate the page with only a keyboard. Confirm that focus is visible, the order follows the content, every recovery link works, and no modal traps the user. With a screen reader, check that the title, heading, explanation, and destinations are announced meaningfully. Turn off images and scripts to confirm that core recovery links remain available.
Measure errors without collecting sensitive paths
Define a missing-page event that records only data needed for maintenance, such as a normalized path identifier, referrer category, timestamp bucket, and whether a recovery link was chosen. Strip personal data, account identifiers, search terms, authentication parameters, and fragments before storage. Document the retention period and access controls.
Separate human visits from known bots where practical, then rank errors by frequency and business importance. Link analytics to a repair queue with an owner, status, and resolution. A high-volume typo may need a redirect; a stale internal link should be corrected at its source; random scans usually do not require new pages.
Test the complete recovery loop
Create cases for a deleted page, a moved page, a typing mistake, a broken internal link, and an unavailable asset. Verify status, canonical behavior, title, navigation, keyboard path, reporting, analytics, and mobile layout for each. Check Search Console or equivalent reports after deployment, but do not treat crawler data as the only evidence.
The review is complete when the server communicates absence correctly, users can recover without guessing, assistive technology gets a clear page, analytics avoids sensitive data, and broken links enter a maintained repair process.
Sources
- RFC 9110 HTTP Semantics: 404 Not Found — RFC Editor
- Troubleshoot crawling errors — Google Search Central
- Understanding Success Criterion 2.4.2 Page Titled — World Wide Web Consortium