Soft 404 Errors: How to Find and Fix Them

What exactly is a soft 404?

Picture a shop door that's open, lights on, and nothing inside but a sign saying "Sorry, we don't have what you're looking for." The door's open, so the shop technically exists. But nobody would call it a shop. A soft 404 is the web version of that.

More precisely, it's a URL that tells browsers and crawlers everything's fine, using a 2xx success status code (usually 200), while the content on the page reads like an error or is so empty it might as well be. Google looks at the page, ignores the cheerful status code and decides it's effectively a "not found."

How does Google define it?

Google's documentation on HTTP status codes is clear. If a page returns a success code but its content looks like an error, such as an empty page or an error message, Google treats it as a soft 404. Search Console then reports it with the label "Soft 404" in the page indexing report. The documentation was last updated on 4 February 2026.

That definition is deliberately broad. It covers obvious cases, like a "page not found" message served with a 200 code, and subtler ones, like a thin page with almost no content.

Why the code and the content can disagree

Usually because of how the site was built. A template that always responds 200 and just swaps in an error message. A search page that doesn't change the status when there are no results. A plugin that redirects missing pages to a generic landing page. The developer rarely meant to cause an SEO issue. It's a side effect.

Why do hard 404s get a better reputation?

Because they're honest. A proper 404 says "this isn't here," and Google understands. The documentation explains that URLs returning 4xx codes aren't used for content, that previously indexed URLs that now return them are gradually dropped, and that newly found 404s are crawled less and less often. A 410 is handled the same way as a 404.

So a true 404 isn't a disaster. It's a clean signal. A soft 404 is a muddled one, which is why Google flags it.

How do soft 404s differ from real 404s and redirects?

The three get tangled up in conversation, and the mix-ups lead to bad fixes. A clear mental map helps.

Here's the difference, side by side.

What is the practical difference?

Google's documentation describes 301 and 308 as strong signals that the redirect target should be processed, and 302, 303 and 307 as weak signals. Content on the redirecting URL is ignored, and Google follows up to ten redirect hops by default.

Where soft 404s and redirects collide

If you redirect many unrelated old URLs to one generic page, such as the homepage, Google may decide the destination doesn't really replace the old content, and treat the redirect as a soft 404. Mapping old URLs to genuinely relevant new ones is the job of 301 redirects and redirect mapping.

Does a soft 404 hurt the rest of the site?

Not directly. There's no site-wide penalty for having some. But there are indirect costs. Each soft 404 consumes crawl time, and Google's crawl budget guidance specifically recommends fixing them because they keep using up crawl resources. On a small site that cost is trivial. On a site with tens of thousands of URLs it adds up.

There's a user cost as well. A visitor who lands on a blank or confusing page leaves. Whether or not Google cares, you've lost a potential customer.

The honest summary

A few soft 404s on a small site are housekeeping. Hundreds on a large site are a signal that something in the template or the process needs attention.

What are the most common causes?

Soft 404s don't appear from nowhere. They come from a short list of patterns. Learn the list and you'll spot most of them in minutes.

Treat each as a hypothesis to check against your own URLs.

Which template and platform causes come up most?

Empty category or tag pages: a shop category with no products, a blog tag with no posts. The template renders a page, the status is 200, and the content is a heading and a "no items" message. Zero-result internal search pages do the same. Calendar or archive pages for dates with nothing on them. Product pages for items that are out of stock and have nothing else on the page.

Another frequent cause is a "page not found" template that was built as a normal page and never configured to send a 404 status. The page looks like an error and says so, but the server cheerfully reports success.

How to recognise them quickly

Open a few flagged URLs. If you see "no results," "not found," "coming soon" or a nearly blank layout, you've probably found the pattern.

Which redirect and migration causes cause trouble?

After a redesign, old URLs are sometimes all redirected to the homepage or a generic section page. It's quick, and it feels safe. It also frequently produces soft 404s, because the destination doesn't match what the old URL offered. Chains and loops can add to the mess.

Similarly, plugins that "catch" missing pages and send visitors somewhere generic can hide the fact that the page is gone. Users aren't told, Google isn't told and the site fills up with ghost URLs. A proper website migration SEO checklist helps you avoid it.

The homepage-redirect habit

If you catch yourself writing a rule that sends "everything else" to the homepage, stop. Write a rule that sends each important old URL to its true replacement, and let the rest return a 404.

Which content causes lead to soft 404s?

Thin pages. A page with only a heading, a sentence and a form can look empty to Google. So can pages that exist only to hold a link, placeholder pages launched before the content is ready, and auto-generated pages with no unique information.

