A soft 404 is a 2xx response whose content looks empty or error-like to Google, so Search Console reports a soft 404 even though the server said success. Google's documentation states that for Google Search, an HTTP 2xx (success) status code doesn't guarantee indexing. Google's crawlers treat the 429 status code as a signal that the server is overloaded, and it's considered a server error. 5xx and 429 server errors prompt Google's crawlers to temporarily slow down with crawling. Check the raw status code first, then the rendered content. Empty catalogue and out-of-stock URLs usually need a content decision, not a status-code fix.
Why does an empty ecommerce page get called a soft 404?
Google's crawler treats HTTP status codes as the server's statement about a request. According to Google's documentation on how HTTP status codes affect Google's crawlers, a 2xx response means the content may be considered for indexing — but indexing is not guaranteed. If that content suggests an error or is an empty page, Search Console shows a soft 404 error.
That definition matters for ecommerce because empty pages are often produced deliberately. A category with no products in stock, a filter combination with no matches, or a product page whose variants are all unavailable can all return 200 with very little on the page. The server is not broken. The page simply has nothing to say.
A server error is different. Google's documentation states that 5xx and 429 server errors prompt Google's crawlers to temporarily slow down with crawling. For Google Search, already indexed URLs are preserved in the index, but eventually dropped. So a 5xx is a temporary signal about the server, while a soft 404 is a content-quality signal about the page.
How do I check the status code before judging the content?
Start with the raw response, not the rendered page. A browser view can hide the difference between a 200 with an empty template and a 500 rendered as a friendly error screen.
A practical diagnostic sequence:
- Request the URL with a tool that shows the status line, such as
curl -Ifor headers or a crawler that records status codes. Note whether the response is 2xx, 3xx, 4xx, 5xx or 429. - If it is 5xx or 429, stop. That is a server or rate-limit issue, not a soft 404. Check server logs, application errors and crawl rate.
- If it is 2xx, fetch the full body and look at what a crawler would see after JavaScript runs. Many ecommerce templates render product grids client-side, so the initial HTML may be empty even when the page is fine for users.
- Compare the rendered text against the page's purpose. A category page with a heading, an explanation and a route to related products is not empty. A category page with a heading and nothing else is.
- Check Search Console's Page Indexing report for the URL. A soft 404 label there confirms Google saw 2xx with error-like or empty content.
This sequence separates the two questions that get confused: did the server succeed, and did the page deliver anything worth indexing?
What should an empty category or out-of-stock page return?
There is no universal status code that fits every empty ecommerce URL. The right response depends on whether the emptiness is permanent, temporary, or a duplicate of another URL.
| Situation | Typical server response | Content decision |
|---|---|---|
| Category temporarily has no products | 200 | Keep the page useful: explain the range, link to alternatives, show restock timing if known |
| Category permanently discontinued | 404 or 410 | Remove or redirect to the closest relevant category |
| Filter combination with no matches | 200 or 404 | Decide whether the filter URL should be indexable at all; often it should not |
| Product permanently removed | 404 or 410 | Redirect to a successor product or parent category if one exists |
| Product temporarily out of stock | 200 | Keep the product page live with availability information |
| Server failure or overload | 5xx or 429 | Fix the server; do not mask it with a 200 error page |
Google's documentation notes that in the case of Google Search, the indexing pipeline removes the URL from the index if it was previously indexed, and newly encountered 404 pages aren't processed. That is a clean signal for permanently gone content. It is a poor signal for a page you intend to bring back.
Example (hypothetical): a retailer sells seasonal garden furniture. In January, the category URL returns 200 but the grid is empty because inventory is zero. If the page also explains that the range returns in spring and links to indoor furniture, it is a thin but legitimate page. If it shows only a heading and a blank grid, it is a candidate for a soft 404 label. The status code is identical in both cases; the content is not.
How do I decide between fixing content and changing the status code?
Use the intent of the URL as the deciding factor.
- If the URL should exist for shoppers and search, fix the content. Add a short explanation of the range, links to related in-stock categories, and a clear statement about availability. This is the same principle behind ecommerce category pages that help shoppers choose: a category should confirm the shopper is in the right place and make the next choice easier.
- If the URL should not exist, remove it properly. Return 404 or 410, or redirect to a genuinely equivalent page. Avoid redirecting every empty filter to the homepage; that creates a soft 404 of a different kind.
- If the URL is a duplicate or near-duplicate of another indexable page, consolidate rather than leaving both live.
- If the URL is temporarily empty but will return, keep it live and useful. This is close to the logic in seasonal ecommerce SEO: preserve URLs that remain useful as offers change.
A reusable worksheet for each flagged URL:
- URL and template type
- Raw status code
- Rendered word count and main content elements
- Whether the emptiness is permanent, temporary or duplicate
- Intended audience: shoppers, search, or neither
- Chosen action: improve content, 404/410, redirect, or noindex
- Owner and review date
What does the evidence not tell us?
Google's documentation explains how status codes are handled and when a soft 404 label appears. It does not publish a threshold for how much content is enough, and it does not say that every empty category must be removed. The soft 404 label is a signal about how Google interpreted a page, not a penalty and not a ranking guarantee either way.
It also does not tell you which of your URLs are affected. That requires your own crawl data and Search Console reports. Treat any specific word count or product-count threshold as a hypothesis to test, not a rule.
How should I prioritise fixes across a large catalogue?
Group flagged URLs by template rather than fixing them one by one. If a filter template produces thousands of empty pages, the fix belongs in the template logic, not in individual URLs. If a discontinued product template returns 200 with an error message, the fix belongs in the product controller.
Prioritise URLs that have impressions or internal links, because those are the ones where a wrong signal has the most effect. URLs that were never indexed and receive no traffic are lower priority, though they still consume crawl attention.
Finally, recheck after changes. A soft 404 label may clear once the page has real content or returns a correct status code, but recrawling takes time. Monitor the Page Indexing report rather than assuming an immediate change.
Follow-up questions
Does an out-of-stock product page always need a 404?
No. If the product will return, keep the page live with clear availability information. A 404 removes it from the index. Use 404 or 410 when the product is permanently gone and no equivalent replacement exists. Google's documentation notes that for 404 responses, the indexing pipeline removes the URL from the index if it was previously indexed, and newly encountered 404 pages aren't processed.
Can a 5xx error cause a soft 404 label?
Generally no. Google treats 5xx and 429 as server errors and temporarily slows crawling, preserving already indexed URLs in the index for Google Search. A soft 404 label comes from a 2xx response whose content looks empty or error-like. If you see both, investigate the server separately from the content.