UX Patterns Guide
UI + UX Feedback, Status, And System State standard

Page not found page

Show a clear page not found page that keeps orientation, states the page cannot be found, avoids blame and technical jargon, provides useful recovery routes, preserves privacy for protected resources, and records the missing URL as a 404 for repair.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • A route, URL, public page, file, object link, or deep link cannot be found.
  • Users might have typed, pasted, bookmarked, or followed a link to a page that does not exist.
  • A removed page has no direct redirect or only a closest recovery destination.
  • The product intentionally masks a protected resource as not found to avoid disclosing existence.
  • The team needs to measure and repair broken links.

Avoid when

  • The service route exists but is temporarily closed, overloaded, or under maintenance.
  • A valid page loaded but a component, save, upload, search, or section operation failed.
  • The requested page is valid and successfully loaded but contains no items.
  • The user lacks permission and a safe access-request or role explanation can be shown.
  • The resource has permanently moved and a direct redirect to the replacement route is available and honest.
  • The user is still waiting for a normal load to resolve.

Problem it prevents

Users arrive at a URL the product cannot resolve and need to understand whether they mistyped an address, followed a broken or removed link, used an expired deep link, or reached a private resource whose existence cannot be disclosed.

Pattern anatomy

What a strong implementation has to make clear

User need

Users may arrive from bookmarks, search results, letters, email links, notifications, copied addresses, external referrals, or stale in-product links.

Pattern promise

Show a clear page not found page that keeps orientation, states the page cannot be found, avoids blame and technical jargon, provides useful recovery routes, preserves privacy for protected resources, and records the missing URL as a 404 for repair.

Required state

Unknown route from typed or pasted URL.

Recovery path

Homepage redirect hides the missing URL and makes users think the task restarted.

Access contract

Use a unique page title and H1 that state the page was not found.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A benefits service 404 page says Page not found, shows the requested path only if safe, offers Search benefits, Start a new application, Report this link, and Contact support.
  • An expired signed-in return link says the page cannot be found and routes the user to their dashboard where current applications are listed.
  • A user who mistyped a web address sees clear check-the-address advice and can search the service immediately.
  • A user follows a removed public help article and is sent to the replacement topic plus a report-broken-link route.
Weak implementation

Vague, hidden, hard to recover from

  • A bare 404 code with a single Home button.
  • An automatic homepage redirect that hides the broken URL and leaves users unsure what happened.
  • Users are sent to the homepage with no explanation and assume their task was lost.
  • A missing page is described as a service outage even though the rest of the service works.
UI guidance
  • Render a full page with site or service identity, a page title and H1 that state the page was not found, concise likely causes, and recovery routes such as search, start page, account dashboard, contact, or report-broken-link.
  • Keep standard header and footer navigation when it helps orientation, but avoid breadcrumbs or path trails that imply the missing page has a valid hierarchy.
UX guidance
  • Use a page not found page when the service is reachable but the requested URL, public page, resource, or deep link cannot be resolved.
  • Help users recover without blame: let them check a typed or pasted address, search the service, return to a stable start or dashboard, report a broken link, or continue a current task when a deep link expired.
Implementation contract

What the implementation must handle

States

  • Unknown route from typed or pasted URL.
  • Broken in-product link.
  • Removed public page with a replacement or closest topic route.
  • Expired deep link that routes signed-in users to a dashboard or current task list.

Interaction

  • The page loads as a stable destination instead of redirecting users without explanation.
  • The page title, H1, visible copy, HTTP status, and analytics all agree that the requested resource was not found.
  • Recovery links lead to valid destinations and are labeled by destination rather than vague escape words.
  • Search, if present, accepts keyboard input, submits reliably, and preserves the user's query.

Accessibility

  • Use a unique page title and H1 that state the page was not found.
  • Keep the explanation and recovery actions in logical reading order after the heading.
  • Ensure search, links, buttons, and report controls are reachable and operable by keyboard.
  • Do not rely on color, code numbers, illustrations, or humor to communicate the condition.

Review

  • Can users tell that the URL did not resolve while the service may still be reachable?
  • Does the page give recovery paths that match how this user arrived?
  • Is the missing path safe to show, or would it disclose a protected object?
  • Are broken links and recovery actions measurable for repair?
Interactive lab

Inspect the states before you copy the pattern

Recover from a missing route

Switch a service route through typed URL, moved page, expired deep link, private no-disclosure, search recovery, report link, popular links, and signed-in return states; compare with auto-redirect, bare 404, outage confusion, dead-end, searchless, and private-title leak misuse.

Page not found page
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

Unknown route from typed or pasted URL.

Keyboard / Access

Focus lands on the not-found heading or first meaningful recovery control after route resolution.

Avoid Generating

Returning a successful status with page-not-found copy.
Evidence trail

Source-backed claims behind this guidance

GOV.UK page not found pages

GOV.UK Design System - checked

GOV.UK documents page-not-found use cases, no-blame copy, page title and H1, contact guidance, link testing, and exclusions such as technical jargon and breadcrumbs.

MDN HTTP 404 Not Found

MDN Web Docs - checked

MDN documents 404 as the response when the server cannot find the requested resource and distinguishes it from 410 Gone.

CMS Design System 404 page guidance

CMS Design System - checked

CMS documents 404 next actions, search or homepage routes, header and footer continuity, functional links, analytics, responsive behavior, and keyboard access.

EPA Page Not Found web standard

United States Environmental Protection Agency - checked

EPA requires clear page-not-found title content, a way to find information, homepage or search links, and other helpful information.

