Two pages can look identical to a visitor and behave in opposite ways for Google. Both display a “page not found” message. One tells the crawler the URL is gone and gets it dropped cleanly. The other tells the crawler the URL is fine, keeps it in the index, and quietly wastes crawl budget for weeks. The difference is a single number in the HTTP response: the status code. That number is the entire subject here.
This is a narrow topic on purpose. The full map of HTTP status codes is a separate reference, and redirect chains are their own cleanup problem. Here the focus is only the fork between a true 404 and its broken cousin, the soft 404, and what each one does to indexing.
What a status code actually decides #
When a browser or crawler requests a URL, the server answers with an HTTP status code that explains the outcome. The 404 code, the most familiar of the errors, means the requested resource was not found. That one number does real work across several systems. The browser uses it to decide whether to render the page or an error state. Google uses it to decide whether to keep the URL in its index, remove it, or treat the page as still meaningful. Analytics uses it to flag a missing-page event. A CDN uses it to decide whether and how long to cache the response.
Trouble starts when the response contradicts reality. A page that is gone for good should return 404 or 410. A page the user is being moved off of should return 301 or 302. A page that exists but hit a temporary fault should return 500. When the status code disagrees with what the page actually contains, Google cannot trust the signal, and that mismatch is what produces a soft 404.
Hard 404: the server confirms the page is missing #
A hard 404, sometimes called a true 404, is what a server returns when the requested URL maps to no resource on the site. The response opens with a status line declaring 404 Not Found, and the body that follows can be anything: a styled error page, a search box, links to popular pages, an illustration. Two layers, working independently. The status line is the machine-readable declaration; the body is what the human sees.
Hard 404s are the correct answer for genuinely missing pages. A deleted blog post. A discontinued product page. A mistyped URL. The crawler reads the 404, removes the URL from its active index (or never adds it), and stops re-crawling it as often. The signal is unambiguous: this URL has nothing to offer.
For URLs that are permanently gone, the sibling code is 410 Gone. The difference is intent. 404 means “not here right now, keep checking.” 410 means “gone for good, don’t come back.” Google treats the two much the same in practice, but processes 410 slightly faster because the signal is more definitive: recrawl frequency drops off faster and the URL clears the crawl queue sooner. In most cases either one is fine for a deleted page.
Soft 404: the page acts missing while claiming to exist #
A soft 404 is the failure mode that breaks the signal. The page returns HTTP 200 (OK, the page exists) while its body tells the user the content is not there. Google’s own definition is exactly this: a URL that returns a page saying the content does not exist, paired with a 200 success code, or a page with no main content.
The pattern shows up in a handful of predictable ways. A catch-all handler routes any unknown URL to a generic “page not found” template that returns 200 the whole way. A search results page finds zero matches, renders “No results found,” and returns 200. A category page that lost all its inventory still loads, returns 200, and reads “This category is currently empty.” A product soft-deleted in the CMS redirects to a generic error template that returns 200. In every case the user understands there is nothing there. The crawler does not. The 200 says “normal page,” so the crawler indexes the URL, keeps re-crawling it, and spends crawl budget on a page that should have been retired.
Google detects most soft 404s automatically, keying on signals like very thin content combined with “not found” phrasing in the body. When it does, the URL is flagged in Search Console’s Page indexing report (the report formerly called Coverage) under the “Soft 404” category, and the page typically drops out of the index even though the server keeps answering 200. The end state resembles a hard 404, the page falls out of search, but it is reached through pattern detection rather than a clean status code. That makes the timeline slower and the outcome less certain.
Why soft 404s happen by accident #
Most soft 404s are not deliberate. They are side effects of how sites get built, and four patterns produce the bulk of them.
The catch-all 200 handler: a CMS or framework routes unknown URLs through a custom error template that returns 200 instead of 404. The message looks right; the status code lies.
The empty result page: search, filter, and dynamic listing pages return 200 even with nothing to show. Every empty filter combination becomes a soft 404 in Google’s eyes.
The thin redesign: a rebuild strips pages that used to carry content. The URLs still resolve, but the new versions hold placeholder text, site-wide boilerplate, or just a navigation menu. Empty to a user, and to Google a page that lost its content but is still being served.
The unintentional removal: a staging bug or CMS glitch wipes body content from many pages at once while keeping the page records. URLs return 200 because the record exists, but the body is empty. Without close attention these can sit in the index for weeks, collecting soft 404 flags as detection catches up.
The thread running through all four: the server does not know the page is broken. It returns 200 because, technically, the request succeeded. The breakdown is at the content layer, which the server never checks.
What actually changes for SEO #
The consequences diverge in specific ways.
| Behavior | Hard 404 (correct) | Soft 404 (broken) |
|---|---|---|
| HTTP status code | 404 (or 410) | 200 |
| Crawler interpretation | "URL is gone, drop it" | "URL is fine, keep it" |
| Initial indexing | URL never enters the index | URL enters, may be dropped later |
| Crawl frequency | Falls off as the URL keeps returning 404 | Stays at normal frequency, wastes budget |
| Link equity | Equity from inbound links clears cleanly | Equity gets stuck on a dead page |
| User experience | Browser shows an error; users understand | Page loads, but content says something is wrong |
| Time to clear from index | Days to weeks | Weeks to months, depends on detection |
| Search Console report | "Not found (404)" | "Soft 404" |
The most damaging consequence is crawl waste. A large site with thousands of soft 404 URLs, often from filter combinations, search pages, or stale listings, burns crawl budget on pages that will never provide value. Google has confirmed that soft 404s consume crawl budget despite the 200 status. The pages that deserve more frequent crawling, money pages and fresh content, get crawled less because the crawler is busy re-fetching soft 404s.
Link equity is the second casualty. Inbound links to a soft 404 URL keep accumulating, but the destination has no content to amplify and no way to consolidate the signal. A hard 404 at the same URL would at least clear the signal, letting the site redirect or canonicalize the equity elsewhere. A soft 404 leaves it stranded.
How to find the soft 404s already on the site #
Detection comes before any fix, and most content-heavy sites have soft 404s they do not know about.
Google Search Console’s Page indexing report is the primary tool. Under “Why pages aren’t indexed,” the “Soft 404” category lists URLs Google has flagged, with the URL, the date it was first flagged, and a content sample from the time of detection.
Crawler tools catch a different slice. Screaming Frog and Sitebulb flag pages with thin content below a configurable word count, and pages whose body matches configurable phrases like “not found,” “no results,” or “page does not exist.” The crawl produces a suspect list for manual review.
Server log analysis surfaces a third category: URLs that return 200 to crawler requests but are linked from nowhere on the site. A page nothing links to that still returns 200 may be a soft 404 no one knew existed. Log tools like Screaming Frog Log File Analyser and Botify surface these at scale.
For small sites, manual sampling works. Take a set of low-traffic pages from analytics, open them, and check whether they hold real content. Minutes per page, and the fixes often clear dozens of soft 404s the site never noticed.
The four-step fix, plus custom 404 pages #
Once a soft 404 is identified, the right response depends on what the page should be doing. Google frames the same choices.
Convert to a hard 404. If the page is genuinely gone, configure the server to return 404 or 410. The error template must return the correct status code, not merely display the right message. In Apache that usually means an .htaccess directive; in Nginx, a try_files fallback that returns 404 explicitly; in a framework, the route handler returning the correct status.
Redirect to a related page. If the content moved, a 301 points the old URL at the new location, preserving link equity and serving users arriving from external links. A discontinued product goes to a successor or the category page; an old post goes to its update.
Restore real content. If the page should have content but currently does not (empty filters, depleted categories, broken templates), fix it at the content layer. Restore the products, re-stock the category, repair the template. The URL stays; the content returns. If Google reports a live page as a soft 404, thin content is the likely cause, and improving the page then requesting re-indexing is the path.
Block from indexing. For pages that should exist for users but not in search (internal search results, infinite filter variants, parameter URLs), noindex is the tool. The page still works; the crawler stops adding it.
The choice tracks the page’s role, and the wrong one creates a new problem: 404ing a page that should redirect breaks bookmarks; redirecting an empty filter to the homepage just makes a different soft 404; noindexing a real page hides it from users who wanted it.
Custom 404 pages sit on top of this and are worth getting right, because they are where soft 404s most often sneak in. The two layers operate independently. The status code must be 404, non-negotiable, and the body can be anything useful: a search box, a list of popular pages, a friendly explanation, a link back to the likely intended destination. Humor and illustration are fine; none of it breaks SEO as long as the status code is correct. The classic soft 404 is the inverse, a stylish “page not found” that returns 200, and the fix is one line of server configuration. Confirm the real status with the URL Inspection tool in Search Console, curl -I, or the Network panel in browser DevTools, since the visible message never tells you the code.
Common questions #
Does a soft 404 hurt rankings across the whole site? Not directly for unrelated pages, but it drains crawl budget and strands link equity, which slows indexing of legitimate content and can degrade visibility for the affected section over time.
Should I use 404 or 410 for a deleted page? Either is fine. 410 clears from the index slightly faster because it signals permanent removal, but Google treats them much the same, so 404 is a safe default.
Why does my live page show up as a soft 404? Usually thin content, or critical resources failing to load during rendering so Google sees an effectively empty page. Improve the content or fix the rendering, then request re-indexing.
Can I just block soft 404 URLs in robots.txt? No. If robots.txt blocks the path, the crawler never fetches the URL, never sees the status, and never learns the page is gone. The status response is the signal, and it only travels if the crawler is allowed to request it.
The takeaway is small and structural at once. Getting the status code right costs one line at the moment you build the page. Getting it wrong is invisible at first and expensive by the time it surfaces, showing up as slower indexing, polluted search results, and inbound links that never pay off. Before the next redesign or CMS migration, pull the Soft 404 category in the Page indexing report and make it a standing item in monthly health reviews; it is the cheapest place to catch the problem while it is still one line to fix.