Soft 404 Errors

TL;DR — A soft 404 is a page that tells your browser “everything’s fine” (a 200 OK status code) while the page itself is empty or says “not found.” Google spots the mismatch and treats the page like a 404 — it won’t get indexed. “Soft 404” isn’t a real error code your server sends; it’s a label Google applies after looking at the page. The fix is to make the code match the content.

What a soft 404 is

A soft 404 is a Google classification, not an HTTP status code: the returned content looks like an error despite a success-like response. Evidence for this claim Google may classify a success response as a soft 404 when rendered content suggests an error or has little usable content. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes Google recommends returning an accurate 404/410 for genuinely missing pages or useful content for valid pages. Evidence for this claim Google recommends an accurate 404 or 410 for missing pages, a relevant redirect for moved pages, or substantive content for valid pages. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Soft 404 errors

Every time a page loads, the server sends back a little status code behind the scenes. 200 OK means “here’s the page, everything worked.” 404 Not Found means “that page doesn’t exist.”

A soft 404 is when those two things disagree. The server says 200 OK — success — but the page is blank, has basically no content, or literally shows a “Page not found” message. Google renders the page, sees that the content looks like an error while the status code says success, and decides not to trust the 200. It treats the URL like a 404 instead and leaves it out of the index.

The important part: there is no such thing as a “soft 404” status code. Your server never sends one. It’s a label — a classification — that Google applies after it looks at your page. You’ll see it in Google Search Console, not in your server logs.

Why it matters

A soft 404 isn’t a penalty, but it’s not harmless either. It means the page won’t get indexed, so it can’t show up in search. And if other sites link to that page, the value from those links may go nowhere. It’s a silent failure — Google quietly drops the page and doesn’t always make a big deal of telling you.

What causes them

The usual suspects:

• A deleted page that still returns 200 instead of a real 404.
• An out-of-stock or discontinued product page that’s been emptied out.
• An empty internal search results page (“0 results for…”).
• A thin JavaScript page where the app loads but there’s no real content for that URL.
• A redirect to the homepage or an unrelated page instead of a real replacement.

How to fix one

It comes down to one question: should this page exist?

• No, it’s gone for good → return a real 404 (or 410, which means “gone”).
• It moved or has a proper replacement → 301 redirect it to that relevant page — not just your homepage.
• Yes, it should be live → add real content so the page stops looking empty, then re-check it.

One thing that trips people up: adding a noindex tag doesn’t fix a soft 404. The page still returns 200, so the underlying mismatch is still there. Want the deeper version — how Google detects them, the JavaScript and ecommerce angles, and the myths? Switch to the Advanced tab.

TL;DR — A soft 404 is a classification, not a status code. The server returns a success code (usually 200), but the rendered content reads as empty or “not found,” so Google overrides the 200 and treats the URL like a 404 for indexing. It still costs you: the page isn’t indexed, and repeated re-crawling of URLs that never actually resolve can add up on larger sites — Google doesn’t publish a universal crawl-budget cost. Root causes cluster into four buckets — deleted pages that don’t 404, thin or empty auto-generated pages, irrelevant redirects, and rendering failures (often JS). Google’s current documentation names missing server-side includes, broken database connections, empty internal search results, and unloaded JavaScript as detection triggers. The fix decision tree has three branches: gone → 404/410; moved → 301 to something relevant; should exist → add real content and re-test. noindex does not fix it.

What a soft 404 actually is

Search Console applies this label after evaluating the response and content; the label is distinct from what appears in server logs. Evidence for this claim Google may classify a success response as a soft 404 when rendered content suggests an error or has little usable content. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes The appropriate fix depends on whether the URL should exist. Evidence for this claim Google recommends an accurate 404 or 410 for missing pages, a relevant redirect for moved pages, or substantive content for valid pages. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Soft 404 errors

In my Ahrefs guide to HTTP status codes, I put it this way:

“Most 2xxs will allow pages to be indexed. However, 204s will be treated as soft 404s and won’t be indexed. Soft 404s may also be URLs where the server says it is successful (200), but the content of the page says it doesn’t exist. The code should have been a 404, but the server says everything is fine when it isn’t. This can also happen on pages with little or no content.”

