Does Google really render all JavaScript pages, regardless of their architecture?

What does this statement from Google really mean?

Martin Splitt announces that Google renders virtually all pages, with no major distinction between the technologies used. Whether your site uses server rendering (SSR), client rendering (CSR), or a hybrid approach, the engine will execute the JavaScript to access the final content.

This position marks a notable evolution. For years, the SEO community has debated Google's actual ability to handle JavaScript. Many have recommended SSR as a precaution, fearing that client-side rendering could penalize indexing. Splitt gets straight to the point: the rendering technology is no longer a decision criterion.

What is this legacy heuristic mentioned?

Google retains a heuristic to detect certain specific cases, but it only comes into play for older domains. Splitt remains intentionally vague on the details — it is unclear what exact criteria trigger this logic.

This mechanism seems to be a remnant from the days when Google had to arbitrate between crawling/rendering or not. Today, its use is marginal and exceptional. For 99% of sites, this technical nuance has no practical impact.

Why this evolution now?

Google's infrastructure has evolved. The server budget allocated to JavaScript rendering has clearly increased. Modern frameworks (React, Vue, Angular, Next.js) dominate the web — Google had no choice but to adapt.

This announcement also aims to reassure developers: you can build in JavaScript without jeopardizing your SEO. But beware, this does not mean that all implementations are equal. Rendering must be fast, clean, and accessible for Googlebot.

• Google renders nearly all pages, regardless of the type of rendering (SSR, CSR, hybrid)
• The server/client distinction no longer influences the crawling decision
• A legacy heuristic still exists, but its use is rare and targeted
• This evolution reflects Google's improved infrastructure and the dominance of JS frameworks
• JavaScript rendering is still possible, but implementation quality still matters

Is this statement fully aligned with what is observed in the field?

Overall, yes. Recent audits show that Google indeed manages to render the majority of JavaScript pages, even in pure CSR. Indexing issues related to rendering have decreased. However — and this is where it gets tricky — "virtually all" does not mean "all, all the time, instantly".

Variable rendering delays are still observed between the initial HTML and the indexing of JavaScript content. On some low-authority or poorly configured sites, this delay can be several days. Google does render, indeed, but not necessarily with the same priority or speed as an SSR page. [To be verified]: the real impact of rendering type on indexing timing remains a grey area.

What nuances should be added to this statement?

Splitt talks about the decision to render, not about the quality of the rendering or its ranking impact. Rendering the page does not guarantee that the content will be correctly interpreted, that the Core Web Vitals signals will be optimal, or that the user experience will be satisfactory.

Poorly optimized JavaScript can still cause 500 errors, timeouts, or unstable layouts. The fact that Google attempts to render does not eliminate the underlying technical issues. A CSR site with an 8-second LCP remains at a disadvantage compared to an SSR competitor at 1.2 seconds.

Moreover, this "rarely used" heuristic is a black box. Google does not specify the exact conditions. We can assume it concerns very old domains with detected spam patterns, but nothing is documented. Limited transparency, as usual.

In what situations might this rule not apply completely?

Some contexts remain problematic. Sites with aggressive lazy-loading, triggering content only on scroll or user interaction, may still escape initial rendering. Google simulates a viewport but does not scroll indefinitely — content "below the fold" that is very deep can remain invisible.

Single Page Applications (SPAs) with complex client-side routing sometimes pose problems. If internal navigation relies solely on JavaScript without distinct URLs or proper pushState management, Google may miss entire sections. Rendering one page does not mean that all its dynamic variations will be discovered.

What should you do next after this announcement?

First thing: do not change your tech stack just to please Google. If your site built with React or Next.js works well, there’s no need to rewrite everything in PHP. The key is to ensure that JavaScript rendering is performed correctly and quickly.

Use the URL Testing Tool in Search Console to inspect the actual rendering of your critical pages. Compare the initial HTML with the rendered DOM. If essential elements (titles, content, internal links) only appear on the client side, make sure they are present in the version Google renders.

Monitor the Core Web Vitals — that’s where CSR can weigh you down. A 4-second LCP because your JS bundle is 800 KB won’t be offset by the fact that Google "renders" the page. Optimize code splitting, intelligent lazy-loading, and browser caching.

What mistakes should you avoid despite this reassuring statement?

Don’t fall into the trap of "Google handles everything, so I don’t need to do anything". JavaScript rendering remains slower and more costly than static HTML. If you can pre-render or use SSR for your strategically important SEO pages (categories, product pages, landing pages), do it.

Avoid asynchronous fetches without fallbacks. If your main content relies on a client-side API call that fails or times out, Googlebot will see an empty page. Plan for loading states, retries, or better: fetch the data server-side.

Do not blindly trust third-party tools that simulate Googlebot. Some do not accurately replicate Google's real rendering environment (version Chrome, user-agent, timeouts). Only the official Search Console test is definitive.

How can I check if my site adheres to these best practices?

Set up regular render monitoring. Monthly test your main templates with the URL Inspection Tool. Compare server logs with coverage reports to detect any delays between crawling and indexing.

Analyze rendering times in JavaScript metrics. If the Time to Interactive exceeds 5 seconds, Google may technically render the page, but user experience (and thus ranking) will suffer. Use Lighthouse, WebPageTest, or Chrome DevTools to audit.

Ensure that your critical content appears within the first few seconds. The h1, main text, and navigation links should be present quickly. If everything loads after 3-4 seconds of JavaScript, you lose crawl budget and responsiveness.

• Regularly test rendering with the Search Console (URL Inspection Tool)
• Compare the initial HTML and the rendered DOM to identify missing content
• Optimize Core Web Vitals, especially LCP and CLS, for JavaScript pages
• Avoid critical dependencies on asynchronous API calls without fallbacks
• Pre-render or use SSR for strategic SEO pages (categories, products)
• Monitor delays between crawling and indexing to spot anomalies