Le problème qu’elle vient régler : les URL en double

Sur un site, une même page vit souvent à plusieurs adresses sans que personne l’ait décidé. Un paramètre de tracking collé au bout d’un lien de newsletter, une version avec et une sans slash final, un produit accessible depuis deux catégories, un filtre de tri qui génère sa propre URL : vous voilà avec trois ou quatre adresses qui servent exactement le même contenu.

Pour un visiteur, ça ne change rien. Pour Google, c’est un arbitrage à rendre : il n’a aucune envie d’indexer quatre fois le même texte, donc il regroupe ces adresses et désigne l’une d’elles comme URL canonique, celle qui apparaîtra dans les résultats. Les autres restent connues, mais sortent de la vitrine.

Le vrai souci arrive quand vous ne dites rien : Google choisit seul, et son choix n’est pas toujours le vôtre. J’ai déjà vu une fiche produit propre se faire remplacer dans l’index par sa variante avec paramètre de filtre.

À quoi sert la balise, concrètement

C’est une ligne de code qui pointe vers l’adresse que vous considérez comme la version de référence. Trois effets concrets :

  • Regrouper les signaux : les liens reçus par les variantes, l’ancienneté, l’historique, tout est attribué à l’URL désignée au lieu d’être éparpillé entre des jumelles. C’est le point qui pèse le plus.
  • Économiser le crawl : Googlebot arrête peu à peu de repasser en boucle sur des adresses qu’il sait redondantes, et consacre ses passages aux pages qui comptent vraiment.
  • Maîtriser l’adresse affichée : vous décidez de l’URL qui sortira dans les résultats, plutôt que de découvrir une version avec ?utm_source= dans la Search Console.

Un point que beaucoup découvrent trop tard : c’est un signal, pas une directive. Google la lit, la croise avec le reste (maillage interne, sitemap, redirections, ressemblance réelle des contenus), et peut retenir une autre adresse. Sa documentation le dit sans détour dans le guide officiel sur la consolidation des URL en double.

À quoi elle ressemble et où la placer

Une seule ligne, dans le <head> du document HTML :

<link rel="canonical" href="https://exemple.fr/chaussures-de-trail/">

Trois règles de base : une seule balise par page (deux balises différentes, et Google les ignore toutes les deux), une URL absolue avec le protocole et le domaine complets, et une adresse qui répond bien en 200. Rien de propriétaire là-dedans : la relation de lien « canonical » fait l’objet de la RFC 6596.

Pour un fichier non HTML (un PDF), la balise n’existe pas : on passe par un en-tête HTTP Link renvoyé par le serveur. Et sous WordPress avec Yoast ou Rank Math, elle est déjà générée sur chaque page. Vérifiez qu’elle est correcte avant d’aller la réécrire à la main.

Les cas où elle est vraiment utile

  • URL avec paramètres : tracking de campagne, filtres, tri, pagination de facettes. C’est de loin le cas le plus fréquent.
  • Un même produit rangé dans plusieurs catégories, donc accessible via plusieurs chemins.
  • Versions imprimables ou versions allégées d’une page.
  • Contenu syndiqué : si un partenaire republie votre article, une canonical vers votre URL d’origine indique qui est la source. Encore faut-il qu’il accepte de la poser.
  • Auto-référencement : chaque page pointe vers sa propre adresse. Ça paraît inutile, ça protège en réalité des paramètres ajoutés par des tiers.

En revanche, ce n’est pas la réponse à tout. Deux pages au contenu réellement différent qui se marchent dessus dans les résultats, c’est un problème éditorial : on fusionne les textes, on ne masque pas le symptôme avec une balise.

Les erreurs qui la rendent inutile

C’est là que je passe le plus de temps en audit. La balise est presque toujours présente, mais elle raconte souvent n’importe quoi.

  • Canonical vers une page en noindex : vous désignez comme référence une page que vous demandez par ailleurs de ne pas indexer. Signal contradictoire, résultat imprévisible.
  • Chaîne de canonicals : A pointe vers B, qui pointe vers C. Faites pointer A et B directement vers C.
  • Canonical vers une 404 ou vers une redirection : ça arrive à chaque refonte, quand les balises conservent les anciennes adresses.
  • URL de préproduction oubliée. Le grand classique : tout le site pointe vers staging.exemple.fr après la mise en ligne, disparaît des résultats, et personne ne comprend pourquoi.
  • Toutes les pages pointant vers l’accueil, sur un thème mal configuré : vous demandez à Google d’oublier l’intégralité de vos pages internes.
  • URL en double bloquée dans le robots.txt. Si le robot n’a pas le droit de charger la page, il ne lira jamais la balise qu’elle contient. Le blocage et la canonical se neutralisent, donc clarifiez d’abord la façon de contrôler ce que les robots explorent avec le robots.txt et le sitemap XML avant d’empiler les signaux.
  • Balise injectée en JavaScript qui contredit celle du HTML initial. Google exécute le JS, mais autant lui éviter l’exercice.

Dernier piège, plus sournois : la cohérence. Si votre balise désigne l’URL A mais que votre maillage interne, votre sitemap XML et vos redirections envoient tous vers l’URL B, Google suivra la majorité. Une canonical isolée qui contredit le reste du site ne sert à rien : c’est l’ensemble des signaux qui doit raconter la même histoire.

Canonical ou redirection 301 ?

La question revient systématiquement, et la règle est simple. Si les deux adresses doivent rester accessibles aux visiteurs (une fiche produit dans deux rayons, une page avec un paramètre de filtre utile), c’est la canonical. Si l’une des deux n’a plus de raison d’exister, c’est la redirection.

La 301 est plus radicale et bien plus contraignante pour Google, qui la suit presque toujours. Pour un changement de domaine, un passage en HTTPS ou une page supprimée, ne bricolez pas avec des balises : posez de vraies redirections, en suivant la méthode pour mettre en place une redirection 301 permanente.

Et quand le site existe en plusieurs langues ?

Cas particulier qui casse beaucoup de sites : chaque version linguistique doit pointer vers elle-même, jamais vers la version française. La canonical dit « voici la référence de CETTE page », le hreflang dit « voici les équivalents dans d’autres langues ». Les deux se complètent, ils ne se remplacent pas.

Une canonical de la version espagnole vers la version française revient à demander à Google d’oublier tout le catalogue espagnol. Si vous visez plusieurs marchés, ce point mérite d’être vérifié avant tout le reste, avec le hreflang et la stratégie de référencement à l’international.

Vérifier que Google la respecte

Poser la balise ne suffit pas, encore faut-il contrôler ce que le moteur en fait. L’outil d’inspection d’URL de la Search Console affiche deux informations côte à côte : la canonique que vous avez déclarée, et celle que Google a réellement retenue. Quand elles diffèrent, vos autres signaux tirent dans la direction opposée.

Écran d’ordinateur affichant un rapport d’indexation avec des barres de statistiques et une liste d’adresses

Le rapport d’indexation des pages complète le tableau. Deux statuts vous intéressent : celui qui signale que Google a retenu une page canonique différente de la vôtre (à investiguer en priorité), et celui qui confirme qu’une page en double renvoie bien vers une autre adresse correctement désignée (comportement normal, rien à faire).

Côté crawl maison, un passage avec Screaming Frog ou un crawler équivalent vous sort la liste des pages sans canonical, celles qui en ont plusieurs et celles qui pointent vers une adresse non 200. C’est un des premiers points que je regarde en audit : quelques lignes corrigées, et des dizaines de pages sortent du purgatoire.