That’s the whole thing in a nutshell. The server says 200, the content says “nothing here,” and Google resolves the contradiction in favor of the content. Google’s own HTTP status codes doc describes the same mechanic under the 2xx table: it considers the content for processing, and “if the content suggests an error… an empty page or an error message, Search Console will show a soft 404 error.” Google’s dedicated crawling-errors troubleshooting page spells out the definition even more directly: a soft 404 is a URL that “returns a page telling the user that the page does not exist and also a 200 (success) status code.”

So a soft 404 is not a status code your server can return. It’s a label search engines apply after comparing the response code (some 2xx) against the rendered page. That precision matters, because a lot of writing about this treats “soft 404” like an error code — it isn’t. (A sibling code, 204 No Content, gets swept into the same bucket, and 404 vs 410 is a separate distinction worth understanding — a 410 says “gone” a touch more emphatically than a 404.)

Why it still costs you even though it’s not a penalty

There’s no ranking penalty for a soft 404. But there’s a real cost, and a likely one:

1. The page isn’t indexed. Google drops it (or never adds it), so it can’t rank, and any links pointing at it may not pass value through.
2. It can waste crawl activity, especially at scale. Because the server keeps returning a success code instead of a 404/410 that tells crawlers “don’t bother,” Google has less signal to stop re-requesting the URL. Google’s documentation doesn’t publish a universal crawl-budget cost, percentage, or ranking effect from this — the practical impact is largest when a site has many soft-404’d URLs, not a guaranteed per-page penalty.

How Google detects them

Detection happens at render time: Google fetches the page, runs the JavaScript, and evaluates the resulting content and available resources against the response code. Google’s current troubleshooting documentation names specific triggers: a missing server-side include file, a broken database connection, an empty internal search results page, or JavaScript that fails to load — any of which can leave a 200 response paired with error-like or effectively empty content.

One older data point worth flagging rather than relying on: in 2021, John Mueller told Search Engine Land that Search Console’s soft-404 status reflected the mobile rendering of a page specifically, and a desktop-only soft 404 might not surface the same way. That’s a real, on-the-record statement — but it’s several years old, and Google’s current soft-404 documentation doesn’t restate a smartphone-only rule. Treat it as historical color rather than a confirmed current mechanic, and verify any specific URL with URL Inspection’s live test instead of assuming the report is device-complete or fully real-time.

The four buckets of causes

Google’s own troubleshooting documentation names a shorter, more mechanical list — a missing server-side include, a broken database connection, an empty internal search results page, or JavaScript that fails to load. Almost every real-world soft 404 I’ve seen falls into one of four broader buckets that cover those mechanics plus the higher-level causes behind them:

1. Deleted or expired pages that never return a real 404. A page is removed but the CMS (or a catch-all route) still serves a “sorry, not found” template with a 200. Fix: return an actual 404/410.

2. Thin or empty auto-generated pages. Tag or category archives with zero posts, filter combinations that match nothing, and — the classic — empty internal search results pages (“0 results for your query”). These load fine and return 200, but there’s nothing on them. Fix: noindex and/or block the search-results path in robots.txt, or render genuinely useful fallback content (popular pages, related results).

3. Irrelevant or overly broad redirects. This one is widely underexplained. Redirecting a deleted page to your homepage or an unrelated category can itself be reclassified as a soft 404. In my ecommerce out-of-stock guide:

“If you have a similar product that you want to push people toward, you may want to 301 redirect the old product to the new product. This will also maintain any link value if the pages are similar enough. If the pages are not similar enough or you redirect to a category page or your homepage, then these pages may be treated as a soft 404 and the value from links may not be preserved.”

So the redirect existing isn’t enough — its relevance is what determines whether link equity flows or the URL gets reclassified.

