Does Google really render ALL JavaScript, even without initial server-side content?

Why does this statement break a long-held misconception?

For years, the SEO community believed that Google skipped JavaScript rendering if the page contained no initial HTML content. The assumption was straightforward: no visible content in the source HTML, no rendering.

Martin Splitt debunks this belief. The engine does not condition JS rendering on the presence of server-side content. In practical terms: even if your page returns empty HTML with just <div id="root"></div>, Google will still execute the JavaScript and index the content generated on the client side.

What is this legacy heuristic that Google mentions?

Splitt refers to a heuristic for certain legacy domains, without specifying which ones or under what conditions it is activated. This is typically the kind of vague phrasing that leaves SEOs wanting more.

We can assume it pertains to very old sites that were never migrated, or domains known for outdated practices. But without numerical data, it’s impossible to know if this exception concerns 0.1% or 5% of the crawl. [To be verified] on the ground with empirical testing.

Does this mean that SSR is unnecessary for SEO?

No. The statement says that Google renders JS anyway, but it does not say that SSR brings no benefits. Server-side rendering remains a performance lever: reducing first contentful paint time, improving crawling by third-party bots (social networks, aggregators), conserving crawl budget.

In other words: if your site is fully CSR (client-side rendering), Google will index your content. But you miss optimization opportunities related to speed, UX, and multi-platform compatibility. SSR or static hydration remain best practices for SEO-critical sites.

• Google renders practically all JS pages, even without initial HTML content
• A heuristic exists for certain legacy domains, but its scope remains unclear
• SSR is not mandatory for indexing, but it is recommended for performance and UX
• Do not confuse “Google indexes JS” with “Google indexes all JS content without delay or limitation”

Is this statement consistent with field observations?

Yes and no. It is indeed observed that Google indexes the majority of JS content, including on completely empty SPAs in source HTML. But the real question isn’t “does Google render?”, it’s “when and with what reliability?”.

In practice, the rendering delay can vary from a few hours to several weeks depending on crawl budget, domain authority, and update frequency. On an e-commerce site with 10,000 JS pages, significant indexing discrepancies are often seen between priority pages and long-tail product listings. [To be verified] with regular monitoring tests.

What nuances should be added to this statement?

Splitt says “practically all pages” — this “practically” is crucial. He implicitly admits that there are cases where Google does not render JS, but he does not detail which ones. Is it related to render timeouts? Critical JS errors? Sites with a robots.txt blocking resources?

Another point: the statement only discusses the decision to render, not the quality of rendering or the indexing process. Google can very well render a page, fail to extract the content if the JS fails, or decide not to index the result if the content is deemed poor. These are two distinct steps in the pipeline.

In what cases does this rule not apply?

It is known that certain dynamic content loaded after user interaction (clicks, infinite scroll, hidden tabs) may not necessarily be rendered. Google simulates a basic user, not a power user who clicks everywhere.

Similarly, if your JS generates different content based on geolocation or cookies, Google will see a “neutral” version that may not correspond to what your users actually see. Finally, sites with slow external dependencies (third-party APIs, overloaded CDNs) may experience rendering failures due to timeouts.

What should I do concretely if my site is fully CSR?

First, test actual indexing. Use Search Console to check that your JS pages are indeed indexed, with the correct content. The URL inspection tool shows you the rendered HTML as Google sees it — that's your field reference.

Next, optimize the render time. Even if Google renders your JS, it does so with a strict timeout. Reduce bundle sizes, defer non-critical scripts, use smart lazy loading. Every millisecond counts to ensure that strategic content is properly extracted.

What mistakes should be avoided at all costs?

Do not rely on the assertion “Google renders everything” to neglect initial HTML content. Even if Google indexes your JS, other crawlers (social networks, feed aggregators, monitoring tools) will not. You lose indirect traffic.

Avoid also blocking JS/CSS resources in robots.txt. This is a classic mistake that prevents Google from properly rendering the page. Ensure that all critical assets are accessible to the crawler.

How can I check if my site is being rendered correctly by Google?

Set up regular indexing monitoring. Compare the number of submitted pages (XML sitemap) with the number of indexed pages (Search Console). If there is a significant gap, dig deeper: is it a crawl budget issue, a rendering issue, or content quality problem?

Use tools like Oncrawl, Botify, or Screaming Frog in “JS rendering enabled” mode to simulate Googlebot's behavior. Compare the extracted content with and without JS. If you observe major differences, that’s a warning sign.

• Check the actual indexing of your JS pages in Search Console
• Optimize JS rendering time to stay within Google’s timeouts
• Never block critical resources (JS, CSS) in robots.txt
• Regularly test with the URL inspection tool to see the rendered HTML
• Consider SSR or static pre-generation for strategic pages (product listings, landing pages)
• Monitor gaps between submitted pages and indexed pages to spot rendering issues