A visitor who reaches a missing page has already spent effort. They followed a link, typed an address, opened a bookmark, or returned to something they expected to find. A helpful 404 page should not make them diagnose your website. It should tell them what happened and offer a short, credible route forward.

That does not mean turning every missing address into the homepage. It means choosing the correct response for the URL, writing a clear message, preserving useful site navigation, and learning enough from the broken path to repair what sent people there.

The page is a recovery point, not a decoration.

Decide whether the URL is truly missing

Before designing the page, decide what the requested address is supposed to do.

The HTTP standard defines 404 Not Found as a response for a resource the server did not find and is not willing to disclose as existing. The status does not say whether that condition is temporary or permanent. RFC 9110’s 404 section also notes that 410 Gone is preferred when a resource is known to be permanently unavailable.

In practical website maintenance, sort the URL into one of four situations:

  • The content moved and has a clear replacement. Send the visitor to that specific replacement with the appropriate redirect. Do not make them search for a page you already know.
  • The content was removed and has no equivalent replacement. Return an actual 404 or, when you intentionally need to signal permanent removal, 410.
  • The content still exists but the link is wrong. Fix the link and decide whether a narrowly targeted redirect helps people using the old address.
  • The site is temporarily failing. A database outage, maintenance window, or application error is not the same condition as a missing resource. Preserve the evidence and use the response intended for the real failure.

MDN’s 404 status reference distinguishes a missing resource from a known permanent removal and names mistyped, moved, and deleted URLs as common causes. The important decision is not “Do we have a nice error page?” It is “Does this exact URL return behavior that matches what happened?”

Return a real 404, not a successful-looking error

A page can say “not found” while its server response says 200 OK. That mismatch is often called a soft 404.

Google’s current guidance on troubleshooting crawling errors recommends a 404 or 410 when content is gone without a similar replacement, and a 301 when it moved to a clear replacement. It also warns against serving an error message with a successful 200 response.

This is not a ranking promise. A correct status code does not guarantee crawling, indexing, traffic, or conversion. It makes the server’s answer honest and gives browsers, search systems, monitoring tools, and maintainers a consistent signal.

Check the response itself. Do not rely on the large “404” heading in the browser. A command-line header check, browser network panel, hosting preview, or deployment test can show whether the requested URL really returns the intended code.

Avoid a catch-all redirect to the homepage. It erases the distinction between a mistyped address, an old campaign link, a removed service, and a page that has actually moved. It can also leave the visitor wondering why the content they requested disappeared.

Say what happened without blaming the visitor

The first screen should answer three questions:

  1. What happened?
  2. Can I continue?
  3. What should I try next?

Use direct language such as “Page not found” and “The address may be incorrect, or the page may have moved.” Do not say “You entered the wrong URL” unless you can prove that is the only cause. The broken path may belong to your own navigation, an old email, a saved bookmark, or an external site.

The U.S. Web Design System’s 404 page guidance recommends a straightforward description, possible fixes, actions, support options, and the error code. It also advises against blaming the user and calls for a descriptive page title.

Keep the tone consistent with the rest of the site, but do not let a joke hide the problem. A clever illustration cannot replace a clear heading. The visitor should understand the situation before choosing a link.

Offer a small recovery ladder

More links do not automatically create more help. A full sitemap dumped under an error message shifts the navigation problem back to the visitor.

Start with the next steps most likely to recover the original task:

  • a specific replacement, when one exists;
  • the parent section or relevant service category;
  • site search, when the search actually works and is maintained;
  • the homepage;
  • a contact or support path for cases the page cannot resolve.

Use descriptive link text. “View website services,” “Search the journal,” and “Report this broken link” explain the result better than three identical “Click here” links. WCAG 2.2 says page titles should describe topic or purpose and that link purpose should be determinable from its text or programmatic context. The WCAG 2.2 recommendation is broader than a 404 page, and this checklist is not an accessibility-conformance audit. Those two requirements are still useful checks for a page whose entire job is orientation and navigation.

Preserve the site’s ordinary header and footer when they remain reliable. Familiar navigation reassures the visitor that they are still on the correct site. If the missing URL is inside a signed-in product or checkout, recovery may require a context-specific route instead of the public homepage; test that path with safe accounts and data.

Build the recovery plan before the page

The worksheet below turns vague “make the 404 nicer” feedback into decisions that can be implemented and verified.

