Que se passe-t-il quand votre HTML initial diffère du HTML rendu par JavaScript ?

Qu'est-ce qu'un "comportement indéfini" pour un moteur de recherche ?

L'expression "comportement indéfini" vient de la terminologie informatique : elle désigne une situation où le résultat d'un processus n'est pas garanti, documenté ni stable. Dans le contexte du crawl et de l'indexation, cela signifie que Google ne s'engage sur aucune règle précise quant au choix qu'il fera entre deux valeurs contradictoires.

Concrètement, si votre HTML brut (celui que voit Googlebot avant l'exécution JS) indique une balise canonical vers la page A, mais qu'après rendu JavaScript la balise pointe vers la page B, Google pourrait prendre A, B, ou alterner d'un crawl à l'autre. C'est un risque d'instabilité majeur qui peut conduire à une désindexation partielle ou à des signaux contradictoires envoyés à l'algorithme.

Pourquoi cette incohérence HTML initial / rendu pose-t-elle un problème structurel ?

Google utilise un processus de rendu en deux temps : un premier passage lit le HTML brut, puis un second passage — souvent différé de plusieurs jours — exécute le JavaScript et analyse le DOM final. Si ces deux couches divergent sur des balises critiques (canonical, robots meta, hreflang, title), le moteur se retrouve avec deux jeux d'instructions contradictoires.

Le problème n'est pas seulement théorique. On observe régulièrement des cas où une page est indexée puis désindexée, où le title oscille entre deux versions, ou où une canonical est ignorée de façon intermittente. Ces incohérences créent du bruit dans les signaux envoyés à l'algorithme et peuvent dégrader le classement sans que le SEO identifie clairement la cause.

Quelles balises sont particulièrement sensibles à cette problématique ?

Martin Splitt cite explicitement canonical, noindex et title, mais la logique s'applique à toute balise qui influence l'indexation ou le classement. Les balises robots meta (noindex, nofollow), les hreflang, les redirects côté client (meta refresh, JavaScript redirect) et même les structured data peuvent être concernés.

En pratique, chaque fois qu'une valeur critique est injectée ou modifiée par JavaScript, il faut vérifier si elle diffère du HTML initial. Et si c'est le cas, privilégier systématiquement le HTML initial pour éviter toute ambiguïté.

• HTML initial et HTML rendu doivent être strictement cohérents sur canonical, noindex, title, hreflang
• Google ne garantit aucune règle de priorité en cas d'incohérence — le choix est aléatoire et variable
• Les frameworks JS (React, Vue, Angular) sont particulièrement exposés si le SSR ou le prerendering est mal configuré
• Tester avec Google Search Console (outil d'inspection d'URL) et comparer HTML brut vs rendu est indispensable

Cette déclaration reflète-t-elle vraiment le comportement observé sur le terrain ?

Oui, et c'est justement ce qui en fait une alerte critique. Depuis des années, on observe des fluctuations inexpliquées sur des sites SPA ou hybrides : pages indexées puis désindexées, titles qui changent d'un crawl à l'autre, canonicals ignorées de façon intermittente. La formulation "comportement indéfini" confirme officiellement ce que les praticiens constataient de manière empirique.

Cependant, Google reste flou sur un point essentiel : existe-t-il une logique de priorité implicite ? Par exemple, si le HTML initial dit "noindex" et le rendu "index", Google penche-t-il systématiquement vers la version la plus restrictive ? [A vérifier] — aucune documentation officielle ne le confirme, et les retours terrain sont contradictoires.

Quels cas concrets illustrent ce risque d'incohérence ?

Le cas le plus fréquent concerne les frameworks JavaScript côté client où le title, la meta description ou la canonical sont injectés après le premier paint. Si le HTML initial contient un title générique ou une canonical par défaut, et que JavaScript les modifie, Google peut indexer la version initiale malgré le rendu final.

Autre scénario : les A/B tests côté client qui modifient le contenu après chargement. Si une balise canonical ou un robots meta est ajouté ou modifié par le test, Google peut le détecter lors du rendu et ignorer l'instruction initiale — ou l'inverse, selon la phase du crawl. C'est cette imprévisibilité qui rend la situation dangereuse.

Y a-t-il des exceptions où cette règle peut être relativisée ?

Sur des éléments purement cosmétiques — par exemple un span injecté par JS sans impact SEO — l'incohérence n'a évidemment aucune conséquence. Mais dès qu'on touche à toute balise lue par Googlebot (head, meta, link, structured data), la règle s'applique sans exception.

Certains SEO pensent que le rendu final "l'emporte toujours" sur le HTML initial. C'est faux. Google a confirmé à plusieurs reprises que le processus de rendu est asynchrone, différé et non garanti. Si le rendu échoue ou est retardé, c'est le HTML initial qui fait foi. D'où l'importance de ne jamais compter sur JavaScript seul pour des instructions critiques.

Que faut-il vérifier en priorité sur vos pages ?

Premier réflexe : comparer systématiquement HTML brut et HTML rendu pour chaque template critique. Utilisez l'outil d'inspection d'URL de Google Search Console, qui affiche côte à côte le HTML tel que crawlé et le HTML tel que rendu. Toute divergence sur canonical, noindex, title, hreflang doit être corrigée avant déploiement.

Ensuite, automatisez cette vérification dans votre pipeline CI/CD ou vos audits SEO. Des outils comme Puppeteer ou Screaming Frog (mode JavaScript) permettent de détecter ces incohérences en masse. L'objectif : ne jamais laisser passer en production une page où JavaScript modifie une balise critique absente ou différente dans le HTML initial.

Comment corriger une incohérence déjà en production ?

La solution la plus robuste : Server-Side Rendering (SSR) ou Static Site Generation (SSG). Dans les deux cas, le HTML initial contient déjà les bonnes valeurs, et JavaScript n'a plus besoin de les injecter. Si SSR/SSG n'est pas envisageable, le prerendering côté serveur (via Rendertron, Prerender.io ou équivalent) reste une alternative viable.

Si vous restez en full client-side rendering, assurez-vous que les balises critiques sont présentes dans le HTML initial — même si leur contenu est générique — puis mises à jour par JavaScript sans divergence de valeur. Par exemple, si le title initial est "Page par défaut" et que JS le change en "Titre optimisé", Google peut indexer "Page par défaut". Mieux vaut un title correct dès le HTML brut.

Quelles erreurs éviter absolument ?

Ne jamais injecter une balise canonical, noindex ou hreflang uniquement via JavaScript. C'est la garantie d'un comportement imprévisible. De même, éviter de modifier le title après chargement si le HTML initial contient un title différent — Google pourrait ne jamais voir la version finale.

Autre erreur fréquente : compter sur le rendu pour "corriger" un problème présent dans le HTML initial. Par exemple, ajouter un noindex via JS pour bloquer l'indexation d'une page qui n'a pas de robots meta initial. Google peut ignorer cette instruction si le rendu est retardé ou échoue. Toujours privilégier le HTML initial pour les directives critiques.

• Comparer HTML brut et HTML rendu via Google Search Console (outil d'inspection d'URL)
• Vérifier que canonical, noindex, title, hreflang sont identiques dans les deux versions
• Privilégier SSR, SSG ou prerendering pour éliminer toute divergence
• Automatiser la détection d'incohérences dans vos audits SEO ou pipelines CI/CD
• Ne jamais injecter de balises critiques uniquement via JavaScript
• Tester chaque template après modification pour confirmer la cohérence HTML initial / rendu