Is serving a 404 to Googlebot while showing a 200 to visitors really cloaking?

Why is there tolerance for divergent HTTP codes?

In modern Single Page Applications, pre-rendering has become essential for facilitating indexing. Tools like Prerender.io or Rendertron intercept Googlebot's requests and serve them static HTML, while human visitors load the client-side JavaScript application.

The issue arises when a route does not exist: the SPA visually displays an error message with a 200 code, while the pre-rendering sends a 404 to Googlebot. Technically, this involves serving different content based on the user-agent — the classic definition of cloaking. However, Google recognizes that the intent here is not fraudulent.

This clarification addresses a legitimate anxiety: many developers fear that optimizing the Googlebot experience through pre-rendering may trigger a manual penalty. Martin Splitt clarifies this ambiguity for standard cases.

What defines the line between optimization and manipulation?

The critical nuance lies in the expression ‘something really dubious’. Google does not precisely define this threshold, but the context suggests that it pertains to cases where the 200 content for the user would be rich and functional, while Googlebot would systematically receive 404s to conceal entire sections.

If the user indeed sees an error page (“Page not found”, “This resource no longer exists”), then serving a 404 to Googlebot aligns with the reality of the user experience. It is even more honest than allowing Google to index an empty 200 that would trigger a soft 404.

How does Google detect soft 404s?

A soft 404 occurs when a server returns a 200 code for a page that logically should be a 404 — very sparse content, a visible error message, degraded UX signals. Google uses content heuristics: text/HTML ratio, linguistic patterns typical of errors, absence of usual structural elements.

In the case of a SPA, if the 200 page served to visitors is indeed an error, Google will classify it as a soft 404 even without receiving the appropriate HTTP code. That is why serving the true 404 to Googlebot via pre-rendering is actually an improvement: you align the HTTP signal with the content reality.

• Pre-rendered 404 for Googlebot + visual error 200 page for the user: tolerated by Google, considered a legitimate technical optimization.
• Soft 404: detected through content analysis, not just the HTTP code — Google identifies empty pages or error messages even with a 200.
• Cloaking prohibited: hiding existing content from Googlebot by serving systematic 404s or showing rich content to the bot while displaying an error to visitors.
• Vague threshold: Google does not clarify ‘really dubious’ — caution dictates documenting any divergence and ensuring it accurately reflects the user experience.

Is this statement consistent with field observations?

Overall, yes. For years, sites using pre-rendering with differentiated HTTP codes have not faced visible manual penalties, as long as the user experience remains consistent. Comparison crawls between Googlebot and standard browsers show that Google tolerates these technical discrepancies when they support indexing.

However, the phrase ‘something really dubious’ remains vague. [To be verified]: no numerical metrics, no precise tolerance threshold is provided. We remain in the subjective judgment of the Quality Raters team or anti-spam algorithms. A site may fly under the radar for months and then change if usage patterns shift.

What gray areas should be monitored?

The real danger is not a legitimate SPA 404, but a gradual drift: a developer starting to serve 404s for marginal pages ‘just to see’, then extending the practice to entire categories. Or worse, serving a rich 200 to the visitor and a 404 to Googlebot to control indexing without using robots.txt.

Another trap: pre-rendering configuration errors. I’ve seen sites where the pre-rendering service served 404s by default due to a poorly calibrated timeout, while the JavaScript page eventually finished loading on the client-side. Google can interpret this as instability, or even manipulation if the pattern is systematic.

In what cases does this rule not apply?

This tolerance only concerns true error pages. If you serve a 404 to Googlebot for an active product page, a service sheet, or a blog post, that is pure cloaking — even if the user sees a 200 with content.

Similarly, if you use this technique to hide duplicate content or low-quality pages that you do not want to index, Google might see it as a manipulation attempt. The best practice remains using noindex or canonical, not a selective 404 based on user-agent.

What concrete steps should you take to stay compliant?

First, audit your pre-rendering: list all the routes serving a different HTTP code to Googlebot compared to users. Document each case with a clear justification — ‘page removed’, ‘invalid parameter’, ‘resource never created’. If you cannot justify the divergence in 10 seconds, it is probably a red flag.

Next, test the visual consistency: navigate to the URLs that return a 404 to Googlebot. Does the user actually see an error message, a broken layout, or empty content? If the page displays useful content, align the HTTP code — serve a 200 everywhere or a 404 everywhere.

What mistakes should you absolutely avoid?

Never create a whitelist/blacklist based on user-agent to serve strategic 404s. This is exactly the pattern that anti-spam algorithms detect. If you need to block indexing, use the robots.txt file, the noindex meta tag, or the X-Robots-Tag header.

Avoid the default 404: some pre-rendering services are configured to return 404s in case of timeout or JavaScript errors. This can mask real bugs and create an illegitimate gap with the user experience. Configure generous timeouts and log rendering errors.

How can I check if my implementation is compliant?

Use the URL Inspection tool in Google Search Console to compare the version rendered by Googlebot with the one viewed in a standard browser. Look for discrepancies in HTTP codes, but also in content — a massive gap signals a problem.

Monitor the index coverage reports for spikes in soft 404s. If Google classifies many of your pages as soft 404s while you are serving clean 404s via pre-rendering, that’s a good sign — it confirms that both signals align. Conversely, if you see soft 404s without having sent an HTTP 404, dig deeper.

• Document each route serving a different HTTP code to Googlebot versus users, with clear business justification.
• Manually test pre-rendered URLs as 404s: does the user actually see a visual error page?
• Configure generous timeouts on the pre-rendering service to avoid accidental 404s due to JavaScript delays.
• Use the URL Inspection tool in Search Console to compare Googlebot rendering and standard browser rendering.
• Monitor coverage reports to spot anomalies (mass soft 404s, unexpected de-indexing).
• Avoid any whitelist/blacklist user-agent logic — prefer robots.txt, noindex, or canonical to control indexing.