Full agent/debug reference

Problem Context

  • Users may arrive from bookmarks, search results, letters, email links, notifications, copied addresses, external referrals, or stale in-product links.
  • The missing route may be a public content page, service step, deleted object, expired signed link, renamed resource, or protected object that must not disclose existence.
  • The service itself may be healthy, so outage, spinner, or local component error treatment would misrepresent the condition.
  • The organization needs operational evidence to find broken links, redirect removed pages, retire stale communications, and improve search recovery.

Selection Rules

  • Choose page not found page when the requested route, page, file, object URL, or deep link does not resolve to a valid destination.
  • Use typed or pasted address guidance when users may have entered an incorrect or incomplete URL.
  • Use moved or removed page guidance when the product knows the old page has a replacement, archive, topic page, or support route.
  • Use signed-in dashboard recovery when a deep link expired or an account-scoped task moved to another current state.
  • Use neutral no-disclosure copy for protected resources when the product must not reveal whether a private object exists.
  • Provide search only when it is available and likely to recover the missing content; otherwise route to a start page, dashboard, sitemap, contact page, or support queue.
  • Offer report-broken-link or contact paths when broken internal links, letters, forms, or external references may need correction.
  • Use service unavailable page when the valid service route exists but cannot currently handle requests.
  • Use error state when a valid page or section failed after loading enough context for in-place recovery.
  • Use empty state when the requested page is valid and loaded successfully but the resulting collection contains no objects.

Required States

  • Unknown route from typed or pasted URL.
  • Broken in-product link.
  • Removed public page with a replacement or closest topic route.
  • Expired deep link that routes signed-in users to a dashboard or current task list.
  • Private or policy-masked resource that uses no-disclosure copy.
  • Search recovery state with query entry and useful suggestions.
  • Report broken link or contact support state.
  • Popular or common task links state for broad public pages.
  • Localized or service-scoped not-found page.
  • Logged 404 state with missing path, referrer, and safe diagnostic identifier.

Interaction Contract

  • The page loads as a stable destination instead of redirecting users without explanation.
  • The page title, H1, visible copy, HTTP status, and analytics all agree that the requested resource was not found.
  • Recovery links lead to valid destinations and are labeled by destination rather than vague escape words.
  • Search, if present, accepts keyboard input, submits reliably, and preserves the user's query.
  • Private-resource variants avoid disclosing names, owners, counts, or IDs beyond what the user's role is allowed to know.
  • The missing path and referrer are captured for diagnostics without exposing sensitive values in the visible UI.

Implementation Checklist

  • Configure the route, edge, or server to return a real 404 status for unresolved public URLs.
  • Use a page title that includes Page not found and the service or site name.
  • Write concise no-blame copy that explains likely address, copied-link, moved-page, or removed-page causes.
  • Add search, start-page, dashboard, contact, report-broken-link, replacement-page, or popular-task links according to the product context.
  • Keep header and footer navigation when they help orientation, but remove breadcrumbs that imply a valid parent trail for the missing page.
  • Avoid technical jargon, humor that obscures the condition, warning colors as the only signal, and raw routing errors.
  • Track missing URL, referrer, account state, locale, and recovery link usage so teams can repair broken links and redirects.
  • Test external links, bookmarks, old route redirects, unauthenticated and authenticated deep links, protected resources, screen readers, keyboard navigation, zoom, and mobile widths.

Common Generated-UI Mistakes

  • Returning a successful status with page-not-found copy.
  • Automatically redirecting to the homepage without explaining that the requested page was not found.
  • Using page not found for a service outage, form validation problem, submission failure, loading delay, or empty collection.
  • Showing only a code, stack trace, route matcher name, or framework error.
  • Providing no search, start, dashboard, contact, replacement, or report-broken-link route.
  • Revealing private object names or owners in a no-disclosure context.
  • Leaving old letters, emails, help pages, and in-product links pointed at missing URLs.

Critique Questions

  • Can users tell that the URL did not resolve while the service may still be reachable?
  • Does the page give recovery paths that match how this user arrived?
  • Is the missing path safe to show, or would it disclose a protected object?
  • Are broken links and recovery actions measurable for repair?
  • Would this situation be more accurately handled by service unavailable page, error state, empty state, permission denied state, or redirect?
Accessibility
  • Use a unique page title and H1 that state the page was not found.
  • Keep the explanation and recovery actions in logical reading order after the heading.
  • Ensure search, links, buttons, and report controls are reachable and operable by keyboard.
  • Do not rely on color, code numbers, illustrations, or humor to communicate the condition.
  • Make link names destination-specific, such as Search benefits or Return to account dashboard.
  • On single-page applications, move focus to the page heading or announce the route change when the not-found page renders.
Keyboard Behavior
  • Focus lands on the not-found heading or first meaningful recovery control after route resolution.
  • Tab order moves from explanation to search, primary recovery route, secondary links, contact, and report-broken-link controls.
  • Search can be submitted with Enter and results preserve the query.
  • Report-broken-link controls do not trap focus and return users to the not-found page or a clear confirmation.
  • Auto-redirects do not steal focus because recovery stays user-initiated.
  • Header and footer navigation remain reachable when included.
Variants
  • Public 404 page
  • Service-scoped 404 page
  • Search-led 404 page
  • Moved or removed page recovery
  • Expired deep-link recovery
  • Authenticated dashboard recovery
  • Private no-disclosure 404
  • Report broken link page
  • Localized page not found
  • Custom static 404 page

Verification

Last verified: