How Do You Build and Test a Useful Custom 404 Page?

What belongs on a useful not-found page?

Use a plain heading such as “Page not found,” a short explanation, and a few reliable destinations. A visitor should be able to reach the homepage, main services, resource library, or contact page without guessing. Keep the normal brand and navigation, but make the recovery options more prominent than a clever error message.

Use a real search feature only if it works. A decorative search box that cannot return results creates another dead end. Do not repeat an untrusted URL into the HTML without safe handling, and avoid collecting unnecessary information about what the visitor typed.

Why is a visible error message not enough?

The page body and HTTP status are separate. A server can display “not found” while returning 200 OK. Search engines may treat that as a soft 404 when the response does not provide the content expected from a successful page. It also makes status-based monitoring less reliable.

A missing resource should normally return 404 Not Found; a deliberately removed resource may use 410 Gone when the platform and situation warrant it. If a page moved to a genuinely equivalent replacement, use a suitable permanent redirect instead. Do not redirect unrelated missing pages to the homepage just to make the error disappear.

Keep the not-found template out of the public sitemap. Do not give every missing URL a canonical that pretends it is a normal content page. The essential signal is the correct response status, accompanied by helpful recovery content.

How does Cloudflare Pages handle a custom 404?

For a plain static Cloudflare Pages site, put 404.html in the published output at the top level to provide a custom not-found page. Pages also supports looking for a 404 file in the nearest applicable directory. Confirm the file exists in the deployed output, not only in a source folder that the build ignores.

Cloudflare documents that, without a top-level 404.html, Pages assumes a single-page application and applies its SPA behavior. That can serve the application entry point for unknown routes. It may be intentional for a client-routed app, but it is usually the wrong fallback for a plain collection of HTML pages.

Functions, framework adapters, and custom routing can change which handler processes a request. A static 404 file does not prove every application route now returns the correct status. Test missing URLs in each relevant routing area and read the framework or function’s routing configuration.

How do you stop the error page’s own assets from breaking?

The browser generally still shows the requested missing URL. If the 404 template uses a relative asset reference such as assets/site.css, a request at /old/services/missing/ may resolve that reference beneath the missing path.

On a domain-root website, use appropriate root-relative references such as /assets/site.css and /contact/. A site served under a project prefix needs that prefix handled correctly. Test a deeply nested missing path, not just a short one.

Keep the page light. Large videos, complex animations, third-party widgets, or a JavaScript-only redirect are poor dependencies for helping someone who is already stuck. Reuse the existing brand styles without adding an unnecessary application.

What should a 404 test include?

1. Choose a clearly nonexistent path, such as /this-test-page-does-not-exist/.
2. Open it directly and verify the HTTP status in Network or with a command-line request.
3. Repeat at a deeply nested missing path.
4. Check that CSS, images, and recovery links work from both addresses.
5. Test keyboard use, mobile layout, and recovery with JavaScript disabled.
6. Confirm valid pages still return their expected successful responses.
7. Test an intentional redirect separately and verify its destination.
8. Repeat the same checks on production after deployment.

curl -s -o /dev/null -w '%{http_code}
'   https://example.com/this-test-page-does-not-exist/

Opening /404.html directly tests the template, not the missing-route behavior; always test an invented missing URL. Replace the example domain with your own. This command reports the initial HTTP status without following redirects. If the host redirects to a canonical hostname or trailing-slash address, inspect that chain and the final response separately. A local static server may not implement your production host’s fallback rules.

How do you decide which broken links to fix?

Fix internal links to missing pages at their source. For an old URL with a relevant replacement, add and test a targeted redirect. For content with no replacement, keep a truthful not-found response and useful navigation. Distinguish real customer journeys from random automated requests before spending time on every unknown path.

A short record can include the broken URL, where the link came from, intended destination, chosen fix, and verification date. Avoid storing raw query strings or other information that could contain private data when a path-level record is enough.

Use the new-page checklist to prevent path mistakes during future additions. For a wider URL transition, the redesign SEO checklist covers mapping and migration decisions. A polished 404 page supports recovery; it cannot replace repairing important broken links.