Soft 404: Your Page Isn't Fine
Key takeaways
- Google describes a soft 404 as a page that returns a success status but displays an error or lacks main content: Google's troubleshooting guidance.
- Removed content without a similar replacement should return 404 or 410; moved content with a clear replacement can use a 301 redirect.
- A valuable page may be misclassified if important resources fail to load, so inspect what Google can render rather than checking the status code alone.
- URL Inspection distinguishes Google's indexed information from a live test; neither is a guarantee of future search visibility.
What is a soft 404?
A soft 404 is a mismatch between an apparently successful response and a page that looks like an error or has no useful main content. Google Search Central describes the common case as a page returning HTTP 200, the success status, while telling the visitor it does not exist.
Google also lists causes such as an empty internal search result, a broken database connection or an unloaded JavaScript file. It says pages recognised as these error pages are excluded from Search and reported as soft 404s in the Page Indexing report.
The important distinction: soft 404 is not the response your server necessarily sent. It is Google's assessment of what that response contains. A green uptime check and a missing commercial page can therefore coexist quite comfortably. Only one of them is pleased about it.
Which soft 404 URLs deserve attention first?
Prioritise pages that should help a customer make a decision, not every historical URL in a report equally. Our recommendation is to group flagged URLs by template and intended business purpose before assigning fixes.
Separate live product pages, service pages, discontinued items, empty search pages and obsolete campaign URLs. Then inspect representative examples from each group. A shared template failure deserves a different response from a genuinely removed page.
Do not assume that every reported URL is a lost ranking opportunity. Google's own decision framework starts by asking whether the content still exists, has moved or is no longer available.
For an ecommerce business, the useful question is whether the intended product information loads. For a lead-generation site, it is whether the visitor can actually understand the service. Counting errors without deciding what each page should do produces a longer spreadsheet, not a repair brief.
Should you fix the page, redirect it or remove it?
Choose the outcome that matches the content's real state and the visitor's intent. Google's soft 404 guidance supports this decision table:
| Real state of the content | Appropriate direction |
|---|---|
| Useful page still exists but loads incorrectly | Repair the content or required resources, then inspect the rendered page and response |
| Content moved or has a clear replacement | Use a 301 permanent redirect to that replacement |
| Content removed with no similar replacement | Return 404, not found, or 410, gone |
The replacement must make sense to the visitor. Our recommendation is not to redirect every discontinued product or old service URL to the homepage merely to reduce the report count. Ask whether the destination answers the original request.
A custom missing-page design is fine. Google says it can include helpful navigation and links, but the server should still return the correct 404 status. Changing the text to something friendlier does not require pretending the page exists.
What if the page looks fine in your browser?
Inspect the rendered content and loaded resources, because your browser view does not establish what Google's tools received. Google notes that missing resources, prominent error messages and blank or nearly blank rendering can trigger soft 404 classification.
Open the URL in Search Console's URL Inspection tool. Review the available rendered screenshot, page code, resource information and JavaScript output. Record the test time and the exact URL, including any parameters.
Compare that evidence with the page the business intends to serve. Does the main service description appear? Does the product content load, rather than only the surrounding navigation? Is an error message occupying the area where the actual answer should be?
Our JavaScript SEO guide covers the broader rendering problem. For a soft 404, keep the investigation specific: identify the missing content or failed dependency before recommending a platform rebuild.
Is returning 200 enough to close the issue?
No: returning 200 is precisely what many soft 404 pages already do. The response needs to match a useful, correctly rendered page, as Google's definition makes clear.
After a repair, test the affected page and a representative set of pages using the same template. Check an intentionally missing URL too, to make sure the fallback route has not started presenting every invented address as a successful page.
These are our suggested acceptance checks, not a claim that we have tested your site. They help separate a genuine template repair from a change that merely hides the original symptom.
If the outcome is removal or redirection, review the links and sitemap entries that still point to the old address. Our XML sitemap guide explains the discovery side of that housekeeping. Updating a sitemap is not a substitute for fixing the page response.
What evidence should a developer hand back?
Ask for a short URL-level record that shows what changed and what the page now does. Our recommended handover contains:
- Exact URL and intended business purpose.
- Original response, visible problem and affected template.
- Chosen outcome: retained page, relevant redirect or removal.
- Change deployed and deployment time.
- Current response and final destination, where relevant.
- Rendered content evidence and any remaining failed resources.
- Live inspection result and a separate later indexing observation.
Keep the last two items separate. Google's documentation says indexed information is not a live test, and a live test cannot predict Google's selected canonical URL.
A successful live check is evidence about the current implementation. It is not proof that Google's historical report has already updated, that the URL will rank or that any AI answer engine will cite it.
Limitations
This is a troubleshooting framework based on current Google documentation, not an audit of your Search Console property. It does not show that your site has soft 404s or that every excluded page needs restoring.
Technical repairs do not guarantee indexing, rankings, traffic or leads. The article does not measure how other search engines or AI systems handle the same URLs. Generated images are conceptual illustrations, not screenshots, client evidence or performance results.
What is the next useful step?
Build the URL evidence record for one important affected page and use it to brief your developer. Once the intended outcome is agreed, expand the investigation to other pages using the same template.
If you want to discuss how that work fits wider search and answer visibility, start a conversation through SAGEO. Bring the URLs and observed behaviour, not just the report total.
Sources
- Troubleshoot Google Search crawling errors, Google Search Central. Soft 404 causes and the restore, redirect or remove decision; updated 18 December 2025.
- URL Inspection tool, Google Search Console Help. Indexed versus live information, rendering evidence and tool limitations.
- JavaScript SEO for AI Search, SAGEO.
- XML Sitemap SEO: Fix Discovery Signals, SAGEO.
- SAGEO: the conversation starts here. Current contact pathway.