Le link rel=canonical est un élément HTML placé dans la section d’en-tête d’une page web pour indiquer aux moteurs de recherche l’adresse de la version qu’un éditeur préfère voir indexée lorsque plusieurs adresses présentent un contenu identique ou très proche.
Le mécanisme repose sur la relation de lien canonical, décrite par l’IETF dans la RFC 6596, publiée en avril 2012. La page concernée contient, dans sa section head, un élément link dont l’attribut rel vaut canonical et dont l’attribut href porte l’adresse préférée. Pour un fichier qui n’est pas une page HTML, comme un PDF, la même indication peut être transmise par un en-tête de réponse HTTP nommé Link. Une page peut aussi se désigner elle-même : on parle alors de canonique autoréférente.
L’indication réunit trois éléments : la page qui la porte, l’adresse cible et le canal de transmission. Selon la RFC 6596, la cible peut se trouver sur un autre nom d’hôte, un autre domaine ou un autre protocole. Elle doit reprendre le contenu de la page qui la déclare, ou un ensemble plus large, comme une page qui réunit tous les éléments d’une liste découpée en plusieurs pages.
Le link rel=canonical ne se confond pas avec l’URL canonique, qui est l’adresse finalement retenue par le moteur : la balise n’est que l’un des signaux qui orientent ce choix. Il se distingue aussi de la redirection 301, qui envoie le visiteur vers une autre adresse, alors que la balise laisse chaque variante accessible. Il est employé pour traiter le contenu dupliqué : pages triées ou filtrées, adresses enrichies de paramètres d’URL, versions multiples d’une même fiche produit, refontes de site.
La documentation de Google Search Central sur la canonisation (2026) le dit sans détour : indiquer une préférence canonique est une indication, non une règle. Le moteur peut retenir une autre page. Il croise la balise avec d’autres signaux, comme le protocole HTTPS, les redirections ou la présence de l’adresse dans le sitemap. Une balise contredite par le reste du site a donc peu de chances d’être suivie. Nous recommandons de la traiter comme un élément d’un ensemble cohérent, jamais comme un correctif isolé posé en fin de projet.
La page « Specify a canonical » de Google Search Central (2026) et la RFC 6596 de l’IETF (2012) se rejoignent sur l’essentiel.
La balise convient quand les variantes doivent rester accessibles aux visiteurs : tri, filtre, paramètre de suivi. Si l’ancienne adresse n’a plus de raison d’exister, la redirection 301 est plus nette. Google range les deux parmi les signaux forts et l’inscription au sitemap parmi les signaux faibles. Pour retirer une page des résultats, c’est la balise noindex qui convient, pas la canonique. Google déconseille aussi d’utiliser le fichier robots.txt pour canoniser : une page dont l’exploration est bloquée ne peut pas être lue, sa balise non plus.
Pour une liste découpée en plusieurs pages, la RFC 6596 met en garde : la page 2 ne doit pas désigner la page 1 comme canonique, au risque de perdre le contenu des pages suivantes.
Le nombre de balises posées ne dit rien. L’indicateur utile est l’écart entre la canonique déclarée et celle que le moteur a retenue. L’outil d’inspection d’URL de la Search Console de Google affiche les deux : la canonique déclarée par la page et celle que Google a sélectionnée. Nous recommandons de contrôler un échantillon de pages par gabarit après chaque mise en production, puis de suivre la part de pages où les deux divergent.
Le modèle gratuit de cahier des charges site internet d’Advalians, au format Word, intègre la reprise du référencement et une grille de conformité pour comparer les offres des agences.
Advalians, cabinet de conseil indépendant en marketing et communication, vous aide à clarifier vos choix et à décider.
La redirection 301 envoie le visiteur et le robot vers une autre adresse : l’ancienne page n’est plus consultable. La balise canonical laisse chaque variante accessible et indique seulement au moteur quelle version indexer.
Critère de choix : si la variante doit rester utile à l’internaute, par exemple une liste triée par prix, posez une balise canonical. Si l’ancienne adresse n’a plus de raison d’exister, après une refonte ou une fusion de pages, préférez la redirection 301. Inutile de combiner les deux sur la même adresse : le visiteur redirigé n’atteint pas la balise.
Commencez par un inventaire des familles d’adresses dupliquées : protocoles, sous-domaines, paramètres de tri ou de suivi, pages imprimables. Pour chaque famille, choisissez une adresse de référence et notez la règle dans un document partagé.
Faites ensuite générer la balise par le gabarit, et non page par page. Chaque page de référence reçoit une canonique vers elle-même. Les variantes pointent vers la référence, en adresse absolue. Mettez enfin le sitemap et les liens internes en cohérence : ils ne doivent citer que les adresses de référence.
Comparez la canonique que vous déclarez et celle que le moteur retient. L’outil d’inspection d’adresse de la console proposée par le moteur affiche les deux pour chaque page contrôlée.
Procédez par échantillon : quelques pages par gabarit, après chaque mise en production. Suivez la part de pages où les deux adresses divergent. Une divergence répétée sur un même gabarit signale en général des signaux contradictoires : liens internes vers la variante, sitemap qui cite la mauvaise adresse, redirection en chaîne. Corrigez ces signaux avant de modifier la balise elle-même.
Elle peut l’être, mais c’est un risque évitable. La documentation du principal moteur sur le JavaScript indique que la meilleure façon de déclarer la canonique reste le HTML d’origine. Un script ne doit jamais remplacer l’adresse déclarée dans ce HTML par une autre.
Le danger vient des contradictions : une canonique dans le code source, puis une autre insérée par un module de l’outil de gestion de contenu. Contrôlez le code source brut et la page rendue sur un échantillon par gabarit. Les deux doivent afficher la même adresse, une seule fois.
Quand la ressource n’est pas une page HTML : un PDF ou un autre fichier téléchargeable. Ces fichiers n’ont pas de section head où placer la balise. La RFC 6596 de l’IETF et la documentation du principal moteur prévoient alors un en-tête de réponse HTTP nommé Link.
Pour une page HTML, restez sur la balise : elle se lit dans le code et se contrôle plus simplement. Cas typique : une fiche technique publiée en page web et en PDF, avec le même contenu. Faites désigner la page web par l’en-tête du PDF, en adresse absolue, puis vérifiez la réponse du serveur.
