Soft 404 Error: What It Means + How to Fix It
“Soft 404” in Google Search Console means a page returns a 200 OK status but looks empty or missing to Google. Here's why it happens and exactly how to fix it.
A soft 404 is a mismatch: your page returns 200 OK, but Google judged its content to be a “not found” page. It comes from one of three situations — an error page returning 200 instead of a real 404, a page too thin to look real, or a JS page Google saw as an empty shell. View the crawled page to tell which, then either return a true 404/410 or give the page real, server-rendered content.
A soft 404 is the rare GSC error that isn't about a broken request — it's about a broken impression. Your server says 200 OK, the page loads fine in a browser, and yet Google filed it as a "not found" page. The HTTP layer and the content layer disagree, and Google sided with the content.
That gap is the whole problem, and it's why "the page works" is not a defense. Google isn't reading your status code here — it's reading the page Googlebot actually rendered and deciding it looks like an error. The fix depends entirely on which of three situations produced that verdict, so the first job is to see what Google saw.
First, look at what Google actually crawled
Don't guess from the live page in your browser — guess from Google's copy. Open URL Inspection, run the affected URL, then click View crawled page → HTML. That's the exact markup Googlebot got, rendered and all.
Three things to check in that HTML:
- Is there real body content, or just a heading and a "no results" line?
- Does it contain words like not found, no results, expired, or coming soon?
- Is the
<body>nearly empty — a shell with no rendered text — even though your live page is full?
Each of those points at a different cause below. The status code Google reports in URL Inspection will also literally say Soft 404 under page indexing — that's your confirmation you're in the right place.
A soft 404 is a content judgment wearing an error label. Google flags it the same way whether the page is a real error you served wrong or a thin page that merely looks like one. The label is identical; the fix is not. That's why looking at the crawled HTML matters more than reading the error name.
Find your cause (it's one of three)
Run the crawled HTML against these three. The tell points you straight at the fix.
1. It's a real error page that forgot to return 404
The page genuinely has nothing to show — a deleted listing, an expired event, a search or filter that matched zero items — but the server still answers 200 OK. So Google sees "Product not found" framed as a perfectly valid page, and reasonably concludes the page shouldn't exist.
Tell: the crawled HTML literally says not found, sold out, no results, or this listing has expired — and the response code is 200, not 404.
2. The page is too thin to look real
The page is "live" but almost nothing is on it — a heading and a sentence, a stub you meant to flesh out, a placeholder with coming soon or filler copy. Google can't tell a deliberately empty page from a broken one, so it defaults to broken.
Tell: the crawled HTML has real structure but barely any body text, or it's clearly a template waiting for content that never got added.
3. Google saw an empty shell on a JS-rendered page
The page is rich in a browser, but the content loads client-side after JavaScript runs. If Googlebot rendered a near-empty <body> — a <div id="root"> with nothing inside, or a loading spinner — it judged the empty version, not the one you see. This is a false positive caused by rendering, not by your content.
Tell: the live page is full, but View crawled page → HTML shows an empty container, a skeleton, or "Loading…" where the real content should be.
How to fix it
Match the fix to your cause — you won't need all three.
- Return a real 404 or 410 for genuine error pages
For cause 1, the page should stop pretending to be valid. Make the route emit a true status code instead of
200:404 Not Found— the default; use it for anything that might come back or that you're unsure about.410 Gone— for content permanently removed; Google deindexes 410s slightly faster.
The trap: a styled "Sorry, not found" template that looks like a 404 but still responds
200is still a soft 404. Verify the real status withcurl -I https://yoursite.com/the-url(or your browser's Network tab) and confirm the first line readsHTTP/… 404, not200. For empty search/filter results, return 404 when the query matches nothing rather than serving an empty "0 results" page at 200. - Give thin pages real substance — or remove them
For cause 2, decide whether the page deserves to exist. If it does, fill it: answer a clear question, add the products/listings, make it more than an empty container — the same content bar Google applies everywhere. If it doesn't, don't leave it half-built at 200; either
noindexit or return a real 404 and drop it from your sitemap. A sitemap entry tells Google "this URL matters," which is the wrong signal for a page you've abandoned. - Get JS content into the initial HTML
For cause 3, the content has to exist before JavaScript runs. Server-render the page (SSR/SSG) or pre-render it so the real text ships in the initial HTML response, not after a client-side fetch. The test is the same one that found the problem: re-run URL Inspection → View crawled page → HTML and confirm the actual content — not a
<div id="root">shell — is present. If it is, Google has something real to evaluate. - Redirect to a real alternative — but only a relevant one
When a removed page has a genuine replacement (a discontinued product superseded by a new model),
301-redirect to the closest relevant page. Do not redirect every missing URL to the homepage — Google treats a redirect to an irrelevant destination as a soft 404 in its own right. No good match? A clean 404 beats a misleading redirect. - Then request indexing
Once the underlying issue is genuinely fixed, run URL Inspection on the page and click Request indexing. This only nudges Google to re-evaluate — it does nothing if the page still returns the wrong status or still looks empty. Fix first, request once.
How to know it worked
Re-crawling takes a few days to a few weeks. Check in this order:
- URL Inspection — re-inspect the URL. For a page you fixed, "URL is on Google" is the definitive all-clear. For a page you intentionally killed, you want to see the 404/410 reported, not a lingering soft 404.
- Crawled page HTML — for a JS fix especially, re-open View crawled page and confirm the real content is now in the markup. This is the only check that proves Google sees what you see.
- Performance report — filter to the page. Impressions appearing where there were none is real-world proof it's indexed and surfacing.
Still flagged after two or three weeks? You likely fixed the wrong cause — most often a "404 page" that's still quietly returning 200, or a JS page whose content still isn't in the initial HTML. Re-check the crawled HTML and the status code together.
Don't confuse it with these neighbors
| Status | What it really means | Fix lives at |
|---|---|---|
| Soft 404 | Returns 200, but Google judged the content to be a missing/error page | This page |
| Submitted URL not found (404) | Returns a real 404 — but you listed it in your sitemap | Submitted URL not found guide |
| Crawled – currently not indexed | Real content, but Google chose not to index it — a quality verdict | Crawled, not indexed guide |
| Discovered – currently not indexed | Google knows the URL but hasn't crawled it yet — a priority issue | Discovered guide |
The line that separates this from the rest: a soft 404 is a disagreement between your status code and your content. A real 404 is honest and easy for Google to act on — so when a page should be gone, a clean 404 is the goal, not something to avoid.
The hard part isn't the fix — it's spotting which "working" URLs Google quietly filed as soft 404s, then telling apart the ones that need a real status code from the ones that need real content.
TurboConsole reads your Search Console data, flags every page stuck in soft 404, and tells you the likely cause per page — wrong status, thin content, or empty JS shell — so you go straight to the right fix instead of inspecting URLs one at a time.
Frequently asked
What's the difference between a soft 404 and a regular 404?
Will Google ever index a page flagged as soft 404?
Why does Google flag empty category pages as soft 404?
Should I use 404 or 410 for permanently removed pages?
We surface these issues automatically.
Connect Search Console once. Every issue like this gets ranked by impact, with a fix you can ship today.
Related issues
- Submitted URL Not Found (404): What It Means + How to Fix It“Submitted URL not found (404)” in Google Search Console means you submitted a URL that returns a 404. Here's why it happens — and exactly how to fix it.
- Crawled – Currently Not Indexed: What It Means + How to Fix It“Crawled – currently not indexed” in Google Search Console means Google saw your page but chose not to index it. Here's why it happens and exactly how to fix it.
- Discovered – Currently Not Indexed: What It Means + How to Fix It“Discovered – currently not indexed” in Google Search Console means Google knows your page exists but hasn't crawled it yet. Here's why — and exactly how to fix it.