Googlebot crawle-t-il et rend-il le JavaScript à la même fréquence ?

Quelle est la séquence officielle du traitement JavaScript par Google ?

La déclaration de Martin Splitt pose un cadre simple : Googlebot crawle d'abord l'HTML brut, puis procède au rendu JavaScript, et enfin indexe le contenu rendu. Cette séquence linéaire est censée se dérouler à la même fréquence — autrement dit, chaque crawl devrait théoriquement déclencher un rendu.

Sauf que la réalité est plus complexe. Google admet lui-même que des décalages se produisent régulièrement. Le rendu peut être exécuté plus souvent que le crawl si Google dispose déjà de ressources en cache (CSS, JS) et détecte un changement sans avoir besoin de re-télécharger l'HTML. À l'inverse, le crawl peut survenir sans rendu si Google estime que rien n'a changé ou si une erreur bloque le processus avant même que le moteur de rendu n'intervienne.

Pourquoi ces décalages posent-ils problème en SEO ?

Parce qu'ils créent une zone grise entre ce que Google voit et ce qu'il indexe. Un site peut être crawlé régulièrement sans que le contenu JavaScript soit effectivement rendu et indexé. C'est particulièrement critique pour les sites en JS frameworks (React, Vue, Angular) où l'essentiel du contenu dépend du rendu côté client.

Un autre angle : si Google rend plus souvent qu'il ne crawle, il peut indexer une version obsolète du DOM basée sur des ressources en cache. Résultat ? L'index reflète une version fantôme de votre page, ni totalement à jour ni totalement périmée. Et vous n'avez aucun moyen direct de savoir quelle version Google a réellement indexée à un instant T.

Quels sont les cas où le rendu n'a pas lieu ?

Google liste deux scénarios explicites. Premier cas : rien n'a changé depuis le dernier crawl. Si le HTML est identique et que les ressources JS/CSS sont déjà en cache, Google peut décider de ne pas rendre à nouveau. C'est une optimisation de ressources côté Google, mais ça signifie aussi qu'un changement subtil dans votre JS peut passer inaperçu si l'HTML source reste inchangé.

Deuxième cas : une erreur avant le rendu. Timeout, ressource JS bloquée par robots.txt, erreur de chargement, budget crawl épuisé avant que le rendu ne démarre. Dans ces situations, Google indexe uniquement l'HTML brut, ce qui peut être catastrophique si votre contenu principal n'existe que dans le DOM post-rendu.

• Le crawl et le rendu ne sont pas synchronisés en pratique, même si Google affirme qu'ils le sont « en général ».
• Le rendu peut être sauté si Google détecte qu'aucun changement n'a eu lieu ou si une erreur survient avant.
• Le rendu peut se baser sur des ressources en cache, ce qui crée un décalage entre la version live et la version indexée.
• Les sites full-JS sont les plus exposés à ces décalages, car leur contenu dépend entièrement du rendu.
• Google ne fournit aucun outil pour vérifier précisément quelle version rendue a été indexée à une date donnée.

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

Partiellement. Sur le papier, Google affirme que crawl et rendu se déroulent à la même fréquence. Mais les praticiens SEO constatent depuis des années que le rendu JavaScript accuse souvent un retard significatif par rapport au crawl HTML. Des tests avec des outils comme OnCrawl ou Botify montrent régulièrement que des pages sont crawlées plusieurs fois avant qu'un rendu ne soit détecté dans les logs.

Ce que Google appelle « même fréquence » mérite d'être challengé. Si le rendu est conditionné à la disponibilité des ressources, à la détection de changements, ou à l'absence d'erreur, alors la fréquence n'est pas la même — elle est conditionnelle. [A verifier] : Google ne fournit aucune donnée chiffrée sur le taux réel de crawl suivi d'un rendu effectif. Sans métriques publiques, cette affirmation reste invérifiable.

Quelles nuances faut-il apporter à cette déclaration ?

Première nuance : le budget crawl n'est pas le budget rendu. Google n'a jamais confirmé explicitement que les deux opérations consomment le même quota de ressources. Or, rendre du JavaScript coûte infiniment plus cher en CPU que parser de l'HTML brut. Il est donc logique — et observé — que Google rationne le rendu plus strictement que le crawl, surtout sur les sites à faible PageRank interne ou avec une infrastructure lente.

