What Is a Soft 404, and How Is It Different from a Normal 404?
Understand soft 404s, compare page content with the HTTP response, and choose a relevant replacement or a genuine not-found page.
Part of our guide: What Is Technical SEO and Why Does It Matter?
A normal 404 response tells a browser or crawler that the requested page was not found. A soft 404 is a search-engine interpretation that a page looks missing or unusable even though the response does not communicate that appropriately, often because it returns a success status.
The important distinction is between what the visitor sees and what the server says. Fixing one without the other can leave a confusing result.
Check content and response together
A branded page saying “sorry, nothing here” may look helpful to a person while returning HTTP 200, the usual success response. Conversely, a genuine article might accidentally return an error status.
Google’s HTTP status guidance explains why response codes matter and why a success response does not guarantee indexing. Its Page indexing documentation describes the soft-404 status.
Ask the developer to check the actual response, including the final destination after redirects.
Use a response-and-content decision table
| What the visitor receives | Response or behaviour | Appropriate investigation |
|---|---|---|
| A genuinely missing page | Successful 200 response | Return the correct not-found status |
| Useful intended content | 404 response | Correct the erroneous response |
| Removed content with a close replacement | No onward route | Consider a relevant redirect |
| Removed content with no replacement | Genuine 404 or 410 | Keep helpful navigation; do not invent a substitute |
| A blank or broken template | 200 response | Repair rendering or content delivery |
This table is an investigation aid, not a reason to change every response across the website.
Decide whether there is a real replacement
If an old service page has moved to an equivalent new page, a redirect may make sense. If the service has disappeared entirely, the homepage is not automatically an equivalent replacement.
Our redirect guide explains the route change, while Page with redirect in Search Console explains what happens to the source address.
Think about the visitor who followed the old link. Would the destination fulfil the expectation created by that link? If not, a clear not-found page with useful navigation may be more honest.
Investigate pages that should still exist
If a valuable page is flagged, check whether its main content appears reliably without an administrator session. Look for failed data requests, missing products, empty templates or error messages inside an apparently successful page.
Capture the exact address and conditions. A temporary service failure may not reproduce in the office several hours later, so logs and timestamps can matter.
Use the technical SEO guide to organise the investigation. Do not rewrite all the copy before checking whether the page was actually delivered.
Make a not-found page useful
A genuine not-found page can explain that the address is unavailable and offer navigation to important sections or a search feature where appropriate.
Avoid pretending the missing content is still there. Do not automatically redirect every unknown URL to the homepage.
Check that the error page itself remains accessible and readable on mobile. The visitor needs a way forward, not a technical code with no context.
Repair the links that create the journey
Correct links under your control that still point to retired or misspelled addresses. Our broken-link checklist covers finding those source locations and recording the repair.
For a larger content review, use update, merge or delete to agree which URLs should remain. Keep a mapping of changed pages so future editors understand the decisions.
External links may continue to use old addresses, which is one reason relevant redirects can still be useful after internal links are corrected.
Verify before declaring the issue resolved
Test the source, final destination, visible content and returned status. Record the change date and review subsequent Search Console evidence when available.
A report can take time to reflect a correction. Repeatedly requesting indexing does not replace checking the response.
If the problem involves a wider loss of visibility, the guide to a website disappearing from Google gives context. Focus this repair on delivering an honest response and a useful next step, not simply removing a warning from a dashboard.
Thinking about your own rebuild?
Tell us about your business, your current website and what you would like to improve. We will help you work out the next step.
