How does Googlebot render JavaScript?

"Can Google render JavaScript?" was answered years ago: yes, it can and does. The questions that actually matter in 2026 are more specific — how the process works, where it stalls, and what limits it — because that is what separates a site that indexes reliably from one that indexes slowly and incompletely.

The three-stage pipeline

It is usually called a two-wave model, but it is clearer as three distinct stages, because the middle one is where pages get stuck.

The Web Rendering Service, and a myth to drop

The rendering itself is done by the Web Rendering Service (WRS), which is essentially a headless Chromium browser operating at scale. A persistent, outdated claim says Googlebot renders with "Chrome 41". That has not been true for years.

Since 2019 the WRS has run an evergreenChromium — kept up to date with the current stable release, so it supports essentially the same modern JavaScript and web APIs a recent Chrome does. This is good news and it removes a whole category of old worry about unsupported syntax. But it also removes a convenient excuse: if your content is missing after rendering, it is almost never because Googlebot's browser is too old. It is because the content depended on something rendering never reached — a slow fetch, an interaction, an error, or a resource it could not load.

The render queue is where the delay lives

The single most consequential fact about this pipeline is that the queue between crawl and render is not instant, and its length is not uniform.

The wait can be anything from seconds to weeks. What decides where you land is, in large part, how Google assesses the site's importance. This is not formally documented as policy, but it is consistent in crawl data: pages on high-authority, frequently-updated sites get rendered quickly, while pages on new or low-traffic sites wait far longer. Rendering budget is finite and it is allocated to the sites Google is most confident are worth the cost.

This produces a compounding disadvantage that is easy to miss. The sites that most need timely indexing — new ones trying to establish themselves — are the ones given the least rendering priority. If your content requires rendering to be seen, you are relying on a queue that is deprioritising you precisely because you are new. Serving complete HTML at crawl time sidesteps the queue entirely.

The limits that quietly bite

Two hard constraints sit on top of the pipeline, and both catch people who assume rendering is unconstrained.

There is also a robots.txt trap worth a mention: if you block Googlebot from the JavaScript or CSS files a page needs, the WRS cannot fetch them and the render fails or comes out wrong. Rendering-critical resources must stay crawlable.

What actually changed in 2026

In March 2026 Google removed a long-standing section from its JavaScript SEO documentation — the guidance recommending that pages be designed to work without JavaScript — describing it as outdated. This was widely misread as "Google now handles client-side rendering fine, so it no longer matters".

That reading is a trap. The removal reflects that Google's own rendering has matured — not that first-pass HTML stopped mattering. In the same period the guidance has pushed harder toward server-side rendering and static generation as the recommended foundation, and treated client-only rendering as the risky option. The documentation got more confident about Google's rendering while the wider crawler ecosystem was moving in the opposite direction.

The real question in 2026 isn't about Google

Here is the reframe that matters. The debate about whether Google can render JavaScript was settled in 2019. In 2026 the useful question is not can Google render it but which crawlers actually reach your content — and increasingly the answer is uncomfortable.

Google renders. Most of the crawlers behind AI assistants and answer engines do not — they fetch the raw HTML and stop, with no render queue and no second pass. So a page that Google eventually indexes after a delay can be permanently invisible to them. Optimising only for Googlebot's patience is optimising for the one reader that has always been most forgiving, at exactly the moment a growing share of discovery is moving to readers that are not forgiving at all. That shift is covered in its own guide.

See exactly what the first pass receives

Everything upstream of the render queue comes down to one thing: what is in the raw HTML at crawl time. That is the response the first pass indexes, the response every non-rendering crawler is limited to, and the response that decides whether your page even earns a render. The checker fetches that raw response and compares it to the fully rendered page, so you can see the gap directly.