For years, "what Chrome version does Googlebot use" had an embarrassing answer: a version from 2018, frozen for so long that entire classes of modern JavaScript silently failed to render for Google while working perfectly for every real visitor. That's no longer true, but the fix changed what SEOs actually need to check for — not "which old version," but "is my page's rendering timing-dependent."
The Short Answer: Evergreen Chromium
Googlebot's rendering engine is evergreen: it runs on the same underlying Chromium codebase as the latest stable release of Chrome, and Google updates it continuously to track new stable Chrome versions rather than freezing it. In practice this means Googlebot supports current JavaScript syntax, current Web APIs, and current CSS features at roughly the same pace a real user's up-to-date browser does — there usually isn't a meaningful list of "features Googlebot doesn't support yet" the way there was for years under the old frozen build.
Why This Used to Be a Much Bigger Problem
Before the evergreen switch, Googlebot rendered on Chrome 41, a build with no support for a long list of JavaScript features developers took for granted: no ES6 classes or arrow functions without transpilation risk, no IntersectionObserver, incomplete fetch support, and no modern async/await guarantees in every code path. Sites built with a framework that assumed a modern runtime could render fine for every human visitor and render as a blank page for Googlebot — a category of bug that was genuinely difficult to diagnose because nothing in a normal browser tab would ever reveal it.
The switch to evergreen rendering closed most of that specific gap. It didn't eliminate JavaScript SEO risk — it just changed what the risk actually is.
How to Check What Googlebot Currently Renders With
Three reliable ways to confirm the current state, since "evergreen" means the exact version number is a moving target rather than a fixed fact worth memorizing:
- Search Console's URL Inspection tool — the "View Crawled Page" → "More Info" panel shows the actual Googlebot user-agent string used for that specific crawl, which includes the Chromium version number in it.
- The Rich Results Test / Mobile-Friendly Test tools — both render the page using the same infrastructure Google's indexing pipeline uses, and expose the rendered HTML and any console errors that occurred during rendering, which is often more diagnostically useful than the version number itself.
- Google's own developer documentation for Googlebot publishes the current user-agent strings directly, since this is treated as public infrastructure information rather than something sites need to reverse-engineer.
What Evergreen Rendering Does — and Doesn't — Fix
Evergreen rendering means feature support is no longer the primary JS-SEO risk. What still causes real rendering failures for Googlebot, even on an evergreen engine:
- Content that depends on user interaction to load — click-to-reveal accordions, hover states, or infinite scroll that only fetches more content on a real scroll event. Googlebot doesn't interact with a page the way a human does; content gated behind an interaction it won't perform is effectively invisible.
- Render timing and timeouts. Googlebot's renderer has to give up waiting eventually. A page that depends on a slow third-party script, a chained sequence of API calls, or a client-side redirect that fires after several seconds can render incompletely even though it works fine for a patient human on a fast connection.
- Resources blocked in robots.txt. If the JavaScript or CSS files a page needs to render correctly are themselves disallowed from crawling, Googlebot can fetch the HTML but render a broken or empty layout — this is a persistent, still-common misconfiguration on sites that over-broadly blocked
/assets/or/static/paths years ago and never revisited it. - Client-side-only routing without server-rendered fallback content for the initial HTML response, on frameworks that don't pre-render or server-side render.
The Two-Wave Indexing Model: Crawl, Then Render
Worth understanding separately from the version question: Google's indexing pipeline processes a page in two passes. The first pass indexes the raw HTML as delivered by the server. The second, separate rendering pass — which can happen with a delay after the initial crawl, not necessarily instantly — executes JavaScript and indexes whatever content that produces. For content that's critical to a page's ranking (not just decorative), relying entirely on the second wave introduces a timing dependency that server-side rendering, static generation, or dynamic rendering avoids. This is a separate issue from which Chromium version is doing the rendering, and evergreen rendering doesn't change the two-wave model itself.
Practical Checks for JS-Heavy Pages
For any page where critical content (main copy, pricing, key structured data) is injected via JavaScript rather than present in the initial server response:
- Run the URL through the Rich Results Test and read the rendered HTML tab directly — if the content you care about isn't in that rendered output, it's not reliably indexed content.
- Check the browser console output in that same test for JavaScript errors specific to Googlebot's render — a script that depends on a browser API Googlebot's headless environment doesn't provide (certain permission-gated APIs, for instance) will fail silently in a way a normal QA pass on a real browser won't catch.
- Confirm no critical JS/CSS asset paths are disallowed in robots.txt with a quick manual check against the file, not an assumption.
The Bottom Line
Googlebot renders with an evergreen, auto-updating Chromium build that tracks current stable Chrome — there's no longer a specific frozen version number worth memorizing, and JavaScript feature support is rarely the bottleneck it used to be. The rendering risks that remain are about timing, interaction dependency, and blocked resources, not feature gaps. Checking the actual rendered output through Search Console's URL Inspection or the Rich Results Test, rather than assuming modern JS "just works," is still the only reliable way to know what Google actually sees.