How I find and fix soft 404 errors in Search Console

What makes Google call a page a soft 404?

It's a mismatch between what the server says and what the page shows. The server sends 200, which means everything's fine, but the page itself is empty or reads like an error. Google's documentation on HTTP status codes puts it plainly: when a 2xx response carries an empty page or an error message, Search Console shows a soft 404. Sorting those pages out is a big part of the Search Console indexing fixes for WordPress I'm hired for, and it starts with knowing which kind of empty you're looking at.

Search Console's help for the Page indexing report gives two halves of the fix. Return a real 404 for pages that don't exist, and give pages that should exist enough content that Google can see they aren't errors. A third group is about where a redirect or a host sends the request.

What's the difference between a 404 and a soft 404?

A 404 is the server telling the truth: nothing lives at this address. A soft 404 is the server saying 200 OK while the page reads like an error, an empty list or a not found message, so Google has to judge it from the content. Neither one gets indexed, but only the soft one keeps getting crawled.

That's the practical difference. Google's crawl budget guide calls a 404 a strong signal not to crawl that URL again, and a 410 gets the same treatment, since its status code documentation says every 4xx except 429 is handled the same way. A soft 404 carries no such signal, so Google keeps coming back to check it.

Do soft 404s hurt SEO?

Not as a penalty. Google's documentation doesn't describe a sitewide penalty for soft 404s. The cost is narrower: each flagged URL stays out of the index, so if it's a page people search for, like a product that renders empty for Googlebot, its search traffic is gone until the page is fixed.

The second cost is crawling, and it depends on the site's size. Google's crawl budget guide says soft 404 pages "will continue to be crawled, and waste your budget,". The same guide is written mainly for sites with 10,000 or more pages that change daily, or a million or more, and says a site without lots of rapidly changing pages doesn't need it. So on a typical WordPress site the crawling cost is small. The pattern behind a long list isn't, because one bad template or host setting keeps producing new ones.

Which WordPress pages turn into soft 404s?

Mostly archives. WordPress core sets the status code in handle_404(), and its own comment spells out the rule. A request that matches no posts gets a 404, unless it matches an existing but empty category, tag or author, or it's a search or the homepage. Those get a 200.

So a tag you created and never used, or used once on a post you later deleted, still has a live URL that answers 200 and lists nothing. The same goes for custom taxonomies, and WooCommerce product categories are custom taxonomy terms, so an empty product category behaves the same way. An author archive for a user who hasn't published anything can do it too.

Search results are a partial exception. They also return 200 when nothing's found, but WordPress adds a noindex robots tag to search pages by default, so they usually show up as excluded by noindex rather than as soft 404s. If search pages appear on your soft 404 list, something's removed that tag, and I check the theme and the SEO plugin first.

Archives with one short excerpt sit on the edge: close enough to empty that Google may call them soft 404s, and thin even when it doesn't. Deciding which to keep, merge or drop is a pruning job across the whole template, not a page by page repair.

How can a redirect cause one?

By landing somewhere that doesn't answer the old page's question. In its guidance on site moves, Google tells you not to send lots of old URLs to a single unrelated page like the new homepage, because that might be treated as a soft 404. Several old pages merged into one new page can all point at it, though.

So the question I ask of each redirect is simple. Would someone who clicked the old link be satisfied with where they end up? A discontinued product that redirects to its own category passes, as long as that category still has products in it. A blog post that redirects to the homepage doesn't. On one WooCommerce store, the old sapphire category went to the new sapphire category, not the homepage, and that's the standard I hold every redirect map to.

Watch for chains of causes, too. A deleted product sent to a product category that's since gone empty fails twice, and fixing only the redirect won't clear it. On a platform move the same discipline applies from day one, which is why the redirect map comes before the import.

Why do some static hosts create them for every missing URL?

Because they're guessing the site is a single page app. Cloudflare Pages is the clearest documented case. Its docs say that when a deployment has no top-level 404.html, Pages assumes it's a single page application and matches every incoming path to the root. For a normal site it means a typo, a stale backlink or a URL that never existed gets the homepage instead of a not found page.

A headless WordPress front end or a static export often lands on this kind of host, so the CMS is fine and the soft 404s come from the layer in front of it.

The check that proves it takes seconds. I request an address that can't exist, something like /this-page-does-not-exist-123/, and read the status code and the size of the response. If it answers 200 and the HTML matches the homepage byte for byte, the host is doing it. The fix is on the host side: add a 404.html at the root of the deploy, and Pages serves it whenever a file isn't found.

For an app that really does route in the browser, Google's JavaScript SEO guide gives two options: redirect with JavaScript to a URL where the server returns a 404, or add a noindex robots tag to the error view.

What should Search Console show once the causes are fixed?

The soft 404 count should fall, and the URLs should reappear somewhere more honest. Deleted archives and retired redirects move into Not found (404), which is fine when the page is meant to be gone. Noindexed archives show up as excluded by noindex, and fixed pages drop off the list.

What I don't want to see is the same URLs coming back under a new label that's just as wrong, like a padded archive sitting in Crawled, currently not indexed. Then the problem's moved from status codes to page quality, and I work through it the way I'd handle any page that's crawled but left out of the index.