You delete a product page, change the structure of your URLs, or migrate to a new CMS. A few weeks later, Google Search Console shows dozens of 404 errors. The classic reflex is to redirect them all to the homepage. This is a false good idea that creates other problems.
Soft 404 and classic 404: the distinction that changes your SEO strategy
A classic 404 error returns an HTTP 404 (or 410) code to the browser and Googlebot. The server clearly states: this page no longer exists. Google understands the signal, gradually removes the URL from its crawl queue, and moves on.
The real trap lies elsewhere. A soft 404 returns a 200 OK code while the page is empty or displays an error message. From Google’s perspective, this URL seems to exist. The bot continues to visit it at each pass, which unnecessarily consumes crawl budget.
On a site with a few dozen pages, the difference is negligible. On an e-commerce catalog or an editorial site with thousands of URLs, accumulated soft 404s slow down the crawling of pages that really matter. Before you start making corrections, the priority is to know how to fix a 404 error on Google by distinguishing between these two cases.
Sites built with JavaScript frameworks (React, Vue, Angular) are particularly exposed. When a route does not exist, the application displays a “page not found” message on the client side, but the server returns a 200 code. Google treats this behavior as a soft 404, and the page remains in the crawl queue.
Sort your 404 errors before fixing them: prioritization method
Not all 404 errors deserve the same treatment. A URL that has never received an external link, never generated traffic, and corresponds to outdated content can remain a 404 without any SEO damage. Google confirms: legitimate 404s are part of the normal functioning of the web.
Have you consulted the “Pages” report in Google Search Console without knowing where to start? Here’s how to rank your 404s by priority:
- URLs that still receive external backlinks: they pass on authority. Without redirection, this SEO capital disappears. Identify them by cross-referencing Search Console data with a crawling tool.
- URLs that generated organic traffic before their deletion: a 301 redirect to the closest content page can recover some of that traffic.
- URLs resulting from typos, bots, or incorrect URL parameters: leave them as 404. Redirecting these URLs would create unnecessary redirects that burden your server configuration.
Prioritize 404s that have backlinks or historical traffic. The rest can wait, or may never be addressed.
301 redirects and 410 code: choosing the right HTTP response
The 301 redirect is the default reflex. It works well when an equivalent page exists on the site. Have you renamed a category or merged two articles? The 301 transfers most of the link authority to the new URL.
When the 301 redirect causes problems
Redirecting an old product page to the homepage helps no one. The user arrives on a page unrelated to their search, and Google eventually treats this redirect as a soft 404. A 301 redirect should point to thematically related content, not to a generic page.
The 410 code to signal a permanent removal
The HTTP 410 (Gone) code tells Google that the page has been intentionally removed and will not return. Google deindexes these URLs faster than with a simple 404. Use the 410 for permanently removed product pages, legally problematic content, or test URLs that should never have been indexed.
The 410 accelerates deindexing compared to the classic 404. On a site with a large volume of deleted pages, this speed difference frees up crawl budget more quickly.
Custom 404 page: turning an error into useful navigation
Even with rigorous redirection work, visitors will still land on non-existent pages. A link shared on a forum, a URL typed from memory with a typo: the zero 404 does not exist.
A custom 404 page does not fix the technical problem, but it limits user loss. To be effective, it must offer:
- An immediately visible internal search field, without having to scroll.
- Links to the main categories or the most viewed content on the site.
- A clear message confirming that the page does not exist, without technical jargon.
The technical point not to miss: your custom 404 page must return a true HTTP 404 code. If your server or CMS returns a 200 code for this page, you create exactly the soft 404 problem described above. Test the response code with the URL inspection tool in Search Console.
404 errors on a JavaScript site: check server-side rendering
Single-page applications (SPAs) manage navigation on the client side. When a visitor accesses a route that does not exist, the framework displays an “error” component without server intervention. The HTTP code remains 200.
For Googlebot to correctly interpret the situation, the 404 response must come from the server. Two approaches work: server-side rendering (SSR) that generates the page with the correct HTTP code before sending it to the browser, or static pre-rendering that produces HTML files with the correct headers.
A “page not found” message displayed by JavaScript with a 200 code is treated as a soft 404 by Google. Check the actual status code in the Network tab of your browser’s developer tools, or directly via Search Console.
On a classic site under WordPress or a similar CMS, this problem usually does not arise: the server natively handles the 404 code. Vigilance is especially needed for decoupled architectures (headless CMS + JavaScript frontend).
