Comment optimiser les balises canonical pour éviter le contenu dupliqué

Vous avez déjà reçu cet email de Google Search Console : « Pages en double : Google a choisi une autre URL canonique ». Et là, vous fixez l'écran en vous demandant ce que vous avez bien pu casser. Rien, probablement. C'est juste que Google a décidé tout seul quelle version de votre page méritait d'être indexée — et ce n'est pas forcément celle que vous vouliez.

La balise canonical, c'est exactement l'outil qui sert à reprendre la main sur cette décision. Mal posée, elle ne fait rien. Posée correctement, elle règle des problèmes d'indexation que vous traînez depuis des mois sans le savoir. Voici comment s'en servir pour de bon, avec les cas tordus que la plupart des tutos oublient.

Comprendre la balise canonical avant de vouloir l'optimiser

Une page peut être accessible par plusieurs URLs. Ce n'est pas un bug, c'est la nature du web : paramètres de tri, versions HTTPS et HTTP, slash final ou non, paramètres de tracking, sous-domaines. Toutes mènent au même contenu. Pour un moteur, ce sont pourtant plusieurs pages distinctes — ou une seule, selon la façon dont vous le signalez.

C'est là que la canonical intervient. Placée dans le <head>, elle déclare : « cette URL-là est la version de référence, indexez-la et oubliez les autres ».

Ce que la balise fait réellement

Elle consolide les signaux. Les liens, l'autorité, le contenu — tout est ramené vers une seule URL. Sans elle, deux versions concurrentes se partagent les mêmes liens entrants, et aucune des deux ne grimpe. Le résultat concret : votre page cible plafonne alors que le contenu mérite mieux.

Un point qu'on lit rarement : la canonical n'empêche pas l'autre URL d'exister. Elle peut toujours être crawlé, indexée dans certaines conditions. Si vous voulez vraiment empêcher l'indexation, c'est noindex qu'il faut, pas canonical. Confondre les deux est l'erreur que je vois le plus souvent chez mes clients.

Canonical, 301, noindex : ne pas confondre les trois

J'ai passé des semaines à expliquer cette distinction à une équipe e-commerce qui avait posé des canonicals partout, y compris sur des pages qu'elle voulait supprimer purement et simplement. Résultat : un index gonflé d'URLs fantômes pendant six mois.

Signal	Usage	Conséquence si mal utilisé
Canonical	Deux URLs vivantes, une seule version préférée	Aucune si cohérent ; le signal se dilue si contradictoire
Redirection 301	L'ancienne URL disparaît définitivement	Si mal chaînée, perte de crawl budget et confusion
Noindex	Ne pas figurer dans les résultats du tout	Peut annuler l'effet d'une canonical pointant ailleurs

Le piège classique : une page marquée noindex ET canonicalisée vers une autre page. Google reçoit deux ordres contradictoires et, dans le doute, choisit souvent d'ignorer les deux. Si le contenu n'a pas sa place dans l'index, retirez-le vraiment.

Auditer les doublons avant de poser la moindre canonical

Ici, la majorité des gens foncent. Ils installent un plugin, activent les canonicals automatiques, et attendent. Sauf que si vous ne savez pas où sont vos doublons, vous ne pouvez pas vérifier que votre correction fonctionne.

Trois méthodes, dans l'ordre que je recommande.

L'opérateur site: — tapez une URL sans paramètre, puis avec, et regardez ce qui remonte. Fastidieux, mais instructif sur les premières pages.

Le rapport « Pages en double » de Search Console — utile, mais partiel : il ne montre que les cas que Google a lui-même détectés. Beaucoup de doublons de paramètres n'apparaissent jamais ici.

Un crawl complet avec un outil comme Screaming Frog — la vraie solution. Vous exportez toutes les URLs, vous filtrez par contenu identique, et vous voyez la liste noire sur papier. Sur un site de 5 000 pages, comptez une à deux heures d'analyse.

Identifier les causes typiques de duplication

• Paramètres d'URL : ?sort=price, ?utm_source=, ?page=2 — chaque variante est une page pour le moteur.
• Facettes e-commerce : filtres de couleur, taille, prix. Génèrent des centaines d'URLs pour le même catalogue.
• Versions HTTPS / HTTP et www / non-www. Si les quatre répondent en 200, vous avez quatre pages identiques.
• Pages imprimables et versions AMP orphelines.
• Slash final : /produit et /produit/ — deux URLs, un contenu.

Chaque cause appelle un traitement différent. Une version imprimable, on la canonicalise ou on la supprime. Un paramètre de tri, on le neutralise côté serveur ou on le canonicalise vers la version propre. Ne traitez pas tous les cas avec le même marteau.

Implémenter une canonical correctement (et sans casser son site)

Le bloc est court, mais chaque caractère compte.

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

Trois règles non négociables.