4. Rendering failures — often JavaScript. JS-framework and single-page-app sites are structurally prone to soft 404s. A client-side router serves the app shell with a 200 no matter what route is requested, so a nonexistent client route never produces a real HTTP 404 unless the server or edge is explicitly configured to intercept it and return one. The result is a page that renders “404 Page Not Found” as text while the response code stays 200 — a textbook soft 404. Framework fixes: Next.js’s notFound() helper (which returns a real 404), server-side rendering / prerendering that intercepts unknown routes, or an edge-level 404 for paths that don’t exist. Broken server-side includes and failed database calls belong in this bucket too — they leave a mostly-blank page served with 200.

Treat the missing-resource state as a response contract:

Then choose the outcome by resource state: use a permanent redirect only when a specific equivalent exists, return 404 when the requested resource does not exist, and reserve 410 for a deliberately removed resource when the application can assert that state. The 404-versus-410 distinction is less important than avoiding a false 200 or an irrelevant redirect. Evidence for this claim Google recommends an accurate 404 or 410 for missing pages, a relevant redirect for moved pages, or substantive content for valid pages. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Soft 404 errors

The fix decision tree

Three branches, driven by one question — should this URL exist?

• Gone for good → return 404 or 410. Stop serving a 200.
• Moved or has a genuine equivalent → 301 to something actually relevant, not a catch-all destination. Redirecting to the homepage to “save” the URL usually backfires into a soft 404.
• Should exist and has value → fix or expand the content so it no longer reads as empty or error-like, then re-test with URL Inspection and request indexing.

Ecommerce: it’s site-size dependent

For out-of-stock and discontinued products, there isn’t one right answer — it scales with your site. John Mueller’s general framing (via Search Engine Roundtable) is to “do what works best for the user, and search engines will generally figure it out from there.” Practically: small sites can keep the page and show related products; medium sites often 404 a truly discontinued product (or, if it’s temporarily out, say when it’s coming back); very large sites can automate expiration with the unavailable_after signal. The through-line: don’t mass-redirect discontinued products to the homepage, because that’s exactly the pattern that gets reclassified as a soft 404.

Myths worth killing

• “Soft 404s are just cosmetic.” No — the page isn’t indexed and its link signals may not pass through. It’s a silent failure mode, not a label you can ignore.
• “noindex fixes a soft 404.” It doesn’t. noindex still returns a 200; the status-vs-content mismatch is untouched, and Google can still classify the page as a soft 404 in reporting. Fix the response code or the content.
• “Redirecting anywhere avoids a soft 404.” False. An irrelevant redirect (to the homepage or an unrelated category) can be reclassified as a soft 404 and break link-equity consolidation.
• “Soft 404 is an HTTP status code.” There’s no such code. It’s a downstream classification — don’t confuse it with 410 or invent a nonstandard code.
• “A soft 404 always means something’s broken.” Not always. Sometimes it’s a legitimately empty state (an internal search with genuinely zero results). The page isn’t “broken” — you just need to control its indexability rather than fix its content.
• “GSC tells me about every soft 404 in real time.” Detection can lag and, per Mueller, is tied to mobile rendering. Treat the report as a strong signal, not a complete or instantaneous one.

Where Google actually documents this now

Worth a heads-up if you’re chasing old links: Google has reorganized its crawling/indexing documentation more than once, and the URLs keep moving. The standalone “How to fix a soft 404” support answer and the old /search/docs/advanced/crawling/soft-404-errors doc both redirect elsewhere now, and even the newer http-network-errors URL I originally cited here has since 301’d to a restructured developers.google.com/crawling/docs/… path. The current live set is: the Page Indexing report help page (the maintained definition with the fix recommendation), the HTTP status codes doc (the 2xx mechanics, at its new URL), and a newer, more direct crawling-errors troubleshooting page that spells out the causes and the three fix branches explicitly. Old bookmarks may 301 or dead-end — see the Official Docs tab for the current live links.

AI summary

A condensed take on the Advanced version:

