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

What is a soft 404 and how does Google define it?

A soft 404 is a page that returns a success status code such as 200 while its content says the page is missing, empty or broken. Google spots the contradiction. It may skip indexing the page and report it as "Soft 404" in Search Console.

The idea is simple. Also, the visitor reads "Page not found" on screen, yet the server tells the browser that everything is fine. So the crawler has to guess from the content whether the page really exists.

Google describes this in its HTTP status code documentation. A page that returns a 2xx code but shows an error message can be flagged as a soft 404. Also, a 2xx code never guarantees that the page gets indexed.

In our SEO consulting work, we see this most often after a platform migration. In addition, the cause is rarely a single page. So it usually sits in the template logic.

How is a soft 404 different from a real 404?

A real 404 tells the crawler through the status code that the page does not exist. A soft 404 says the same thing only in the visible text. Moreover, the difference shows up in the signal the bot receives. With a correct code Google knows what to do; with a wrong one it has to guess.

So a real 404 is not a defect by itself. Returning 404 for a page you removed is the right behavior. Also, the trouble starts when the status code and the content contradict each other.

Why do soft 404 errors hurt SEO?

These pages do not get indexed, and the crawl budget you spend on them is wasted. Signals also get mixed. A URL in your sitemap and internal links says "I matter", while its content says "nothing here".

You can group the damage into three areas:

• Crawl budget: Google spends time on URLs with no value, so it reaches your real pages later.
• Index quality: Many empty pages weaken how the site looks as a whole, even without a separate penalty.
• User experience: A visitor arrives from search, lands on an empty page and leaves at once.

Reporting suffers as well. So it gets harder to tell why pages are missing from the index. In practice, when we investigate why Googlebot crawls a site less, piles of soft 404 URLs often sit near the top of the suspect list.

Where do soft 404 errors show up most often?

They usually appear on template-driven pages. A content management system keeps rendering the template even when no data exists, and the result is an empty page with a 200 code. So that is why testing the template is faster than checking single URLs.

In the field we meet these patterns most:

• Out-of-stock or removed product pages: The title stays, the product details vanish.
• Internal search and filter combinations with no results: Pages that say "0 products found".
• Empty category and tag archives with no posts inside.
• Removed pages that redirect to the homepage or a generic page.
• JavaScript apps that return 200 even when they show an error.
• Pagination pages at the end of a chain that hold no content.

For example, an online store can generate hundreds of filter combinations. In addition, most of them show zero products. In practice, if each one returns 200, the soft 404 count in Search Console climbs within days.

How do you find soft 404 errors in Search Console?

Open the "Pages" report under "Indexing" in Search Console. In the table that explains why pages are not indexed, find the "Soft 404" row. Click it to see example URLs. You can also export the list to your own spreadsheet.

To read the report well, follow these steps:

1. Select the "Not indexed" tab in the Pages report.
2. Open the "Soft 404" row in the reasons table.
3. Group the example URLs by template type: product, category, search, tag.
4. Inspect at least one URL from each group by hand.
5. Watch the trend chart. A sudden jump usually points to a release or a template change.

For general use, read our Search Console guide. For other indexing reasons, our post on finding unindexed pages adds more detail.

How do you confirm a soft 404 with the URL Inspection tool?

The URL Inspection tool shows how Google sees a single page. Paste a URL from the report and you get its index status and last crawl details. Moreover, the "Test live URL" option fetches the page as it is right now.

This check beats the delay of the report. Search Console data can lag by a few days. In practice, if you already fixed the problem, the live test tells you at once whether the page now answers correctly.

During the test, look at these points:

• Does the crawled HTML contain the real main content?
• Does the screenshot match what a user sees?
• Do blocked resources make the content look empty?

This way you also catch pages that have real content but look empty to Google. That split matters because it decides which fix you pick.

How do you check the HTTP status code on the server?

The most reliable way is to skip the browser view and read the response header directly. On the command line, curl shows the headers of a request. In the browser, the network tab of the developer tools gives the same data.

The key question is this: if the page tells users "missing", does the server say "missing" too? In practice, if not, the URL is a strong soft 404 candidate. For bulk checks, collect suspect URLs in a list and run a small script that prints each status code.

You can also inspect redirects quickly with our redirect checker. So it shows every hop a URL takes and the final code.

• Test a URL you removed. It should return 404 or 410.
• Test an out-of-stock product. Depending on your rules it should return 200 or 404.
• Test a search URL with no results. An empty page must not return 200.

How can server logs reveal soft 404 patterns?

Server logs show which URLs Googlebot requested and which status codes it received. So this data is more detailed and more current than Search Console. Filter for Googlebot requests, then pick URLs that return 200 with an unusually small response size.

A small response size is a strong hint of an empty or skeleton template. For example, if normal product pages return around 80 KB while a group of URLs always returns 12 KB, that group probably has no content. So this is an example reading method, and thresholds differ from site to site.

Read the logs from these angles:

• Clusters of URLs with the same response size.
• Paths that Googlebot visits often but that bring no organic traffic.
• Heavy request volume on parameter URLs.
• Crawl requests that still hit pages you removed.

