Website · THE NO-PANIC PLAN
Audit a custom 404 page for correct status and recovery links
A good-looking error screen can still be broken if the server returns HTTP 200 for a missing page, or if real users have no useful way back. This workflow tests a missing route at the HTTP layer, reviews the message and recovery links, checks keyboard and link accessibility, then rechecks crawl signals after changes. HTTP Status Checker (tool 32193) can help interpret an observed status code; verify the live URL itself with your own browser network panel or command-line request and the production origin/CDN, because a local tool result alone does not prove what every client receives.
MISSION Verify that a website's missing-page experience returns the correct HTTP status, explains the problem clearly, offers accessible recovery paths, and is not misreported as a soft 404.
Check the missing route's HTTP statusTHE REAL-WORLD BIT
What happens outside this browser tab?
Decide whether the resource is missing, permanently gone, or moved; inspect the actual production response and redirect chain; improve the 404 content and useful destinations; test accessibility; then use crawler diagnostics and internal-link checks to close the issue without turning a real missing page into a soft 404.
YOUR CHECKLIST, WITH FEWER DRAMATIC SIGHES
One step at a time.
Follow the order below. If a step names a Nirmion tool, its link is right there with it.
- 01
Decide what should happen to the missing URL
Start with one exact URL that users or crawlers cannot open. Ask whether the resource still exists at another address, was removed with no replacement, is temporarily unavailable, or is being requested through a mistyped path. If there is a close replacement, use the site's approved redirect rule and test the destination; do not redirect every unrelated missing URL to the home page. If the origin has no current representation, RFC 9110 defines 404 Not Found; if the site knows the removal is likely permanent, review whether 410 Gone better reflects that state. Record the intended result before editing templates or routing. (Sources 1, 2)
- 02
Check the actual HTTP response and redirect chain
Request the missing URL on the deployed site from a browser network panel or a command-line client and record each response code, redirect target, and final URL. Test the exact path variant that failed, including language prefix or trailing slash if those are part of the site. Use HTTP Status Checker (Nirmion tool 32193) to interpret an observed code, then compare that result with the production request and origin/CDN logs; do not rely on page appearance alone. A branded message returned with HTTP 200 can be treated by Google as a soft 404, so make the server response agree with the resource state. (Sources 1, 2, 3)
- 03
Make the error page clear and give visitors a useful next step
Use a concise heading and plain explanation that the requested page is unavailable, then offer working paths that match the site's content: a site search, a link to the relevant section, the home page, and a support route when appropriate. Preserve the requested URL in the browser so visitors can correct a typo, and avoid a misleading success message, unexplained blank page, or automatic redirect that hides what happened. Check that each recovery link leads to a real, maintained destination and that the search form can be used without a mouse. The visual page is helpful content for people; the HTTP response still needs to represent the actual missing resource. (Sources 2, 4)
- 04
Test headings, links, focus, and small-screen behavior
Navigate the error page using only a keyboard and confirm that focus reaches the search and recovery links in a sensible order, remains visible, and does not get trapped. Read the page with a screen reader or accessibility inspection tool: the error heading should explain the state, and link labels should make sense in context instead of repeating vague text such as 'click here.' Check heading structure, text contrast, zoom, and narrow-screen layout, then confirm that the page does not hide the main message in an image. WCAG 2.2 includes success criteria for link purpose and headings/labels; use the site's full accessibility process for any broader conformance claim. (Sources 4)
- 05
Fix the source of the error and verify crawler reports
Search internal links, navigation, and submitted XML sitemaps for the missing URL. Correct internal references to the current destination, remove obsolete sitemap entries, and retain an appropriate missing response when no replacement exists. In Google Search Console, inspect the example URL and read the current error category; Google's documentation distinguishes a real 404/410 from a soft 404 where an apparently missing page returns success. After deployment, repeat the production response test, follow every redirect, check the page's recovery links, and review whether the error report changes. Do not treat a single successful browser render as proof that status, indexing, and user navigation are all correct. (Sources 1, 3)
THE HELPER CREW
Tools for the fiddly bits.
These are the currently published Nirmion tools matched to this guide. Open a tool page for its accepted inputs and limits.
RECEIPTS, PLEASE
Sources & review notes
Each source is linked to the steps it supports. Open it to check its scope and current guidance.
Source checked 2026-10-10