Soft 404 occurs when the protocol and the content do not match. The server returns 200 OK, which promises a complete resource, but the HTML contains an error, an empty template, or a page that does not match the requested address. A search engine may classify this URL as missing even though it did not technically receive status code 404. There is no separate soft 404 status in DevTools: this is a conclusion drawn from multiple signals.
Why a successful status code becomes an error signal
A common cause is a generic CMS template. The router cannot find a record in the database but still renders the header, footer, and the message “Nothing found.” The application handled the exception, so the web server sent 200. To the user, this is an error page; at the protocol level, it is a successful document.
Another scenario involves catalogs. A product has been discontinued, a filter returns no results, a city is not served, or a profile has been deleted. The template remains available, but there is no unique main content block. The reverse can also happen: a useful, short page may be incorrectly identified as soft 404 because it has very little content or resembles an error message.
Google recommends returning 404 for pages that are genuinely missing and checking the rendered result with the live test in Search Console; this is covered in the official help on the indexing report. The site owner’s task is to make the status code match the meaning of the response. Hiding the notification in the console will not solve the problem.
First, identify the URL class
Do not start by replacing statuses in bulk. Divide the flagged addresses into at least four groups:
| Resource status | Correct response |
|---|---|
| The resource never existed or was deleted without a replacement | 404 or 410 |
| There is an exact new equivalent | permanent redirect to the equivalent |
| The page is temporarily empty but still serves a useful purpose | 200 with meaningful status information |
| A useful document was incorrectly identified as empty | keep 200 and remove the error signals |
Add the source of each URL to the list: internal links, sitemap, old import, filter parameters, or external traffic. If soft 404 appears across many URLs that use the same template, investigate the generator: fixing individual addresses will leave the underlying cause in place. If one important landing page is affected, compare it with a working page of the same type.
The article on common 404 errors can help you choose between restoring a page, removing it, or redirecting it, but soft 404 also requires checking the content of the successful response.
Inspect the actual response at every level
Get the status code without automatically following redirects, then check the final redirect chain. Save the raw HTML. Next, open the page with JavaScript disabled and with scripts running normally. If the source contains a valid product but the interface replaces it with a “not found” message after an API request, the cause lies in the data or client-side application. If the source is empty but the browser receives content later, check whether the API is accessible to crawlers.
Compare four elements: HTTP status code, <title>, H1, and main text. The combination of 200, “Page not found” in the title, a generic H1, and an almost empty main clearly indicates an error template. Check the canonical too: an error page should not point to the homepage as its canonical in an attempt to preserve signals.
For a dynamic site, it is useful to inspect network requests and server logs for a specific URL. The 200 status of the external document may conceal an internal API response of 404 or 500. In that case, fix the data handling; a meta tag will not change the API’s incorrect response.
Choose a response based on the resource status
Return 404 if the requested object does not exist and there is no relevant replacement. Code 410 Gone indicates an intentional, permanent deletion more precisely, but for most CMSs, a correct 404 is sufficient. Both responses can display a formatted page with search, categories, and navigation; a useful interface does not require status code 200.
A permanent redirect is appropriate when there is a close successor: the same product card at a new URL, a merged article, or a service whose address has changed. Redirecting every deleted product card to the homepage or parent category is not a universal fix. The user expected a specific object and received something else; the redirect itself may be treated as soft 404. The rules for building redirect chains are covered in the article on checking redirects.
Remove the deleted URL from the sitemap and internal links. It is not possible to update all external links, so a useful 404 page is still needed. Do not block the address in robots.txt: the crawler needs to see the correct status and update its records.
When to keep 200
An empty result does not always mean that a resource is missing. A “Jobs” category page may temporarily have no listings but still provide a company description, a subscription for new positions, and contact details. A product category may remain an important entity even when all items are out of stock. In that case, 200 makes sense if the main content explains the situation and continues to serve the user’s purpose.
Remove system-error language from the title and H1. Provide unique context: what the section is, why it currently has no items, what actions are available, when the information is updated, and whether there are neighboring categories. Do not fill the template with arbitrary SEO text. The content should make clear what lasting entity the URL represents. Masking missing data will create the same soft 404 signal.
For product pages, the business decision depends on the catalog model. A temporarily unavailable product is usually kept with its specifications and availability status. A permanently removed product with no equivalent is served with 404 or 410. If there is an exact successor model, redirect only after checking that it is semantically equivalent.
How to fix a template-level issue affecting many URLs
Find the layer that first detects that an object is missing: the router, controller, server component, or API. That is where the response status must be set. If the application first sends 200 and then client-side JavaScript displays an error, it is already too late to change the HTTP status code. For SSR frameworks, use the built-in not-found mechanism before sending the headers; in a traditional CMS, set the status before rendering the template.
Handle invalid parameters separately. A nonexistent pagination page, a filter combination, and a junk identifier do not have to become indexable empty landing pages. Define valid values, normalize URLs, prevent the generation of infinite combinations, and keep only selected canonical pages in the sitemap. The connection between such URLs and crawling is explained in the article on crawl budget.
Tests should cover an existing object, a deleted object, an invalid identifier, a temporarily empty list, and a data source error. The last case is not the same as a missing resource: if the database or API fails, it is more appropriate to return 5xx so you do not tell search engines that real pages have been deleted.
Check for a false positive
If the page is useful, compare what the crawler sees with what the browser displays. Check the mobile version, rendered HTML, Search Console screenshot, resource availability, and content shown to visitors who are not logged in. A short page can stand on its own, but generic titles, identical H1s, and the absence of main content make it more likely to resemble a placeholder.
Do not try to resolve a false positive just by adding more words. Make the page’s subject clear: use its exact name, factual information, navigational context, correct structured data, and its own canonical. Make sure important content is not hidden until a user takes an action. After making changes, request a live test and save the resulting HTML as a reference copy.
Checks after publishing the fix
First, check a sample of URLs from each class, then crawl the entire affected template. Acceptance criteria: missing objects return the chosen status code; working pages return 200 and contain their main content; redirects lead to a relevant final address; sitemaps and internal links are cleaned up; data source errors do not turn into 404.
After the sample check, a full reChecker site audit can collect pages from the sitemap and internal links and show their responses and recurring technical signals. Logs and search consoles remain the source of historical data, while the site owner assigns a business class to each URL.
Changes to the search engine’s report will appear after the next crawl, so a check a few minutes later will show only the site’s current state. Save the deployment date, the new response, and a record of the selected URL class. When the crawler visits the address again, this information will show whether it received the updated version and whether the status matches the resource’s lifecycle.