What is a soft 404? The error page that says one thing and does another
A soft 404 looks missing to a person but returns a successful status to machines. Here is how to find and fix the contradiction.
Filed: · By:Steve Bullis
A soft 404 is an error page wearing a 200 OK name tag.
The visitor sees “page not found,” an empty search result, or a nearly blank shell. The server tells browsers and crawlers that everything worked. Neither side is necessarily broken on its own. The problem is that they disagree.
Google defines a soft 404 as a URL that looks like an error page but returns a success status. A missing page can still have illustrations, navigation, search, jokes, and excellent typography. It should simply return the status that describes what happened.
Why soft 404s happen
Most are ordinary implementation mistakes:
- A catch-all application route renders the not-found component but keeps the default
200response. - A CMS sends every unknown slug to a generic page.
- An empty product or search template has no results but is technically “successful.”
- A JavaScript app discovers the missing record only after the original HTML response has arrived.
- A host redirects every bad URL to the home page.
That last one feels helpful, but it erases context. Someone following a link to a discontinued green lamp did not ask for the furniture store’s home page.
How to check one
Do not trust the pixels. Check the response.
curl -I https://example.com/a-page-that-cannot-exist-92841The first line should contain 404, such as:
HTTP/2 404Test a nonsense URL, not only /404. Some sites build a beautiful demonstration at /404 while their genuinely unknown routes behave differently.
Also test with JavaScript enabled and disabled when the site is client-rendered. A route can return a blank 200 document, discover the missing content in the browser, and then paint an error message too late for the response status to change.
How to fix it
The best fix is server-side: render the custom error design while sending 404 Not Found. Frameworks expose this differently, but the principle is stable. The response and the page should tell the same story.
If content moved to a clear replacement, use a permanent redirect to that specific replacement. If nothing comparable exists, keep the honest 404. Do not redirect a cemetery of unrelated URLs to home.
For a client-only application where the server cannot vary the status, Google documents two fallback approaches: redirect to a server URL that returns a real 404, or mark the client-side error page noindex. A real status remains the cleaner answer.
Is a soft 404 still worth looking at?
Sometimes. This museum prefers genuine 404 responses because implementation is part of the design. A famous or historically interesting page can still be admitted as a labeled soft 404 by editorial override.
That label matters. A charming page with the wrong response is not worthless; it is just an incomplete specimen.