• A soft 404 is a classification, not a status code. The server returns a success code (usually 200), but the rendered content is empty or reads as “not found,” so Google overrides the 200 and treats the URL like a 404 for indexing. No server literally sends “soft 404.”
• It’s not a penalty, but it has real costs: the page isn’t indexed (and link signals may not pass through), and repeated re-crawls of URLs that never resolve can add up on larger sites — Google doesn’t publish a universal crawl-budget cost or ranking effect.
• Detection happens at render time, comparing the response code against missing resources, broken includes, database failures, or empty content. A 2021 Mueller comment tied the report to mobile rendering specifically, but current Google documentation doesn’t restate that as a rule, so treat it as historical color and the report as a strong signal rather than a complete, real-time inventory.
• Four cause buckets: (1) deleted pages that don’t 404; (2) thin/empty auto-generated pages (empty tags, filters, internal search results); (3) irrelevant redirects (to homepage / unrelated category); (4) rendering failures — often JS/SPA, where a client router returns 200 for a route that doesn’t exist.
• Fix decision tree: gone → 404/410; moved → 301 to something relevant (not the homepage); should exist → add real content and re-test with URL Inspection.
• noindex does NOT fix it — it still returns 200. Ecommerce out-of-stock handling is site-size dependent (related products / 404 / unavailable_after).

Official documentation

Primary-source documentation from the search engines.

Google

• Page indexing report — “Soft 404” section — Google’s maintained definition and fix recommendation (“return a 404 response code… and add more information on the page”). This is the canonical current source.
• Troubleshoot Google Search crawling errors — soft 404s — the most direct current explainer: defines a soft 404 as a page telling the user it doesn’t exist while also returning 200, lists specific causes (missing server-side include, broken database connection, empty internal search result, unloaded JavaScript), and spells out the three fix branches (gone/moved/still-valid).
• HTTP status codes, network and DNS errors, and Google Search — the 2xx (success) mechanics: Google evaluates the content, and “if the content suggests an error… Search Console will show a soft 404 error.” (This doc’s URL has moved at least twice; the link here is the current live one as of this update.)
• Crawl Errors now reports soft 404s (2010) — historical: when Google first surfaced soft 404s as their own bucket.
• Farewell to soft 404s (2008) — historical color on Google’s original motivation for handling them.

Bing / Microsoft

• 404 Pages Best Practices (Bing Webmaster Tools Help) — Bing’s guidance on returning proper 404s. (Bing uses content classifiers to detect not-found pages that return 200/302; its help center is JS-rendered, so confirm exact wording live.)

Quotes from the source

On-the-record statements from Google. Each link is a deep link that jumps to the quoted passage on the source page.

Google Search Console Help — the definition and the fix

• “The page request returns what we think is a soft 404 response. This means that it returns a user-friendly ‘not found’ message but not a 404 HTTP response code. We recommend returning a 404 response code for truly ‘not found’ pages and adding more information on the page to let us know that it is not a soft 404.” — Google Search Console Help, “Page indexing report.” Jump to quote

Google Search Central — the 2xx mechanic

• “Google considers the content for processing (for example, in the case of Google Search, for indexing). If the content suggests an error for Google Search, an empty page or an error message, Search Console will show a soft 404 error.” — Google Search Central, “HTTP status codes, network and DNS errors, and Google Search.” Jump to quote.%20If%20the%20content%20suggests%20an%20error%20for%20Google%20Search%2C%20an%20empty%20page%20or%20an%20error%20message%2C%20Search%20Console%20will%20show%20a%20soft%20404%20error)

Google Search Central — the current troubleshooting-doc definition

• “A soft 404 error is when a URL that returns a page telling the user that the page does not exist and also a 200 (success) status code.” — Google Search Central, “Troubleshoot Google Search crawling errors.” Read the doc

John Mueller, Google — 2021 comment on mobile-specific detection (historical, not restated in current docs)

• “In Search Console, we do show soft 404s but we show it for the mobile version… So if on the mobile version everything is okay on your side, then in Search Console it will look like it’s indexed normally. But for desktop, you won’t be able to see that directly in Search Console.” — John Mueller, Google, via Search Engine Land (2021). Read the coverage

John Mueller, Google — redirecting vs. 404ing discontinued products

• “The short version, imo, is to do what works best for the user, and search engines will generally figure it out from there too. Sometimes that’s a redirect, sometimes a friendly 404 page (and those can be customized too).” — John Mueller, Google, via Search Engine Roundtable. Read the coverage

Finding and fixing soft 404s

Find them in Google Search Console

