Faut-il abandonner le modèle des deux vagues d'indexation ?

D'où vient cette histoire de deux vagues ?

La métaphore des deux vagues d'indexation a circulé pendant des années dans la communauté SEO. L'idée ? Google crawlerait d'abord le HTML brut (vague 1), puis reviendrait plus tard — parfois plusieurs jours après — pour exécuter le JavaScript et indexer le contenu dynamique (vague 2).

Ce modèle mental simplifiait la manière dont Googlebot traite les sites modernes. Il rassurait aussi certains praticiens qui voyaient leurs pages en JS lourd indexées avec retard. Sauf que ce schéma a toujours été une approximation grossière, jamais une description technique fidèle du pipeline réel.

Que se passe-t-il réellement lors de l'indexation ?

Martin Splitt tranche : le processus est crawl-render-index dans la quasi-totalité des cas. Concrètement, Googlebot récupère la page, exécute le JavaScript dans la foulée, puis indexe le contenu rendu. Pas de file d'attente mystérieuse, pas de second passage systématique des semaines plus tard.

Cela ne signifie pas que chaque page est rendue instantanément — le crawl budget et les priorités algorithmiques jouent toujours. Mais la séparation en deux vagues distinctes et prévisibles ? C'était du storytelling, pas de l'ingénierie.

Pourquoi Google utilisait-il cette métaphore ?

Parce qu'expliquer les subtilités du rendering pipeline à un public non technique tourne vite au cauchemar. La métaphore des deux vagues permettait de faire passer un message clé : « Votre JS peut retarder l'indexation, optimisez-le. »

Le problème ? Elle a créé une fausse certitude. Certains SEO ont construit des stratégies entières autour de cette prétendue seconde vague, surveillant des délais fictifs et s'inventant des corrélations. Résultat : beaucoup de bruit, peu de signal.

• Le processus crawl-render-index est unifié dans la majorité des scénarios
• Il n'existe pas de file d'attente « vague 2 » prévisible et systématique
• Les délais d'indexation dépendent du crawl budget, de la qualité du contenu et de la charge serveur, pas d'une architecture en deux temps
• La métaphore était un outil pédagogique, jamais un modèle opérationnel

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

Oui et non. Sur des sites bien optimisés avec un crawl budget généreux, on constate effectivement que le contenu JS est indexé rapidement, en une seule passe. Les logs confirment : Googlebot ne revient pas systématiquement des jours plus tard pour « finir le boulot ».

Mais sur des sites massifs, avec des milliers de pages JS et un budget limité, on observe encore des décalages. Certaines pages restent en HTML brut pendant plusieurs semaines avant d'être pleinement rendues. Est-ce une « vague 2 » ? Non. C'est juste que Google priorise et ne rend pas tout immédiatement. Nuance importante. [A vérifier] sur chaque projet en fonction de son profil technique.

Pourquoi cette clarification maintenant ?

Parce que la métaphore a généré trop d'idées fausses. Des SEO attendaient passivement une seconde vague qui n'allait jamais venir. D'autres sur-optimisaient pour accélérer un processus qui n'existait pas tel qu'ils l'imaginaient.

Google préfère désormais marteler le message simple : optimisez votre rendering dès le départ. Pas de hack, pas de stratégie d'attente. Si votre contenu critique est en JS, assurez-vous qu'il soit rapide à exécuter, sinon vous perdrez du crawl budget — point final.

Quelles zones grises subsistent ?

Martin Splitt dit « quasi-totalité des cas ». Quelles sont les exceptions ? Aucune liste exhaustive n'a été fournie. On sait que certaines pages à très faible priorité peuvent être repoussées indéfiniment dans la queue de rendering. Mais est-ce 1 % des cas ? 5 % ? 15 % sur un site mal ficelé ?

Autre point flou : la manière dont Google gère les mises à jour de contenu dynamique après le premier rendering. Si une page change côté client après le crawl initial, y a-t-il un re-render automatique ou faut-il forcer un nouveau crawl ? [A vérifier] — les docs officielles restent évasives sur ce scénario.

Que faut-il faire concrètement sur un site JS-heavy ?

Arrêtez d'attendre une hypothétique seconde vague. Votre contenu critique doit être accessible dès le premier rendering. Cela passe par du server-side rendering (SSR), du pré-rendering ou, à minima, un JS optimisé qui charge vite et proprement.

Testez systématiquement avec la Search Console (outil d'inspection d'URL) et vérifiez que le contenu rendu correspond à vos attentes. Si des éléments manquent dans la version rendue, Google ne les verra pas — ou alors bien plus tard, avec un impact négatif sur le ranking.

Quelles erreurs éviter après cette clarification ?

Ne pas tomber dans l'excès inverse. Certains vont conclure « Google rend tout instantanément, je peux faire n'importe quoi en JS ». Faux. Le crawl budget reste limité, et un rendering coûteux ralentit l'indexation de l'ensemble du site.

Autre piège : croire que cette déclaration invalide toute stratégie de progressive enhancement. Non. Servir un HTML de base avec du contenu textuel reste une bonne pratique, même si Google rend le JS. Cela améliore la résilience, la vitesse et l'accessibilité — des signaux que Google valorise indirectement.

Comment vérifier que mon site est aligné avec ce modèle crawl-render-index ?

Analysez vos logs serveur pour repérer les patterns de crawl. Si Googlebot revient fréquemment sur les mêmes URLs sans changement de contenu, c'est peut-être un signe que le rendering pose problème. Croisez avec les données de la Search Console : un écart entre « pages explorées » et « pages indexées » peut indiquer un souci de rendering.

Utilisez des outils comme Screaming Frog en mode JavaScript ou des tests via Puppeteer pour simuler le comportement de Googlebot. Si votre outil de crawl met 10 secondes à rendre une page, Google aura le même problème — et il ne patientera pas indéfiniment.

• Implémenter du SSR ou du pré-rendering pour le contenu critique
• Tester chaque template clé avec l'outil d'inspection d'URL de la Search Console
• Analyser les logs pour détecter des anomalies de crawl/rendering
• Optimiser le poids et la vitesse d'exécution du JavaScript (code splitting, lazy loading intelligent)
• Ne jamais bloquer le contenu stratégique derrière des interactions utilisateur (clics, scroll infini non fallback)
• Monitorer l'écart entre pages crawlées et pages indexées dans la Search Console