Pourquoi Google ignore-t-il vos balises canoniques quand le HTML brut contredit le rendu ?

D'où vient cette confusion entre HTML brut et HTML rendu ?

Le HTML brut correspond au code source envoyé directement par le serveur lorsqu'un navigateur (ou Googlebot) effectue une requête HTTP. C'est ce que tu vois si tu affiches le source d'une page via « Afficher le code source » dans Chrome.

Le HTML rendu correspond à l'état du DOM après exécution du JavaScript côté client. Si ton framework (React, Vue, Angular, Next.js en mode CSR partiel) injecte, modifie ou remplace une balise <link rel="canonical"> via JS, Google voit d'abord une version, puis une autre après l'indexation côté rendering.

Pourquoi cette divergence pose-t-elle problème à Google ?

Google crawle d'abord le HTML brut, puis met la page en file d'attente pour le rendu JavaScript. Ce processus n'est ni instantané ni garanti : certaines pages peuvent attendre des jours, voire des semaines, avant d'être rendues. Entre-temps, Googlebot a déjà extrait les signaux du HTML brut — y compris la canonique.

Quand la canonique change après rendu, Google hérite de deux instructions contradictoires pour la même URL. Le moteur n'a aucun moyen de savoir laquelle est « la bonne » — ce qui brise la logique de consolidation. Martin Splitt affirme que dans ce cas, Google peut choisir une troisième URL comme canonique ou basculer entre les deux versions selon les cycles de crawl.

Concrètement, que signifie « alterner entre les deux versions » ?

Cela veut dire que lors d'un crawl, Google retient la canonique du HTML brut, puis lors d'un crawl suivant (après rendu), bascule vers la canonique du HTML rendu. Cette instabilité fragmente les signaux de ranking : backlinks, ancres, historique de clics, tout se dilue entre plusieurs URL.

Dans Search Console, tu observes des rapports de couverture incohérents : une URL marquée « Doublon – URL canonique différente de celle définie par l'utilisateur », puis reclassée en « Indexée », puis à nouveau marquée doublon. Impossible de piloter proprement ton indexation dans ces conditions.

• Signal mixte = Google ne peut pas décider quelle URL consolider comme référence.
• Alternance de canoniques = tes métriques GSC deviennent inutilisables pour le suivi des performances.
• Choix arbitraire = Google peut élire une URL que tu n'as jamais définie comme canonique, diluant ton autorité.
• Impact crawl budget = le bot perd du temps à crawler et retraiter des variantes instables au lieu de découvrir du contenu frais.

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

Oui, et elle confirme un phénomène que beaucoup de praticiens SEO attribuaient à tort à des « bugs » de Google. En réalité, c'est un problème d'architecture front-end mal maîtrisé. Les sites migrant vers des frameworks JS modernes (Next.js, Nuxt, SvelteKit) sans SSR strict tombent régulièrement dans ce piège.

On observe notamment ce comportement sur des sites e-commerce où la canonique est gérée via un composant React qui se charge après le HTML initial. Résultat : Google indexe d'abord la page produit avec une canonique vide ou générique, puis rebascule vers la bonne URL après rendu — mais entre-temps, les backlinks ont atterri sur la mauvaise variante.

Quelles nuances faut-il apporter à cette affirmation ?

Martin Splitt évoque un « choix complètement différent » de canonique par Google, mais il ne précise pas les critères exacts de ce choix. [À vérifier] : on peut supposer que Google utilise d'autres signaux (sitemaps, liens internes majoritaires, backlinks externes) pour arbitrer, mais aucune confirmation officielle sur la pondération exacte.

Autre point flou : la fréquence d'alternance. Est-ce que Google bascule à chaque crawl ? Seulement lors des cycles de rendu ? Ou de manière aléatoire selon la charge des serveurs de rendering ? Là encore, pas de données publiques exploitables. On navigue à vue, en mode observation empirique.

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

Si ton site est 100 % statique (SSG complet, sans hydratation JS côté client modifiant les balises meta), tu ne risques rien. Le HTML brut = HTML rendu, donc aucune divergence. C'est le cas de sites Gatsby, Hugo ou Jekyll bien configurés.

Également, si tu utilises du SSR strict (Server-Side Rendering) où le serveur envoie directement le HTML final avec la bonne canonique, et que le JS côté client ne touche jamais à cette balise, tu restes safe. Mais dès qu'une librairie tierce (tracking, consentement, CMP) injecte ou modifie des balises dans le <head>, le risque réapparaît.

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

D'abord, audite ton HTML brut vs rendu pour toutes tes pages stratégiques. Compare le code source serveur (curl ou « Afficher le code source ») avec l'état du DOM après chargement complet (DevTools → Elements). Si les balises canoniques diffèrent, tu es en zone rouge.

Ensuite, privilégie le rendu côté serveur pour les balises critiques : canonique, hreflang, meta robots, structured data. Ne laisse jamais JavaScript modifier ces éléments après le premier paint. Si ton framework l'impose, configure un SSR ou SSG strict pour les pages indexables.

Quelles erreurs éviter absolument ?

Ne jamais injecter une balise canonique via un useEffect React, un mounted() Vue ou un script qui s'exécute après le DOMContentLoaded. Google crawle le HTML brut en priorité — ton JS peut mettre des secondes à s'exécuter, et entre-temps, le signal est déjà envoyé.

Autre piège classique : les CMS headless (Contentful, Strapi, Prismic) qui génèrent les canoniques côté client via des requêtes API asynchrones. Si l'API met 500 ms à répondre, ton HTML initial est vide de canonique, puis elle apparaît après rendu. Google voit deux états incompatibles.

Comment vérifier que mon site est conforme ?

Utilise l'outil d'inspection d'URL dans Search Console : compare l'onglet « HTML brut » avec « Capture d'écran » (qui reflète le rendu). Si les canoniques divergent, tu as un problème. Fais cette vérification sur 10-15 pages types (home, catégories, produits, articles).

Complète avec un crawl Screaming Frog en mode JavaScript : compare les colonnes « Canonical Link Element 1 » (HTML brut) et « Rendered Canonical » (après JS). Toute divergence = signal mixte potentiel. Priorise la correction des pages à fort trafic organique et backlinks.

• Auditer HTML brut vs rendu sur 15 pages stratégiques avec l'outil d'inspection GSC
• Configurer un SSR strict pour toutes les balises canoniques, hreflang et meta robots
• Ne jamais injecter de balise canonique via JavaScript côté client (useEffect, mounted, etc.)
• Crawler le site avec Screaming Frog en mode rendu JS et comparer les canoniques brutes vs rendues
• Vérifier que les CMS headless envoient les canoniques dans le HTML initial, pas via requête API asynchrone
• Monitorer les rapports de couverture GSC pour repérer les basculements de canoniques entre deux crawls