Faut-il supprimer la balise canonical plutôt que d'en servir une incorrecte corrigée en JavaScript ?

Pourquoi une canonical incorrecte pose-t-elle problème avant le rendu ?

Google crawle et indexe en deux temps : le HTML initial envoyé par le serveur, puis le rendu JavaScript qui peut modifier le DOM. Lorsqu'une balise canonical est présente dans le HTML initial avec une valeur incorrecte, Googlebot l'enregistre immédiatement.

Même si JavaScript corrige ensuite cette valeur côté client, Google peut déjà avoir traité la première canonical. Cette double lecture crée une ambiguïté de signal : quelle version doit-il privilégier ? Le moteur peut hésiter, ralentir la consolidation des signaux, voire ignorer la correction JavaScript.

Dans quels cas cette situation se produit-elle concrètement ?

Les frameworks JavaScript modernes (React, Vue, Next.js en mode client) servent souvent un shell HTML minimal avant d'hydrater le contenu. Certains CMS ou plateformes injectent une canonical générique dans ce shell, puis la corrigent via un script côté client une fois la page montée.

Ce pattern est fréquent dans les sites e-commerce avec variantes produit, les plateformes multilingues générant dynamiquement les hreflang et canonical, ou les sites migrant progressivement vers le JavaScript sans refonte complète du serveur. Le problème est que Google lit le HTML initial avant que le JavaScript ne s'exécute, et cette première lecture laisse une trace.

Que recommande Martin Splitt exactement ?

L'instruction est claire : si vous ne pouvez pas fournir la bonne canonical dès le HTML initial, mieux vaut ne pas en mettre du tout. Googlebot fera alors son propre choix de canonicalisation en analysant les signaux disponibles (similarité de contenu, redirections, liens internes, sitemap).

Splitt précise que cette confusion est rare — ce qui signifie que Google gère cette situation dans la majorité des cas, mais pas toujours. Le risque existe, et dans un environnement concurrentiel, pourquoi laisser une zone d'incertitude quand on peut l'éliminer ?

• Une canonical incorrecte dans le HTML initial peut être interprétée par Google avant toute correction JavaScript
• La correction client-side n'est pas toujours prise en compte ou peut créer un signal contradictoire
• L'absence de canonical est moins risquée qu'une valeur erronée : Google choisira lui-même la version canonique
• Le rendu JavaScript n'est pas instantané pour Googlebot : la première lecture compte
• Cette recommandation s'applique surtout aux sites en SSR partiel, SPA ou frameworks hydratant le DOM après chargement

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

Oui, elle confirme ce que de nombreux SEO constatent depuis des années : Google privilégie le HTML initial pour les signaux critiques comme la canonical. Les outils de test (PageSpeed Insights, Search Console) montrent bien deux vues distinctes — HTML brut et rendu — mais la priorité reste au premier contact serveur.

Ce qui est nouveau, c'est l'affirmation claire qu'une canonical incorrecte peut créer de la confusion même si elle est corrigée après rendu. Cela tranche avec l'idée reçue que « JavaScript, c'est OK tant que Google le rend ». Non : pour la canonical, le timing compte. [A vérifier] : Splitt ne précise pas si cette confusion affecte l'indexation, le crawl budget ou uniquement la consolidation des signaux de ranking.

Quelles nuances faut-il apporter à cette recommandation ?

Splitt dit que le problème est « rare ». Cela signifie que dans la majorité des cas, Google gère correctement la correction JavaScript. Mais quelle est cette majorité ? 90% ? 98% ? L'absence de données chiffrées rend difficile l'évaluation du risque réel.

Pour un site à faible concurrence ou avec peu de pages, ce risque est probablement négligeable. Pour un site e-commerce avec des milliers de variantes produit ou un média avec des URL dynamiques, chaque confusion peut coûter du trafic. Le conseil de Splitt est donc conservateur et prudent, mais pas forcément critique pour tous.

Faut-il vraiment supprimer la canonical si elle est incorrecte ?

Soyons honnêtes : supprimer la canonical expose à un autre risque, celui que Google choisisse la mauvaise version canonique. Si votre site a des URL avec paramètres, des variantes paginées ou des contenus dupliqués intentionnels (facettes, filtres), l'absence de canonical peut créer plus de problèmes qu'elle n'en résout.

La vraie solution n'est pas de supprimer, mais de corriger à la source : servir la bonne canonical dès le HTML initial, via du SSR (Server-Side Rendering), du pré-rendu ou une génération dynamique côté serveur. C'est techniquement plus lourd, mais c'est la seule approche qui élimine le risque sans en créer d'autres.

Comment vérifier si mon site sert des canonicals incorrectes avant rendu ?

Utilisez l'outil d'inspection d'URL de la Search Console et comparez les deux vues : « Page explorée » (HTML brut) et « Page indexée » (après rendu). Si la canonical diffère entre les deux, vous êtes dans le cas de figure décrit par Splitt.

Vous pouvez aussi faire un curl du HTML initial (`curl -A "Googlebot" https://votresite.com/page`) et vérifier la balise canonical, puis comparer avec ce qu'affiche le navigateur après chargement complet. Un écart entre les deux signale le problème. Automatisez cette vérification avec Screaming Frog en mode « Rendering JavaScript » pour crawler l'ensemble du site.

Quelle est la solution technique la plus robuste ?

La meilleure approche est le Server-Side Rendering (SSR) ou le pré-rendu statique (SSG, Static Site Generation). Avec Next.js, Nuxt.js ou des solutions de pré-rendu comme Prerender.io, la canonical est écrite côté serveur et servie directement dans le HTML initial.

Si le SSR n'est pas envisageable à court terme, une alternative est de supprimer complètement la canonical du HTML initial et de laisser Google décider. Ce n'est pas l'idéal, mais c'est moins risqué qu'une valeur incorrecte selon Splitt. Une autre option : utiliser des redirections 301 plutôt que des canonicals pour les variantes simples (paramètres, trailing slash).

Quelles erreurs éviter lors de la migration ou refonte ?

Ne vous contentez pas de « migrer vers JavaScript » sans revoir l'ensemble de la chaîne de rendu. De nombreux sites passent en SPA en pensant que Google gère tout, puis découvrent des problèmes d'indexation six mois plus tard. Testez le HTML initial avant chaque déploiement.

Évitez les canonical « par défaut » injectées par le CMS ou le framework si elles ne sont pas dynamiques. Certains thèmes WordPress ou Shopify ajoutent une canonical générique dans le `` qui est ensuite écrasée par un plugin — exactement le scénario problématique. Enfin, ne comptez pas sur les outils de test qui montrent uniquement le rendu final : Google lit d'abord le HTML brut.

• Comparer systématiquement HTML initial et rendu avec l'outil d'inspection de la Search Console
• Privilégier le SSR ou le pré-rendu statique pour servir la bonne canonical dès le HTML initial
• Si SSR impossible, supprimer la canonical du HTML initial plutôt que d'en servir une incorrecte
• Automatiser la vérification avec Screaming Frog en mode « Rendering JavaScript »
• Tester le HTML brut (curl ou view-source) avant chaque mise en production
• Éviter les canonical génériques injectées par le CMS si elles ne sont pas dynamiques