Pourquoi Google ne voit-il pas votre contenu JavaScript sans rendering ?

Qu'est-ce que le rendering et pourquoi Google en a-t-il besoin ?

Le rendering est le processus qui transforme du code brut (HTML, CSS, JavaScript) en page web affichable. Concrètement, Google utilise une version récente de Chrome headless pour exécuter le JavaScript et reconstituer ce que verrait un utilisateur. Sans cette étape, le contenu injecté par JS — menus, filtres, textes dynamiques — n'existe tout simplement pas pour le bot.

Cette déclaration officialise un principe que les praticiens connaissent : si votre contenu critique dépend d'une exécution JS côté client, vous devez accepter que Google passe par une phase de rendering. Et cette phase a ses contraintes propres : délais, goulets d'étranglement, erreurs d'exécution possibles.

Google voit-il le code source ou la page rendue ?

Il voit les deux, mais à des moments différents. D'abord, Googlebot crawle le HTML brut. Ensuite, si la page est jugée prioritaire, elle entre en file d'attente pour le rendering. C'est là que le JavaScript s'exécute et que le contenu dynamique apparaît. Entre les deux, il peut s'écouler quelques secondes… ou plusieurs jours.

Ce décalage crée un risque : si votre contenu essentiel n'existe que post-rendering, il peut rester invisible pendant un temps variable. C'est particulièrement critique pour les pages à forte vélocité éditoriale ou les sites e-commerce avec stock fluctuant.

Quels types de contenu sont concernés ?

Tout ce qui est généré ou modifié par JavaScript côté navigateur : single-page applications (SPA), frameworks comme React, Vue, Angular, mais aussi des éléments plus simples comme des accordéons, des filtres de produits ou des zones de texte chargées en lazy loading. Si le contenu n'apparaît dans le DOM qu'après exécution d'un script, il nécessite rendering.

• Googlebot crawle d'abord le HTML brut, puis met en file d'attente le rendering JavaScript
• Le rendering s'appuie sur une version récente de Chrome, donc compatible avec la plupart des APIs modernes
• Le délai entre crawl et rendering peut retarder l'indexation du contenu dynamique
• Les SPA et frameworks JS sont entièrement dépendants de cette phase de rendering
• Tout contenu critique doit idéalement être présent dans le HTML initial pour éviter ces délais

Cette déclaration reflète-t-elle la réalité observée sur le terrain ?

Oui, mais avec des nuances importantes. Google rend effectivement le JavaScript — c'est documenté et observable via Search Console, Mobile-Friendly Test ou l'inspection d'URL. Cependant, le timing est imprévisible. Sur des sites à forte autorité ou avec un crawl budget généreux, le rendering peut intervenir quelques secondes après le crawl. Sur d'autres, ça peut prendre des jours, voire ne jamais se produire pour certaines pages secondaires.

Gary Illyes parle d'une « version récente de Chrome », mais ne donne pas de précision sur la version exacte ni sur la fréquence de mise à jour. [A vérifier] : en pratique, on observe parfois des décalages avec certaines APIs très récentes. Si votre code JS utilise des fonctionnalités de pointe, testez systématiquement avec les outils Google avant de déployer.

Quels sont les angles morts de cette déclaration ?

Premier angle mort : le budget de rendering. Google ne dit pas combien de pages il peut ou veut rendre par site et par jour. On sait qu'il existe une file d'attente, mais sa logique d'arbitrage reste floue. Résultat : certaines pages peuvent être crawlées sans jamais être rendues si elles sont jugées peu prioritaires.

Deuxième angle mort : les erreurs d'exécution JavaScript. Si votre code plante lors du rendering (timeout, erreur de script, dépendance externe qui échoue), Google peut indexer une version partielle ou vide de la page. Et vous ne le saurez pas forcément, sauf à surveiller activement Search Console et les logs serveur.

Dans quels cas peut-on se passer de rendering côté Google ?

Si votre contenu critique est présent dans le HTML initial — autrement dit, si vous faites du server-side rendering (SSR) ou de la génération statique — Google n'a pas besoin d'exécuter le JavaScript pour accéder au texte, aux titres, aux balises meta. C'est le scénario le plus fiable : pas de délai, pas de file d'attente, pas d'erreurs d'exécution possibles.

En revanche, si vous utilisez du JS pour améliorer l'UX (carrousels, animations, lazy loading non critique), le rendering interviendra quand même, mais l'indexation ne dépendra pas de lui. C'est l'approche la plus robuste : contenu essentiel en SSR, enrichissements en client-side.

Que faut-il faire concrètement si votre site dépend du JavaScript ?

Première étape : auditer ce qui est visible sans rendering. Désactivez JavaScript dans votre navigateur et naviguez sur votre site. Tout ce qui disparaît sera invisible pour Googlebot lors du crawl initial. Si c'est du contenu stratégique (titres produits, descriptions, pricing), vous avez un problème.

Ensuite, testez le rendering côté Google avec l'outil d'inspection d'URL dans Search Console. Comparez le HTML brut et le HTML rendu. Vérifiez les erreurs JavaScript dans l'onglet « Plus d'infos ». Si des ressources sont bloquées (CSS, JS externes), corrigez immédiatement.

Quelles erreurs éviter absolument ?

Ne bloquez jamais les ressources critiques (CSS, JavaScript) dans le robots.txt. C'est une erreur encore fréquente et catastrophique : Google ne pourra pas exécuter le code, donc ne verra pas le contenu. Vérifiez également que vos scripts ne dépendent pas de ressources tierces lentes ou instables — un CDN qui timeout peut faire planter tout le rendering.

Autre piège : les SPAs sans fallback SSR. Si votre site React ou Vue ne génère qu'une coquille HTML vide côté serveur, vous dépendez à 100 % du rendering Google. C'est jouable, mais risqué. Mieux vaut implémenter du SSR ou de la génération statique (Next.js, Nuxt, etc.) pour garantir que le contenu soit accessible dès le crawl initial.

Comment vérifier que votre configuration fonctionne correctement ?

Mettez en place un monitoring régulier : inspectez vos principales pages dans Search Console chaque semaine, exportez les logs serveur pour repérer les crawls sans rendering subséquent, surveillez les Core Web Vitals (un JS mal optimisé ralentit aussi l'expérience utilisateur). Si vous détectez des pages indexées avec du contenu manquant, c'est un signal d'alerte.

• Désactiver JS dans le navigateur pour voir ce que Googlebot voit au crawl initial
• Utiliser l'outil d'inspection d'URL pour comparer HTML brut et HTML rendu
• Vérifier qu'aucune ressource CSS/JS critique n'est bloquée dans robots.txt
• Tester les pages stratégiques avec le Mobile-Friendly Test pour détecter les erreurs de rendering
• Mettre en place du SSR ou de la génération statique pour le contenu essentiel
• Surveiller les logs serveur pour identifier les pages crawlées mais jamais rendues
• Auditer régulièrement Search Console pour détecter les contenus partiels ou vides indexés