On this page · 7 sections
A URL flagged as a soft 404 can't appear in Google Search or in the AI features built on Google's index, so a false flag on a live product or article page quietly removes it. This guide quotes Google's definition, shows when to leave the status alone, covers the usual causes by platform, and walks through confirming, fixing, validating and recrawling.
What does "Soft 404" mean in Search Console?
"Soft 404" means Google requested the URL, got a 200 (success) response, and judged from the content that the page is really an error or empty page. As of October 2026, Google's help page defines it like this: "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" (Page indexing report help).
Google's crawling guide adds that it isn't only "not found" messages: "In some cases, it might be a page with no main content or empty page." It explains how the label is applied: "When Google's algorithms detect that the page is actually an error page based on its content, Search Console will show a soft 404 error in the site's Page Indexing report" (Troubleshoot crawling errors).
The status is a mismatch: the status code says "this page is fine", and the content says "there's nothing here".
What the server sends | What the page shows | What Search Console reports |
|---|---|---|
404 or 410 | Anything | Not found (404), or another error status |
200 | Real content | Indexed, or another non-error status |
200 | "Not found", an error message, or almost nothing | Soft 404 |
Is a soft 404 a problem?
A soft 404 is a problem only when the flagged URL is a page you want in search. Google says such pages "are excluded from Search", and that returning 200 while showing an error is "a bad user experience" (Google Search Central).
Leave it alone, apart from returning the right status code, when the flagged URLs are:
- Products, posts or pages you deleted on purpose. Wix's help says soft 404s for "deleted product pages or deleted blog posts" are "normal behaviour and will be resolved eventually" (Wix Help Center).
- Internal search result pages with no results.
- Old URLs nobody links to any more.
Treat it as a problem when:
- A live page with real content is flagged. That usually means Googlebot saw something different from what your visitors see.
- The count jumps after a release. A template, routing or hosting change can turn many working pages into empty ones for Googlebot.
- Thin pages you meant to rank are flagged. Wix notes soft 404s can appear "if it thinks your site pages contain little or no original content."
If flagged pages are spread across several sites or clients, check which of them Google has indexed free before you start changing templates.
What causes soft 404 errors?
Soft 404s come from pages that return 200 when they should return an error, or that look empty to Googlebot. Google lists typical triggers: "A missing server-side include file", "A broken connection to the database", "An empty internal search result page" and "An unloaded or otherwise missing JavaScript file" (Google Search Central).
Cause | What it looks like | Typical fix |
|---|---|---|
Missing page served with 200 | "Page not found" text on a 200 response | Return 404 or 410, or redirect |
Empty or near-empty page | Empty category, no search results, a page with only a heading | Add real content, or return 404 |
Page didn't render for Googlebot | Blank or broken screenshot in URL Inspection | Unblock or fix the resources it needs |
Client-side routing in a single-page app | Every path returns the same 200 shell | Redirect to a real 404 URL, or add |
Error shown during a streamed response | Not-found UI on a 200 response | Platform-specific; see below |
Missing pages that still return 200
Missing pages that return 200 are the classic soft 404. Many sites and apps answer every path with the same page, then show "not found" in the content. You can check what your server sends for a path that shouldn't exist:
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/this-page-does-not-exist-123On October 17, 2026 we ran that check against a made-up path on freshlycited.com and got 404, the right answer. We then ran a small local test server that serves the same index.html for every path, the way client-side routing setups often do, and one that returns 404 for routes it doesn't know:
catch-all server: 200 /products/discontinued-mug
fixed server: 404 /products/discontinued-mug
fixed server: 200 /The catch-all response is the pattern Google can flag: a 200 code with "Sorry, this page could not be found" in the rendered page.
Empty or near-empty pages
Empty or near-empty pages get flagged even when nothing is broken. Google's definition covers "a page with no main content or empty page", and its example list includes "An empty internal search result page." An empty category or collection in an online store, or a tag page with no posts, can fit the same description.
Pages that didn't render for Googlebot
A page that works in your browser can still look empty to Googlebot. Google says an otherwise good page flagged as a soft 404 most likely "didn't load properly for Googlebot, it was missing critical resources, or it displayed a prominent error message during rendering." It names the usual reasons resources fail: "blocked resources (blocked by robots.txt), having too many resources on a page, various server errors, or slow loading or very large resources" (Google Search Central).
Platform notes
Some setups make soft 404s more likely. Each note below comes from the platform's or Google's own documentation, as of October 2026.
Platform | What its documentation says | What to check |
|---|---|---|
React and other client-rendered apps | Google: with client-side routing, "using meaningful HTTP status codes can be impossible or impractical" | Missing routes return 200; see our React indexing guide |
Lovable | Apps created from May 13, 2026 use server-side rendering; older React + Vite apps are pre-rendered for verified crawlers (Lovable docs) | Run the curl check on a missing path; see our Lovable guide |
Next.js | "Streaming page responses begin with a 200 status code"; a streamed not-found page gets | Call |
Wix | Soft 404s can follow deleted pages or "little or no original content" (Wix Help Center) | Content on flagged pages; see our Wix guide |
How do you confirm a soft 404 with URL Inspection?
Confirm a soft 404 by inspecting an example URL and looking at what Google rendered, not what your browser shows. Google's own instruction is to "run a live URL inspection test against the page and click View tested page to see a screenshot showing how Google renders the page" (Search Console Help).
- Open the reason in the Page indexing report and click the inspect icon next to an example URL. Our URL Inspection tool guide explains every field.
- Check the indexed result's crawl date. If you fixed the page after that date, the flag may already be out of date.
- Click Test live URL, then View tested page. A screenshot is available "only in a live test with a successful test result" (URL Inspection tool help).
- Read the screenshot, HTML and resources. The panel shows "a screenshot of the rendered page, the raw HTML returned, the HTTP headers, JavaScript console output, and any page resources loaded."
- Decide which case you have: the page is gone, has moved, or exists but rendered badly or thinly. Each needs a different fix.
How do you fix a soft 404?
Fix a soft 404 by making the status code and the content agree. Google's fix depends on which of three states the page is in: "The page and content are no longer available", "The page or content is now somewhere else", or "The page and content still exist" (Fix soft 404 errors).
- Gone with no replacement: return 404 or 410. Google says these codes "indicate to search engines that the page doesn't exist and you don't want search engines to index the page." Keep a helpful custom 404 page for visitors, but make sure "the server returns a 404 HTTP status code."
- Moved: return a 301 redirect. Google says if the page "has moved or has a clear replacement on your site, return a 301 (permanent redirect)."
- Still exists: fix what Googlebot sees. Unblock CSS and JavaScript the page needs in robots.txt, cut very large or slow resources, and fix server errors on resource requests. Then re-run the live test.
- Thin page: add what makes it useful, or merge it into a stronger page and redirect the old URL.
- Single-page app: send Googlebot a real error signal. Google offers two options: "Use a JavaScript redirect to a URL for which the server responds with a 404 HTTP status code", or "Add a
<meta name="robots" content="noindex">to error pages using JavaScript" (JavaScript SEO basics). Google's redirect example looks like this:
fetch(`/api/products/${productId}`)
.then(response => response.json())
.then(product => {
if(product.exists) {
showProductDetails(product); // shows the product information on the page
} else {
// this product does not exist, so this is an error page.
window.location.href = '/not-found'; // redirect to 404 page on the server.
}
})If you use the noindex route, the URL will then show as excluded by a noindex tag rather than as a soft 404. Don't put noindex in the original HTML of pages you do want indexed: Google says that when it sees noindex it "may skip rendering and JavaScript execution", so removing it with JavaScript later may not work.
How do you validate the fix?
Validate a soft 404 fix by clicking Validate fix on the Soft 404 reason once every affected URL is fixed, then re-inspecting a few of them. Google says validation "typically takes up to about two weeks, but in some cases can take much longer" (Search Console Help).
- Expect pages you removed to change status, not to get indexed. A URL that now returns 404 belongs under "Not found (404)", and Google says "404 responses are not necessarily a problem, if the page has been removed without any replacement."
- Expect fixed live pages to leave the soft 404 list and, if Google keeps them, to show as indexed.
- Watch for a stubborn thin page. If a fixed page drops into crawled - currently not indexed, Google reached it and decided it wasn't worth keeping yet; that's a content question.
When should you push the URL for a recrawl?
Push for a recrawl only for live pages you fixed, and only after the fix is deployed. Don't push URLs you turned into 404s, 410s or redirects: there's nothing there for Google to index.
- A few important URLs: use Request indexing in URL Inspection. You "cannot request indexing if the page is considered to be non-indexable in the live test" (URL Inspection tool help), and Google says "requesting a recrawl multiple times for the same URL won't get it crawled any faster" (Ask Google to recrawl).
- Many URLs: resubmit a sitemap with accurate
<lastmod>dates for the fixed pages. - Then wait and re-check. Google says crawling "can take anywhere from a few days to a few weeks."
Our guide to submitting a fixed URL to Google compares the routes. If you manage many sites, you can check which fixed pages Google has indexed in one list, then push only the ones still invisible. FreshlyCited re-checks each pushed link on days 1, 3 and 7, and an index credit is used only if the link gets indexed, and comes back after the day-7 re-check if it isn't (exclusions apply, such as pages that return an error or carry noindex). Its pre-flight check flags URLs that return 404, 410 or 5xx first, so you can skip them for free. Google still decides what it indexes. A sibling status worth knowing is blocked due to other 4xx issue, where the server does return an error code.
Fixed a batch of soft 404s? Check your pages free to see which ones Google now has, and push only those it still can't see.
Written by