In the end you can see which template produces soft 404 pages without opening a single URL.

What are the ways to fix a soft 404?

Google suggests three core fixes. Return 404 or 410 if the page is truly gone. Redirect with 301 or 308 if the page moved. Serve real content if the page should exist. Also, your choice depends on the business value of the page and on whether a real match exists.

We covered the 404 and 410 choice for removed content in our post on content pruning. In addition, we will not repeat it here. One point matters for soft 404 cases: the status code and the content must say the same thing.

How do you handle removed product pages?

First ask whether the removed product has a successor. In practice, if a new model, an equivalent product or a truly close alternative exists, a 301 redirect makes sense. In practice, if not, a 404 or 410 is more honest and cleaner.

You can use this simple flow:

• Product removed for good and a close alternative exists: redirect with 301 to that product or its category.
• Product removed for good and no alternative exists: return 404 or 410 and link to categories on the custom 404 page.
• Product temporarily out of stock: keep the page at 200 and show a stock alert and similar items.
• Seasonal product: keep the page and offer a "notify me" option out of season.

Turning an out-of-stock product into an empty shell with "0 items" is a classic trap. Moreover, our post on why product pages are not indexed covers the other side of it.

You also do not have to match thousands of removed products by hand. Also, our redirect mapping tool helps you pair old and new addresses by similarity.

How do you stop empty search and filter pages?

The way to stop them is to treat "no results" as "no page". For a filter combination with zero results, a 404 from the server is the clearest signal. In practice, if you must keep a search page, add noindex and leave it out of the sitemap.

Apply these rules:

• Return 404 when the result count is zero. Never show "No results" with a 200 code.
• Do not generate internal links to zero-result combinations. Let the filter widget list only options that have stock.
• Manage internal search pages with noindex, not with robots.txt. Google must be able to crawl a page to see its noindex tag.
• Add only URLs with real content to the sitemap.

For common robots.txt mistakes, see our post on robots.txt mistakes. In practice, when you build a sitemap, our XML sitemap generator saves time.

Can wrong redirects create soft 404 errors?

Yes, they can. Sending many removed pages to an unrelated target, especially the homepage, may lead Google to treat the redirect like a soft 404. The visitor finds a generic page instead of the content they wanted, and Google sees that it is not a true match.

Stick to one rule when you redirect: the target must really replace the source. In practice, if topic, search intent and page type match, redirect. In practice, if they do not, leaving a 404 is healthier.

• Use 301 when source and target cover the same topic.
• If the target is only the "nearest generic page", rethink the redirect.
• Do not build chains. Each old URL should reach the final address in one step.
• For permanent moves, choose 301 or 308 instead of a temporary 302.

Google treats a 301 as a strong signal and a 302 as a weaker one. It also follows up to 10 redirect hops. In addition, we cover chains in our post on the redirect chain problem.

How do you handle soft 404 errors on JavaScript sites?

In single-page apps the server often returns 200 for every URL and shows the error in the browser. So this setup invites soft 404 pages. The server does not know the "not found" decision, because the client makes it after the data loads.

The fix is to move that decision to the server, or at least to a point the server can see. With server-side or pre-rendering, return a real 404 status when the data is missing. In practice, if you cannot, build a fallback that adds noindex on error or redirects to a URL that returns a real 404.

• With server-side rendering, tie the "no data" state to a 404 code.
• With client-side rendering, add noindex on error or redirect to an address that answers 404.
• Make sure the error component never appears on valid pages.
• When you test, compare the screenshot and the rendered HTML from the live URL test.

Our post on technical SEO tips covers the wider picture.

How should you design a custom 404 page?

A custom 404 page guides the user and still returns the right status code. No matter how nice it looks, the server response must be 404. Otherwise even your best error page turns into a source of soft 404 URLs.

A good 404 page contains these parts:

• A clear message: "This page was not found."
• A search box and links to main categories.
• Popular content or products in a short list.
• A link back to the homepage, but no automatic redirect.
• The 404 status code when the page loads.

To check it, type a random address that does not exist and read the headers. In practice, if you do not see 404, fix your template settings. In short, design speaks to the user and the status code speaks to the bot. Both must be right.

Why does a page with real content get flagged?

A page with content can still be flagged. Typical reasons are very little text, error-like wording, resources that fail to load, or content that only appears on the client side. In practice, if the main content looks empty after Google renders the page, Google treats the page as empty.

In that case you need more content or a rendering fix. Check these points:

• Does the page hold only a few sentences and a "not found" template?
• Does a JavaScript error stop the main content from loading?
• Does the API that delivers the content block Googlebot?
• Do titles or texts contain words like "error", "not found" or "unavailable"?

Very thin pages can also look like soft 404 pages even without an error message. Merging or enriching them raises the chance of indexing. That said, filling every thin page is not the right answer. For some pages, removal is the smarter move.

How do sitemaps and internal links feed the problem?

