A missing page should not masquerade as a successful page
A soft 404 is a URL that appears missing or unhelpful but returns a successful response such as 200, confusing the signal sent to crawlers. Google’s JavaScript SEO guidance recommends meaningful HTTP status codes and specifically calls out soft 404 risk in client-side applications. Return a real 404 for content that does not exist, or a suitable alternative status for a deliberately removed resource.
Start by sampling expired products, misspelled URLs, old campaign paths, and application routes whose data record has been deleted. Record status, title, primary heading, visible message, canonical tag, robots directive, and any redirect. A friendly design with search links is compatible with a 404; the status is what makes the response unambiguous to an HTTP client.
Trace the route, not the page shell
Consider a ticket site where /events/sold-out-2024 fetches no record but renders the normal event template saying “Event unavailable,” returns 200, and canonicals to itself. A visitor sees an error; a crawler sees a successful, indexable URL. Change the server route to emit 404 with a useful not-found page. If a single-page application cannot produce that status for its client route, Google documents alternatives: redirect to a server URL that returns 404 or ensure the error state has noindex. A server-side 404 remains clearer when available.
Run direct HTTP checks with JavaScript disabled as well as the normal UI path. Confirm that CDN fallback rules do not rewrite all unknown routes to index.html with 200. Check that a deleted page is removed from the XML sitemap and no longer receives internal links. The XML sitemap audit checklist and redirect chains guide help close those related paths.
Do not create a different indexing problem
Do not redirect every missing page to the homepage. Do not make a bare 404 that abandons users; offer navigation or search without pretending the requested item exists. Do not label a temporary outage as permanent deletion. Do not use noindex as a substitute for an accurate status where the server can return one.
The AI search readiness checker can show raw response status and page evidence for a supplied URL. It does not diagnose every search engine’s classification or promise removal timing. Recheck after route-framework upgrades and template changes.
Cover invalid routes in release tests
Test missing IDs, invalid slugs, and out-of-range pagination as explicit routes. These cases often bypass the ordinary server path and regress after frontend changes. A good missing page keeps useful navigation while plainly saying that the resource is unavailable; its response status should remain just as clear.
FAQ
Log the decision for each major removal: replacement, 404, or another deliberate response. That record prevents later teams from restoring an obsolete route merely because it appears in old reports.
Can a polished 404 page still be a real 404?
Yes. Helpful content and a 404 HTTP status work together.
Should a deleted product use a redirect?
Redirect only when there is a close, useful replacement. Otherwise return an appropriate missing or removed response.