• Open Search Console → Indexing → Pages (the Page Indexing report — older articles and Google’s own older posts call this the “Coverage” report).
• Scroll to “Why pages aren’t indexed” and look for the “Soft 404” reason row.
• Click into it to get the list of affected URLs, and export them.
• Spot-check a URL with URL Inspection → Test live URL → View tested page to see the rendered screenshot and HTTP response Google got.
• Check the page’s smartphone rendering in URL Inspection — Google crawls and indexes primarily as mobile Googlebot, so confirm that view first (an older, unconfirmed report also tied soft-404 detection specifically to mobile rendering).
• Cross-check at scale with a crawler (Ahrefs Site Audit, Screaming Frog, Sitebulb) that flags “possible soft 404” phrases and thin/empty pages — but remember these are the tool’s own heuristic, not proof Google’s classifier reached the same conclusion. Confirm any flagged URL against Search Console or a live URL Inspection test before acting on it.

Fix workflow — one question per URL: should this page exist?

• Gone for good? Return a real 404 (or 410). Stop serving a 200 with a not-found template.
• Moved / has a real equivalent? 301 redirect to that relevant page — not the homepage or an unrelated category (that gets reclassified as a soft 404).
• Should stay live? Add substantive content so it no longer reads as empty or error-like.
• Empty internal search / filter pages? noindex them and/or block the path in robots.txt, or render useful fallback results.
• JS/SPA route? Configure the server/framework to return a real 404 for unknown routes (e.g., Next.js notFound()), not a client-rendered “404” with a 200.
• Don’t rely on noindex alone — it still returns 200 and doesn’t resolve the mismatch.
• After fixing, re-test with URL Inspection and Request indexing (or Validate fix) in the Page Indexing report.

Concrete soft 404s — before and after

Three of the most common patterns, with what’s wrong and how to fix each.

1. Empty internal search results page

• Before: example.com/search?q=asdfgh returns 200 OK and renders “0 results found.” The app shell loads fine, the status code is a success, but there’s no real content — Google flags it as a soft 404. Multiply this across every zero-result query a user (or a crawler following a faceted link) generates, and you get a pile of them.
• After: Add noindex to search-results pages and/or block the /search path in robots.txt so bots don’t index them at all. If you want them useful for users, render fallback content (popular products, related suggestions) instead of a bare “no results.”

2. Out-of-stock / discontinued product page

• Before: A discontinued SKU at /products/old-widget has had its content stripped down to “This product is no longer available,” but still returns 200. Or, worse, it 301 redirects to the homepage. Either way Google treats it as a soft 404, and the links that pointed at the product don’t consolidate anywhere useful.
• After (pick by intent): If there’s a genuine successor, 301 to that specific product so link value transfers. If it’s simply gone, return a 404/410. If it’s only temporarily out, keep the page live with real content and note when it’s returning — and for very large catalogs, automate expiration with unavailable_after. Don’t mass-redirect to the homepage.

3. Thin JavaScript-rendered page (SPA route)

• Before: A single-page app serves /account/orders/99999 (an order that doesn’t exist). The client-side router returns the app shell with 200, then renders “Order not found” as on-page text. Real HTTP status: 200. Rendered content: an error message. Classic soft 404, and every broken deep link produces another one.
• After: Intercept unknown routes on the server or edge and return a real 404 — for example, Next.js’s notFound() helper, an SSR/prerender check that 404s missing entities, or an edge rule that 404s paths with no backing data. The page should send the status code that matches what it renders.

4. One retired-product template, thousands of successful empty responses

• Before: A crawl finds 18,400 URLs matching /products/retired-*. Every URL returns 200 OK, the title is “Product unavailable,” the body is the same two-sentence shell, and no replacement product is linked. A status-code export looks green even though the rendered cohort behaves like missing content.
• After: Fix the route or template once: return 404/410 when no replacement exists, issue a direct 301 only when a genuinely equivalent successor exists, or keep a useful product page when demand and user value justify it. Recrawl a representative sample, compare rendered content as well as status, and verify the Page Indexing reason after Google processes the change.