Location pages that swap a place name into identical text sometimes fall into this category, as do tag archives with a list of titles and nothing else. If the page offers nothing a visitor couldn't get elsewhere, Google may treat it as not worth indexing, and in some cases as a soft 404.

JavaScript and rendering failures

Pages that depend on JavaScript to load their content can appear empty if the scripts fail or are blocked. Google sees an almost blank page and may label it a soft 404. Testing the rendered HTML in the URL inspection tool will show whether that's happening.

How do you find soft 404s?

You don't have to hunt blindly. Google tells you where to look, and a couple of extra checks fill in the gaps.

Start with the report, then widen out.

Where do you look in Search Console?

Open the page indexing report under Indexing, then Pages. Scroll to the list of reasons pages aren't indexed and look for "Soft 404." Click through to see a sample of affected URLs and a trend chart. Note how many there are, when they appeared and whether the number is rising.

Then inspect individual URLs with the URL inspection tool. You'll see how Google last crawled the page, what status it received and whether the page is indexed. Run a live test to compare Google's current view with your own.

What the sample can't tell you

The report shows a sample, not necessarily every URL. For a complete picture on a larger site, export the data and combine it with a crawl.

How do you find the ones Google hasn't reported yet?

Crawl your own site with a tool like Screaming Frog or Sitebulb. Filter for pages that return 200 but have very little content, a title or heading containing words like "not found," "no results," "unavailable" or "error," or an unusually small page size. Compare the results with your sitemap and your analytics.

Also look at your server logs, if you can, for requests that return 200 to URLs that shouldn't exist, such as random strings added to your domain. A healthy site returns a proper 404 for nonsense URLs. A site that returns 200 for everything is a soft 404 factory.

A one-minute test

Type your domain followed by a random jumble of characters. If the page that loads has a 200 status, your 404 handling is broken. Check the status in your browser's developer tools or with a header checker.

How do you fix a soft 404 properly?

The right fix depends on a single question: should this page exist? Everything else follows from the answer.

Go through each group of URLs and decide.

What if the page should exist?

Then make it real. Add genuine, useful content: a clear explanation, specific details, images, relevant links and a reason for a visitor to stay. If it's an empty category, either populate it, merge it into a parent category or remove it. If it's a thin service page, build it out properly or combine it with a stronger one.

For pages that rely on JavaScript, make sure the content renders in the HTML Google sees. Server-side rendering or pre-rendering can help. After changes, use the URL inspection tool to test the live page and request validation in Search Console.

Don't just pad the page

Adding filler to dodge the label doesn't help. The aim is a page that serves a real need. If you can't think of one, the page probably shouldn't exist.

What if the page shouldn't exist?

Return the right status code. A 404 or 410 tells Google the page is gone, and Google handles both the same way. For pages removed permanently with no replacement, many teams use 410 for clarity. Make sure a helpful custom error page is shown to visitors, with a search box, links to main sections and contact details.

Then remove internal links to the dead URL and take it out of the sitemap. Leaving links to a 404 page wastes crawl time and frustrates visitors.

What a good error page includes

A friendly message, a short list of popular pages, a search field and a way to report the problem. It's the one page where visitors are most likely to be lost, so make it helpful.

What if there's a good replacement?

Use a 301 redirect to the closest equivalent page. A product that's been discontinued might point to its category or a successor. An old article might point to an updated version on the same topic. The redirect should send users where they'd reasonably expect to go.

Avoid sending unrelated URLs to the same destination. If a good match doesn't exist, a 404 is more honest and usually better. Keep redirects short: point old URLs directly to their final targets rather than through chains.

A quick decision table

What about shops, search pages and other special cases?

Some site types generate soft 404s by design. They need specific handling.

The principle stays the same. The details differ.

How should an online shop handle empty and out-of-stock pages?

For temporarily out-of-stock products, keep the page live with useful information: availability notice, alternatives, an option to be notified, maybe related items. Treat it as a real page. For discontinued products with no successor, a 410 or 404 is reasonable; with a close successor, a redirect to it works well.

Empty category pages should be avoided where possible. If a category has no products, consider hiding the link, merging it, or showing relevant alternatives with real content. Keeping categories useful is a core part of ecommerce category page SEO.

Filters that produce nothing

Filter combinations with zero results should return a 404 or be prevented from creating crawlable URLs at all. Letting them return 200 with "no products found" creates a stream of soft 404s.

What about internal search results?

