Decide what happened to the requested URL
A missing URL is not always the same editorial or technical event. A visitor may mistype a path that never existed. A published guide may have moved to a clear new address. A time-limited campaign may have ended with no suitable replacement. Or a live product page may fail to render because of an application fault. Put those cases into an owner-maintained decision list before designing the visual page. MDN defines 404 as “not found”: it says the resource cannot be found without saying whether absence is temporary or permanent. If content is known to be permanently gone, 410 communicates that more specifically. Google Search Central advises a permanent redirect when a page has moved to a clear replacement, and a 404 or 410 when no replacement exists. A temporary server problem belongs to its own error handling, not a fabricated 404. The visitor-facing message should follow the same truth as the status code. A business can make the 404 page friendly, but it cannot use pleasant copy to turn an unknown URL into a successful resource. That status distinction lets browsers, crawlers, monitoring tools and support staff interpret the response consistently.
Return the error status with the helpful page
One common implementation mistake is to show a page headed “not found” while the server returns HTTP 200. Google calls this a soft 404 and explains that such pages may be excluded from Search because the response claims success while the content says failure. A custom page can still contain normal navigation, a search field and clear next steps; the missing URL's response must remain 404. Check the status on the requested URL, not only on the separately accessible template file. Application routers, static-host fallbacks and single-page applications can all make this easy to get wrong: a blanket fallback may serve the home page with 200 for any unknown path. Another mistake is to redirect every missing URL to the home page. That hides the fact that the requested resource was absent and often drops the visitor into unrelated content. Reserve a redirect for an identified successor with a similar purpose. Where a page has permanently disappeared and there is no match, give the visitor an honest 404 or 410 and useful choices from there. The page design and the protocol response are one customer experience, even though different teams may configure them.
Give a route back to the original task
The best 404 content tells the visitor that the page cannot be found, then offers routes grounded in the site's real structure. Keep familiar navigation so the customer can orient themselves. A link to the home page is useful, but a business with distinct services, product categories or support channels should offer a small set of stable, relevant destinations as well. If the URL reveals an old category or guide topic, a nearby category page can help, provided it actually contains material related to the request. Avoid guessing a replacement so confidently that the visitor believes it is the same product, price or offer. Provide a way to report a broken link with the attempted URL attached only if the business can receive and act on those reports. Google recommends a clear explanation, a consistent look, useful links and a way to report a broken link as components of a custom 404 page. The page should not repeat a vanished promotion's dates, imply an expired offer still applies, or expose internal path details that have no value to customers. For bilingual Hong Kong sites, the error message and links should follow the visitor's language where the site supports it, while still offering a route to the other language.
Handle three URLs from one small business
Suppose a repair shop has a service guide at a new permanent URL, an expired seasonal campaign, and a customer who types a non-existent address. For the guide, identify the exact new guide and set a permanent redirect from the old address. Test that the destination actually answers the same question; sending the old guide to a broad service index because it is convenient may strand the reader. For the campaign, first check whether a current page honestly replaces its purpose. If there is none and the offer is over, a 404 or 410 response can explain that the page is unavailable and link to current services without claiming the old terms continue. For the typo, return a 404 with site navigation and perhaps a search field; do not create a permanent redirect from a random misspelling to a guessed page. Now add a fourth case: the valid booking page temporarily throws an error. Investigate and report a server failure rather than relabelling it as missing. These cases make a useful staff checklist: does the URL have a verified successor, was the resource intentionally removed, or is there an operational fault? The right response is decided by that evidence, not by a desire to make error dashboards look quiet.
Use missing URLs to repair real paths
A 404 page is a safety net, not a replacement for maintaining links. Review missing URL records by source and task. A link from your own menu, checkout email or product description deserves prompt repair because the business controls it. An external site may be linking to an old, valuable page; if there is a verified replacement, a specific redirect may help. Random bot probes and arbitrary typos need different treatment, and a raw count of 404 requests is not a quality score. Keep the attempted path, referring page when available, frequency and customer impact, while avoiding unnecessary retention of query strings that may contain personal information. Compare reports with the current route inventory before creating new redirects. A blanket rule can mask a genuine application regression, and a growing cluster of missing product pages after a catalogue update may indicate a broken internal URL generator. The repair loop is straightforward: reproduce the URL, identify who linked to it, decide whether to fix the source link, redirect to a true successor or leave a correct 404, then retest. Do not treat unknown traffic as proof of demand for an old offer. It may be automated scanning or an obsolete bookmark.
Test status, content and destination together
Before release, request a deliberately unknown URL in each supported language and inspect the actual HTTP status, rendered page and links. Repeat for a known moved page, an intentionally removed page and a valid page made unavailable in a safe test environment. Verify redirects do not form loops, land on the intended language and lead to content that still serves the original purpose. On the missing-page response, confirm that navigation works with keyboard and mobile layouts, the text names the problem without blaming the visitor, and a search control does not hide the message. Check the final response after any CDN or hosting fallback, because the edge layer may change a status returned by the application. If the site has a client-side router, test both clicking through the app and directly loading the unknown URL in a fresh browser tab. Keep one small regression list of representative paths and rerun it after route or hosting changes. A passing visual screenshot alone is insufficient: it cannot show whether the URL returned 200, 404, 410 or a redirect. The completed decision is a page that tells the truth at the protocol layer and gives the person a useful route to continue.
Assign a decision owner for retired content
The most difficult missing-page decisions often occur before a technical ticket exists. Marketing may retire a campaign, product staff may remove an item, and support may still send customers an old link. Give each content type an owner who can answer whether there is a true successor and when the original promise ended. Record the old URL, the decision, the destination if any and the date the change was made. That small register prevents a future maintainer from redirecting an expired offer to a superficially similar promotion with different terms. It also helps support explain why a bookmark no longer works. Keep the 404 template independent of live stock or campaign feeds where feasible, so a catalogue outage does not leave even the recovery page blank. If the error page itself relies on search, retain static navigation as a fallback when search is unavailable. This is practical resilience: a person arriving through an old email link still sees an intelligible message, and the business can trace who decided what should happen to the URL.
Before you proceed
- Classify moved, removed, unknown and broken valid URLs.
- Return 404 or 410 with a useful page when no replacement exists.
- Check final HTTP status and destination after hosting or CDN rules.
