Soft 404 Errors: How to Find and Fix Them in Search Console

A normal 404 is honest: the server says the page does not exist, and says so with the HTTP status code 404. A soft 404 is the opposite. The page looks like an error, an empty shell or a "nothing found" message, but the server answers with a success status such as 200. Search engines then have to guess, and when Google guesses that the page is really an error, Search Console reports it as a soft 404.

This guide is for site owners and developers who see the "Soft 404" status in the Page Indexing report, or who suspect their error pages answer with the wrong code. You will learn how to confirm what your server returns, how to decide whether each URL should exist, and how to fix the cause in a CMS, a custom server or a single-page app. You will also learn what a fix cannot do: it does not force a page into the index, and it does not stop Google from reporting the same status again if the page still looks empty.

Before you begin

You need access to Search Console for the property, a way to inspect HTTP responses (browser developer tools or curl), and the ability to change either the page, the server or the CMS template that renders it. A developer is useful if your site is a single-page app.

Before you change a template or a redirect rule, save the current version. Allow an hour for a first pass. Search Console takes longer to update: Google's help says validation typically takes up to about two weeks, and can take much longer.

Know the terms. A status code is the three-digit number at the start of a response. Google ignores the content of pages that return 4xx codes, and it treats 404 and 410 alike, so you do not need to choose between them to fix a soft 404. A 200 response is processed as a page, and if it looks empty or like an error message, Search Console flags it.

What counts as a soft 404

Google's own wording is brief. Under its documentation of 2xx responses, it says that if the content suggests an error for Google Search, such as an empty page or an error message, Search Console shows a soft 404. The Page Indexing report's help page defines the status as a page that shows a "not found" message but returns a normal HTTP status instead of a 404 code.

In practice, soft 404s tend to come from a few places:

A CMS or custom router that shows a friendly "page not found" template but forgets to set the 404 status.
A category, tag or search results page with no items, which renders an empty list with a 200 status.
A product that is out of stock and removed, but whose URL still returns an almost empty page.
A single-page app that serves the same shell for every address and decides client-side that the content is missing.
A redirect that sends many unrelated missing URLs to one page, such as the home page.

The last case deserves a caution. As a matter of plain design, a visitor looking for a retired page should land on a relevant replacement or on an honest error, not on an unrelated page.

Step-by-step instructions

Step 1: List the soft 404 URLs

In Search Console open Indexing, then Pages, and find "Soft 404" under the reasons pages are not indexed. Open the example list and copy the URLs. Look for patterns: a folder, an empty-results template, a product type, a parameter.

What success looks like: You have a list of URLs grouped by pattern, not a single count.

Step 2: Check what the server really returns

For each pattern, request one URL and read the status code. With curl:

curl -I https://example.com/old-product-page

Read the first line. HTTP/1.1 200 OK on a page that says "not found" confirms a soft 404. A 404 or 410 means the server is behaving correctly, and the report may be stale. A redirect (301, 302) is a different case; the status of a redirected URL is covered in Page with redirect.

Then open the same URL in Search Console's URL Inspection tool and run the live test. Google suggests viewing the tested page's screenshot to see how Google renders it. If the screenshot shows an empty frame or an error message, you have the cause.

What success looks like: You know the exact status code and what Google renders for each pattern.

Step 3: Decide whether each URL should exist

This decision drives the fix. For each pattern, choose one answer.

The page is gone for good. Return a real 404 (or 410).
The page should exist, but its content is thin or empty. Add real content, or merge it into a better page and redirect.
The page has moved. Redirect it to its new equivalent with a 301. See 301 vs 302 redirects for the choice of code.
The page is a useful but empty list. Decide whether it should be indexed. If not, noindex it; if so, give it content.

Be honest in this step. Pages that exist only to hold a "nothing here" message should usually not be crawlable results.

What success looks like: Every pattern has a decision: 404, enrich, redirect or noindex.

Step 4: Return a real 404 for pages that no longer exist

Google's help for the status says that for truly missing pages you should return a real 404 response. How you do it depends on the platform.

In a CMS, find the not-found template or the setting for deleted content and make sure it sets the status. In a custom application, set the status on the response where you render the error view, not just the page body. Many frameworks have a way to re-execute the pipeline with the status code set; check your framework's documentation rather than redirecting the visitor to an error page.

Do not redirect missing URLs to a generic error page. A redirect to an error page that returns 200 recreates the soft 404 at a new address. Serve the 404 at the URL where the page was requested. Create a custom 404 page that works for visitors and sends the right status.

For a server that handles unknown addresses badly, a test is simple: request an address you know is absent, such as https://example.com/this-page-should-not-exist-12345, and confirm the response is a 404.