The completed example is fictional. Maple Street Workshop is an imaginary local craft business. It is not a Fireproof Studio customer, product, traffic report, or search result. The URLs, owners, and observations are examples only.

On a phone or other narrow screen, swipe the table horizontally to read every column.

Requested URL or situation What the evidence says Intended outcome HTTP behavior Visitor message Recovery paths Accountable owner Verification and follow-up
/classes/winter-2025 from an old email The dated class ended and there is no equivalent session Explain that the page is unavailable and help the visitor find current classes 404 Not Found “That class page is no longer available.” Current classes; homepage; contact the workshop Content owner Confirm 404 response; test links; remove the expired URL from the sitemap; review email archive references
/book-a-class from the primary navigation The booking page moved to /classes/book and serves the same task Take the visitor directly to the replacement Permanent redirect to the exact replacement Replacement page content, not an error message The destination’s normal navigation Website owner Test old and new URLs; update primary navigation; verify the redirect does not loop
/clases typed by a visitor No matching page exists, but classes are a likely destination State that the address was not found and offer a likely section without forcing it 404 Not Found “We could not find that page.” Browse current classes; homepage; contact Website owner Confirm 404 response; check whether repeated demand justifies a targeted alias or new page
Missing product URL reported through support The item and removal reason are not yet confirmed Avoid inventing a destination while the owner investigates 404 Not Found until the source of truth is confirmed “This page is not available.” Shop categories; search; support Catalog owner Record the referrer and report; confirm product state; choose removal, restoration, or a specific redirect

The worksheet is a decision record, not a blanket redirect list. Each row binds one requested path to evidence, a visitor outcome, an HTTP behavior, recovery options, an owner, and a verification step.

Use evidence to repair the source of the dead end

A custom page helps after a failure. It does not remove the broken link that caused it.

Collect enough evidence to identify the source:

  • the missing URL;
  • the referring page or campaign, when available and appropriate;
  • the time and environment;
  • whether the path came from internal navigation, search, a bookmark, or an external link;
  • the response code actually returned;
  • repeated patterns, such as one old directory or a common typo.

The U.S. Web Design System recommends tracking 404 usage and referrers so teams can locate problematic links. Choose measurement that fits your site’s consent, privacy, retention, and analytics rules. Do not copy query strings, personal information, account identifiers, tokens, or other sensitive data into an ordinary report simply because it appears in a failed URL.

Prioritize fixes by visitor task and source, not only raw counts. One broken booking link in the main navigation can matter more than many random probes for files that never existed. Repair internal links at their source. Update owned campaign destinations. Ask external publishers to correct important links when practical. Add a targeted redirect only when the requested page has a genuine replacement.

This is part of ordinary website ownership. The handoff checklist in Who Owns a Website After Launch? can help assign responsibility for broken links, public facts, renewals, backups, and support.

Test the complete recovery path

Verify the page as a visitor and as a maintainer.

For at least one deliberately nonexistent URL:

  1. confirm the response is the intended 404, not 200, a loop, or an unrelated redirect;
  2. check that the browser title and visible heading clearly identify the not-found state;
  3. open every recovery link and confirm it reaches the promised destination;
  4. navigate with a keyboard and verify visible focus, logical order, menu operation, and a usable return path;
  5. inspect desktop, tablet, phone, and narrow layouts for clipping or off-screen controls;
  6. check that the page uses the current header, footer, support details, and brand treatment;
  7. verify that the missing URL is not being added to the sitemap or presented as a normal canonical page;
  8. confirm that any reporting path transmits only the intended safe context;
  9. review monitoring or analytics evidence without treating automated probes as customer demand.

The keyboard-only website check provides a focused path through menus, links, forms, dialogs, and recovery. Passing that practical check does not by itself establish accessibility conformance, but it can reveal whether the 404 page’s promised exits are actually reachable.

Re-test after every change. A corrected message does not prove the status code changed. A new redirect does not prove the destination works. A valid destination does not prove the old internal link was repaired.

Make the dead end honest and recoverable

A helpful 404 page does four jobs well.

It returns behavior that matches the URL’s real state. It explains the problem without blame. It offers a small number of useful next steps. It leaves enough evidence and ownership to fix the path that failed.

That will not guarantee rankings, eliminate every broken external link, or prove accessibility conformance. It will give visitors a clearer way forward and give the site owner a repeatable maintenance decision.

Need help reviewing or improving a website path? Tell Fireproof Studio what the visitor needs to accomplish.