SPA Soft 404s Start at the Server Response

A soft 404 occurs when a URL returns a success status, commonly 200, but its content signals that the requested resource is missing. Single-page applications create this accidentally when the host rewrites every unknown path to index.html. The router eventually paints “not found,” yet the network contract already declared success.

This mismatch wastes crawl attention, makes monitoring ambiguous, and can leave arbitrary typo URLs eligible for processing. A designed empty state is valuable for users, but it must sit on top of an accurate response. Visual polish cannot correct the semantics of a response that has already been cached, logged, and fetched as a valid document.

A development server history fallback is convenient because client routing works without server configuration. In production, the deployment should know which static routes, dynamic record keys, assets, and true client-only paths exist. Generate known article directories, use framework not-found primitives, or resolve a record before returning the application shell.

Test the deployed host rather than only client navigation. Clicking from a valid page may render the not-found view, while a cold request is rewritten differently by the CDN. Probe random paths, malformed record IDs, removed slugs, trailing-slash variants, encoded characters, and asset-like paths. The final edge response is the contract Search receives.

An empty category can be a legitimate 200 page if the category exists and the empty state helps users. A missing product ID should be 404. A permanently merged article should redirect to the relevant successor. A database timeout should return a server error rather than pretending that every record disappeared. These states need typed handling before they reach the page component.

Avoid blanket redirects from missing URLs to the homepage or nearest category. The destination is not an equivalent replacement, so the redirect can itself be treated as a soft 404 and disorient users. Redirect only when there is a strong one-to-one replacement; otherwise return the honest absence with useful navigation.

Google documents client redirects to a URL that returns a real 404 and dynamically added noindex as possible SPA approaches. They are fallback mechanisms, not equivalent to an origin that returns the correct status immediately. Rendering must execute before Google can observe them, other clients may not, and an indexed typo URL can linger until recrawled.

If infrastructure constraints force a fallback, create one stable not-found route with a real 404 response, prevent loops, and preserve the attempted URL in a privacy-safe way for diagnostics. If using noindex, ensure Google can render and see it, exclude the URL from sitemaps and internal links, and plan the server correction rather than normalizing the workaround.

Build a route manifest and assert that every published route returns 200, every retired mapping returns one intended permanent redirect, and representative unknown routes return 404. Validate title, canonical, robots directives, sitemap membership, structured data, and visible body for each class. Run the probes against preview and production-like hosting, not just a local fallback server.

Monitor Google’s soft 404 indexing reason, origin logs, and random canary paths that should never exist. A sudden 200 on the canary detects a broad rewrite regression before search reports settle. Preserve sample URLs and crawl dates because Google’s classification can lag a deployment and can also identify thin or misleading real pages as soft 404s.