Soft 404 errors: what they mean and how to fix them

The difference is between what the server says and what the page shows.

Single-page applications are the classic case: the host serves the same HTML shell with a 200 status for every path, and the app renders a not-found view in the browser. Other causes include empty category or search pages with no results, out-of-stock product pages reduced to a template, pages with very little main content, and redirecting many unrelated URLs to the homepage, which Google may also classify as soft 404s.

The server, not the browser, must return 404 for unknown routes. On serionflow.com we replaced the catch-all rewrite that sent every path to the app with rewrites scoped to known private routes, prerendered every public page, and let unknown paths fall through to a static 404 page that returns a real 404 status. Our build now verifies that a random unknown URL returns 404. On frameworks with server rendering, return the 404 status from the route handler; on static hosts, configure a 404 page instead of a blanket rewrite.

For pages that were removed, return 404 or 410. For pages that moved, redirect permanently to the closest equivalent, not to the homepage. For empty listings, either add useful content, noindex them while empty, or stop generating them. For out-of-stock products that will return, keep the page with real product information and availability; for discontinued ones, redirect to a close alternative or return 410.

Fetch an affected URL and confirm the status code in your browser's network panel or with a command-line request. Run Test live URL in URL Inspection. Then validate the fix in the Page indexing report. Our free broken link checker reports the status code of every linked URL on a page, which helps spot internal links that still point to missing pages. SerionFlow is the wrong tool for fixing soft 404s in your own app; status codes and routing are set by your server or host.