Zero-result search pages are a classic source. A visitor searches for something you don't sell, the site displays "no results" and returns 200. Generally, internal search result pages shouldn't be indexed at all, so you can block crawling of search URLs and use sensible controls for them.

If you want search results to be useful to visitors, keep them useful. Suggest alternatives, show popular items and make it easy to contact you. Just keep them out of the crawl path.

A note on robots.txt

If you block crawling of search URLs with robots.txt, remember that blocking doesn't remove already-known URLs from the index. Before relying on that, weigh the limits of pages blocked by robots.txt.

What about temporary and seasonal pages?

Events, offers and seasonal landing pages often expire. When they do, don't leave an empty shell behind. Either keep the page updated with a clear notice and links to current alternatives, redirect it to the next relevant page, or remove it with a proper status code.

Planning the end of a page's life when you launch it saves clean-up work later. A simple note in your content calendar, "review on this date," is enough.

Avoid the placeholder trap

"Coming soon" pages with no content invite soft 404 labels. If a page isn't ready, don't publish it, or noindex it until it is.

How do you confirm the fix worked?

You've changed things. Now you need to prove they stuck. This is where many clean-ups quietly fail.

A short, repeatable check keeps you honest.

What do you verify first?

Check the status code of each fixed URL using a header checker or your browser's developer tools. A page you've removed should return 404 or 410. A redirect should return 301 with the correct target. A page you've rebuilt should return 200 and show real content when viewed in the URL inspection tool's live test.

Then check the internal links and sitemap. Dead URLs shouldn't appear in either. A crawl of the site afterward should show no 200 pages with "not found" content and no long redirect chains.

Use the validation feature

In Search Console, once you've fixed the issue, use "Validate fix" on the soft 404 report. Google will re-check the affected URLs and tell you how it goes. It takes time, so don't expect an instant answer.

How long until Search Console updates?

It depends. Google needs to recrawl the URLs and reprocess them. Sites with healthy crawling may see changes within days or weeks. Slower sites take longer. Track the soft 404 count weekly and expect a gradual decline rather than a sudden drop.

If numbers stop falling or new ones appear, look for a template or plugin that's still generating them. Recurring soft 404s usually mean the underlying cause hasn't been fixed. Related statuses you might see during the clean-up include crawled, currently not indexed.

What not to expect

You may not see a traffic jump. Cleaning up soft 404s mostly protects crawl efficiency and prevents slow leaks. The gains are usually quiet.

How do you stop soft 404s coming back?

Fixing is good. Prevention is better. A few habits remove most future problems.

None of them are heavy.

Which technical safeguards help?

Make sure your platform returns a true 404 status for missing pages, and test it after every major update. Add a check to your launch process: request a nonsense URL and confirm the status. Require developers to set the correct status for empty templates, such as empty categories or search results. Keep redirect rules tidy and review them when you remove content.

If you use plugins that manage redirects or error pages, test them. Plugin updates can change behaviour without warning, and a small configuration change can switch a clean 404 into a soft one.

Add it to the release checklist

A single line, "Check 404 handling and status codes on key templates," catches a surprising number of regressions.

Which content habits help?

Don't publish thin placeholders. Review empty sections before launch. When you retire content, decide in advance whether it gets a redirect, a 404 or a refresh, and write it down. Keep an eye on the page indexing report monthly, so new patterns are caught early.

Those habits belong to whoever owns the site, which brings us back to ownership. If nobody checks, the report fills quietly. An expert pair of eyes on your indexing reports and templates, such as an SEO audit, covers soft 404s alongside the rest of the technical picture.

Where to go next

Once soft 404s are under control, the next indexing topics worth understanding are canonical tags, crawl efficiency and the difference between crawling and indexing. They're all connected, and each makes the others easier to manage.

What does a worked example look like from start to finish?

Let's walk through one, because the steps are easier to follow with a concrete case. It's hypothetical, and the numbers are deliberately round.

The scenario is a small online shop with a few hundred real products.

How did the problem show up?

The owner opens Search Console and sees a "Soft 404" entry in the page indexing report, with around two hundred URLs. A sample shows addresses like category pages for sizes nobody stocks and tag pages for old campaigns. The owner assumes it's harmless, then notices that two product pages the team cares about are missing from search.

A quick crawl confirms the pattern. The site has about three hundred real product and category pages, plus a few hundred auto-generated URLs that return 200 with a heading and the line "No products found." Nobody built them on purpose. A plugin creates them whenever someone clicks a size filter.

The key observation

Every flagged URL shared one template and one message. When a problem has a single shape, it usually has a single cause.

What did the fix involve?

