HTML initial vs HTML rendu : pourquoi Google peut-il ignorer vos balises critiques ?

Que signifie exactement « HTML initial » versus « HTML rendu » ?

L'HTML initial correspond au code source que le serveur envoie au navigateur — celui que vous voyez dans « Afficher le code source ». C'est le premier état du document, avant toute exécution JavaScript.

L'HTML rendu est l'état final du DOM après que tous vos scripts aient modifié la page. Si React, Vue ou n'importe quel framework injecte des balises canonical, noindex ou title côté client, c'est cet état « rendu » que Googlebot analyse en second temps, après le crawl initial.

Pourquoi cette distinction pose-t-elle problème pour l'indexation ?

Googlebot crawle d'abord le HTML initial, extrait les balises critiques, puis exécute le JavaScript pour obtenir le rendu final. Si les deux versions contiennent des instructions contradictoires, le moteur n'a aucune règle documentée pour départager.

Google peut privilégier l'HTML initial un jour, le rendu le lendemain — ou même traiter différemment deux pages identiques selon la charge serveur, le budget crawl ou d'autres paramètres opaques. Cette non-détermination est le cœur du problème : vous perdez le contrôle.

Quelles balises sont concernées par cette incohérence ?

Martin Splitt cite explicitement trois balises : canonical, noindex et title. Mais l'enjeu s'étend potentiellement à toute directive d'indexation modifiée côté client.

Un canonical qui pointe vers une URL A dans le HTML initial puis vers une URL B après exécution JavaScript crée une situation indéfinie. Idem pour un noindex absent au départ puis injecté par React, ou inversement. Le moteur n'est pas tenu de respecter l'une ou l'autre version — et dans la pratique, il choisit de manière imprévisible.

• Google crawle l'HTML initial en premier, avant toute exécution JavaScript
• Le rendu JavaScript peut modifier canonical, noindex, title et créer des incohérences
• En cas de divergence, Google choisit arbitrairement — aucune règle documentée
• Les balises critiques doivent être identiques dans les deux états pour garantir le comportement attendu
• Cette règle s'applique à tous les sites utilisant du JavaScript côté client pour manipuler le DOM

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

Oui. On observe depuis des années que Google traite de manière erratique les sites qui injectent des balises critiques en JavaScript. Des pages marquées noindex côté client finissent indexées, des canonicals rendus sont ignorés au profit de la version initiale, des titles React disparaissent dans les SERPs.

Ce qui change, c'est que Google assume désormais publiquement l'absence de garantie. Auparavant, on pouvait espérer une convergence vers le rendu final — Martin Splitt nous dit explicitement que ce n'est pas le cas. Le moteur se réserve le droit de choisir. [A vérifier] : Google n'a jamais publié de stats sur la fréquence de chaque comportement, ni les critères de décision.

Quelles nuances faut-il apporter à cette règle ?

La déclaration ne précise pas si certaines balises sont plus « stables » que d'autres. On sait empiriquement que les titles côté client sont souvent ignorés, mais qu'en est-il des hreflang, des meta descriptions, des structured data ? Google reste flou.

De plus, cette règle ne s'applique pas de la même manière selon l'architecture : un site en SSR (Server-Side Rendering) ou SSG (Static Site Generation) envoie un HTML initial déjà complet, éliminant le problème à la source. Le vrai danger concerne les architectures CSR (Client-Side Rendering) pures où le HTML initial est quasi vide.

Dans quels cas cette incohérence peut-elle sembler acceptable ?

Certains praticiens tentent de « forcer » Google à indexer une version plutôt qu'une autre en jouant sur le délai de rendu. Par exemple, bloquer l'indexation dans le HTML initial puis injecter un canonical via JavaScript après détection du user-agent. C'est techniquement une incohérence — mais dans ce cas précis, on cherche à tromper le moteur.

Google ne garantit rien, mais si votre objectif est justement d'obtenir un comportement imprévisible pour des raisons tactiques (cloaking edge cases, tests), cette « faille » peut sembler utile. Évidemment, c'est jouer avec le feu — et Splitt nous dit explicitement que le comportement est « indéfini », donc non stable.

Que faut-il faire concrètement pour éviter ces incohérences ?

La règle est simple : toutes les balises critiques doivent être présentes et identiques dans le HTML initial. Si vous utilisez React, Next.js, Nuxt ou tout autre framework, configurez le rendu serveur pour que canonical, noindex et title soient déjà dans le code source avant toute exécution JavaScript.

Si vous modifiez ces balises côté client, assurez-vous que la modification est strictement identique à l'état initial — ce qui revient à dire : ne les modifiez pas. Toute divergence crée un risque d'indexation imprévisible.

Comment vérifier que mon site respecte cette règle ?

Comparez le HTML source brut (clic droit > « Afficher le code source ») et le DOM inspecté après chargement complet. Les balises canonical, noindex et title doivent être rigoureusement identiques.

Utilisez l'outil de test des URLs Google Search Console pour voir ce que Googlebot crawle et rend. Si les deux versions diffèrent dans la capture d'écran ou le code source rapporté, vous avez un problème. Un audit automatisé avec Screaming Frog ou Sitebulb peut également détecter ces divergences — mais attention, ces outils rendent parfois différemment de Googlebot.

Quelles erreurs éviter absolument ?

Ne laissez jamais un framework JavaScript injecter un canonical ou un noindex qui n'existe pas dans le HTML initial. C'est la source d'incohérence la plus fréquente : le développeur ajoute la balise côté client « pour simplifier », sans réaliser que Google peut l'ignorer.

Ne comptez pas sur le rendu JavaScript pour « corriger » une balise mal configurée côté serveur. Si le HTML initial contient un canonical erroné, ne tentez pas de le remplacer en JS — corrigez-le à la source. Enfin, évitez les A/B tests qui modifient ces balises côté client : Google verra une version au hasard, et vous n'aurez aucune garantie.

• Générer toutes les balises critiques côté serveur (SSR, SSG ou templates serveur classiques)
• Comparer systématiquement HTML source et DOM rendu avec les DevTools
• Utiliser Google Search Console pour vérifier ce que Googlebot crawle réellement
• Ne jamais modifier canonical, noindex ou title via JavaScript après le premier rendu
• Auditer régulièrement avec Screaming Frog en mode « rendu JavaScript » vs « HTML brut »
• Documenter toute modification de ces balises pour tracer les incohérences potentielles