Building useful websites

Your 404 page may return 200: check the real HTTP response

A page can say “not found” while the server reports success. Check the requested URL, response status and visible content together; each answers a different question.

By coru · Published 2026-10-21 · Updated 2026-10-21

Start with three URLs, not a sitewide change

Choose one published page that should work, one deliberately nonexistent address under the same section, and—if you have one—an old URL with a known replacement. Record what each should do before testing. Use public pages you manage, without login tokens or private query strings.

For example, a repair café site might have /guides/mend-a-seam/, a nonexistent /guides/missing-check-7q9/, and an old /sewing-help/ address. These are invented examples. Testing a random path alone can miss a broken rule limited to one section.

Google may classify an error-like response as a soft 404 even when the server sends a success status. A 200 response does not guarantee indexing. The checks below inspect your response; they do not reproduce Google’s classification.

Read the document response in your browser

A normal browser page can render an error document. Its design, title and screenshot do not tell you the HTTP status. If a service worker supplies the response, the browser result may differ from the direct network check below; record that difference before changing the server.

Open Developer Tools → Network before loading the address. Enable Preserve log and Disable cache while DevTools is open. Load the complete test URL directly.
Select the document request (Doc), not an image, stylesheet or favicon. In Headers, record Request URL and Status Code. If there is a redirect, inspect its row and Location header as well as the final document.
Read the visible page. Does it contain the intended article, a useful missing-page explanation, a login screen or a generic home page? Save the final address separately.
Repeat for the known working URL and the known moved URL. A red 404 for a missing image does not establish that the HTML document returned 404.

Check the GET response with curl

In a macOS or Linux terminal, replace the example URL in this command. It requests the page with GET, prints response headers and discards the body:

curl -sS --max-time 15 -D - -o /dev/null "https://example.com/guides/missing-check-7q9/"

Read the HTTP status line and any Location header. This command does not follow redirects. On Windows, use curl.exe and replace /dev/null with NUL. Do not substitute curl -I for this check: that requests HEAD, so you would be testing a different method.

To follow a known redirect and report its destination, use:

curl -sS -L --max-redirs 5 --max-time 15 -o /dev/null -w "%{http_code} %{url_effective}\n" "https://example.com/sewing-help/"

The second command reports the final status. Keep the first response too: a final 200 alone hides the redirect. Inspect the destination in a browser to confirm that it supplies the promised replacement.

By default, curl can exit successfully after receiving HTTP 404. Its exit code describes the transfer, not whether your article exists. With --fail, an HTTP error normally produces curl exit 22; still inspect the HTTP status when diagnosing a specific URL.

Our controlled test: identical page, different status

On 21 October 2026 we served the same 96-byte error document at two local test URLs. Both displayed “Page not found” and “Try the article index.” in Chrome 155.0.8059.12. The response body hashes were identical. Only the route’s response status differed.

To reproduce the comparison in your own staging environment, make two routes serve one shared error template: return 200 from the first and 404 from the second. Compare their document requests and visible text. Add a redirect to a working page and compare the initial and final statuses. Remove the deliberately incorrect route after the test.

This was a local technical demonstration, not a test of Google indexing or real reader behaviour. It shows why a screenshot and a successful curl exit are insufficient acceptance checks.

/soft-missing: HTTP 200; curl 8.5.0 exit 0; visible missing-page message.
/fixed-missing: HTTP 404; curl exit 0 without --fail and 22 with it; the same visible message.
/moved: HTTP 301 with Location: /index; the follow-redirect check reported HTTP 200 at /index.

Choose the repair from the intended result

A generic checklist cannot supply the exact configuration for every host, framework or CDN. Give whoever controls routing the failing URL, expected result, initial status, final URL and visible result. Ask them to preserve the working control page while repairing the missing route.

The page should exist, but it shows an error or empty content: restore the route, content or data dependency. Check the rendered result before treating 200 as success.
The address never existed, or content was removed without a suitable replacement: return a real 404 (or 410 for intentionally gone content) while showing a useful explanation and links. Changing the heading to “404” does not change the response status.
There is a clear permanent replacement: redirect the old URL to that specific page, then check its content and final status. Sending every missing address to the home page makes the destination less useful and can still lead to a soft 404 diagnosis.
A working article starts returning 404 after a routing change: fix the routing rule. Do not apply a blanket 404 to every address handled by an application shell.

Retest the public route after deployment

Repeat all three checks on the public hostname after the change. Test the real path, not only the error-template file; the template can return 200 when opened directly while the missing route correctly returns 404. Check a fresh browser session as well as curl if caching or a service worker affected the earlier result.

Use this acceptance note: “URL → intended result → initial status → final URL/status → visible result → checked at.” Keep one known-good URL as a regression control. If Search Console previously reported a soft 404, compare its crawl date with your change; a successful local retest does not establish that Google has recrawled or indexed the page.