Search Console will call a URL a soft 404 when the server says success and the page says failure. Google's documentation on HTTP status codes is direct about this: a 2xx response does not guarantee indexing, and if the content looks like an error, an empty page, or an error message, the Page indexing report shows a soft 404. The crawler spent a request on a URL that behaves like a missing page. That request did not retrieve a document worth indexing.

Publishers hit this in a few predictable places: a tag archive with no stories, an internal search page that says "no results", a retired offer that still returns the site chrome, and a JavaScript app that renders "not found" inside a 200 shell. The report groups them together. The fixes are not the same.

A real 404 and a soft 404 are different signals

A URL that returns 404 or 410 tells Google the document is gone. Google's status-code guide says crawlers do not use the content of 4xx responses, except that 429 is treated as a server overload. For the other 4xx codes, including 404 and 410, previously indexed URLs are removed from Google Search over time, and newly seen 404 URLs are not processed as pages. The crawl budget guide adds a practical note: a 404 is a strong signal not to crawl that URL again, while a URL that is only blocked in robots.txt stays in the queue much longer.

A soft 404 does the opposite. The status code says the page exists. Google fetches it, renders it, and then classifies the body as empty or as an error. The URL remains something Google may try again. On a large site, a pile of those URLs shows up both as soft 404s and as crawl waste. The crawl budget guide explains why that matters only after your site is large or changing quickly. On a small site the damage is quieter: the URLs clutter the Page indexing report and, if they were ever indexed, they can sit in Search looking like thin pages.

Do not "fix" a soft 404 by adding noindex and leaving the 200 in place if the URL should not exist. noindex still requires a crawl so Google can see the tag. A real status code is the cleaner signal for a page that is gone.

How to confirm one URL before you edit the template

Open the URL in a browser and read the status code, not just the design. Browser devtools, or a simple curl -I against the production host, will show whether you received 200, 404, or a redirect. Then read the body. A soft 404 often has a normal header, a normal footer, and a main column that says the content is unavailable, or a main column that is blank.

In Search Console, inspect the URL and run the live test. Compare the screenshot with the HTML. If the screenshot is a friendly "we couldn't find that" message and the status is 200, you have confirmed the report. If the screenshot is blank while the HTML contains the article, you have a rendering problem, which is a different fix: the content has to be visible without an extra click, a login, or a failed script. The URL Inspection guide covers the live test fields you will use.

Check the Page indexing report filtered to the sitemap that lists URLs you care about. A soft 404 on a URL that is also in your sitemap means you are advertising a page you do not have. Remove it from the sitemap when you fix the status code. Sitemap rules are covered in the sitemap guide.

Six patterns and the fix for each

The URL should not exist. A deleted article, a merged story, or a product you will not sell again. Return 404 if you simply have nothing to put there. Return 410 if you want the HTTP semantics of "gone". Google's indexing pipeline treats those 4xx codes the same way for Search, so choose the code that is honest for other clients, not because you expect a special ranking effect. Remove the URL from the sitemap. Remove internal links to it, or point those links at a genuine replacement. A redirect is better than a 404 when a real successor page exists. Do not redirect every deleted URL to the home page. That turns the home page into a dumping ground and looks like a soft error to anyone who followed the old link.

The URL should exist and the template is empty. A section page, an author page, or a topic page that renders the chrome and the words "no posts yet". If you intend to keep the URL for later, it is not a missing page and it should not pretend to be one. Either wait to publish the URL until it has a real introduction and real links, or leave it unpublished. An empty archive that returns 200 is a soft 404 candidate. A short page that explains the topic and links to related articles is a real page. Do not paste the same paragraph onto every empty tag to clear the report. Google classified the page because it looked empty or like an error. A repeated stub does not become a different document.

Internal search and filtered listings. "No results for ..." with a 200 is the textbook soft 404. Site search URLs do not belong in the index. Return a 404 when the query matches nothing, or keep the 200 and noindex the search template if you have a reason to show the page to users. Do not list those URLs in the sitemap. Infinite filter combinations have the same shape: a 200, almost no unique text, and a new URL for every control. Block crawling of the combinations you do not want, as the crawl budget guide suggests for unimportant variants, or canonical them when they are true duplicates. Canonicals are the wrong fix for a page that has no document. Status and indexing rules are the right fix.

Client-side "not found" screens. A single-page app answers every path with 200 and index.html, then the router paints a not-found view. Google fetches the 200, renders the scripts, and sees the error text. That is a soft 404 even though your router feels correct to a user. The server, or the edge, has to return 404 for unknown paths. The HTML body can still be your branded not-found page. The status code is what changes the classification. Paths that are real articles must return 200 with the article in the response, not only after an extra API call that fails for the crawler.

Thin landing pages and expired campaigns. A campaign URL that now says "this offer has ended" and links to the home page is an error message on a 200. If the campaign is over, 404 or 410, or a redirect to the specific page that replaced the offer. If the page still explains something useful, say what ended, what replaced it, and who it is for, and keep the 200. The test is whether a stranger learns something from the main column. A headline and a button back home will not pass that test.

Moved content with a broken redirect. A 301 that lands on a 200 "not found" page is worse than a clean 404, because Google follows the redirect (up to a documented limit of 10 hops for ordinary crawling) and then classifies the target. Fix the target or remove the redirect. Redirect chains that end in a soft 404 show up as redirect errors or as soft 404s depending on where the chain breaks. Point the old URL at a live document in one hop.

What not to change

Do not mass-noindex every URL in the soft 404 report. Some of those URLs are real articles caught by a rendering bug. noindex would remove them on purpose.

Do not block the URLs in robots.txt and call the job done. Google cannot see a noindex or a proper status body if it cannot fetch the URL, and a blocked URL can remain indexed from outside links. The robots.txt guide explains that distinction.

Do not add a long copyright footer or a popular-posts widget and expect the classification to change. The main content is what looks empty. Chrome around an empty column is still an empty column.

Do not request indexing on a soft 404 to "clear" it. A fresh crawl of the same 200 error page confirms the problem.

A repair order that survives the next theme update

Export the soft 404 sample from the Page indexing report. Group the paths. You are looking for a prefix: /tag/, /search, /author/, /print/, or a pattern of numeric IDs that no longer resolve.

For each group, decide "gone" or "real page". Gone means 404 or 410, drop from the sitemap, fix internal links. Real page means unique main content and a 200. Unknown application routes mean 404 at the server.

Deploy, then inspect two URLs from each group with a live test. You want the status you chose and a screenshot that matches it. Use "Validate fix" on the soft 404 row only after the template is fixed. Validation checks a sample over time. It fails when a second template still emits the old 200.

Keep the status-code decision next to the route table in the repo, not in a spreadsheet nobody opens. The next redesign will recreate soft 404s if the new front end serves one HTML file for every path.

If your important articles are the URLs in that report, stop treating them as deletions. Look at rendering and at whether the article is actually in the first HTML response. The indexing diagnostic separates that case from a page that was never a page.

CrawlFaster's indexing monitor is a way to see whether a status-code change shows up as a pattern across a section, instead of inspecting every retired URL by hand. The status code itself still has to be set on your server.