Soft 404 Error: Meaning, Causes, and How to Fix It (2026)

A soft 404 is a page that returns HTTP 200 to the crawler but looks empty, missing or broken to Google, so Google treats it as if it had returned 404 and keeps it out of the index. The classic example is a "Product not found" screen that still answers with a success status code. Your server says everything is fine, the content says nothing is here, and Google trusts the content. Search Console reports it under Page indexing as "Soft 404", and the fix is either to return a real 404 or 410, or to put genuine content on the page.

It is one of the few Search Console statuses that is almost always your fault and almost always cheap to fix. It is also one of the easiest to accumulate by the thousand without noticing, because nothing breaks. The pages load. Monitoring stays green. Only the index quietly shrinks.

What is a soft 404 error?

A soft 404 happens when a URL responds with a 200 OK status but Google decides the page has no real content to index. Google makes that call from the rendered page: wording like "not found", "no results", "this product is no longer available", an empty template, or a page whose main content area is essentially blank. Because the status code and the content disagree, Google sides with the content and files the URL as a soft 404.

The name is worth unpacking. A hard 404 is a server-level answer: the URL does not exist, here is the status code that says so. A soft 404 is a content-level judgment: the server claimed the URL exists, but Google looked and found nothing worth keeping. Google is explicit that a soft 404 is not a penalty. The page is simply not indexed, and it will not rank, no matter how many times you resubmit it.

Soft 404 vs 404: the difference that matters

The practical difference is trust. A hard 404 gives Google a clean, machine-readable answer and it moves on. A soft 404 gives it a contradiction to resolve, and resolving contradictions costs fetches. On a large catalog with tens of thousands of discontinued products all answering 200, that waste is a genuine drag on crawl budget, because the crawler spends its allowance on pages you did not want indexed instead of the ones you did.

What causes soft 404 errors?

Six causes cover nearly everything I have seen in real Search Console accounts.

1. A custom error page that returns 200. Somebody built a nice "Sorry, we could not find that page" template and wired it up as a normal route. It looks like an error page to a human and reads as a success to a crawler. This is the single most common cause, and it is usually a one-line fix in the framework.

2. Empty search results, categories or filters. An internal search URL with no matches, a category with every product sold out, a faceted combination that returns nothing. The template renders, the page is technically valid, and there is nothing on it. These URLs should generally not be crawlable at all.

3. Out of stock or discontinued products. Ecommerce sites remove the product but leave the URL serving a stub, or redirect it to a generic "this item is no longer available" page that answers 200. Multiply by a seasonal catalog and you get thousands of soft 404s in a quarter. Getting this right is a big part of ecommerce product indexing, because Google will not index a page that tells it there is nothing to buy.

4. JavaScript apps that never set a status. Single-page apps route client side. The server returns 200 and an empty shell for every URL, then JavaScript decides whether to render the product or a not-found message. Google gets the 200 immediately and the "not found" only after rendering, and rendering happens later on a separate queue. This is why soft 404s cluster in React, Vue and Next.js sites, and why the pattern often shows up alongside other rendering problems in how Googlebot reads the page.

5. Thin or placeholder pages. Auto-generated location pages with a heading and a map, tag archives with one post, profile pages with no profile filled in, "coming soon" stubs. Nothing here says "not found", but there is not enough substance for Google to consider the URL worth a slot in the index.

6. Redirecting a dead page to an irrelevant one. Bulk-redirecting every deleted product to the homepage feels tidy. Google treats an irrelevant redirect as a soft 404 anyway, because the destination does not answer the request the URL made. A redirect only counts when it goes to a genuinely equivalent page.

How do I fix soft 404 errors?

Start by deciding what each URL should be, then make the status code and the content agree. That single principle resolves almost every case.

The page is genuinely gone and is not coming back. Return 404, or 410 if you want to be emphatic. Google treats 410 slightly more decisively but the practical difference is small. Do not redirect it to the homepage. Do not serve a friendly stub with a 200. If a close equivalent exists, a 301 to that specific page is better than either.

The page should exist but is thin. Add the content that justifies the URL, or remove the URL. A location page needs the address, hours, staff, local specifics, something only that page has. If you cannot write it, the page should not be in a sitemap and probably should not exist.

