Soft 404: Why Google Treats a Working Page as Missing

01

Preconditions

Collect the exact URL, its raw HTTP status, its rendered HTML, and the content that should appear. A soft 404 is not simply a custom error page. It is a mismatch between a success-like response and a page that Google interprets as missing, empty, broken, or error-like.

Google says a 2xx response can move content into processing, but an empty page or visible error message can still be classified as a soft 404. How HTTP status codes affect Google's crawlers^[2]

Before editing, decide which state is true:

• The page and content are permanently gone.
• The content moved to a clear replacement.
• The page should exist, but its content failed.

That decision controls the response. Cosmetic changes to an error template do not resolve a wrong status.

02

Ordered process

1. Compare a real 404 with the reported page.

Search Console describes a soft 404 as a request that returns a user-friendly not-found message without a real 404 response. Page indexing report^[1]

1. Inspect the raw response before rendering.

Confirm whether the server returns 200, 204, a redirect, or a real error. Check both the first and final response. A route can redirect to an error template that then returns 200.

1. Inspect the rendered main content.

Use URL Inspection’s tested page, rendered HTML, screenshot, and resource list. Look for:

• an empty application shell;
• a database or API error;
• a “no results” message with no useful alternative;
• a missing server-side include;
• a consent layer hiding the page;
• primary content loaded only after a failed script;
• a title and navigation surrounding no main content.

Google specifically lists empty internal search results, missing JavaScript files, database failures, and missing includes as common soft-404 sources. Troubleshoot Google Search crawling errors^[3]

1. Classify the page as gone, moved, or broken.

1. Repair internal search and expired inventory deliberately.

An internal search with zero matches can be useful to a person, but it is usually not a standalone search landing page. Keep it out of indexable inventory and avoid generating crawlable combinations without distinct value.

For expired products, events, jobs, or listings, decide whether the page retains lasting information. A page with useful specifications, documentation, or historical context may remain a real page. A shell that only says “unavailable” may be better removed or redirected to a genuinely equivalent successor.

1. Avoid irrelevant homepage redirects.

Redirecting every removed URL to the homepage obscures whether the content moved. It can confuse visitors and may be interpreted as a soft error. Redirect only when the destination is a close replacement.

1. Test JavaScript routes under failure conditions.

Single-page applications often return 200 for every route because the server serves one shell. If the client later discovers that the item does not exist, the rendered page becomes an error while the response remains successful. Google’s JavaScript guidance recommends routing to a server URL that returns 404, or applying noindex to the error view when a meaningful HTTP status is impractical. Fix Search-related JavaScript problems^[4]

1. Retest the final response and rendering.

Use an uncached request, a normal browser, and a current live URL test. URL Inspection separates indexed data from live-test data, so record the last crawl date before expecting the report to clear. URL Inspection Tool^[5]

03

Failure cases

• The server status alone is trusted. A 200 only says the request succeeded; the returned content may still be empty or erroneous.
• The screenshot alone is trusted. A polished custom error page can still carry the wrong status.
• Every expired item redirects to a category. The destination may not answer the original intent.
• Text is added to disguise a missing page. Decorative copy does not restore the expected resource.
• A client-side router owns every error. The origin never emits a meaningful missing response.
• Crawler requests receive a different application state. Bot protection, cookies, geography, or failed APIs can change rendering.
• A transient backend failure is treated as permanent removal. Fix the availability layer before returning a lasting 404 or 410.

If the page is genuinely gone, follow the Not Found 404 decision guide. If the failure is caused by an unstable backend, continue with Server Error 5xx.

When a live test and ordinary browser disagree, compare the exact rendered main content, resource failures, response time, and cache state. The correct repair follows the resource’s intended state, not whichever tool produced the more convenient label.

Preserve a failing example before the change and retest the same URL afterward. This distinguishes a repaired template from an unrelated page that happened to render correctly.

04

Completion criteria

The diagnosis is complete when the raw response, rendered page, and intended content state agree.

The repair is complete when:

• a gone page returns 404 or 410;
• a moved page redirects directly to a relevant replacement;
• a live page renders its primary content without critical resource failures;
• internal search and expired inventory do not create empty indexable shells;
• the custom missing page remains useful to people;
• internal links and sitemaps exclude removed URLs;
• live URL Inspection shows the intended response and rendered result.

The Page Indexing report may continue showing the earlier classification until Google recrawls the URL. Use the report as inventory, not as an instant deployment monitor. The broader Page Indexing guide and indexing flow provide the next diagnostic context.

References

Sources behind this record

1. Page indexing report — Google (accessed July 25, 2026)
2. How HTTP status codes affect Google's crawlers — Google (accessed July 25, 2026)
3. Troubleshoot Google Search crawling errors — Google (accessed July 25, 2026)
4. Fix Search-related JavaScript problems — Google (accessed July 25, 2026)
5. URL Inspection Tool — Google (accessed July 25, 2026)

Corrections

Correction history

No corrections recorded.

To report an error, use the public corrections path.