Is it really cloaking when Googlebot sees a 404 while users see a 200?

Why is this question being raised for React SPAs?

Modern single-page applications consistently return a 200 OK code, even when the content does not exist. The logic for displaying the 404 error is handled client-side in JavaScript after the initial load.

This behavior creates an obvious problem: Googlebot receives a 200 for a page that should technically return a 404. Pre-rendering services like Prerender.io or Rendertron specifically address this gap by serving the correct HTTP code to the crawler.

Does dynamic rendering really change the game?

Yes, because it allows you to serve a pre-rendered version to Googlebot with the correct HTTP status codes while keeping the SPA intact for real users. Google has always validated this approach as a temporary solution.

Martin Splitt clarifies here that returning a 404 to the bot while the user sees the same error page in 200 is not considered cloaking, since the displayed content remains identical. Only the HTTP code changes — and that’s exactly what we aim to correct.

What happens if we leave the 200 for everyone?

Google will detect a soft 404 if the content of the page clearly indicates an error (like a "page not found" message, little content, etc.). Soft 404s are treated like real 404s regarding indexing, but with a detection delay.

The problem is that this detection is not instantaneous and can lead to wasted crawl budget, especially on sites with thousands of dynamically generated pages. Serving a real 404 via dynamic rendering speeds up the process.

• Dynamic rendering with correct HTTP codes: a practice validated by Google, no risk of cloaking
• Soft 404: automatically detected by Google, but with a variable delay based on the sites
• Identical content: only the HTTP code changes between bot and user, which is precisely the goal of dynamic rendering
• Suspicious behavior: if the content differs significantly or if patterns of manipulation are detected, the risk of penalty exists

Is this statement consistent with observed field practices?

Absolutely. I've seen dozens of React/Vue/Angular sites using dynamic rendering with differentiated status codes without ever receiving a penalty. As long as the visible content remains the same, Google does not consider it cloaking.

What matters to Google is the intention to manipulate. If you serve a 404 page to the bot and commercial content to the user, then you cross the line. But correcting an HTTP code while displaying the same error page? That's exactly what dynamic rendering is supposed to do.

What nuances should be added to this statement?

The wording "unless there is suspicious behavior" remains deliberately vague. Google never details precisely what triggers a cloaking flag in these cases. [To be verified]: we lack data on tolerance thresholds — how many pages can differ in HTTP codes before a suspicious pattern is detected?

Another point: Splitt mentions that soft 404s will be detected anyway, but he does not provide a timeline. On sites with limited crawl budget, this can take weeks. Serving a real 404 remains objectively more effective, even if Google eventually figures it out on its own.

In which cases does this rule not apply?

If your dynamic rendering service introduces additional content visible only to Googlebot — enhanced metadata, hidden texts, additional links — you dip into pure cloaking territory, even if the HTTP codes are correct.

Also be cautious of unintentional discrepancies: if your pre-renderer injects third-party scripts, different consent banners, or significantly alters the HTML structure, Google might see it as an attempt at manipulation. Always check that the pre-rendered version matches pixel for pixel what the user sees.

What should you concretely do to remain compliant?

First, configure your dynamic rendering service (Prerender.io, Rendertron, or a custom solution) to return the correct HTTP codes based on the content. If your SPA displays a 404, the bot must receive a 404. If it's a 301, likewise.

Next, systematically test using the URL inspection tool in Search Console. Compare the version rendered by Google with what a real user sees. Zero difference in visible content — that's the golden rule.

What mistakes should you absolutely avoid?

Never serve rich content solely to Googlebot just because you're using dynamic rendering. Adding hidden text, hyper-boosted Schema.org tags, or additional internal links only in the pre-rendered version is classic cloaking.

Avoid also unintentional HTTP code discrepancies. If your SPA returns a client-side 301 redirect but your pre-renderer serves a 200, Google will get confused. Clearly document the mapping rules between JavaScript states and HTTP codes.

How can I check that my implementation is solid?

Set up an automated monitoring system that regularly compares the bot version and the user version across a sample of pages (existing, 404, redirects). Tools like Screaming Frog or Sitebulb can do this in comparison mode.

Check in Search Console for the presence of detected soft 404s. If Google detects them despite your dynamic rendering, it means your service is not returning the correct codes or the content is not clearly signaling the error.

• Configure dynamic rendering to serve correct HTTP codes (404, 301, 410, etc.)
• Test every type of page (existing, error, redirect) with Google's URL inspection tool
• Compare pixel by pixel the bot and user versions — no visible content difference
• Monitor soft 404s in Search Console to catch configuration discrepancies
• Document mapping rules between JavaScript states and HTTP codes for the whole team
• Regularly audit third-party pre-rendering services to avoid uncontrolled changes