How can you effectively manage 404 errors in a single-page application?

Single-page applications (SPAs) generate their content client-side via JavaScript. When a user types a non-existent URL, the server often responds with a 200 OK code along with the app shell — then JavaScript detects the error and displays a 404 page. The problem is that Google sees a 200, crawls the page, and may index it as a real page.

This situation creates a conflict between technical architecture and SEO signals. Developers prefer serving the app shell for all routes, including non-existent ones, to maintain a coherent user experience. However, from a crawl perspective, this pollutes the index with error pages.

Why does this statement change the game?

Until now, the official recommendation remained vague. Some suggested returning a real 404 code from the server, while others favored the noindex approach. Splitt clarifies: both approaches work, and Google treats them equivalently.

Specifically, if your SPA detects an invalid route, you can either inject a <meta name="robots" content="noindex"> into the DOM or redirect via JavaScript to a real 404 page that correctly returns a 404 status code. Both signals are understood by Googlebot.

What does this technically change for an SPA?

The noindex meta tag solution is lighter on the dev side: you remain within the application, inject the tag via JavaScript, and display the error template. No additional requests, no leaving the application context.

Redirecting to an external page requires more logic: you need to maintain a real route /404 that returns a correct HTTP code, manage the redirection client-side, and ensure that this page is crawlable without JavaScript. More robust, but costlier in development.

In what cases does this equivalence really apply?

The equivalence holds if — and only if — Googlebot correctly executes your SPA's JavaScript. If the bot doesn’t see the noindex tag because the script breaks or times out, you'll end up with indexed 404 pages.

Another condition is that the noindex meta tag is injected quickly. If your framework takes 3 seconds to detect the error and add the tag, Google may have already decided to crawl the page as valid. Timing matters.

• Both approaches (noindex and redirect to an external 404) are officially equivalent according to Google
• The choice depends on your technical stack and the complexity of implementation
• The noindex tag must be injected quickly and visible to Googlebot during rendering
• An actual external 404 page offers more guarantees in case of JavaScript issues
• Check in Search Console that your 404s are not accidentally indexed

Does this statement correspond to field observations?

Yes, to a large extent. It has been observed for years that Google generally respects the noindex meta tag injected via JavaScript, provided that the rendering is correct. But — and here’s where it gets tricky — not all SPAs are equal when it comes to crawling.

Some frameworks (misconfigured React, aggressively lazy loading Vue) can delay the injection of the noindex tag to the point where Googlebot makes a decision before seeing it. In these cases, you indeed find indexed 404 pages. [To verify]: Google has never precisely documented the timeout threshold before indexing decisions for an SPA.

What nuances should be added to this recommendation?

First point: the announced equivalence assumes that your implementation is technically clean. A mispositioned noindex in the DOM, a persistent 200 code on the server-side even after redirection — all of this breaks the equivalence. Splitt discusses the ideal case, not the messy edge cases encountered in audits.

Second nuance: redirecting to an external 404 page remains more robust against JavaScript bugs. If your bundle crashes, if an ad blocker blocks a critical script, the external page with a proper 404 code will continue to function. The noindex, on the other hand, entirely depends on JS execution — a point of fragility.

In what cases does this equivalence not hold?

If your site serves a 200 code for all routes, including non-existent ones, and the noindex is never injected (framework bug, timeout, console error), Google will index your 404s. This is often observed on poorly maintained SPAs where hundreds of "not found" pages pollute the index.

Another case: non-Google crawlers. Bing, for example, is less effective at executing JavaScript. If you rely solely on the noindex injected client-side, you may find indexed 404s by them. A real redirection to an HTTP proper 404 works everywhere.

What should be done concretely for existing SPAs?

First, audit the current state: open Search Console, go to the Coverage section, filter by "Excluded", and look for 404 pages. If you find dozens indexed, your current implementation isn’t working. Test a few 404 URLs with the inspection tool — check if the noindex appears in the rendered HTML.

Next, choose your method. If your dev team has a good grasp of the framework and JavaScript executes quickly, the noindex meta tag is viable. Otherwise, switch to a redirection to an external 404 page with a proper HTTP code — this is more defensive, especially if you have recurring JS rendering issues.

What mistakes should be avoided during implementation?

Don’t clumsily mix the two approaches. If you add a noindex and redirect to a page that returns a 200, you’re sending contradictory signals. Google may become confused and adopt unpredictable behavior.

Another classic mistake: injecting the noindex too late in the component lifecycle. If your framework waits for a useEffect or a mounted() that triggers after several seconds, Googlebot may make its decision beforehand. Inject the tag as early as possible, ideally server-side if you’re doing SSR.

How can you verify if the implementation is correct?

Use the Search Console URL inspection tool on several different 404 URLs. Check that the rendered HTML indeed contains the noindex meta tag, or that the page returns a real 404 code. Compare with the source HTML — if the noindex only appears in the rendered version, it’s being injected by JS (which is normal for an SPA).

Monitor your coverage reports for a few weeks after making changes. If new 404 pages continue appearing as "Excluded" with the reason "Page with redirection", that’s a good sign. If they show up as "Indexed", your implementation is failing — back to the dev drawing board.

• Audit Search Console to identify currently indexed 404s
• Test injection of the noindex meta tag with the URL inspection tool (rendered HTML)
• Ensure that the HTTP 404 code is properly returned if you opt for external redirection
• Ensure that the noindex is injected quickly, before Googlebot’s likely timeout
• Monitor coverage reports for 4-6 weeks after changes
• Document the chosen approach for future maintenance