A sitemap tells Google "these addresses matter". Moreover, every URL inside it carries a claim about crawl priority. In practice, if the page is empty, the claim falls apart and Google reports the conflict. So treat the sitemap as a list of pages you want indexed, not as a crawl list.

Internal links work the same way. Also, every link in menus, related product blocks or page footers that points to an empty page pulls Googlebot there. In addition, the stronger the source page, the more crawling goes to the empty target.

The order of cleanup matters:

• First remove the faulty URLs from the sitemap.
• Then crawl your internal links and update those that point to removed pages.
• Next fix the status code for the remaining URLs.
• Finally stop the template from producing new empty pages.

This order closes the problem at its source and at its symptom. In practice, if you fix only the status code and leave the links, Googlebot keeps walking the same paths. As a result the crawl budget is still wasted, and only the error type changes.

How would you fix a typical store step by step?

The scenario below is not an invented case. So it is a typical example flow, and the numbers are an example calculation. Assume a store has 12,000 product pages and Search Console flags 900 of them as soft 404.

First you export the 900 URLs and group them. Let us assume this example split: 500 removed legacy products, 250 temporarily out-of-stock products and 150 filter pages with no results.

Second, you change the template for each decision. Third, you verify the change in a test environment and check again with the live URL test after release. Fourth, you start validation and watch the trend for a few weeks.

The key point is that you never touch 900 URLs one by one. Four decision rules solve the whole group. This approach, based on our field experience, also keeps the same problem from returning with new products.

Which tools speed up detection and validation?

No single tool is enough. Moreover, each one sees a different place. Search Console shows Google's view, browser developer tools show the detail of one page, and logs show real bot behavior. Together they complete the picture.

• Search Console Pages report: shows which URLs are flagged and how the trend moves.
• URL Inspection: gives the Google-side view of one page and the live test result.
• Server logs: show which response Googlebot got for which URL.
• Browser network tab and curl: show the status code and redirect steps.
• A site crawler: lists status code and page size for the whole site.

In a crawler, read response size and headers together. URLs with a 200 code and a tiny body are good candidates. You can also filter titles that contain words like "not found".

Also check redirects separately with the redirect checker. So that way your fix does not create a new chain or loop.

What common mistakes should you avoid?

Teams that fight this problem repeat a few mistakes. Knowing them saves time. Also, most come from treating the symptom while missing the cause.

• Redirecting every removed page to the homepage in bulk.
• Designing a custom 404 page but leaving the status code at 200.
• Blocking the page in robots.txt and assuming the problem is gone.
• Fixing only the example URLs in the Search Console list without touching the template.
• Forgetting to update the sitemap and clean up internal links.
• Skipping the live test and going straight to validation.

All these mistakes share one trait: they look at a single layer. Status code, content, linking and sitemap work together. In practice, if you fix one and ignore the rest, Google keeps seeing the conflict.

Team communication matters too. In addition, many cases start when the content team deletes a page and the developers and SEO team never hear about it. A simple deletion checklist closes most of that gap.

Finally, focus on the number of affected templates, not on the error count. A list of 1,000 URLs is often the result of just three template problems.

How do you validate the fix in Search Console?

After the fix goes live, open the soft 404 row in Search Console and select "Validate fix". Moreover, google recrawls the listed URLs and checks whether the problem is gone. So this can take a few days, sometimes longer.

Finish these steps before you start validation:

1. Test the live response of the fixed URLs with URL Inspection.
2. Confirm that removed pages return 404 or 410 and moved pages return 301.
3. Update the sitemap and remove the URLs you took down.
4. Clean up internal links so they stop pointing at removed pages.
5. Then start validation and follow the result.

When validation passes, the issue closes. In practice, if it fails, Search Console lists the failing example URLs. Inspect them one by one and try again. For sitemap details, see our post on the sitemap lastmod tag.

What does a soft 404 checklist look like?

The list below is the short frame we use when we review a site for this issue. Working through it in order helps you find the problem and pick the right fix.

1. Export the soft 404 URLs from the Search Console Pages report.
2. Group the URLs by template type.
3. Confirm one URL per group with the live test.
4. Read the status code from the server header.
5. Return 404 or 410 if the page is truly gone.
6. Redirect with 301 to the related page if a real match exists.
7. If the page should stay, complete the content and fix the rendering problem.
8. Update the sitemap and internal links.
9. Start validation and watch the result.
10. Ship and test the permanent template-level fix.

When you apply this list, the number of faulty URLs drops and your crawl budget shifts to real pages. Your reports also become easier to read.

How can our team help with soft 404 fixes?

These problems often sit between SEO, development and content teams. Because nobody owns them, they can last for months. As Talha Aslan and team, we work in exactly that gap. We first diagnose the issue at template level, then build a workable fix plan with your developers.

Our way of working looks like this:

• We identify soft 404 sources with Search Console and log data.
• We write down the status code and content decision for every template.
• We prepare the redirect map and mark unmatched URLs as 404 or 410.
• Finally, we set up a post-release validation and monitoring schedule.

If you suspect this problem on your site, reach us through our SEO consulting page. In a first review we can work out together which templates cause the trouble.