How to fix soft 404 errors
A soft 404 is Google’s assessment that a response looks like an error or lacks the expected content even though it returns a success status. Inspect both the HTTP response and the rendered page before choosing a repair.
Start with the reported URL
Save the exact URL, Search Console coverage state and last crawl date. A current browser screenshot alone cannot reconstruct what Google received on its earlier crawl. A soft-404 label is not proof that the URL is currently indexed. Google’s Page Indexing reference describes the reported states.
Capture status and content separately
Use a GET request, retain every redirect response, and inspect the saved body. Replace this illustrative URL with the affected public URL; the command’s output is your evidence, not the example address.
curl -sS -L -D response-headers.txt -o response-body.html 'https://example.com/affected-url'
Then use URL Inspection to compare the indexed result with a live test and rendered screenshot. A failed script or missing resource can leave the rendered page empty even when the initial request succeeded. URL Inspection documentation.
Choose the repair from the observed state
| Illustrative evidence | Action to verify |
|---|---|
| GET returns 200; body says the retired item was not found | If it has no replacement, return an appropriate 404 or 410 and retain a helpful error page. |
| GET returns 200; intended page is blank after rendering | Repair the content or rendering failure, then check the rendered result. |
| An old URL has a directly equivalent replacement | Use the appropriate permanent redirect and verify its final destination. |
| GET returns 403, 429 or 5xx | Investigate the observed access/server failure. It is a different response from the 200 example. |
An intentionally missing URL can be correct
Google can remove previously indexed URLs that return 4xx. A 200 response does not guarantee indexing. Select a response that matches the resource’s actual state; do not turn every retired page into a homepage redirect. Google’s HTTP status-code reference.
Keep a before/after receipt
Record URL, capture time, status/redirect chain, body or screenshot, deployed revision and later inspection date. Mark the repair verified only when the intended response changed. Mark indexing or ranking separately when those outcomes are observed. This page provides a diagnostic workflow, not a claimed customer recovery.
Also inspect canonical declarations and Bing’s own indexing evidence.