First, the developer changed the filter plugin's settings so that combinations with no products no longer generate crawlable links, and so that any request for such a combination returns a 404. Second, the team removed three genuinely thin tag pages and let them return 410. Third, two discontinued product pages that had backlinks were redirected to their closest alternatives. Fourth, the sitemap was regenerated so that it listed only real, live pages.

After that, the team checked a nonsense URL, confirmed it returned a 404, and used "Validate fix" in Search Console. Over the next several weeks the soft 404 count fell to near zero, and the two missing product pages were crawled and indexed.

What the team avoided

They didn't redirect everything to the homepage. They didn't pad empty pages with filler. And they didn't ignore the report, assuming it was cosmetic.

How do soft 404s connect to crawl efficiency?

For most small sites, soft 404s are tidy-up work. For large sites, they can be part of a bigger crawl problem. It helps to see the connection.

The link is about attention. Google only has so much time to spend on your site.

Why does Google care about wasted requests?

Every request to a useless URL is a request not spent on a useful one. Google's crawl budget guidance says soft 404s keep consuming crawl budget, and recommends fixing them. On very large sites, thousands of ghost URLs can slow the discovery of new and updated pages.

If you also have lots of URLs in the "Discovered, currently not indexed" state, the two problems may be related. A bloated URL set can crowd out the good pages, as the pattern of discovered, currently not indexed URLs shows.

The practical takeaway

Cleaning soft 404s is one of the cheaper ways to improve crawl efficiency, because it involves removing junk rather than adding anything.

Do soft 404s affect the pages that link to them?

Indirectly. Internal links pointing to dead or empty pages send both users and crawlers to dead ends. They dilute the value of your internal linking and make the site feel neglected. Fixing the destination helps, but so does removing or updating the links.

A crawl report of internal links pointing to 404 or soft 404 pages gives you a ready-made to-do list. Tidy those, and the site becomes easier to use as well as easier to crawl.

What should you say to your developer?

Many soft 404 fixes live in code, so the conversation with the person who owns that code matters. A clear brief saves days of back and forth.

You don't have to be technical. You just have to be specific.

What does a good brief include?

The affected URL patterns, with three or four examples. The current behaviour: status code and what the page shows. The desired behaviour: for example, "return a 404 status with the standard error page when a filter combination has no products." Why it matters, in one sentence. And how you'll check it: "request a nonsense URL and confirm a 404."

Add any constraints, such as pages that must stay live for customers or redirects that are needed for old campaigns. Attach a screenshot of the Search Console report and the crawl export so that nobody has to guess.

A sample ticket in plain English

"When a visitor requests a product filter combination that has no products, the site currently shows a page saying 'No products found' with a 200 status. Google treats these as soft 404s. Please return a 404 status for these requests, show the standard error page and stop linking to empty combinations from the filter menu. Test by requesting /category/?size=xxl-tall and checking the response header."

How do you keep the work moving?

Agree an owner and a date, and ask for a quick confirmation once the change is live. Test it yourself, not just via the developer's word. Then check Search Console again in a few weeks. Treat it as a small project with a defined finish, and log what changed.

If your developer isn't familiar with SEO, offer short, specific guidance rather than a long document. Most developers are glad to fix a clearly described problem. If the work is more complex than expected, a technical SEO consultant can write the brief and check the result.

Close the loop

Update the release checklist so that the same issue doesn't return. One line is enough, and it turns a one-off fix into a lasting improvement.

What if the developer pushes back?

Sometimes you'll hear "that's just how the platform works." It's worth asking what the platform can do, because most systems can return a proper 404 when told to, even if the default is lazy. Ask for the cheapest option that achieves the outcome, which may be a plugin setting, a template condition or a server rule, not a rebuild.

If there's a genuine technical limit, agree a workaround together: perhaps noindexing the empty pages, removing links to them and blocking crawling of the pattern, then revisiting the root cause at the next release. A documented compromise beats an argument.

Keep it factual

Bring evidence: the report, the crawl and a clear example. Developers tend to respond well to data and badly to vague alarm. Describe the user impact too, such as visitors landing on empty pages, because that often carries more weight than the SEO argument.

How do you check the fix without waiting weeks?

You don't need to wait for Google to confirm the basics. Test the status codes yourself the moment the change goes live. Request a missing URL and read the response header. Visit an empty category and check what it returns. Run a quick crawl of the affected section and confirm the pattern has gone.

Then add a reminder to review the soft 404 report in a month. Google's reporting lags behind reality, so your own checks give you the answer first, and Search Console confirms it later.