How to Fix Soft 404 Errors in Google Search Console

A soft 404 is Google's name for a page that returns a 200 HTTP status but appears to have no useful content. Your server says "everything is fine," but Google looks at the page and decides it's essentially empty or broken.

These are worse than real 404s in some ways, because they waste crawl budget on pages that add no value to your index, and they can drag down how Google perceives your site's overall quality.

Here's how to find them, understand what's causing each one, and fix it.

What Google Classifies as a Soft 404

Google doesn't publish the exact classifier, but the pattern is consistent: a page that matches one of these descriptions tends to get flagged:

• Near-zero content. A page with a template shell (header, footer, nav) but no meaningful body content.
• "No results" pages. A search results page saying "0 results for [query]" — the server returns 200, but the page is functionally empty.
• Deleted-item landing pages. A product or post page where the item has been removed but the URL still resolves to a placeholder.
• Redirect-destination problems. A URL that redirects to another URL that redirects to a dead end.

The "Soft 404" bucket appears in Search Console under Indexing → Pages → Why pages aren't indexed.

The 5 Common Patterns and Their Fixes

1. Empty Search Results Pages

What it looks like: Your site search (e.g., /search?q=xyz) returns a 200 with the message "No results found."

Why it happens: Search bots follow links and form parameters. If someone linked to a search URL or your internal linking generates search queries, Googlebot will crawl them.

Fix: Block these from crawling entirely in robots.txt:

Disallow: /search
Disallow: /?s=

If you're on WordPress, the default search parameter is ?s=. Add that to your disallow rules. For custom search implementations, block the path prefix.

If the search results pages sometimes have real content that you want indexed (unusual, but possible for curated results), add noindex to the empty-results template only.

2. Thin Tag and Category Pages

What it looks like: A tag archive page with one or two posts, or a category with no posts, returning 200.

Why it happens: CMS platforms auto-generate archive URLs for every tag and category, even if they're only used once or contain barely any content.

Fix options:

• noindex the tag/category template and let link equity flow to the individual posts: <meta name="robots" content="noindex, follow">
• Redirect the thin archive to a more substantial category if one exists
• Add content to the archive page — an intro paragraph, curated featured posts, or a meaningful description — so it has value beyond the list

The noindex approach is the fastest and most common. You keep the URL working for users but tell Google not to index it.

3. Deleted Product or Post Pages Returning 200

What it looks like: A product was discontinued or a post was unpublished, but the URL still loads a "this item is no longer available" page with a 200 status.

Why it happens: Developers sometimes build placeholder landing pages for deleted content to improve UX — but these placeholders confuse crawlers because they look like empty pages.

Fix: Choose based on whether the URL has any link equity or traffic history:

• No history: Return a real 404. Update your CMS or server to respond with HTTP/1.1 404 Not Found for deleted items. Users land on your custom 404 page, which can still have navigation.
• Has inbound links or traffic: 301 redirect to the closest equivalent — the parent category, a replacement product, or the closest topic match.

# Test the current status code
curl -I https://example.com/deleted-product-url

The response should show HTTP/2 404 or HTTP/2 301 after your fix, not HTTP/2 200.

4. Infinite Scroll Without Proper Pagination

What it looks like: A paginated URL like /blog/page/47 loads a container but no actual posts because the content loads via JavaScript after a scroll event.

Why it happens: Googlebot renders JavaScript, but infinite-scroll implementations that require scroll events to trigger content loading often don't fire those events during rendering. The page skeleton loads; the posts don't.

Fix:

Option A: Implement proper pagination with rel="next" / rel="prev" links and ensure each paginated URL renders its content server-side or via a crawlable JavaScript pattern.

Option B: Add noindex to paginated pages beyond page 1 and consolidate them with a canonical pointing to page 1. This is acceptable if the primary goal is indexing individual posts, not pagination pages.

Option C: Use a "Load More" button instead of infinite scroll. Load-More patterns are easier for Googlebot to handle and keep pagination crawlable.

5. Malformed Redirect Destinations

What it looks like: A URL redirects to a destination that returns a near-empty page — often because a redirect rule was set up to point to a generic path that happens to have no content.

Why it happens: Bulk redirect rules in .htaccess or a CDN sometimes catch URLs and send them to a catch-all destination that isn't meaningful.

Fix: Audit your redirect rules and trace every soft-404 URL through its full redirect chain:

curl -IL https://example.com/suspect-url

The -IL flag follows all redirects and shows each hop's status code. If the final destination is a thin page, either update the redirect target to a real page or return a 404 for URLs that genuinely have no good destination.

For a deeper look at redirect issues, see how to fix redirect loops and redirect chain SEO fix.

Reading the Coverage Report

In Search Console, clicking a soft 404 URL opens the URL Inspection overlay. The "Coverage" section shows the discovered URL, last crawl date, and a "TEST LIVE URL" button.

Use "Test Live URL" to see what Googlebot sees in real time — this is faster than waiting for a re-crawl after you make a fix. If your fix is in place and the live test comes back clean, hit "Request Indexing" to push the update.

Finding What's Linking to Soft 404 Pages

Before fixing a soft 404, check whether other pages on your site are linking to it. If they are, those internal links are wasting crawl budget on a dead end.

The internal link extractor shows you every internal link and anchor on a page, making it straightforward to find and update links that point to URLs you're about to redirect or noindex.

Where This Fits in Technical SEO

Soft 404s are an indexing control problem — they sit in the same category as accidental noindex tags and crawl budget waste. Once you've cleaned up your robots.txt and confirmed your important pages are crawlable (see indexed though blocked by robots.txt), soft 404s are typically the next place to look.

A technical SEO audit should flag soft 404s in the coverage report as a standard step. They're easy to miss because they don't break anything for users — your site looks fine — but they consistently degrade crawl efficiency and index quality over time.