Rendertron retire-t-il vraiment tout le JavaScript du HTML généré pour les bots ?

Rendertron, c'est quoi exactement et pourquoi Google en parle ?

Rendertron est un outil open-source développé par Google pour faciliter le server-side rendering (SSR) des applications JavaScript. Il s'agit d'une solution middleware qui intercepte les requêtes des bots, exécute la page dans un navigateur headless (Puppeteer), puis renvoie le HTML généré.

La particularité soulignée par Martin Splitt : Rendertron supprime activement tout le JavaScript du document final. Autrement dit, le bot ne reçoit qu'un fichier HTML statique dépourvu de balises <script>, même si ces scripts ont bel et bien tourné pendant la phase de rendering. Cette approche radicale vise à éviter toute tentative d'exécution JS côté bot — ce qui, dans l'absolu, rend le HTML plus léger et potentiellement plus rapide à indexer.

Quel est le cycle de vie exact du rendering avec Rendertron ?

Le processus se déroule en quatre étapes distinctes. D'abord, le bot envoie sa requête au serveur — User-Agent Googlebot, par exemple. Ensuite, Rendertron détecte qu'il s'agit d'un crawler et déclenche Puppeteer pour charger la page dans un navigateur headless complet.

Pendant cette phase, tout le JavaScript s'exécute normalement : appels API, hydratation React/Vue, événements analytics, pixels de tracking. Une fois le DOM stabilisé, Rendertron capture le HTML résultant, puis supprime toutes les balises <script> avant de servir ce snapshot au bot.

Le bot reçoit donc un HTML qui reflète l'état final de la page après exécution JS, mais sans aucune trace de code exécutable. C'est un snapshot figé, pas une page interactive.

Quelles implications pour les scripts tiers et le tracking ?

Les scripts comme Google Analytics, GTM, Facebook Pixel ou tout autre tag de tracking s'exécutent pendant le rendering Puppeteer. Ils envoient leurs requêtes HTTP normalement — donc vos événements analytics peuvent théoriquement se déclencher lors du rendu bot.

Mais ces scripts disparaissent du HTML final. Si vous inspectez le code source servi au bot (via un test Fetch as Google ou un crawl headless), vous ne verrez aucune balise <script src="analytics.js">. Cela complique la vérification manuelle et peut fausser certains audits automatiques qui parsent le HTML pour détecter les outils installés.

• Rendertron exécute le JS puis le retire — le bot voit le résultat, pas le code
• Les scripts tiers tournent pendant le rendering mais sont invisibles dans le HTML final
• Le snapshot est statique : aucune interactivité, aucun événement JS côté bot
• L'indexation repose sur le DOM final, pas sur la capacité du bot à exécuter du JavaScript
• Cette approche simplifie le crawl mais masque certaines implémentations techniques aux audits manuels

Cette déclaration est-elle cohérente avec les pratiques observées sur le terrain ?

Oui et non. Rendertron est un outil spécifique, pas la solution de rendering utilisée par Googlebot en production. Google crawle aujourd'hui avec son propre moteur basé sur Chromium, capable d'exécuter nativement le JavaScript sans passer par un middleware comme Rendertron.

Ce que dit Splitt concerne donc les sites qui choisissent d'implémenter Rendertron eux-mêmes pour servir du HTML pré-rendu aux bots — une pratique encore courante chez certains sites JS-heavy qui veulent garantir un contrôle total sur le rendu. Mais attention : Googlebot moderne n'a pas besoin de Rendertron pour indexer du React ou du Vue. Il le fait directement.

La suppression totale du JavaScript côté Rendertron est documentée dans le repo officiel. Elle évite les doubles exécutions et les bugs liés à l'hydratation client après un SSR partiel. Côté Googlebot natif, en revanche, le JS reste présent dans le HTML crawlé — il est simplement exécuté dans le navigateur headless interne de Google.

Quelles nuances faut-il apporter à cette affirmation ?

Première nuance : tous les sites ne passent pas par Rendertron. Si votre application React utilise Next.js avec du SSR natif ou Nuxt.js, vous servez déjà du HTML complet avec hydratation JS côté client — Rendertron n'intervient jamais. La déclaration de Splitt ne s'applique donc qu'aux implémentations manuelles de Rendertron en tant que proxy.

Deuxième point : dire que « les scripts s'exécutent mais disparaissent » peut prêter à confusion. Les événements déclenchés pendant le rendering (analytics, pixels) sont bel et bien envoyés aux serveurs tiers — donc vos stats peuvent comptabiliser des visites bot si vous ne filtrez pas les User-Agents. Mais ces hits ne reflètent pas un comportement utilisateur réel. [A vérifier] : aucune donnée publique de Google ne précise si ces événements analytics bot sont filtrés automatiquement par GA4 ou s'il faut gérer cela manuellement.