Deuxième nuance : la notion de « rien n'a changé » est floue. Google compare-t-il uniquement l'HTML source ? Le DOM post-rendu ? Les ressources JS elles-mêmes ? Aucune précision officielle n'existe. Si Google se base sur un hash de l'HTML source, un site qui modifie uniquement du contenu injecté via JS ne déclenchera jamais de nouveau rendu, même si le contenu visible a radicalement changé.

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

Sur les sites avec rendu côté serveur (SSR) ou génération statique, la problématique disparaît en grande partie. Si le HTML source contient déjà le contenu final, Google n'a pas besoin de rendre. Le crawl suffit. C'est pour ça que Next.js, Nuxt, ou Gatsby en mode SSR/SSG échappent à ce casse-tête — le HTML crawlé est déjà le HTML indexable.

Autre cas : les sites à très forte autorité ou avec un trafic massif. Google semble allouer un budget rendu plus généreux aux sites prioritaires. C'est inéquitable, mais c'est observé. Un site e-commerce majeur verra probablement chaque crawl suivi d'un rendu, tandis qu'un petit site en React peut attendre des jours entre crawl et rendu effectif. Google ne l'admet pas publiquement, mais les données de crawl en disent long.

Que faut-il faire concrètement pour s'assurer que Google rend bien votre JS ?

D'abord, monitore la différence entre crawl HTML et rendu effectif. Les outils comme Google Search Console ne montrent pas cette distinction, mais des plateformes comme Botify ou OnCrawl permettent de croiser les logs serveur avec les traces de rendu. Si tu constates un écart important (ex: 80% de crawls HTML mais seulement 20% de rendus détectés), c'est un signal rouge.

Ensuite, vérifie que tes ressources JS critiques ne sont pas bloquées. Robots.txt, erreurs 4xx/5xx, timeouts — tout ça peut empêcher le rendu avant même qu'il ne démarre. Utilise l'outil de test d'URL dans Search Console pour simuler un rendu et repère les ressources qui échouent. Si Google ne peut pas charger ton app.js principal, il indexera uniquement l'HTML vide.

Quelles erreurs éviter pour ne pas casser la séquence crawl-rendu ?

Première erreur classique : versionner tes fichiers JS sans invalidation de cache côté Google. Si tu deploy un nouveau bundle.js mais que Google a encore l'ancienne version en cache, il peut rendre une version hybride — HTML nouveau, JS ancien. Résultat : un DOM incohérent qui peut casser l'affichage ou générer du contenu erroné dans l'index.

Deuxième erreur : ne pas fournir de fallback HTML pour le contenu critique. Si Google décide de ne pas rendre (erreur, timeout, budget épuisé), il indexe l'HTML brut. Si cet HTML ne contient rien — juste un <div id="root"></div> vide —, ta page n'existe pas pour Google. Un minimum de contenu en HTML source (titres, intro, métadonnées structurées) peut sauver l'indexation en cas de rendu raté.

Comment vérifier que mon site est conforme à cette logique de rendu ?

Utilise l'outil de test d'URL dans Search Console pour chaque page clé. Compare le HTML source (onglet « Plus d'infos » > « HTML brut ») avec le DOM rendu (onglet « Voir la page testée »). Si le contenu visible dans le DOM rendu n'existe pas dans l'HTML brut, tu dépends à 100% du rendu — et tu es donc exposé à tous les décalages décrits par Google.

Ensuite, audite tes temps de rendu. Si ton JS met plus de 5 secondes à s'exécuter, Google peut timeout avant la fin. Utilise Lighthouse ou WebPageTest pour mesurer le Time to Interactive (TTI) et le First Contentful Paint (FCP). Un TTI > 5s est un signal que Google risque de ne pas attendre la fin du rendu.

• Vérifier que les ressources JS critiques ne sont pas bloquées par robots.txt ou des erreurs HTTP
• Comparer systématiquement HTML source et DOM rendu dans Search Console
• Monitorer les logs serveur pour détecter les crawls sans rendu associé
• Mesurer les temps de rendu (TTI, FCP) et optimiser en dessous de 3-5 secondes
• Fournir un fallback HTML avec au moins le contenu critique (titres, intro, schema.org)
• Versionner correctement les assets JS pour éviter les conflits de cache côté Google