Why Does Search Console Say Your Page Is a Soft 404?

Why does Search Console say your page is a soft 404?

Because the page tells a visitor that something is missing while telling Google that everything is fine. Google's own wording is that the page "returns a user-friendly 'not found' message but not a 404 HTTP response code". The words and the status code disagree, so Google trusts neither.

This is one of the most common reports we see when we take over a B2B site that has been running for a few years. It rarely breaks anything a visitor would notice. It quietly keeps pages out of the index, and it makes the rest of your indexing data harder to read.

The fix is almost always small. Finding which pages are affected, and why, is the part that takes a little care.

What is a soft 404, exactly?

It is a mismatch between content and status code. The server answers with a success code, usually 200, and then the page shows an error message, an empty state, or nothing useful. Google's Page Indexing report flags this as a soft 404 and lists it under pages that are not indexed.

The word "soft" is doing real work here. A hard 404 is honest. The server says the page is gone and Google removes it. A soft 404 is a page claiming to exist while behaving like a page that does not.

Google's recommended action is direct: "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." That second half matters. Sometimes the page is real and just too thin to look real.

Why does Google care about the status code at all?

Because the status code is how it decides what to keep. Google's documentation on HTTP status codes says it does not index URLs that return a 4xx status code, and that previously indexed pages returning 4xx are removed from the index. That is a clean, predictable rule.

A 200 gets no such promise. Google states plainly that a 200 status code does not guarantee indexing. The content still has to earn its place. So a page that returns 200 and shows nothing is asking Google to make a judgement call, and the call goes against you.

Redirects sit in between. Google describes a 301 as a strong signal to use the redirect target, and a 302 as a weak one. If you are moving a page for good, the stronger signal is the one you want. We cover the whole set in our guide to HTTP status codes and SEO.

What actually causes soft 404s on B2B sites?

Four patterns cover most of what we find. The first is a CMS that renders a custom "page not found" template at a 200 status. The design team built a nice error page, and nobody checked the header.

The second is an empty collection. A blog category with no posts, a careers page with no open roles, a case study filter with no matches. The template loads, the loop returns nothing, and the page ships an empty shell with a success code.

The third is a retired page that was left in place with a short "this product has moved" note. The fourth is a search results page with no results, indexed because the URL got linked or submitted somewhere. All four look fine to a person. All four look like nothing to a crawler.

How do single page apps create soft 404s?

By design, unless someone stops them. A client-rendered app answers every URL with the same shell at a 200 status, then decides in the browser what to show. Google's documentation names this exactly: single page applications commonly report a 200 status where an error code belongs, so error states get indexed.

Google gives two fixes. The first is to "redirect to a URL where the server responds with a 404 status code". The second is to "add or change the robots meta tag to noindex". The first is cleaner for genuinely missing content. The second works when a redirect is impractical.

This is one more reason we push marketing sites toward static or server rendered output rather than a client-rendered app. The crawler gets a real answer from the server. We go deeper on the tradeoffs in JavaScript rendering and SEO.

Should you return 404 or 410?

Either, and the difference is smaller than the internet suggests. Google's documentation treats 404 and 410 the same way: both are 4xx, both mean the URL is not indexed, both mean an indexed URL gets removed.

We default to 404 because it is what every platform and CDN already supports, and because a 410 claims certainty about a page never coming back. If your CMS makes 410 easy and you are sure the content is gone for good, use it. Do not build tooling for it.

What matters more is that the response is fast and the page is useful. An error page that loads slowly wastes crawl requests. An error page with no navigation wastes the visitor who landed there. We wrote about both sides of that in 404 pages and broken links.

When is a redirect the right fix instead?

When there is a genuinely equivalent page. A product renamed, a service page merged into a bigger one, a blog post replaced by an updated version. Those are redirects, and a 301 is the right code.

When there is no equivalent, redirecting everything to the homepage is the mistake we see most. It feels tidy. It creates a different problem: a stream of unrelated URLs all resolving to one page, which Google may itself treat as a soft 404 because the destination does not match the request.

Our rule is simple. Redirect to a page that answers the same question the old URL answered. If no such page exists, return a 404 and make the error page genuinely helpful.

How do you find and confirm a soft 404?

Start in the Page Indexing report in Search Console. Soft 404 is one of fourteen reasons Google lists for a page not being indexed, alongside "Crawled, currently not indexed", "Duplicate without user-selected canonical", "Excluded by noindex tag" and "Page with redirect". The report gives you example URLs, which is what you need.

Then confirm at the URL. Request the page and read the status code rather than trusting the browser. Any command line request or a browser network panel will show it. If a page shows an error message at a 200 status, you have found one.

For anything rendered in the browser, use the URL Inspection tool and read the rendered HTML. Google's own guidance for lazy loaded content is to "check the rendered HTML to make sure your content is in the rendered HTML by looking for it in URL Inspection Tool". The same check tells you whether your empty state or your real content is what Google sees.

What about real pages Google calls soft 404s?

They exist, and they are the more interesting case. If a page is genuinely live but has almost no content, Google can read it as an error page. That is the situation Google's advice about "adding more information on the page" is aimed at.

We see this on programmatic pages most often: location pages with a heading and a form, integration pages with a logo and one sentence, or filtered views generated from a CMS. The template works. The content does not exist yet.

The answer there is not a status code change. It is either writing enough real content to justify the page or consolidating the set into fewer, better pages. We laid out how we make that call in consolidating thin pages.

How do you stop soft 404s coming back?

Make the status code part of your launch checklist, not an SEO audit finding. Before a site goes live we request a URL that definitely does not exist and confirm the header says 404. It takes one command and it catches a class of problem that otherwise sits undetected for a year.

Then check empty states. Every list template on the site should be asked what it does with zero items. A category with no posts should either not exist as a URL or should carry a noindex tag. Google's crawler does not click, scroll or type, so whatever the template renders on its own is the whole story.

If your Search Console report is full of soft 404s and you are not sure which are real pages and which are leaks, we are happy to take a look. Send the property and the site at phoenix.studio and we will tell you which ones actually matter.