Troisième nuance : le HTML sans JS est plus léger, certes, mais il peut aussi masquer des erreurs d'implémentation. Si un script critique plante pendant le rendering Puppeteer, le snapshot HTML sera incomplet — et sans les balises <script> dans le code source, diagnostiquer le problème devient plus difficile.

Dans quels cas cette approche pose-t-elle problème ?

Si vous utilisez du lazy-loading JS pour le contenu critique — par exemple, charger des produits via fetch après l'événement onload — Rendertron peut capturer le snapshot trop tôt. Résultat : le bot voit une page vide ou incomplète. Vous devez alors configurer un délai de rendering ou un signal de « page ready » pour garantir que tout le contenu soit présent avant la capture.

Autre cas problématique : les sites qui s'appuient sur des scripts inline critiques pour injecter du schema.org ou des données structurées. Si ces balises <script type="application/ld+json"> sont supprimées par Rendertron, Google ne verra jamais vos données structurées — sauf si vous les injectez directement dans le HTML server-side avant le rendering.

Faut-il implémenter Rendertron sur son site en 2025 ?

Soyons honnêtes : la plupart des sites n'ont plus besoin de Rendertron. Googlebot exécute le JavaScript nativement depuis des années, et les frameworks modernes (Next.js, Nuxt, SvelteKit) proposent du SSR ou du SSG out-of-the-box. Rendertron reste pertinent pour des cas ultra-spécifiques : sites avec des SPA legacy complexes, besoin de contrôle total sur le rendu bot, ou contraintes de performance extrêmes.

Si vous partez de zéro sur un projet React/Vue/Angular, privilégiez un framework SSR natif plutôt qu'un middleware externe. Vous gagnez en maintenabilité, en compatibilité avec les Core Web Vitals, et vous évitez les pièges liés à la suppression du JavaScript.

Comment vérifier que le rendu bot est conforme à vos attentes ?

Première étape : utilisez l'outil d'inspection d'URL de Search Console et comparez le « HTML reçu » vs le « HTML rendu ». Si vous passez par Rendertron, le HTML rendu ne doit contenir aucune balise <script> mais tout le contenu visible doit être présent. Un écart entre les deux versions signale un problème de rendering.

Deuxième check : crawlez votre site avec Screaming Frog en mode JavaScript activé, puis en mode texte pur. Les deux crawls doivent retourner les mêmes titres, descriptions, H1, et contenus principaux. Si le crawl sans JS est vide ou incomplet, c'est que votre SSR (Rendertron ou autre) ne fonctionne pas correctement.

Troisième vérification : inspectez manuellement le code source d'une page stratégique via curl avec un User-Agent Googlebot. Si vous voyez des balises <script>, vous n'utilisez pas Rendertron — ou il est mal configuré. Si elles ont disparu, vérifiez que vos données structurées sont bien injectées server-side.

Quelles erreurs éviter absolument avec Rendertron ?

Erreur numéro un : ne pas tester le délai de rendering. Par défaut, Puppeteer attend que l'événement load se déclenche, mais certains contenus chargent après via des timers ou des observers. Configurez un waitUntil adapté (networkidle0, custom signal) pour capturer le DOM complet.

Deuxième erreur : oublier de filtrer les User-Agents analytics. Si vos scripts de tracking tournent pendant le rendering bot, vous polluez vos stats avec des hits non-humains. Implémentez une détection côté serveur ou configurez GA4 pour exclure les bots connus.

Troisième piège : croire que Rendertron résout tous les problèmes SEO JS. Si votre architecture applicative est mal conçue — lazy-loading agressif, routes client-side non gérées, pas de fallback SSR — Rendertron ne fera que capturer un snapshot d'une page cassée. Le problème, c'est l'implémentation JS elle-même, pas le rendering bot.

• Privilégier un framework SSR moderne (Next.js, Nuxt) plutôt que Rendertron sauf cas très spécifique
• Tester le rendu bot via Search Console et Screaming Frog en mode JS activé
• Vérifier que les données structurées sont injectées server-side, pas via JS client
• Configurer un délai de rendering adapté pour capturer tout le contenu asynchrone
• Filtrer les User-Agents bot dans vos outils analytics pour éviter la pollution de données
• Crawler régulièrement avec et sans JS pour détecter les écarts de rendu