Pourquoi Google indexe-t-il le JavaScript en deux vagues et comment ça impacte ton référencement ?

Que se passe-t-il exactement lors de ces deux phases d'indexation ?

Quand Googlebot crawle une page JavaScript, il récupère d'abord le HTML brut envoyé par le serveur. Cette première phase est quasi instantanée — le contenu statique présent dans le HTML source est analysé et indexé rapidement.

La seconde phase intervient après : Google met la page en file d'attente pour le rendu. Un navigateur headless (basé sur Chromium) exécute le JavaScript, construit le DOM final, et Google indexe alors le contenu qui n'apparaît qu'après exécution du code. Ce processus peut prendre de quelques heures à plusieurs semaines selon le crawl budget, la charge serveur de Google, et la complexité de la page.

Pourquoi ce délai entre les deux vagues pose problème en SEO ?

Le vrai souci, c'est l'écart temporel. Si ton contenu principal n'existe que dans le DOM post-JavaScript, il reste invisible pour Google pendant toute la période où ta page attend son tour dans la queue de rendu.

Pour des contenus sensibles au temps — articles d'actualité, produits en promotion, événements — ce délai peut tuer la visibilité. Google indexe une coquille vide en phase 1, et quand le contenu arrive enfin en phase 2, le pic de recherches est passé. Tu te retrouves invisible au moment où ça compte.

Comment vérifier ce que Google voit réellement sur ton site ?

La Search Console propose l'outil d'inspection d'URL qui montre une capture du rendu final. Mais attention : cet outil force un rendu immédiat, il ne reflète pas le délai réel que subit une page en production.

Le test le plus fiable ? Compare le HTML source brut (Ctrl+U dans Chrome) avec le DOM inspecté (F12). Si le contenu critique n'apparaît que dans le second, tu es en zone de risque. Google le verra, oui — mais quand ?

• Phase 1 d'indexation : HTML statique analysé immédiatement, sans exécution JavaScript
• Phase 2 d'indexation : rendu JavaScript différé, délai variable de quelques heures à plusieurs semaines
• Crawl budget limité : les sites à faible autorité ou au contenu massif attendent plus longtemps leur tour de rendu
• Contenu critique : tout élément SEO essentiel (titres, textes, liens) doit idéalement être présent dès la phase 1
• Outils de vérification : Search Console (inspection d'URL), comparaison HTML source vs DOM inspecté, logs serveur pour identifier les crawls Googlebot

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

Oui, et c'est même un euphémisme diplomatique. Quand Martin Splitt dit "ce qui peut prendre du temps", on parle parfois de 10-15 jours sur des sites à crawl budget limité. J'ai vu des cas où des pages JavaScript-heavy restaient partiellement indexées pendant trois semaines après publication.

Les tests terrain montrent que Google priorise le rendu JavaScript selon l'autorité du domaine et la fraîcheur historique du contenu. Un site d'actualité établi aura un rendu plus rapide qu'un blog corporate lambda. Google ne le dit jamais explicitement, mais les données de logs sont claires là-dessus.

Quelles nuances faut-il apporter à cette vision en deux phases ?

Google ne rend pas systématiquement tout le JavaScript. Si une ressource met trop de temps à charger, si un script fait une boucle infinie, ou si le budget temps de rendu (quelques secondes) est dépassé, Google indexe ce qu'il a réussi à construire et passe à autre chose.

Autre point rarement mentionné : les API calls asynchrones. Si ton contenu arrive via fetch() après le load event, Google peut ne jamais le voir, même en phase 2. Il n'attend pas indéfiniment que toutes les promesses se résolvent. [À vérifier] : Google n'a jamais publié le timeout exact appliqué au rendu, mais les tests suggèrent entre 5 et 10 secondes max.

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

Si tu fais du Server-Side Rendering (SSR) ou du Static Site Generation (SSG), cette problématique disparaît quasi totalement. Le HTML envoyé au premier hit contient déjà le contenu complet — Google n'a pas besoin d'attendre une seconde vague.

De même, les frameworks modernes (Next.js, Nuxt, SvelteKit) avec hydratation progressive envoient du HTML pré-rendu. Le JavaScript n'enrichit que l'interactivité, pas le contenu indexable. Dans ces architectures, la déclaration de Google devient moins critique — tu bénéficies d'une indexation quasi immédiate.

Que faut-il faire concrètement pour minimiser l'impact de ce délai ?

Première action : auditer le HTML source de tes pages stratégiques. Ouvre le code source brut (view-source: dans l'URL) et vérifie que les éléments critiques — title, meta description, H1, premiers paragraphes, liens internes prioritaires — sont présents avant l'exécution de tout JavaScript.

Si ces éléments n'apparaissent qu'après rendu, tu as deux options. Soit tu migres vers du SSR ou du pré-rendu (solution propre mais lourde), soit tu implémente un rendu dynamique côté serveur qui détecte Googlebot et lui sert du HTML complet (solution pragmatique mais double maintenance).

Quelles erreurs éviter absolument avec du contenu JavaScript ?

L'erreur classique : charger le contenu principal via une API externe sans fallback HTML. Si l'API est lente ou timeout pendant le rendu Google, ton contenu n'est jamais indexé. Toujours prévoir un squelette HTML avec au minimum un contenu textuel de secours.

Autre piège : les lazy-loading agressifs qui cachent du contenu sous des conditions d'intersection observer. Google scrolle rarement au-delà du viewport initial lors du rendu. Si ton contenu est en dessous de la ligne de flottaison et qu'il nécessite du scroll pour se charger, il peut rester invisible.

Comment vérifier que ton site est correctement crawlé et indexé ?

Mets en place un monitoring des logs serveur filtré sur Googlebot. Compare les hits du crawler classique (phase 1) avec ceux du renderer (user-agent contenant "Chrome" et venant des IPs Google). Un écart de plusieurs jours entre les deux signale un problème de priorisation.

Utilise aussi la Search Console pour traquer les pages "Crawlées, actuellement non indexées". Si ce statut persiste au-delà de deux semaines sur des pages stratégiques, c'est souvent un symptôme de rendu JavaScript problématique. Google a vu la page en phase 1, mais n'arrive pas à la rendre en phase 2 — ou alors le rendu ne produit pas assez de contenu unique pour justifier l'indexation.

• Vérifier que le contenu critique (H1, texte principal, liens) est présent dans le HTML source avant exécution JavaScript
• Implémenter du Server-Side Rendering (SSR) ou du pré-rendu statique pour les pages stratégiques
• Tester le rendu avec l'outil d'inspection d'URL de la Search Console régulièrement
• Monitorer les logs serveur pour identifier l'écart temporel entre crawl et rendu
• Éviter les lazy-loading qui bloquent le contenu hors du viewport initial
• Prévoir des fallbacks HTML pour tout contenu chargé par API externe