Is it still necessary to modify your JavaScript for Google to crawl it?

What exactly changes for JavaScript crawling?

For years, Googlebot relied on an old version of Chromium to interpret JavaScript. This limitation forced developers to transpile their modern code (ES6, ES7) to ES5 to ensure that the bot could execute scripts without errors.

With this announcement, Google states that its crawler now supports let, const, arrow functions, and array methods like map(), filter(), reduce(), and other features introduced since ECMAScript 2015. In short: the JavaScript you write for modern browsers is now understood by the bot, without going through Babel or any other transpilation tool.

Why is this change happening now?

Google has gradually updated the version of Chromium embedded in Googlebot. Historically, the bot was stuck on Chrome 41, a 2015 version that only supported ES5. This limitation forced developers to maintain two versions of the code: one for users, one for bots.

In recent years, Googlebot has been following an 'evergreen' version of Chromium, meaning it updates regularly like a standard browser. This means that modern web APIs, new JavaScript syntax, and recent features are theoretically accessible to the crawler. This announcement formalizes an evolution that some practitioners had already noticed in the field.

Are all modern features truly supported?

This is where it gets complicated. Google mentions let, const, and array methods, but does not specify exactly how far the support goes. Async/await? Native ES6 modules? Optional chaining? Nullish coalescing? The statement remains vague on the exact scope.

Furthermore, even if Googlebot understands the code, this does not guarantee that rendering occurs correctly. JavaScript execution time is limited, crawling may fail if the code is too heavy or poorly optimized, and some asynchronous features may still pose problems if they delay the display of critical content.

• Googlebot now uses an evergreen version of Chromium, allowing it to understand modern JavaScript without ES5 transpilation.
• Polyfills added solely for the bot are now unnecessary—but those required for old mobile browsers remain relevant.
• The exact support for recent features (async/await, ES6 modules, etc.) is not explicitly documented—testing is required.
• JavaScript compatibility does not solve performance or delayed rendering problems that could still affect indexing.

Does this announcement align with what is observed in the field?

Yes, overall. Since Googlebot transitioned to an evergreen version of Chromium (announced in late 2019), tests show that the crawler can indeed execute ES6+ code without errors. Developers who have removed heavy transpilation have not observed a drop in indexing.

That said, Google has never provided a comprehensive list of supported features. The announcement mentions let, const, and array methods, but what about Promises, fetch(), workers, native ES6 modules? [To be verified]—no official documentation details the exact scope. We are still in a grey area that requires testing each stack on a case-by-case basis.

What are the actual limitations of this compatibility?

The fact that Googlebot understands modern JavaScript does not solve structural crawling problems on the client side. If your content is completely rendered in JS with delays of several seconds, if you load dozens of third-party scripts, if your API calls are slow or poorly optimized, the bot is still likely not to index your pages correctly.

The JavaScript rendering consumes crawl budget, and Google does not render all pages under the same conditions as a user with a 4G connection. Sites that heavily rely on client-side JS still need to monitor Search Console, use the URL testing tool, and ensure that critical content appears in the rendered HTML.

Should we really remove all polyfills?

No, not all. Google states that polyfills added specifically for Googlebot are no longer necessary. But if you need to support old browsers (some mobiles running Android 4-5, Safari iOS 12, etc.), you still need polyfills for these actual clients.

The best practice is to load polyfills conditionally: use solutions like Polyfill.io or a loading based on client-side feature detection. Serve only what is strictly necessary, based on user-agent or browser capabilities. Googlebot no longer needs these patches—your users on old devices do.

What should be done concretely with this information?

First, audit your build configuration. If you are using Babel, Webpack, or another transpiler, check which version of ECMAScript you are targeting. Many projects still compile to ES5 by default, even though this is no longer essential for Googlebot. You can safely target ES2017 or ES2018 without affecting crawling.

Next, test the rendering of your key pages with the Search Console URL testing tool. Ensure that the content displays correctly, that internal links are present in the rendered HTML, and that JavaScript does not block indexing. If everything works with modern code, you can lighten your bundle by removing bot-specific polyfills.

What mistakes should be avoided during migration?

Do not remove polyfills in bulk without testing. Some sites discovered afterward that their code relied on APIs not supported by the version of Chromium in Googlebot. Proceed step by step: test first on a few non-critical pages, monitor crawl logs, check indexing.

Another pitfall: confusing JavaScript compatibility with rendering performance. Googlebot can understand your ES6 code, but if your scripts block display for 3 seconds or if the main content arrives after a badly handled asynchronous fetch(), you will still have an indexing problem. Optimize the critical rendering path, reduce bundle sizes, and avoid blocking network calls.

How can I check if my site is compliant and crawled properly?

Use the URL testing tool in Search Console to inspect the HTML rendered by Googlebot. Compare it to the initial source code: critical content must be visible in the final DOM. Also, check the JavaScript console in the tool—any errors can block rendering.

Consult the crawl statistics to identify any potential 5xx errors or timeouts related to JavaScript rendering. If you notice an increase in errors after removing polyfills, it’s a sign that you need to revisit your configuration. Finally, monitor your positions and organic traffic: a sudden drop after a build modification may indicate a crawl or indexing problem.

• Audit the Babel/Webpack configuration and target ES2017+ instead of ES5 if possible
• Test rendering with the Search Console URL testing tool on representative pages
• Gradually remove Googlebot-specific polyfills while monitoring crawl logs
• Keep necessary polyfills for old browsers used by your actual visitors
• Optimize the critical rendering path to limit JavaScript rendering time
• Monitor crawl statistics and any rendering errors in Search Console