What Is a Soft 404, and Why Does Google Decide You Have One?

What is a soft 404, and why does Google decide you have one?

A soft 404 is a page that tells a person it does not exist while telling a machine that everything is fine. Google's own help documentation describes the status as a page returning a user-friendly not found message but not a 404 HTTP response code. Google reads the content, sees an error page, and labels it accordingly.

The part that surprises people is that this is a judgement, not a rule. Nothing in your headers triggered it. Google looked at what the page said and concluded that a human arriving there would think the page was missing, regardless of what the server claimed.

That makes soft 404 one of the few statuses in Search Console you cannot debug purely with a network tool. You have to look at the page the way Google looked at it, which is as a reader rather than as a response code.

Why does Google judge the content rather than the status code?

Because the status code is frequently wrong and the content usually is not. Plenty of systems serve a friendly page saying the item could not be found, with a 200 response, either by default or because somebody built the error page as an ordinary page. Trusting the header alone would fill the index with apologies.

So the check is a sanity test on what you told it. If your server says success but your page says failure, one of those is a lie, and Google resolves it in favour of the thing a user would experience. That is the right call, even when it is inconvenient.

The consequence is that the label is probabilistic. Google's documentation phrases it as what they think is a soft 404 response, which is unusually candid for platform documentation and worth taking literally. Sometimes the judgement is wrong, and when it is, the fix is to make the page less error-like rather than to argue.

What kinds of pages get flagged by accident?

Thin pages that read like an absence. A category page with no items in it. A search results page with no matches. A product page for something out of stock that says this is no longer available. A location page with a placeholder paragraph and nothing else. None of these are errors, and all of them sound like one.

The common thread is a page that exists on purpose but has nothing to say today. That is an ordinary state for any site driven by a database, and it is exactly the state that looks like a missing page from the outside.

The second group is pages where the real content is loaded after the initial response and never quite arrives for a crawler. The visible text at assessment time is a loading message or an empty shell, which is indistinguishable from a page that failed. The content exists. It just was not there when it was looked at.

What does Google say to do about it?

Two things, and the second is the one people miss. Google's help documentation recommends returning a 404 response code for truly not found pages, and adding more information on the page to let them know that it is not a soft 404. So either agree with the diagnosis, or make the page substantive enough to disagree with it.

The first path is for pages that genuinely should not exist. Stop serving a friendly 200 for them and return a real 404. That is a configuration change and it is usually quick, once you have found where the friendly page is coming from.

The second path is for pages that should exist and are currently too thin. An empty category page can carry an explanation of what belongs in that category and links to related ones. An out-of-stock product page can say what the product is, what replaced it, and when it might return. You are giving the page a reason to be read by somebody, which is also what makes it stop reading as an error.

When should a page return 404 and when 301?

Return 404 when the thing is gone and nothing replaced it. Use a permanent redirect when the content moved somewhere else. Google's documentation is explicit that 404 responses are not necessarily a problem if the page has been removed without any replacement, which is permission a lot of site owners do not realise they have.

That permission matters because the reflex on seeing 404s in a report is to redirect them all somewhere. Redirecting a genuinely deleted page to your homepage is not a fix. It creates a page that says one thing and resolves to another, which is the same class of mismatch that produced the soft 404 in the first place.

Google also documents that it will continue attempting to crawl a 404 URL periodically. So a 404 is not a delete key. The URL stays in the system as something Google occasionally rechecks, which is fine and does not need managing.

Does a soft 404 hurt anything beyond that one page?

The direct effect is straightforward: Google's documentation states that a page with the Soft 404 status is not indexed. Beyond that, treat the wider harm as unproven rather than assuming the worst. What I would not do is panic about site-level consequences you cannot demonstrate.

What is documented, and is worth knowing separately, concerns server errors rather than soft 404s. Google states that 5xx and 429 server errors prompt its crawlers to temporarily slow down with crawling, and that the decrease in crawl rate is proportionate to the number of individual URLs returning a server error. That is a real, documented feedback loop and a different problem.

The practical reading is that a handful of soft 404s is a housekeeping task, and a wave of them is a symptom. If two hundred pages got flagged at once, something changed in your templates or your data, and finding that change matters more than fixing the pages one at a time.

How does this show up on a CMS-driven site?

Usually through templates that render nothing when the data is empty. A collection page with a filter applied that matches no items will happily render the surrounding layout and an empty space. From the outside that is a page that exists, returns 200, and says nothing.

Filtered and paginated views are the usual suspects, because they can generate combinations nobody ever intended to publish. A filter for a tag that only ever had one post, now unpublished, is a live URL with no content behind it. Sites with faceted browsing can produce a lot of these without anybody noticing.

The fix is at the template level rather than the page level. Decide what an empty state should say, write it once, and let every empty page inherit it. That single piece of work usually clears a whole category of flags, and it improves the experience for the handful of humans who land there too.

How do you check a specific page?

Request the URL and look at the response code, then look at the rendered text separately. If the code is 200 and the visible text is an apology, you have found it. If the code is 200 and the text is real content, the problem is that the content is not present when Google assesses the page.

Google's help documentation suggests running a live URL inspection test and viewing how Google renders the page, which is the step that settles most arguments. The rendered output is the evidence. What you see in your own browser after everything has loaded is not the same thing and regularly disagrees.

Keep a note of which of the two problems each page has, because they have different owners. A wrong status code is a configuration fix. A page that renders empty is a content or template fix. Mixing them in one list is how these tickets sit unresolved for months. I go through the wider status code audit in the piece on checking HTTP status codes.

What should you do about the ones that are correct?

Agree with them and move on. If Google has flagged a page that genuinely has nothing on it and never will, the right response is to stop serving it, not to pad it out. Adding two paragraphs of filler to satisfy a report is the worst available outcome, because now you have a real page that is worth nothing.

Decide whether the URL should exist at all. Many of these are artefacts of a system generating combinations rather than deliberate pages. If nobody would ever want to visit it, it should not be a URL, and the template that produces it should be constrained.

Some flagged pages are neither errors nor worth expanding, and simply have not been crawled properly yet. That is a different diagnosis with a different response, and I wrote about the neighbouring case in the piece on crawled but currently not indexed.

What should you do next?

Open the Page indexing report, filter to Soft 404, and sort the list by URL pattern rather than reading it top to bottom. Patterns tell you whether this is a template problem or a scattering of individual pages, and that distinction decides how much work you are in for.

Then pick one page from the largest pattern and inspect how it renders. One page usually explains the whole group, and fixing the template behind it clears the group at once rather than one ticket at a time.

While you are in there, look at what your actual not found page does for a human being, because it is doing more work than most people credit. I made that case in the piece on what a good 404 page does on a content-heavy site. If you are staring at a Search Console report full of statuses you cannot interpret, reach out and I will help you sort the real problems from the noise.