A 404 error is an HTTP status code returned by a server when it cannot find the requested resource at the specified URL. The browser receives this code, displays a message like “page not found,” and the visitor leaves the site. For search engines, the situation is different: Googlebot records this response, logs it in its reports, and adjusts its crawling behavior accordingly.
404 Error and Soft 404: Two Problems, Two Fixes
Google makes a clear distinction between a classic 404 error and a soft 404. The former occurs when the server explicitly returns the HTTP code 404 or 410: the page no longer exists, and the server confirms it. The handling is straightforward.
The soft 404, on the other hand, poses a more insidious problem. The page returns an HTTP 200 (success) code, but its content resembles an empty page, an error message, or a result without data. Google then classifies it as a soft 404 in the indexing report of the Search Console, even though technically the server has not reported any error.
This distinction changes the correction to be applied. For a page that has actually been deleted, the 404 or 410 code is the correct response; it is merely a matter of deciding whether a 301 redirect to relevant content is warranted. For a soft 404, you either need to enrich the content so that it deserves to exist or return a true 404 code.
Before taking any action, it is useful to understand the 404 error on Google to make a reliable diagnosis.
Soft 404 on Dynamic Sites: The JavaScript Rendering Trap
E-commerce sites and media often generate filtered results pages, product facets, or temporarily empty categories. These “zero result” pages are a frequent cause of large-scale soft 404s. Google crawls them, sees a nearly empty template, and reports them massively in the Search Console.
Another trap concerns JavaScript rendering. A page may display correctly in a browser, with all its content loaded on the client side, but appear empty or incomplete to Googlebot if the JS rendering fails. The page works for a human, not for the bot. Google then classifies it as a soft 404 without the webmaster noticing during regular browsing.
Verification is done through the URL inspection tool in the Search Console, which shows the version of the page as Google sees it. If the displayed rendering differs from what the browser shows, the problem lies with JavaScript, not the server.
Sorting 404 Errors Before Fixing Them
Fixing all 404s on a site indiscriminately is a waste of time. The best practice is to sort each reported URL according to its actual status before taking action. Four categories emerge:
- URLs that correspond to content intentionally deleted: the 404 or 410 code is the correct response. No action needed; Google will eventually remove them from its index.
- URLs that pointed to moved or renamed content: a 301 redirect to the equivalent page is the only relevant fix. Redirecting to the homepage is treated by Google as a soft 404.
- URLs generated by broken internal links (typos, structural changes): the link must be corrected at the source, in the content or in the menu, rather than creating a permanent redirect.
- URLs from external links over which the webmaster has no control: a 301 redirect to the closest content preserves the link juice passed by these backlinks.
This sorting avoids creating dozens of unnecessary redirects that burden the server configuration and mask real problems.
Detecting 404s in Google Search Console: Reading the Indexing Report
The “Pages” report in the Search Console lists the URLs that Google could not index, categorized by reason. 404 errors appear under the label “Not Found (404)” and soft 404s under “Soft 404.” These two categories deserve separate reading.
For each listed URL, the Search Console indicates the date of the last crawl and the source of discovery (sitemap, internal link, external link). The source of discovery guides the correction: a 404 discovered via the sitemap means that the XML file references a page that no longer exists. A 404 discovered via an internal link indicates a broken link structure within the site.
An external crawler like Screaming Frog complements this diagnosis by crawling the entire site from the root. It identifies internal links pointing to 404s even if Google has not yet reported them, allowing action before the problem surfaces in the Search Console.
Monitoring 404s Over Time
A one-time audit is not enough. 404 errors appear with every content update, every product deletion, every change in URL structure. Regular monitoring of the indexing report, combined with a monthly crawl, allows for the detection of new 404s before they accumulate.
301 Redirect and 410 Code: Choosing the Right Signal
The 301 redirect indicates to Google that the content has been permanently moved to a new URL. It transfers some authority from the old page to the new one. This is the appropriate fix when equivalent content exists elsewhere on the site.
The HTTP 410 (Gone) code indicates that the resource has been permanently deleted and that no replacement is planned. Google treats the 410 as a stronger signal than the 404 to remove the URL from its index. For obsolete content without an equivalent, the 410 is more explicit.
A common mistake is redirecting all 404s to the homepage. Google identifies this pattern and treats it as a soft 404: the redirect provides no value to the user, and the homepage does not match the intent of the original URL. Each redirect should point to the closest content related to the original topic.
Managing 404 errors is not spectacular, but it conditions how Google crawls and indexes a site. A cleaned sitemap, verified internal links after each structural change, and a methodical sorting of reported URLs are enough to keep a site technically clean on this point.
