rel="canonical" placée dans l'en-tête de la page. Son rôle est de dire au moteur de recherche laquelle des variantes doit être indexée et recevoir le crédit des liens, pour que le signal ne se disperse pas entre plusieurs adresses identiques.
Un même contenu finit presque toujours par exister sous plusieurs adresses. Un paramètre de campagne ajouté à un lien partagé, un identifiant de session, un filtre de tri dans un catalogue, une fiche produit rangée dans deux rubriques : chaque variante est une URL différente aux yeux du moteur, même si le visiteur voit strictement la même page.
Sans indication, le moteur doit deviner laquelle garder. Il regroupe les variantes qu'il estime équivalentes et en élit une, celle qu'il affichera dans ses résultats. Les autres restent explorées mais ne sont pas indexées. Le risque est double : il peut retenir une adresse que vous n'auriez pas choisie, et les liens entrants reçus par les différentes variantes ne se cumulent pas de façon lisible.
La balise dans le <head>. C'est la méthode de loin la plus répandue. Une seule ligne, placée dans l'en-tête HTML : <link rel="canonical" href="https://exemple.fr/ma-page/">. L'URL doit être absolue, complète, protocole compris, et pointer vers une page qui répond en 200.
L'en-tête HTTP Link. Utile pour les fichiers qui n'ont pas de <head>, typiquement un PDF téléchargeable qui reprend le contenu d'une page web. Le serveur renvoie alors Link: <https://exemple.fr/ma-page/>; rel="canonical".
Le sitemap XML. Les adresses listées dans un fichier sitemap sont interprétées comme des candidates à la canonicalisation. Ce signal est plus faible que les deux précédents, mais il compte dans l'arbitrage, et un sitemap qui liste des variantes contredit vos balises.
Ces trois méthodes doivent dire la même chose. Un sitemap qui pointe vers l'URL avec paramètre pendant que la balise pointe vers l'URL propre envoie deux signaux contradictoires, et c'est le moteur qui tranche.
Les paramètres de suivi. Une campagne d'e-mailing ou une publication sociale ajoute des paramètres UTM à vos liens. Chaque variante devient une URL distincte. Une canonical auto-référente sur chaque page ramène tout le monde vers l'adresse propre, sans aucune intervention à chaque campagne.
Les facettes et les tris d'un catalogue. Trier une liste par prix croissant ne change pas le contenu de façon significative. Les URL de tri pointent vers la liste non triée. En revanche, un filtre qui change réellement l'assortiment, par exemple une couleur avec son propre volume de recherche, mérite souvent sa propre page indexable plutôt qu'une canonical.
La pagination. Depuis l'abandon de la prise en charge de rel="next" et rel="prev" par Google, chaque page d'une série se déclare canonique d'elle-même. Faire pointer les pages 2, 3 et suivantes vers la page 1 est une erreur fréquente : leur contenu propre disparaît alors de l'index, et les produits ou articles qui n'apparaissent que là avec.
Le contenu republié ailleurs. Quand un partenaire reprend votre article, la canonical inter-domaines pointée vers votre version indique quelle adresse doit recevoir le crédit. C'est le réflexe à demander systématiquement dans un accord de syndication.
Les variantes techniques. Version avec et sans www, avec et sans slash final, HTTP et HTTPS, page d'accueil accessible à la racine et sous /index.php. Ces cas se traitent mieux par une redirection 301, la canonical servant alors de filet de sécurité.
Les deux mécanismes concentrent le signal sur une adresse unique, mais ils n'ont pas le même effet sur le visiteur, et c'est ce critère qui tranche le choix.
| Critère | Balise canonical | Redirection 301 |
|---|---|---|
| Effet pour le visiteur | Aucun, la page reste affichée | Il est envoyé sur l'autre URL |
| Force du signal | Indication, arbitrée par le moteur | Directive, suivie dans la quasi-totalité des cas |
| Quand l'employer | Les deux URL doivent rester utilisables | L'ancienne URL n'a plus de raison d'être |
| Cas typique | Paramètres de campagne, syndication | Changement de slug, fusion de deux pages |
| Réversibilité | Immédiate, une ligne à changer | Immédiate côté serveur, mais l'index met du temps à suivre |
Le test le plus simple tient en une question. Si un visiteur arrivait sur l'URL secondaire, aurait-il une raison d'y rester ? Si oui, canonical. Si non, redirection.
La balise placée dans le <body>. Une canonical injectée après coup par un script, ou glissée dans le corps de la page par un module mal écrit, est purement et simplement ignorée. Elle doit se trouver dans le <head>, et de préférence dans le HTML servi par le serveur.
Plusieurs canonicals sur la même page. Un thème qui en pose une et une extension qui en ajoute une seconde, et le moteur reçoit deux réponses contradictoires. Il ignore alors généralement les deux. Ce défaut est invisible à l'œil et se repère en inspectant le code source ou avec un crawler.
Une canonical vers une page qui ne répond pas en 200. Pointer vers une URL en 404, en redirection ou en noindex revient à désigner une référence qui n'existe pas. Le moteur retombe alors sur son propre arbitrage.
La combinaison canonical et noindex. La première dit « indexe plutôt cette autre page », la seconde dit « n'indexe pas celle-ci ». Les deux signaux se contredisent et le résultat devient imprévisible. Il faut choisir.
La canonical qui pointe toujours vers l'accueil. Erreur de configuration classique sur certains CMS mal paramétrés. Toutes les pages du site désignent la page d'accueil comme référence, et le site disparaît progressivement de l'index à l'exception d'une seule adresse. Un contrôle sur dix pages prises au hasard suffit à le détecter.
La Search Console reste l'outil de vérification décisif. Le rapport d'inspection d'URL affiche côte à côte la canonique que vous déclarez et celle que Google a effectivement retenue. Quand les deux diffèrent, c'est que d'autres signaux pèsent plus lourd que votre balise, et il faut aller les corriger plutôt qu'insister sur la balise.