Vous avez sans doute déjà vécu ce moment. Vous ouvrez le rapport « Pages » dans Search Console, et là, deux URL quasi identiques se disputent la même requête. Google en choisit une, puis change d'avis deux semaines plus tard. Votre position fait le yo-yo. Le problème n'est presque jamais votre contenu : c'est que deux adresses différentes racontent la même chose au robot, et personne ne lui a dit laquelle écouter.
C'est exactement le rôle de l'attribut rel="canonical". Mal posé, il ne sert à rien. Mal compris, il peut carrément sortir une page de l'index. Et pourtant, dans 80 % des audits que je fais, c'est la première chose que je corrige — avant même de toucher au contenu.
Points clés à retenir
- La balise canonique désigne l'URL que vous voulez voir indexée parmi plusieurs adresses au contenu similaire.
- Elle se place dans le
<head>, en URL absolue, et doit être auto-référente sur la page canonique. - Une redirection 301 est un signal plus fort : si vous pouvez rediriger, redirigez.
- Un canonical pointant vers une page en
noindexest une erreur classique qui tue l'indexation. - On vérifie le résultat dans le rapport « Pages » de Search Console, pas dans le code source.
- Le canonical gère la duplication interne. Pour le plagiat externe, il n'y a pas de solution magique.
Dans cet article, vous allez voir comment l'utiliser concrètement, avec du code copiable et surtout les erreurs que j'ai commises — parce que je les ai toutes commises.
Comment utiliser rel=canonical pour éviter le contenu dupliqué
Commençons par la base, parce que beaucoup de gens sautent cette étape et se plantent juste après.
Ce que fait vraiment la balise (et ce qu'elle ne fait pas)
Quand Google explore deux pages au contenu très proche, il doit choisir laquelle montrer dans les résultats. La balise canonique est votre vote sur ce choix. Ce n'est pas un ordre. C'est une indication forte, que Google suit la plupart du temps — mais pas toujours.
Le mécanisme concret :
- Google crawle
https://exemple.fr/article?utm_source=newsletterethttps://exemple.fr/article. - Il constate que le contenu est identique à 95 %.
- Si la version avec paramètres déclare
rel="canonical"vers la version propre, il consolide les signaux sur cette dernière. - Si aucune balise n'existe, il choisit lui-même. Et il se trompe souvent.
Ce qu'elle ne fait pas, en revanche : elle n'empêche pas le crawl. La page reste accessible, elle peut apparaître dans certains résultats. Pour la bloquer complètement, il faut une redirection ou un noindex.
Le code exact, à copier tel quel
La balise se place dans le <head>, jamais dans le <body>. Elle utilise toujours une URL absolue (avec https:// et le domaine complet). Voici la version minimale :
<link rel="canonical" href="https://exemple.fr/article-principal" />Et pour la page qui reçoit les signaux, on ajoute une auto-référence — c'est-à-dire un canonical qui pointe vers elle-même :
<link rel="canonical" href="https://exemple.fr/article-principal" />Oui, c'est la même ligne. C'est volontaire : chaque page doit se déclarer canonique d'elle-même par défaut. C'est votre filet de sécurité.
Il existe aussi une variante envoyée dans les en-têtes HTTP, utile pour les fichiers non-HTML (PDF, images). Elle ressemble à :
Link: <https://exemple.fr/fichier.pdf>; rel="canonical"Je l'utilise rarement, mais elle rend service quand mon client diffuse des PDF en téléchargement depuis plusieurs URL.
Canonical ou redirection 301 : lequel choisir ?
Question qu'on me pose à chaque audit, et la réponse est moins tranchée qu'on ne le croit.
La hiérarchie est simple. Redirection 301 > canonical. Quand une page n'a plus aucune raison d'exister à son adresse actuelle, redirigez. Le signal est direct, Google transfère tout, il n'y a pas d'interprétation.
Le canonical prend le relais dans les cas où vous ne pouvez pas rediriger, ou ne voulez pas :
- Une page existe pour une raison technique (version imprimable, version PDF, paramètres de tracking).
- Deux pages doivent rester accessibles pour des utilisateurs différents.
- Une facette produit doit rester navigable pour l'internaute, mais ne pas être indexée.
- Vous voulez conserver la page pour vos stats, même si elle ne doit pas se classer.
Sur mon propre site, j'ai longtemps gardé une version /blog/article et une version /article accessibles simultanément. Pendant six mois, Google alternait entre les deux dans les résultats. J'ai fini par rediriger, et l'oscillation a disparu en trois semaines. Ce que j'aurais dû faire dès le départ.
Tableau de décision rapide
| Situation | Outil recommandé | Pourquoi |
|---|---|---|
| Ancienne URL à remplacer définitivement | Redirection 301 | Signal le plus fort, transfert complet |
| Paramètres UTM / tracking | rel="canonical" | La page doit rester accessible pour les stats |
| Facettes e-commerce (filtres de couleur, taille) | rel="canonical" + maillage interne | Utile pour l'utilisateur, inutile en index |
| Version HTTPS vs HTTP | Redirection 301 | Le HTTP n'a plus aucune raison d'exister |
| Version imprimable / PDF d'un article | rel="canonical" vers la version HTML | Redirection impossible pour un fichier |
| Contenu syndiqué (partenaire reprend votre article) | Accord contractuel + rel="canonical" chez le partenaire | Le canonical seul ne suffit pas |
Les erreurs qui plombent votre référencement
J'en ai fait trois sur quatre. Voici celles qui font le plus de dégâts.
Canonical vers une page en noindex
C'est l'erreur la plus vicieuse. Vous placez un canonical vers /page-a, mais /page-a contient elle-même une balise <meta name="robots" content="noindex">. Résultat : Google reçoit deux signaux contradictoires — il finit par ne rien indexer du tout. J'ai vu un site perdre 40 % de son trafic organique à cause de ça, sur une migration mal testée.
Règle absolue : une page canonique ne doit jamais être en noindex. Vérifiez systématiquement avant de déployer.
Les chaînes de canonical
La page A envoie son canonical vers B, B vers C. Certains moteurs finissent par suivre la chaîne, d'autres non. Google gère, mais c'est un gaspillage de budget de crawl et un facteur de confusion. Visez toujours une cible directe : A → C, B → C.
URL relative au lieu d'absolue
J'ai vu des développeurs écrire href="/article-principal" au lieu de l'URL complète. Ça passe parfois, mais ça casse dès que la page est accessible via un sous-domaine ou une version sans www. Utilisez toujours l'URL absolue.
Plusieurs balises canoniques sur la même page
Certains CMS en injectent une par défaut, puis un plugin en ajoute une autre. Google ignore les deux et choisit lui-même. Passez toujours par un view-source pour vérifier qu'il n'y en a qu'une seule.
Comment vérifier que Google a bien pris en compte votre canonical
La balise est posée. Mais est-ce que Google l'a suivie ? Deux méthodes, complémentaires.
Inspection d'URL dans Search Console
Collez l'URL de la page dans l'inspection d'URL. Dans la section « Indexation », Google indique l'URL canonique qu'il a retenue. Si elle diffère de la vôtre, il ne l'a pas suivie — et vous devez comprendre pourquoi.
Le rapport « Pages »
Ouvrez le rapport « Indexation des pages » dans Search Console. La colonne « Page envoyée » et « URL canonique sélectionnée par Google » vous montre directement les divergences. Sur un site e-commerce de taille moyenne, j'ai vu jusqu'à 12 000 pages où Google avait choisi une autre canonique que celle déclarée. Le problème venait d'un plugin qui générait des canonical toutes différentes sur les paginations.
Et si Google ignore votre canonical ?
Quelques causes classiques :
- Le contenu des deux pages n'est pas assez similaire — Google considère qu'elles méritent chacune leur place.
- Une page reçoit beaucoup plus de liens internes que l'autre : Google suit vos liens plutôt que votre canonical.
- Le canonical pointe vers une page en noindex, bloquée par
robots.txt, ou renvoyant une erreur. - Le maillage interne pousse vers la mauvaise URL malgré la balise.
Dans ce cas, ajustez le maillage interne, pas la balise. Un lien interne est un signal plus fort qu'un canonical — c'est contre-intuitif mais vrai dans la pratique.
Ce que rel=canonical ne résout pas
Et là, je vais être direct : la balise canonique est souvent vendue comme la solution au contenu dupliqué. Ce n'est pas vrai. Elle gère la duplication interne, celle que vous contrôlez. Pour le reste, elle ne sert à rien.
Le scraping, par exemple. Si un site reprend votre article intégralement, votre canonical ne l'empêchera pas d'être indexé. Vous pouvez signaler le plagiat via le formulaire DMCA de Google, mais comptez plusieurs semaines avant une action — et parfois aucune. J'ai eu le cas sur un article qui générait 5 000 visites par mois. Le scraper s'est classé en première position pendant douze jours avant d'être retiré. Douze jours, c'est court, mais ça fait mal au moral.
Autre limite : les versions linguistiques. Un site en français et sa traduction anglaise ne sont pas des duplicatas pour Google, ce sont deux pages distinctes. Le canonical n'a rien à y faire — c'est hreflang que vous cherchez.
Enfin, les contenus réellement similaires mais pas identiques (un produit décliné en cinq couleurs avec le même texte de description) : le canonical aide, mais la vraie solution reste d'écrire des descriptions distinctes. Le contenu unique, encore et toujours.
Le réflexe à garder
Quand vous avez un doute sur deux pages similaires, posez-vous une seule question : si je devais n'en garder qu'une dans les résultats, laquelle ? C'est celle-là qui reçoit le canonical. Toutes les autres doivent pointer vers elle.
Et si vous ne pouvez pas répondre à cette question, ce n'est pas un problème de canonical. C'est un problème de contenu — deux pages qui se ressemblent assez pour qu'on hésite à en sacrifier une n'ont probablement pas besoin d'exister toutes les deux.
Ce qui me ramène à ce que je disais au début. Dans la majorité des cas où l'on me parle de contenu dupliqué, le canonical corrige un symptôme. La cause, c'est qu'on a créé deux pages là où une seule aurait suffi. La balise vous évite de perdre des signaux. Elle ne vous évitera jamais de faire ce travail-là.