The counts and URLs are illustrative. The point is the cohort: repeated titles, body fingerprints, and template paths reveal a systemic soft-404 cause faster than reviewing individual URLs.

What should this soft-404 URL do?

Soft-404 fixes that are not fixes

Return 200 for every route

Why it’s wrong: An error template or empty page with a success response creates the mismatch Google is classifying.

Do instead: Return a real 404/410 for missing resources, or restore substantive content when the URL should exist.

Add noindex and leave the mismatch

Why it’s wrong: noindex does not change the 200 response or make an empty/error page valid. It controls indexing, not HTTP truth.

Do instead: Correct the response or content first; use noindex only when it matches the actual page strategy.

Redirect every removed URL to the homepage

Why it’s wrong: An irrelevant catch-all destination can itself be treated as a soft 404 and does not preserve useful intent.

Do instead: Redirect only to a genuinely equivalent page. Otherwise return an intentional 404 or 410.

Treat the Search Console label as a penalty

Why it’s wrong: The label describes how Google interpreted the URL; it is not a manual action or site-wide punishment.

Do instead: Decide the intended URL state, verify the live response and rendered content, and fix only mismatches.

Assume the report is complete and immediate

Why it’s wrong: Google must crawl and render the page, and Search Console can lag or show examples rather than a real-time inventory.

Do instead: Combine the report with live requests, smartphone rendering checks, server logs, and a crawl of the affected templates.

Common soft-404 symptoms

The page says “not found” but the network response is 200

Likely cause: The CMS, framework, or single-page-app router renders an error template without setting the document response status.

Fix: Return 404/410 from the server, SSR layer, or edge for unknown routes. Confirm with a fresh document request, not only the text visible in the browser.

Discontinued products appear as soft 404s

Likely cause: The product template was stripped to an availability sentence, or many products redirect to a broad category/homepage.

Fix: Keep temporarily unavailable products useful and substantive; redirect a permanently removed product only to a real successor; otherwise return 404/410. Re-test the status, destination relevance, and rendered page.

Empty search, tag, or filter pages are flagged

Likely cause: Auto-generated URLs return 200 with no results or near-empty boilerplate.

Fix: Prevent useless combinations from being discoverable/indexable where appropriate, provide useful fallback content for pages that should exist, or return a truthful missing response. Confirm the chosen template no longer produces an empty 200 at scale.

The live page looks fine, but Search Console still says soft 404

Likely cause: Google saw an older version, smartphone rendering differs, required resources failed, or the fix has not been recrawled.

Fix: Use URL Inspection’s live test and rendered screenshot, compare the mobile document response and resources, then request validation after the live evidence is correct. Do not change a healthy page solely because the report has not refreshed.

An apparently valid redirect is reported as a soft 404

Likely cause: The destination is unrelated to the source intent, commonly a homepage or broad catch-all category.

Fix: Map to a specific equivalent or remove the redirect and return 404/410. Confirm the entire chain ends on a relevant 200 page.

Prompt: classify suspected soft 404s

Paste a CSV with URL, HTTP status, final URL, rendered title/H1/body excerpt, intended state, template, sitemap presence, and Search Console reason. Remove private or user data first.

Classify each suspected soft-404 URL using only the supplied evidence.

Use these cause buckets:
1. missing/deleted URL returning a success response;
2. thin or empty generated page;
3. irrelevant redirect destination;
4. JavaScript/rendering failure;
5. likely valid page that needs live mobile verification;
6. insufficient evidence.

For every row, report the likely bucket, exact supporting evidence, intended-state
conflict, recommended next check, and the appropriate outcome: real 404/410, 301 to a
genuine equivalent, restore substantive content, fix server/rendering behavior, or no
change pending verification. Do not recommend noindex as the sole fix for a 200 error
page. Do not invent replacement URLs or infer page quality from word count alone.

Return a table and group repeated template-level causes separately from one-off URLs.

DATA:
[PASTE SANITIZED CSV HERE]

Validate classifications with a live request and smartphone-rendered output before deploying a template-wide change.

Tools for confirming the mismatch

