Chrome evergreen pour le rendering : Google met-il vraiment à jour son moteur aussi vite qu'annoncé ?

Qu'est-ce qu'un "Chrome evergreen" dans le contexte du rendering Google ?

Un navigateur evergreen se met à jour automatiquement sans intervention de l'utilisateur. Contrairement aux anciennes versions de Chrome figées dans le temps, Googlebot utilise une version qui évolue en continu, calée sur les releases publiques de Chrome.

Martin Splitt précise que cette version suit les mises à jour stables de Chrome avec un décalage de quelques semaines. Si Chrome 120 sort le 5 décembre, Googlebot passera probablement à cette version fin décembre ou début janvier. Ce n'est pas instantané, mais c'est prévisible.

Pourquoi ce décalage de "quelques semaines" existe-t-il ?

Google ne veut pas casser l'indexation de millions de sites à chaque micro-évolution de Chrome. Le décalage permet de tester la stabilité du moteur de rendering en environnement contrôlé avant déploiement massif sur la Search infrastructure.

Ce délai couvre aussi les mécanismes de retry automatiques : si une page plante lors du rendering, Googlebot retente plusieurs fois avant d'abandonner. Un rendering raté ne signifie pas indexation nulle — le système fait preuve de résilience.

Quelles fonctionnalités JavaScript sont réellement supportées par Googlebot ?

Avec une version evergreen de Chrome, toutes les APIs stables récentes sont supportées : ES6+, fetch, IntersectionObserver, modules JavaScript, async/await, Web Components v1, et même la plupart des features CSS modernes comme grid et custom properties.

En revanche, les APIs expérimentales ou en phase Origin Trial ne sont généralement pas actives côté Googlebot. Si votre site repose sur une feature bleeding-edge encore sous flag, elle ne sera pas exécutée lors du rendering.

• Chrome evergreen : Googlebot suit les releases stables de Chrome avec un décalage de quelques semaines
• Support JavaScript moderne : ES6+, modules, async/await, fetch, IntersectionObserver sont pleinement fonctionnels
• Retry automatique : en cas d'échec de rendering, le système retente avant d'abandonner
• Pas d'APIs expérimentales : les features sous flag ou en Origin Trial ne sont pas disponibles côté bot
• Prévisibilité : vous pouvez anticiper les capacités du bot en suivant le calendrier de release de Chrome stable

Cette déclaration est-elle cohérente avec les observations terrain ?

Globalement, oui. Les tests réguliers sur Search Console et via des crawls comparatifs montrent que Googlebot exécute effectivement du JavaScript moderne sans broncher. Les sites utilisant React, Vue ou Angular avec transpilation Babel standard s'indexent sans problème.

Mais attention : le décalage de "quelques semaines" est flou. Splitt ne donne pas de chiffre précis — 2 semaines ? 6 semaines ? 8 ? Ce manque de transparence complique la planification pour les sites qui adoptent rapidement des nouvelles features. [A vérifier] : Google ne publie pas de changelog public des versions de Chrome déployées côté Googlebot, contrairement à ce qu'il serait souhaitable.

Quelles nuances faut-il apporter à cette affirmation ?

Première nuance : evergreen ne signifie pas instantané. Si vous déployez une SPA qui exploite une API sortie dans Chrome 119, et que Googlebot tourne encore sur Chrome 117, votre contenu risque de ne pas s'afficher correctement lors du rendering.

Deuxième nuance : le système de retry automatique est une bonne nouvelle, mais il a ses limites. Si votre JavaScript plante systématiquement (erreur de syntaxe, ressource bloquée, timeout), même après plusieurs tentatives, Googlebot abandonnera. Le retry ne corrige pas les bugs — il compense seulement les aléas réseau ou de charge serveur.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Si votre site utilise des polyfills conditionnels détectant le user-agent, vous risquez de servir du code différent à Googlebot qu'aux visiteurs réels. Certains frameworks détectent des browsers "legacy" et chargent du code adapté — mais si Googlebot est détecté comme Chrome moderne, il recevra le bundle optimisé, qui peut parfois manquer de fallbacks.

Autre cas limite : les sites qui font du feature detection agressive et affichent du contenu uniquement si une API très récente est disponible. Si cette API n'est pas encore dans la version Chrome de Googlebot, le contenu reste invisible. Soyons honnêtes : c'est rare, mais ça arrive sur des sites très orientés PWA ou WebAssembly expérimental.

Que faut-il faire concrètement pour s'assurer d'une compatibilité optimale ?

D'abord, auditez votre stack JavaScript. Si vous utilisez Babel ou un transpileur, configurez-le pour cibler au minimum Chrome stable -2 versions (puisque Googlebot a quelques semaines de retard). Évitez de transpiler vers ES5 si vous n'avez pas besoin de supporter IE11 — vous alourdirez les bundles inutilement.

Ensuite, testez systématiquement avec l'outil d'inspection d'URL dans Search Console après chaque déploiement majeur. Cet outil vous montre exactement ce que Googlebot a réussi à render, y compris les erreurs console et les ressources bloquées. Si le rendering échoue, vous verrez pourquoi.

Quelles erreurs éviter absolument ?

Ne bloquez jamais vos ressources JavaScript ou CSS dans robots.txt. C'est la faute classique qui empêche le rendering même si Googlebot supporte votre code. Google a beau utiliser Chrome moderne, si les fichiers JS sont interdits, le bot ne peut rien exécuter.

Évitez aussi de compter uniquement sur des APIs bleeding-edge sans fallback. Si votre site affiche du contenu critique via une API en phase 3 du TC39 mais pas encore dans Chrome stable, prévoyez un plan B. Le rendering échouera silencieusement et votre contenu disparaîtra de l'index.

Comment vérifier que mon site est conforme au rendering Google ?

Utilisez Puppeteer ou Playwright en mode headless avec la version de Chrome stable actuelle -1 ou -2 pour simuler ce que voit Googlebot. Si votre contenu s'affiche correctement, vous êtes probablement safe. Sinon, debuggez avant que Google ne découvre le problème.

Activez aussi le monitoring des erreurs JavaScript via Sentry ou un outil équivalent, en incluant le user-agent Googlebot dans vos filtres. Si le bot génère des erreurs que les vrais users ne voient pas, vous saurez qu'il y a un problème de compatibilité spécifique.

• Configurez Babel pour cibler Chrome stable -2 versions minimum
• Testez chaque déploiement majeur avec l'outil d'inspection d'URL Search Console
• Ne bloquez jamais JS/CSS dans robots.txt — vérifiez votre fichier aujourd'hui
• Ajoutez des fallbacks pour toute API récente non encore stabilisée dans Chrome
• Mettez en place un monitoring des erreurs JS filtré sur user-agent Googlebot
• Simulez le rendering avec Puppeteer en version Chrome stable -1 ou -2 en local