Pourquoi le HTML initial est-il devenu l'arbitre de votre indexation Google ?

Qu'est-ce que cette histoire de « deux vagues » d'indexation ?

Googlebot crawle votre page et récupère le HTML initial — celui qui arrive tel quel depuis le serveur. À ce stade, rien n'est exécuté : pas de JavaScript, pas de frameworks front, pas de fetch API. Cette première vague constitue l'ossature de l'indexation.

La seconde vague arrive plus tard — parfois des heures, parfois des jours — et exécute le JavaScript pour compléter le rendu. Mais voilà : si votre contenu critique (titres, méta, maillage interne, paragraphes) n'est disponible qu'après cette seconde passe, vous avez déjà perdu un temps précieux. Et c'est là que ça coince.

Pourquoi cette stratégie pose-t-elle problème sur les gros sites ?

Un site de 10 000 pages qui dépend du JavaScript pour afficher ses URL produits ou ses liens de navigation interne crée un goulot d'étranglement. Googlebot ne peut pas tout re-crawler en mode rendu JS : c'est trop coûteux en ressources.

Résultat : certaines pages ne passent jamais la seconde vague, ou y passent avec un tel retard que les mises à jour fréquentes ne sont jamais prises en compte. Votre site devient un fantôme pour Google — techniquement crawlé, mais indexé de manière lacunaire.

Est-ce que le rendu côté serveur règle vraiment tout ?

Le SSR (Server-Side Rendering) ou le pré-rendu statique deviennent des mécanismes de survie dans cet écosystème. Ils garantissent que le HTML initial contient déjà le contenu critique, sans attendre que le navigateur exécute du code.

Mais attention : un SSR mal configuré peut encore renvoyer un squelette vide au bot, surtout si vous servez des versions différentes selon le user-agent. Google ne triche pas : il analyse ce qui arrive dans la requête HTTP initiale, point.

• HTML initial = première impression : tout ce qui n'y figure pas est considéré comme secondaire par Googlebot lors de la première vague.
• Crawl budget limité : sur un gros site, la seconde vague peut ne jamais arriver sur certaines pages ou arriver trop tard.
• Mise à jour fréquente = risque accru : si vos contenus changent vite (e-commerce, actualités), l'écart entre les deux vagues devient un handicap majeur.
• SSR/SSG obligatoire : pour garantir que le contenu critique est présent dès la première passe, le rendu côté serveur devient incontournable.
• Pas de magie JS : un site SPA (Single Page Application) pur, sans fallback HTML, prend un risque énorme sur l'indexation complète.

Cette déclaration est-elle cohérente avec ce qu'on observe sur le terrain ?

Oui, et c'est même un constat brutal pour quiconque a migré un site vers une stack full-JS sans SSR. On voit régulièrement des chutes d'indexation massives après des migrations React ou Vue mal gérées — des pages qui disparaissent de l'index simplement parce que leur contenu n'arrive plus dans le HTML initial.

Ce qui est intéressant, c'est que Google ne fait pas mystère de ce fonctionnement depuis des années, mais beaucoup de développeurs et même de SEO continuent de traiter le rendu JS comme un détail technique. Splitt remet les points sur les i : ce n'est pas un détail, c'est le cœur du problème.

Quelles nuances faut-il apporter à cette affirmation ?

Le terme « deux vagues » est une simplification pédagogique. En réalité, Googlebot gère un pipeline complexe où certaines pages sont re-crawlées en mode rendu JS quasi immédiatement, d'autres jamais. La priorité dépend du crawl budget, de la fraîcheur du contenu, de la popularité de la page.

Deuxième point : l'« absence de rendu initial » ne signifie pas forcément blackout total. Mais elle entraîne un retard d'indexation, une perte de contexte (liens internes non découverts lors de la première passe), et un risque accru que les mises à jour ne soient pas prises en compte. [A vérifier] : Google ne publie pas de statistiques précises sur le pourcentage de pages qui passent effectivement la seconde vague sur un gros site.

Dans quels cas cette règle peut-elle être contournée ?

Sur un petit site statique (moins de 500 pages, peu de mises à jour), l'impact est négligeable. Googlebot a les moyens de tout re-crawler en mode rendu complet. Mais dès qu'on parle d'un catalogue produit, d'un blog à forte fréquence de publication ou d'un annuaire, le problème devient structurel.

Certains ont tenté de contourner via le dynamic rendering (servir du HTML pré-rendu uniquement aux bots). Google tolère cette approche… mais la déconseille officiellement. Et c'est là que le discours de Splitt prend tout son sens : plutôt que de bidouiller des solutions de contournement, mieux vaut concevoir son architecture pour que le HTML initial soit riche dès le départ.

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

Première étape : auditer le HTML initial. Désactive JavaScript dans ton navigateur (ou utilise un outil comme curl) et vérifie ce qui reste. Si tes titres H1, tes paragraphes, tes liens internes disparaissent… tu as un problème.

Ensuite, mets en place du SSR (Server-Side Rendering) ou du SSG (Static Site Generation) selon ton stack. Next.js, Nuxt, Gatsby, Eleventy — peu importe l'outil, l'objectif est le même : envoyer du contenu complet dès la première requête HTTP. Si tu es sur WordPress avec un thème classique, tu es probablement déjà bon. Si tu es sur un headless CMS avec un front React, c'est là que ça se complique.

Quelles erreurs éviter absolument ?

Ne te contente pas de vérifier la homepage. Les pages profondes — fiches produits, articles de blog, pages catégories — sont celles qui souffrent le plus du déficit de crawl budget. C'est là que la seconde vague n'arrive jamais.

Autre piège classique : activer un SSR mais oublier de configurer correctement le caching côté serveur. Résultat : chaque requête Googlebot génère un rendu complet, tes serveurs s'effondrent, et tu désactives le SSR en panique. Configure un cache intelligent (Varnish, Cloudflare, Redis) pour servir du HTML pré-rendu sans tuer ton infra.

Comment vérifier que ton site est conforme à cette exigence ?

Utilise Google Search Console et inspecte une URL représentative. Compare le « HTML récupéré » avec le « HTML rendu ». Si les deux sont identiques (ou quasi), tu es tranquille. Si le rendu ajoute 80% du contenu… tu as un souci.

Lance aussi un crawl avec Screaming Frog en mode « rendu JavaScript désactivé ». Compte le nombre de pages avec contenu vide, liens manquants, balises title absentes. C'est un indicateur brutal mais fiable de ton exposition au risque d'indexation lacunaire.

• Auditer le HTML initial sur un échantillon représentatif de pages (homepage, catégories, produits, articles)
• Implémenter du SSR ou SSG si le contenu critique dépend actuellement du JavaScript
• Vérifier la cohérence entre HTML récupéré et HTML rendu dans Google Search Console
• Configurer un cache côté serveur pour éviter la surcharge liée au rendu dynamique
• Crawler le site avec JavaScript désactivé pour mesurer l'ampleur du problème
• Prioriser les pages à forte valeur SEO (top landing pages, pages génératrices de conversions)