What success looks like: A request for a made-up address returns 404, and the same page still shows a helpful message to visitors.

Step 5: Add real content where the page should exist

If a page is meant to exist but Google sees little on it, the fix is content. Google's help says that for pages that should exist, you can add more content so they are not treated as soft 404s. Check the live-test screenshot again. If the main content loads only after a script runs, make sure it renders for Googlebot (see JavaScript SEO rendering basics). For empty category pages, either fill them or stop linking to them until they contain products or articles.

What success looks like: The tested page in URL Inspection shows the real content, not an empty template.

Step 6: Handle single-page apps

In a single-page app, routing happens in the browser, and the server may return the same shell with a 200 for any path. Google's JavaScript SEO documentation notes that meaningful status codes can be impossible or impractical here, and gives two workarounds.

The first is to redirect with JavaScript to a URL for which the server returns a real 404, such as /not-found:

fetch(`/api/products/${productId}`)
  .then(response => response.json())
  .then(product => {
    if (product.exists) {
      showProduct(product);
    } else {
      window.location.assign('/not-found'); // the server returns 404 for this path
    }
  });

The second is to add a noindex robots meta tag to the error view with JavaScript, if no other robots meta tag is already present:

const meta = document.createElement('meta');
meta.name = 'robots';
meta.content = 'noindex';
document.head.appendChild(meta);

Server-side rendering of status codes is the cleaner route if your framework supports it.

What success looks like: Nonexistent routes either lead to a URL that returns 404 or carry noindex.

Step 7: Confirm and validate

Retest a sample of URLs in each pattern with curl and the live test. When every instance is fixed, return to the issue in Search Console and press "Validate fix". Google says to do this only after fixing all instances and not to press it again until the validation has succeeded or failed. If it fails, use "See details", fix the URL that caused the failure and start a new validation.

What success looks like: The validation completes and the number of soft 404 URLs falls on later reports.

Final verification checklist

Each soft 404 pattern has a decision: real 404, richer content, redirect or noindex.
curl -I on a made-up address returns a 404 status.
Removed pages return 404 or 410 and still show a helpful message to visitors.
Pages that should exist have unique main content visible in the live test screenshot.
Redirects point to a relevant replacement, not to an unrelated page.
Single-page app error routes lead to a 404 URL or carry a noindex tag.
You pressed "Validate fix" once, after every fix was live.
You reviewed the sitemap and removed URLs that now return 404.

Common mistakes to avoid

Fixing only the message. Changing the words on the page does not change the status. Check the status code.
Redirecting every missing URL to the home page. Visitors lose the context they came for. Redirect only to a close equivalent.
Leaving 404 URLs in the sitemap. A sitemap should list indexable pages only. See Find and Fix 404 and 500 Errors in XML Sitemaps.
Serving a 404 status with a full, normal page body that is empty of help. Visitors still need a way forward. Add search and navigation links.
Treating empty internal search pages as content. Block or noindex them unless they offer value.
Using JavaScript to rewrite the status. Scripts cannot change the HTTP status code of the response that already arrived. Use the documented workarounds instead.
Blocking soft 404 pages in robots.txt. A blocked URL cannot be rechecked. Fix the response instead.
Pressing Validate fix before all instances are repaired. Fix everything first.

Frequently asked questions

What is the difference between a soft 404 and a 404?

A 404 sends the "not found" status code. A soft 404 shows a not-found message, an empty page or little content but returns a success status such as 200.

Does a soft 404 hurt my whole site?

A soft 404 URL is not treated as a normal page, which matters most when it is one you wanted to appear in search. Use the report to find genuine mistakes rather than treating the count as a site-wide score.

Should I use 404 or 410 for removed pages?

For Google Search they are handled alike. Google says all 4xx errors except 429 are treated the same, so either removes already indexed URLs and gradually reduces crawl frequency. See 410 vs 404.

Can a page with real content be flagged as a soft 404?

Yes, if it looks empty or like an error to Google. Check the rendered page in the live test, especially if content loads through JavaScript.

Is it a soft 404 if I redirect to another page?

A redirect is a separate status in the report. The destination should be a relevant page. If the destination itself looks like an error, it can be flagged.

Does Crawvix check for soft 404s?

Crawvix has a check that requests a random address that should not exist and flags a success status, available to verified site owners, and a heuristic check that flags pages that return a success status, use "not found" wording in the title or main heading and have very little text.

Official references

Next step: See how Crawvix checks a website and capture a baseline once scanning opens. This guide provides technical information, not a guarantee of rankings, traffic or index inclusion.