Google détecte-t-il vraiment le duplicate content après le rendu JavaScript ?

Qu'est-ce qu'un hash de contenu et pourquoi Google l'utilise-t-il deux fois ?

Un hash de contenu est une empreinte numérique unique générée à partir du HTML d'une page. Google utilise cette technique pour identifier rapidement les pages identiques ou quasi-identiques sans devoir comparer ligne par ligne des millions de documents.

La révélation de Martin Splitt précise que Google génère un premier hash sur le HTML brut — celui que le serveur envoie directement — puis un second hash après exécution du JavaScript. Cette double passe permet de détecter les duplications qui n'apparaîtraient qu'après le rendu côté client, un scénario fréquent avec les frameworks modernes comme React, Vue ou Angular.

Pourquoi cette distinction entre HTML initial et rendu change-t-elle la donne ?

Pendant des années, l'industrie SEO a débattu du moment exact où Google détecte les duplications : avant ou après le rendu JavaScript ? Cette déclaration tranche : la décision finale se base sur le HTML rendu, pas sur l'initial.

Concrètement, si deux pages affichent un HTML initial différent mais produisent un contenu identique après exécution du JS, Google les considérera comme duplicates potentiels. À l'inverse, deux pages avec un shell HTML identique mais du contenu JavaScript distinct seront traitées comme uniques.

Dans quels cas cette mécanique devient-elle critique ?

Les sites en Single Page Application (SPA) sont les premiers concernés. Leur HTML initial est souvent squelettique — un simple conteneur générique — tandis que le contenu réel s'injecte via JavaScript. Sans le rendu, toutes les pages d'un SPA auraient un hash quasi-identique.

Les sites e-commerce avec des filtres côté client sont également exposés. Si le HTML initial est le même pour toutes les combinaisons de filtres, mais que le JS génère des listings produits différents, Google doit attendre le rendu pour discriminer ces variantes.

• Hash sur HTML initial : première passe rapide, détection grossière des duplications évidentes
• Hash sur HTML rendu : décision finale, prise en compte du contenu généré par JavaScript
• Canonicalisation : basée sur le contenu rendu, pas sur le HTML brut reçu du serveur
• Implication pour les SPA : le shell générique ne suffit pas à différencier les pages, le JS devient décisif
• Budget de rendu : cette double détection consomme du temps et des ressources, surtout sur les gros sites

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

Oui, elle confirme ce que plusieurs tests empiriques suggéraient depuis l'essor des SPA. Des cas documentés montraient que Google indexait du contenu inexistant dans le HTML source mais présent après rendu — preuve qu'il exécutait le JavaScript avant de finaliser la canonicalisation.

Cependant, un point reste flou : quel délai entre les deux hash ? Martin Splitt ne précise pas si le rendu intervient immédiatement ou si Google peut laisser passer plusieurs jours entre le crawl du HTML initial et son exécution JavaScript. Sur les sites à fort volume, ce délai peut créer des situations transitoires où Google traite temporairement des pages comme duplicates avant de les différencier post-rendu. [À vérifier]

Quelles nuances faut-il apporter à cette affirmation ?

Google ne garantit pas que toutes les pages passeront par le rendu JavaScript. Le budget alloué à l'exécution JS reste limité, surtout pour les sites peu autoritaires ou mal structurés. Si Google décide qu'une page est duplicate sur la base du HTML initial, il peut choisir de ne jamais la rendre — économisant ainsi des ressources.

Autre nuance : la vitesse de rendu influence la décision. Une page qui met 10 secondes à charger son contenu via JS risque que Google abandonne avant la fin, capturant un état incomplet. Le hash généré ne refléterait alors pas le contenu final, biaisant la détection de duplication.

Dans quels cas cette règle pourrait-elle ne pas s'appliquer pleinement ?

Les pages orphelines — sans liens internes ni externes — ont peu de chances de bénéficier d'un rendu JavaScript si Google les découvre uniquement via le sitemap. Le moteur peut appliquer un hash sur HTML initial sans aller plus loin, faute de signaux de qualité suffisants.

Les sites avec des erreurs JavaScript critiques subissent le même traitement. Si l'exécution du JS échoue, Google se rabat sur le HTML initial. Dans ce scénario, deux pages avec le même shell HTML mais du JS différent seraient considérées comme duplicates, même si le rendu aurait dû les différencier.

Que faut-il auditer en priorité sur un site JavaScript ?

Commence par comparer le HTML source et le DOM rendu sur un échantillon représentatif de pages. Utilise les DevTools de Chrome (Ctrl+U pour le source, Inspect pour le DOM rendu). Si le contenu principal diffère massivement, tu dépends entièrement du rendu JavaScript pour échapper aux duplications.

Vérifie ensuite que les balises canoniques sont présentes dès le HTML initial. Google lit ces balises avant le rendu, ce qui influence la priorisation du crawl. Une canonical absente du HTML brut mais injectée en JS arrive trop tard pour certaines décisions de budget.

Comment s'assurer que Google rend effectivement mes pages JS ?

Utilise l'outil d'inspection d'URL de la Search Console. Il affiche le HTML rendu tel que Googlebot le voit. Compare-le avec ton HTML source : si les différences attendues apparaissent, le rendu fonctionne. Sinon, tu as un problème d'exécution JavaScript.

Surveille les logs serveur pour repérer les appels de Googlebot vers tes APIs ou ressources JavaScript. Un site SPA sans requêtes API dans les logs indique que Google ne rend pas le contenu — il se contente du shell initial. Cela signale soit un budget de rendu insuffisant, soit des erreurs bloquantes.

Quelles erreurs techniques amplifient le risque de duplicate content ?

Le contenu généré avec un délai pose problème. Si ton JavaScript attend 3 secondes avant d'injecter le contenu principal, Google peut capturer un état intermédiaire vide ou incomplet. Le hash résultant sera identique pour plusieurs pages, créant de faux duplicates.

Les requêtes asynchrones non gérées aggravent le problème. Si Google rend ta page avant que tes appels fetch() ne reviennent, il hash un DOM incomplet. Implémente un mécanisme signalant à Google que le contenu est prêt — par exemple, un événement personnalisé ou un indicateur DOM.

• Auditer la différence entre HTML source et DOM rendu sur 50-100 URLs clés
• Placer les balises canonical dans le HTML initial, pas uniquement en JavaScript
• Tester l'inspection d'URL Search Console pour confirmer le rendu effectif
• Analyser les logs serveur pour détecter les appels Googlebot vers les ressources JS/API
• Éliminer les délais d'injection de contenu supérieurs à 2 secondes
• Implémenter un indicateur DOM signalant la fin du chargement asynchrone