Pourquoi Google peut-il fusionner vos pages JS si les balises meta sont identiques ?

Que signifie exactement « version non rendue » d'une page JavaScript ?

Quand Googlebot crawle une page, il récupère d'abord le HTML brut renvoyé par le serveur. C'est la version non rendue. Si votre site s'appuie sur JavaScript pour générer le contenu principal ou les balises meta, ces éléments n'existent pas encore à ce stade.

Google va ensuite tenter de rendre la page — c'est-à-dire exécuter le JavaScript pour voir le contenu final. Mais ce processus de rendu prend du temps, consomme des ressources, et n'est pas systématiquement fait immédiatement. Parfois, l'indexation se base temporairement ou définitivement sur le HTML initial.

Pourquoi des balises meta identiques provoquent-elles une fusion de pages ?

Google utilise les balises meta (title, description, canonical, robots, etc.) comme signaux pour comprendre le contenu et l'unicité d'une page. Si deux URL retournent exactement les mêmes balises meta dans le HTML initial, Google peut considérer qu'il s'agit de contenu dupliqué ou redondant.

Le moteur va alors chercher à fusionner ces pages sous une seule URL canonique. C'est un mécanisme de déduplication censé nettoyer l'index. Sauf que si vos pages sont réellement différentes mais que seul le JS les distingue, Google n'a aucun moyen de le savoir avant le rendu. Et c'est là que ça coince.

Dans quels cas l'indexation se fait-elle sans rendu complet ?

Le rendu JavaScript est coûteux pour Google. Le moteur priorise les sites selon leur crawl budget, leur popularité, et la complexité technique. Si votre site a des problèmes de vitesse, un mauvais crawl budget, ou une architecture JS trop lourde, le rendu peut être différé de plusieurs jours — voire jamais fait.

De plus, certaines pages peuvent être indexées rapidement sur la base du HTML initial, surtout si Google détecte un fort taux de fraîcheur (actualités, e-commerce). Dans ce contexte, compter uniquement sur le JS pour différencier vos pages est un pari risqué.

• Balises meta uniques dès le HTML initial : ne comptez pas sur le JS pour générer title, description, canonical
• Le rendu n'est pas instantané : Google peut indexer avant d'avoir exécuté le JavaScript
• Fusion incorrecte : deux URL avec meta identiques risquent d'être traitées comme doublons même si le contenu rendu diffère
• Crawl budget limité : les sites JS consomment plus de ressources, ce qui peut ralentir ou bloquer le rendu
• SSR ou pré-rendu recommandé : pour garantir que Google voit le bon contenu dès le premier crawl

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

Absolument. On observe régulièrement des cas où Google indexe le HTML brut avant de rendre le JavaScript, surtout sur les sites à fort volume de pages ou les applications SPA (Single Page Application). Martin Splitt confirme ici un phénomène bien documenté : l'indexation peut se faire en deux temps, avec un premier passage basé uniquement sur le HTML initial.

Ce qui est intéressant, c'est que Google admet explicitement que ce décalage peut provoquer une fusion incorrecte. Cela valide les recommandations historiques des SEO expérimentés : ne jamais compter uniquement sur le JS pour différencier des pages, surtout pour les balises meta critiques.

Quelles nuances faut-il apporter à cette déclaration ?

Google ne précise pas ici quels critères déclenchent le rendu immédiat versus différé. On sait que le crawl budget, la popularité des URL, et la vitesse de chargement jouent un rôle, mais les seuils exacts restent opaques. [À vérifier] : Google ne dit pas non plus combien de temps peut s'écouler entre le crawl initial et le rendu complet — certains tests montrent des délais de plusieurs semaines sur des sites peu prioritaires.

Autre point : la déclaration parle de « fusion incorrecte », mais ne dit rien sur la réversibilité de ce processus. Si Google fusionne deux pages par erreur, combien de temps faut-il pour corriger après avoir ajouté des balises meta uniques ? Les observations terrain montrent que cela peut prendre des semaines, voire nécessiter une demande de réindexation forcée.

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

Si vous faites du Server-Side Rendering (SSR) ou du pré-rendu statique, le problème disparaît en grande partie. Le HTML initial contient déjà le contenu et les balises meta finaux, donc Google n'a pas besoin d'exécuter le JavaScript pour comprendre la page. C'est la solution recommandée pour les sites à fort enjeu SEO.

De même, si vos pages sont très peu nombreuses et que votre crawl budget est généreux, Google aura probablement le temps de rendre chaque page correctement. Mais c'est un pari risqué : mieux vaut sécuriser dès le départ avec des balises meta uniques dans le HTML initial.

Que faut-il faire concrètement pour éviter ce problème ?

La solution la plus robuste est d'implémenter du Server-Side Rendering (SSR) ou du Static Site Generation (SSG). Cela garantit que le HTML initial contient déjà les balises meta uniques et le contenu complet, sans dépendre du JavaScript côté client. Des frameworks comme Next.js (React), Nuxt.js (Vue) ou Angular Universal facilitent cette transition.

Si le SSR n'est pas envisageable à court terme, optez pour du pré-rendu dynamique : un service comme Prerender.io ou Rendertron détecte les bots et leur sert une version HTML pré-rendue. C'est une solution intermédiaire efficace, mais vérifiez que cela ne soit pas perçu comme du cloaking — le contenu servi aux bots doit être strictement identique à celui vu par les utilisateurs.

Quelles erreurs éviter absolument ?

Ne générez jamais les balises title, meta description, ou canonical uniquement via JavaScript côté client. C'est l'erreur classique des SPA : le HTML initial contient un title générique (« Mon App ») et le vrai title n'apparaît qu'après exécution du JS. Google peut indexer avec le title générique, voire fusionner toutes vos pages sous la même URL si elles partagent ces balises identiques.

Autre erreur fréquente : supposer que Google rendra votre JS rapidement. Les tests montrent que sur des sites peu prioritaires, le rendu peut être différé de plusieurs jours. Si vous lancez une nouvelle section du site, elle peut rester invisible dans les SERP pendant ce délai. Validez systématiquement que le HTML brut contient les signaux critiques.

Comment vérifier que mon site est conforme ?

Utilisez l'outil Inspect URL de la Search Console et comparez l'onglet « HTML » (version brute) avec l'onglet « Rendered » (version après JS). Si vous voyez des différences majeures dans les balises meta ou le contenu principal, c'est un signal d'alerte. Idéalement, les deux versions doivent être quasi identiques.

Testez également avec curl en ligne de commande pour récupérer le HTML brut de vos pages critiques. Si deux URL retournent le même title ou la même meta description, vous avez un problème. Enfin, surveillez les rapports de couverture d'index : des pages exclues pour « Doublon, utilisateur n'a pas sélectionné de page canonique » peuvent indiquer une fusion incorrecte due à des meta identiques.

• Implémenter SSR ou SSG sur les pages stratégiques (catégories, fiches produits, articles)
• Vérifier que title, meta description et canonical sont uniques dans le HTML initial
• Utiliser l'outil Inspect URL de la Search Console pour comparer HTML brut et rendu
• Tester avec curl ou un scraper simple pour valider le HTML côté serveur
• Auditer régulièrement les rapports de couverture pour détecter les fusions incorrectes
• Éviter les title ou meta génériques générés uniquement côté client