• Google Index Checker — check observable status, redirects, noindex, and canonical blockers, then follow its handoff to Search Console URL Inspection for Google’s actual indexed-state answer. It does not claim to query Google’s private index directly.
• Bulk HTTP Status Code Checker — collect live status codes and final destinations for a suspected URL set. Pair the export with rendered content evidence; status alone cannot identify a soft 404.
• Search Console Page Indexing report — find Google’s Soft 404 reason group and affected examples.
• URL Inspection → Test live URL → View tested page — compare the live document status, HTML, screenshot, and loaded resources as smartphone Googlebot sees them.
• A rendering-capable crawler — locate 200 pages with error phrases, empty templates, or irrelevant redirect destinations across a whole site. Review false positives rather than treating phrase matching as Google’s classifier.

Test yourself: Soft 404 Errors

Five quick questions on what soft 404s are and how to fix them. Pick an answer for each, then check.

Resources worth your time

My related writing

• HTTP Status Codes & Their SEO Impact — my breakdown of how Google handles 2xx codes, including the soft-404 definition quoted above.
• How Should You Handle Out-of-Stock Products? It Depends — the redirect-relevance nuance and why redirecting to a category or homepage can become a soft 404.
• 11 Types Of Redirects & Their SEO Impact — how Google treats irrelevant redirects as soft 404s and why link equity then doesn’t pass.
• The Beginner’s Guide to Technical SEO — where status codes and indexing fit in the bigger picture.
• JavaScript SEO Issues & Best Practices — why client-side routing produces soft 404s and how to return real status codes.

My speaking

• SMX replay: SEO that Google tries to correct for you (Search Engine Land) — coverage of my SMX Advanced session on the signals Google silently overrides, soft 404s among them.

From around the industry

• Page indexing report — “Soft 404” (Google Search Console Help) — the canonical, maintained definition and fix recommendation.
• Troubleshoot Google Search crawling errors — soft 404s (Google Search Central) — the most direct current explainer, with the cause list and the three fix branches.
• HTTP status codes, network and DNS errors, and Google Search (Google Search Central) — the 2xx-status mechanics behind soft-404 detection.
• Google now does soft 404 detection by device type (Search Engine Land, 2021) — Mueller’s mobile-rendering comment; historical, not restated in Google’s current soft-404 documentation.
• Google On Redirecting vs 404ing Products That No Longer Exist (Search Engine Roundtable) — Mueller’s “do what works best for the user” guidance and the irrelevant-redirect angle.
• 404 vs. Soft 404 Errors: What’s The Difference & How To Fix Both (Search Engine Journal) — a solid competitor explainer of the distinction.
• What is a soft 404 error and what to do about it? (Yoast) — plain-language overview with WordPress-flavored fixes.
• Soft 404 Pages (issue doc) (Screaming Frog) — how a crawler flags likely soft 404s at scale.
• Contains possible soft 404 phrases (Sitebulb) — the phrase-matching heuristic for catching them in an audit.

Soft 404

A soft 404 is a URL that returns a success status code (usually 200 OK) even though the page is empty, missing, or shows a 'not found' message. It isn't a status code a server sends — it's a label search engines apply after comparing the response code against the rendered content, and they treat the page like a 404 for indexing.

Related: 404 Not Found, HTTP Status Code

Soft 404

A soft 404 is what you get when a page’s HTTP status code says one thing and its content says another. The server returns a success code — almost always 200 OK — but the page itself is blank, has effectively no content, or displays a “not found” / “no results” message. Google (and Bing) notice the mismatch, override the 200, and treat the URL like a 404 Not Found for indexing purposes.

The key thing to understand is that soft 404 is not a real status code. No server ever literally sends “soft 404.” It’s a classification search engines apply after rendering the page and comparing what they see against the response code. That’s why you find it labeled “Soft 404” in Google Search Console’s Page Indexing report rather than in your server logs.

Contrast it with a true (hard) 404: a hard 404 Not Found correctly tells both browsers and search engines that the page doesn’t exist. A soft 404 tells them the page loaded fine, while the content says otherwise. The fix is to make the code match the content — return a real 404/410 when a page is genuinely gone, or add substantive content when it should stay live.

Related: 404 Not Found, HTTP Status Code

Changelog