1. L'URL est absolue : protocole, domaine, chemin. Une version relative (/produit/chaussures-rouges/) est interprétée au mieux, souvent mal.
2. Une seule balise canonical par page. Deux balises, et Google choisit la première ou ignore l'ensemble. J'ai vu un thème WordPress en injecter une automatiquement en plus de celle ajoutée à la main — double canonical sur 200 pages, découverte après trois semaines de baisse de trafic.
3. L'auto-référence : chaque page doit se pointer elle-même, sauf si elle est censée pointer ailleurs. Cela paraît redondant, mais c'est le filet de sécurité contre les canonicals héritées de plugins mal configurés.

Une fois en place, vérifiez la cohérence avec votre sitemap XML. Si la canonical d'une page pointe vers une URL absente du sitemap, vous envoyez deux signaux contradictoires. C'est subtil, ça se paie.

Canonical et pagination : le cas qui fait débat

La pagination a longtemps été gérée avec rel="next" et rel="prev". Ces balises ont été abandonnées par Google, et ne servent plus à rien aujourd'hui. Que faire alors ?

La règle actuelle est simple : chaque page paginée est une page canonique d'elle-même. Ne canonicalisez pas la page 3 vers la page 1 — vous dites à Google que le contenu de la page 3 n'existe pas. Chaque page de la pagination possède son propre contenu et mérite d'être indexée pour ce qu'elle est.

Ce point est régulièrement contesté dans les commentaires de forums. C'est pourtant la recommandation stable depuis plusieurs années. Je m'y tiens, et je n'ai jamais vu un cas où canonicaliser des pages paginées vers la première améliorait une situation.

Canonical et JavaScript : le piège des applications rendues côté client

C'est la partie que les tutos de 2019 ignorent. Si votre site est une application JavaScript, la balise canonical doit être présente dans le HTML initial, avant que le script ne la modifie. Une canonical injectée dynamiquement après le chargement du DOM risque fort de ne jamais être vue par le robot.

La solution : générez la balise côté serveur (SSR), ou via un rendu statique. Ne comptez pas sur le JavaScript côté client pour porter un signal SEO aussi critique. Vérifiez toujours en inspectant le code source brut de la page (Ctrl+U), pas via l'inspecteur qui exécute le JS.

Les erreurs qui annulent tout le travail

Même posée correctement, une canonical peut ne rien faire si elle entre en conflit avec d'autres signaux.

La chaîne de canonical

La page A pointe vers B, la page B pointe vers C. Vous pensiez consolider trois pages vers C. En pratique, Google doit suivre deux sauts et perd rarement la patience. Dans le doute, il peut ignorer l'ensemble. La règle : toutes les canonicals pointent directement vers la version finale. Pas d'intermédiaire.

Je l'ai vu exploser sur un site après une migration, où d'anciennes URLs redirigeaient vers des pages elles-mêmes canonicalisées. Une nuit de correction, deux semaines de retour à la normale.

La canonical qui pointe vers une page noindex

Si vous demandez à Google d'indexer une URL que vous avez marquée noindex, il ne peut pas obéir aux deux. Il choisit souvent d'ignorer la canonical et d'indexer la page d'origine — l'inverse de ce que vous vouliez. Vérifiez toujours que la cible d'une canonical est bien indexable.

Le conflit hreflang / canonical

Sur un site multilingue, chaque version linguistique doit avoir sa propre canonical auto-référente. Une erreur courante consiste à canonicaliser la version française vers l'anglaise « parce que c'est la version principale ». Résultat : la version française disparaît des résultats français. L'hreflang et la canonical doivent raconter la même histoire.

Vérifier que ça fonctionne vraiment

Après correction, attendez. Pas 24 heures — deux à six semaines selon la taille du site et la fréquence de crawl. Sur un petit site que je suivais, 12 jours ont suffi pour voir la page cible remonter en première position sur sa requête principale, après deux ans de stagnation.

Comment mesurer :

• Le rapport « Pages en double » de Search Console doit voir son volume baisser.
• Le nombre d'URLs indexées doit se rapprocher du nombre réel de pages uniques.
• La page cible doit capter plus de clics pour les mêmes requêtes.

Si rien ne bouge après six semaines, vérifiez d'abord la cohérence : canonical unique, URL absolue, cible indexable, pas de chaîne. Dans neuf cas sur dix, le problème est là.

Reste une vérité désagréable : parfois, Google ignore votre canonical même quand tout est parfait. Il juge que les deux pages ont un contenu suffisamment différent pour mériter une indexation séparée. Dans ce cas, la vraie solution n'est pas technique. C'est éditoriale : fusionnez les contenus, ou différenciez-les assez pour qu'ils vivent leur vie. La balise ne fait que traduire une décision que vous devez prendre vous-même — elle ne la prendra jamais à votre place.