Does Google really render ALL crawled pages with JavaScript?

What does this 'Web Rendering Service' actually mean?

Google's Web Rendering Service is a distributed system that orchestrates thousands of headless Chrome instances in the cloud. Each instance loads a page, executes its JavaScript, reconstructs the final DOM, and then sends this result to the indexer. It's exactly what a traditional browser does, except it's automated at a very large scale.

This service isn't new — Google has been using it for years. But Martin Splitt's statement clarifies one point: it's no longer an exception reserved for 'important' sites. According to him, it has become the norm for almost all crawled URLs. The process is systematic, not conditional.

Why does Google emphasize the word 'nearly'?

The term 'nearly all' is telling. Google doesn’t say 'all,' but 'nearly all.' This leaves room for interpretation: some pages may be excluded from rendering, particularly those deemed non-priority or already crawled recently without detected changes.

In practice, this may concern pages with a very low crawl budget, duplicate URLs, or sections blocked by robots.txt. Rendering is resource-intensive — Google won’t render a zombie page that has no traffic and no incoming links. Let’s be honest: if your page is of zero interest, it probably won’t go through this pipeline.

Is JavaScript rendering done in real-time during the crawl?

No. And that’s where many sites struggle. Crawling and rendering are two distinct steps. Googlebot first crawls the raw HTML, then queues the URL for the Web Rendering Service. This second pass can occur several hours or even days after the initial crawl.

This time lag has direct implications on the freshness of the indexed content. If you publish JS-generated news, it may not be visible in the SERPs immediately. The rendering delay becomes a bottleneck, especially for sites with high editorial velocity.

• The Web Rendering Service executes JavaScript on nearly all crawled pages, but with variable delays.
• The term 'nearly all' excludes some low-priority URLs or those considered irrelevant by Google.
• Crawling and rendering are two separate steps — which can create an indexing delay for dynamic content.
• Google uses headless Chrome instances in the cloud, ensuring faithful execution of JS, but resource-intensive.
• Pages blocked by robots.txt or excluded by meta directives do not undergo rendering, even if crawled.

Is this statement consistent with field observations?

Yes and no. For the past few years, it has indeed been observed that Google is indexing JavaScript-generated content better. Frameworks like React, Vue, or Angular no longer pose the same issues as they did in 2015. But — and it’s a big but — the rendering delay remains a real issue for many sites, especially those with a limited crawl budget.

I’ve seen e-commerce sites with JS-generated product pages wait 5 to 7 days before full indexing. On a news site, that’s a deal-breaker. Splitt's statement is theoretically true, but it glosses over the timing issue. Nearly all pages are rendered, sure — but when? [To be checked] for each site based on its authority and crawl budget.

What nuances should be added to this claim?

First nuance: rendering is not instantaneous. Second nuance: not all rendered pages are necessarily indexed. Google can very well execute the JS, notice that the content is thin or duplicated, and decide not to index. Rendering does not guarantee indexing.

Third nuance, and it's significant: some JS resources may fail to load. If your main script is blocked by robots.txt, hosted on a slow CDN, or if you have incorrectly configured CORS, the rendering will be incomplete. Google isn't going to wait 30 seconds for a script to load. There is a timeout, and after that, too bad. The final DOM will be partial.

In what cases does this rule not apply?

It does not apply to pages explicitly blocked by robots.txt or by a noindex meta tag. No rendering if Googlebot can’t crawl the raw HTML. It also doesn’t apply to orphan pages without any internal or external links — Google can’t render what it doesn’t discover.

Another case: pages with non-deterministic JavaScript or dependent on user interactions (infinite scroll without fallback, content revealed on click without accessible markup). Google can execute the JS, but if the content doesn’t appear in the DOM without interaction, it won’t be indexed. Let’s be clear: the Web Rendering Service is not a robot that clicks around to see what’s going on.

What concrete steps should be taken to optimize JavaScript rendering?

First, test. Use the URL Inspection tool in Search Console to check how Google renders your pages. Compare the raw crawled HTML with the final DOM after rendering. If critical elements (titles, descriptions, main content) are missing from the rendering, you have a problem.

Next, reduce JS execution time. The faster your JavaScript loads and executes, the more efficiently Google can render the page. Compress your bundles, use code-splitting, and avoid blocking scripts. Aim for a Time to Interactive of under 3 seconds — that’s a good indicator that Googlebot can render your page without timing out.

What mistakes should you absolutely avoid?

Number one mistake: blocking critical JavaScript resources in robots.txt. Google needs access to your JS files to execute rendering. If you block them, the final DOM will be incomplete, and your content will not be indexed. Check your robots.txt file and make sure essential scripts are accessible.

Number two mistake: relying solely on client-side rendering for strategic content. If you have high-value pages (product sheets, pillar articles), prioritize Server-Side Rendering (SSR) or static generation. The initial HTML should contain the main content, even if JS enhances the experience afterward. Don’t bet everything on the Web Rendering Service.

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

Three complementary methods. First method: use Search Console, under the 'URL Inspection' tab, then 'Test Live URL.' Check the screenshot and the rendered HTML. If the main content is there, that’s a good sign. If sections are missing, dig deeper.

Second method: Screaming Frog in JavaScript rendering mode. Configure it to emulate Googlebot and compare results with a raw HTML crawl. The differences will indicate which elements depend on JS. Third method: analyze your server logs. If you see crawls from Googlebot Desktop followed a few hours later by crawls from Google Cloud IPs (the Web Rendering Service), rendering is taking place. No second pass? Figure out why.

• Systematically test your strategic pages in Search Console using the URL Inspection tool.
• Never block your critical JavaScript resources in robots.txt.
• Prioritize Server-Side Rendering or static generation for high SEO value content.
• Reduce JS execution time and aim for a Time to Interactive of under 3 seconds.
• Analyze your server logs to detect passes from the Web Rendering Service and identify non-rendered pages.
• Regularly compare the raw HTML and the rendered DOM using Screaming Frog configured in JS mode.