The URL should never have been crawlable. Internal search results, empty filter combinations and infinite parameter spaces belong behind a robots.txt disallow. Blocking crawling saves fetches in a way noindex does not, because a noindexed page still has to be fetched to see the tag. The robots.txt rules for wildcards and parameters do most of the work here.

The product is out of stock but the page has value. Keep the page, keep the description, reviews and specifications, and say clearly that the item is unavailable while linking to alternatives and the parent category. Google indexes that happily. What it will not index is a page stripped down to a single line of apology.

It is a JavaScript app. Return the correct status from the server for URLs you know are invalid, using server-side rendering or a pre-render layer, rather than deciding client side. If your framework cannot, the documented workaround is to add a noindex meta tag when the client-side router lands on a not-found state, which at least gives Google a clear instruction, and to redirect to a URL that does return a real 404.

How do I find soft 404 errors on my site?

Search Console is the authoritative source. Open the Page indexing report, find "Soft 404" in the list of reasons pages are not indexed, and export the sample URLs. The sample is capped at 1,000 per reason, which on a big site is a sample rather than an inventory, but the patterns in it are usually enough to identify the template at fault. Reading the rest of that report is worth an hour on its own, and the page indexing report guide walks through every status.

For anything larger, crawl the site yourself and look for URLs that return 200 while the rendered body contains phrases like "not found", "no results", "0 items", "out of stock", or has a main content area under a few hundred bytes. Export status code, title, word count and any of those markers to a table. Once the crawl is in a database you can slice it however you want, even by asking in plain English instead of writing the query. Group by URL pattern and the culprit template usually falls out in minutes.

Then confirm the outcome rather than assuming it. Fixing the template is step one, but the pages you actually care about are the ones that should be indexed and are not, and Search Console updates slowly. Checking the real index status of the affected URLs across Google and Bing, and watching how that changes after the fix, is the only way to know it worked. That is exactly what our index checker is for, and if the status is heading the wrong way, detecting deindexed pages early keeps a template regression from eating a quarter.

Is a soft 404 bad for SEO?

Not as a penalty, and Google has been clear on that point. A soft 404 does not damage your rankings elsewhere and does not mark the site as low quality by itself. The harm is narrower and more literal: the affected URL will not be indexed and cannot rank, and Google keeps spending crawl requests on it because a 200 implies it still exists.

On a small site with a handful of soft 404s, this is genuinely not urgent. On a 50,000-URL catalog where a template change turned every discontinued product into a 200-status stub, it matters twice: you are burning crawl allowance on pages that will never index, and that allowance is being taken from the new products you want discovered this week. The symptom is often mistaken for something else, with fresh pages sitting at Discovered, currently not indexed while the crawler works through thousands of dead ends.

How long does it take for soft 404s to clear?

After you deploy the fix, use the URL Inspection tool to validate a couple of URLs live, then click Validate Fix in the Page indexing report. Google re-crawls the affected sample over the following days, and the status typically clears in one to three weeks depending on how often your site is crawled. A large batch can take longer, since Google works through it at its own pace.

Two things speed it up and neither is a shortcut. Make sure the fixed URLs are reachable by internal links from pages that already get crawled often, and make sure your sitemap reflects reality, listing only canonical, indexable, 200-status URLs. If you are pushing a big correction, resubmitting the genuinely valid URLs through the official Google Indexing API and Bing IndexNow gets them re-fetched sooner than waiting. What no tool can do is force Google to index a page it has judged empty, which is why the content fix has to come first.

Soft 404 checklist

• Confirm your error page returns 404, not 200. Test with a made-up URL and read the status code, not the rendered page.
• Return 410 for pages permanently removed, and 301 only when a genuinely equivalent page exists.
• Stop bulk-redirecting dead URLs to the homepage. Google reads that as a soft 404 anyway.
• Block internal search results and empty filter combinations in robots.txt.
• Keep out of stock product pages substantive, and say the item is unavailable rather than emptying the page.
• In JavaScript apps, set the status server side instead of deciding client side after render.
• Add real content to thin pages, or delete them and let them 404.
• Keep sitemaps to canonical, indexable, 200-status URLs only.
• After the fix, verify index status directly rather than trusting the report to update.

Soft 404s are a plumbing problem, not a content strategy problem, and that is good news: the fix is usually one template and one status code. The part worth building a habit around is the checking. Status codes drift with every deploy, and the only reliable signal that your pages are actually in the index is looking at the index itself.