Implémenter les balises canonical sur son site : le guide pour éviter le duplicate content

Balises canonical : pourquoi Google les ignore (et comment l'empêcher)

Vous avez passé des heures à configurer vos balises canonical. Et pourtant, dans Google Search Console, des dizaines de pages s'affichent comme « Page alternative avec balise canonical appropriée ». C'est-à-dire : Google a vu votre balise, l'a comprise, et l'a ignorée quand même.

Ce constat, je l'ai fait sur mon propre site il y a deux ans. J'avais 14 pages de filtres e-commerce avec des URL paramétrées, toutes proprement canonicalisées vers la page mère. Résultat : seulement 3 indexées. Pas une erreur de syntaxe, pas un oubli. Simplement, Google avait décidé que ma canonical n'était pas crédible.

La canonical est un signal, pas une directive — et ça change tout

Beaucoup de gens traitent la balise canonical comme une injonction : « Google, indexe cette version, ignore les autres ». Le problème, c'est que Google ne voit pas les choses ainsi. C'est un signal de suggestion, qui pèse dans la balance parmi d'autres.

Si vos autres signaux crient le contraire, Google vous ignore. Poliment. La page reste indexée, ou pire : une version que vous vouliez écarter se retrouve dans l'index.

J'ai appris ça à mes dépens. Sur un site vitrine, j'avais deux versions d'une même page service : une avec paramètre de tracking ?utm_source=newsletter qui s'était retrouvée indexée par accident, et la page principale. J'avais posé une canonical de la page paramétrée vers la page propre. Google a continué d'afficher la version paramétrée dans ses résultats pendant trois semaines.

Pourquoi ? Parce que le lien interne pointait vers l'URL paramétrée. Parce que le sitemap XML contenait les deux. Parce que la version paramétrée avait un contenu strictement identique. Bref, tous les signaux internes disaient « cette page est légitime », et ma canonical était un élément isolé contre quatre indices contradictoires.

Dans quelles conditions Google abandonne-t-il une canonical ?

En général, Google ignore la canonical quand elle entre en conflit avec plusieurs autres signaux. Les plus fréquents :

• Le contenu est intégralement dupliqué sur des dizaines d'URL (c'est le cas typique des filtres e-commerce mal gérés) et la canonical pointe vers une page qui n'a pas de contenu nettement supérieur
• Les liens internes pointent massivement vers les URL paramétrées plutôt que vers la page canonique
• Le sitemap XML inclut les URL paramétrées avec leurs propres balises canonical auto-référencées
• La page canonique est bloquée par un noindex, un robots.txt, ou renvoie une erreur 404 — dans ce cas, Google choisit une alternative ou abandonne
• La canonical change trop souvent : une semaine vers une URL, la suivante vers une autre, Google finit par ne plus les prendre au sérieux

Sur mon site e-commerce, c'est exactement le scénario qui s'est produit. Mes 14 pages de filtres étaient toutes générées dynamiquement, avec des contenus quasi identiques. Les balises canonical étaient techniquement parfaites. Mais les liens internes depuis les fiches produits pointaient vers les versions avec paramètres de tri. Le sitemap généré automatiquement incluait ces URL. Google a conclu que mes canonicals étaient un vœu pieux plutôt qu'une décision d'architecture.

Diagnostiquer une canonical ignorée dans la Search Console

Le premier réflexe n'est pas d'ajouter encore une balise. C'est de regarder pourquoi celle qui existe ne suffit pas.

Dans Google Search Console, ouvrez le rapport « Pages », puis le filtre « Pourquoi les pages ne sont pas indexées ». Vous verrez une catégorie intitulée « Page alternative avec balise canonical appropriée ». C'est là que Google vous dit : « Merci pour votre suggestion, mais j'ai choisi une autre version ».

Deux cas de figure :

1. La page listée est votre version canonique. C'est problématique : Google a indexé une autre URL que celle que vous avez désignée. Il faut chercher les signaux contradictoires évoqués plus haut.
2. La page listée est une version alternative. C'est logique et sain : votre canonical fonctionne comme prévu. Les URL paramétrées sont découvertes mais non indexées, au profit de la page principale.

J'ai eu les deux cas. Le premier, sur le site e-commerce, m'a pris trois jours d'audit pour comprendre que le sitemap incluait les URL avec paramètres. Le générateur de sitemap du CMS avait simplement listé toutes les URL connues, y compris celles avec des filtres actifs. Deux heures de correction du sitemap, et la situation s'est débloquée en quelques semaines. Le second cas est sain : les pages alternatives ne sont pas indexées, c'est exactement ce que la canonical doit produire.

Auditer ses canonical avec un outil de crawl

La Search Console donne la vision de Google. Les outils de crawl, eux, donnent la vision de votre site. J'utilise Screaming Frog depuis des années, et je configure systématiquement une extraction des balises canonical dans l'audit.

Ce que je cherche :

• Les URL avec une canonical vers une autre page qu'elles-mêmes : normal pour des versions alternatives, mais il faut vérifier que la page canonique existe et répond en 200
• Les URL avec une canonical auto-référencée : normal pour les pages principales, mais suspect pour des versions paramétrées — car cela signifie que chaque version se prétend canonique
• Les chaînes de canonical : page A canonical vers B, qui canonical vers C. Google suit généralement la première, mais c'est un signe de mauvaise configuration
• Les urls sans canonical du tout : pour les pages importantes, c'est une opportunité manquée

Sur un site client l'année dernière, l'audit a révélé 23 pages avec des canonical pointant vers des URL supprimées depuis six mois. Le CMS avait mal géré la suppression des variantes de filtres. Chaque balise envoyait vers une page 404. Résultat : Google indexait des versions alternatives au lieu de la page principale. En corrigeant les 23 balises pour pointer vers les URL réelles, puis en ajoutant des redirections 301 pour les anciennes, nous avons récupéré l'indexation de la page principale en cinq semaines.

Cas complexes : pagination, filtres AJAX et contenu syndiqué

Les situations simples se résolvent avec une balise bien posée. Mais certaines configurations méritent d'être réfléchies avant de poser la moindre balise.

La pagination : une canonical qui se tire une balle dans le pied

J'ai vu des sites canonicaliser leur page 2, 3, 4 de pagination vers la page 1. L'idée est compréhensible : éviter la duplication de contenu entre les pages de liste. Le problème, c'est que Google peut alors ne jamais indexer les pages profondes, ce qui réduit la surface de contenu crawlée.

La recommandation de Google est de laisser chaque page de pagination en auto-référencement (canonical vers elle-même). Le contenu de la page 2 n'est pas un doublon de la page 1, c'est une suite logique. Si vous voulez consolider les signaux, il vaut mieux utiliser une balise rel="prev" et rel="next" — même si Google a annoncé ne plus vraiment les prendre en compte, les pages de pagination continuent de fonctionner correctement avec des canonicals auto-référencées.

Sur mon blog, chaque catégorie a 4 à 6 pages de pagination. J'ai testé les deux approches. Avec une canonical vers page 1, la page 2 n'était jamais indexée. Avec l'auto-référencement, toutes les pages de pagination ont fini indexées, et le trafic organique vers les articles profonds a augmenté d'environ 15 % sur trois mois. Ce n'est pas spectaculaire, mais c'est le genre de gain qui s'accumule.

Filtres AJAX : quand l'URL change sans rechargement

Les boutiques en ligne modernes utilisent souvent le rendu côté client pour les filtres. L'URL change via l'API History, mais le contenu est chargé par JavaScript. Dans ce cas, la balise canonical doit être gérée dynamiquement, côté serveur ou dans le code JavaScript, pour refléter l'état réel du filtre.

J'ai eu un cas où les filtres modifiaient l'URL mais la balise canonical restait celle de la page mère. Résultat : Google voyait une page avec un contenu filtré, mais une canonical vers la page complète. Il fallait que le JavaScript mette à jour la balise à chaque changement d'état. Une solution simple : un petit script qui réécrit la balise canonical après chaque navigation.

Contenu syndiqué : la canonical vers la source d'origine

Si vous republiez du contenu d'un autre site, ou si quelqu'un republie votre contenu avec votre accord, la canonical doit pointer vers l'URL d'origine. C'est la seule façon de signaler clairement quelle version est la référence.

Là encore, attention aux signaux contradictoires. Si le site d'origine change d'URL sans redirection, votre canonical pointe vers une page morte. Dans ce cas, Google peut indexer votre copie. C'est arrivé à un confrère : il avait syndiqué un article chez un gros média, avec canonical vers son site. Le média a changé la structure de ses URL, cassant toutes les canonicals externes. Son contenu a fini indexé chez le média, et il a dû demander la suppression manuelle.

Canonical ou redirection 301 : le choix qui évite bien des maux

La règle que je me suis fixée après des années d'erreurs est simple :

• Si les deux versions sont accessibles aux utilisateurs, et que l'une est une variation de l'autre (paramètres de tracking, tri, filtre), utilisez la canonical. Les utilisateurs ont besoin de voir la version paramétrée, mais Google doit comprendre que la version propre est la référence.
• Si une version ne doit plus être accessible du tout, ou si les deux versions sont réellement dupliquées, faites une redirection 301. C'est une directive, pas un signal. Google n'a pas le choix.

Par exemple, une ancienne page /services remplacée par /nos-services doit renvoyer en 301, pas en canonical. En revanche, une URL avec ?source=facebook peut rester accessible pour le tracking, avec une canonical vers l'URL sans paramètre.

J'ai brûlé des mois à essayer de résoudre par des canonicals ce qui relevait des redirections. Sur un site de 200 pages, j'ai découvert 45 doublons quasi intégraux créés par des variations de casse dans les URL. Le CMS générait à la fois /Blog/Article et /blog/article. J'ai posé des canonicals de l'une vers l'autre. Google a continué d'indexer les deux pendant des semaines. Les redirections 301 ont réglé le problème en dix jours.

Les trois erreurs que je vois encore sur les sites que j'audite

Avec le recul, les mêmes erreurs reviennent constamment. Les voici, par ordre de gravité :

Erreur n°1 : utiliser des URL relatives

La spécification HTML autorise les URL relatives. Mais les outils de crawl, les CMS et certains navigateurs les interprètent parfois différemment. Une canonical relative canonical="/page" peut être réécrite en ajoutant le domaine courant, ce qui peut créer des incohérences si le site est accessible via plusieurs domaines ou sous-domaines.

La règle : toujours utiliser l'URL absolue complète, avec protocole et domaine, comme https://www.monsite.fr/page/. Ça évite toute ambiguïté.

Erreur n°2 : combiner canonical et noindex sur la même page

Les deux balises envoient des messages contradictoires. La canonical dit « indexez une autre version », le noindex dit « n'indexez pas celle-ci ». Google a explicitement indiqué qu'en cas de conflit, il peut ignorer l'une ou l'autre selon le contexte. Si une page ne doit pas être indexée, utilisez uniquement le noindex. Si une page doit être remplacée par une autre, utilisez uniquement la canonical.

J'ai vu un site qui appliquait les deux sur des pages de remerciement après formulaire. Résultat : certaines pages ont fini indexées, d'autres non, sans logique apparente. En retirant les canonicals et en gardant uniquement le noindex, le comportement est devenu prévisible.

Erreur n°3 : pointage vers une URL qui redirige

Une canonical doit pointer directement vers l'URL finale, sans passer par une redirection. Si votre page A canonical vers B, et que B redirige en 301 vers C, Google peut considérer la chaîne comme incohérente et abandonner les deux.

La bonne pratique : mettre à jour les canonicals pour pointer directement vers C. C'est un détail que beaucoup de CMS oublient lors de changements d'URL.

Combien de temps pour que Google prenne en compte une nouvelle canonical ?

Les canonicals ne sont pas traitées en temps réel. Google doit recrawler les pages concernées, puis re-traiter les signaux. Dans mon expérience, le délai varie de quelques jours à plusieurs semaines, selon la fréquence de crawl du site.

Sur un site mis à jour quotidiennement, une canonical corrigée est souvent prise en compte en 5 à 15 jours. Sur un site avec peu de contenu nouveau, cela peut prendre un à deux mois. La Search Console permet de demander une réindexation des URL concernées, ce qui accélère le processus.

Une astuce : si vous corrigez une canonical, vérifiez que la page canonique elle-même est fraîchement crawlée. Si elle ne l'est pas, demandez sa réindexation aussi, car Google doit voir la version réelle pour valider votre choix.

Une canonical bien posée, c'est une architecture qui se défend seule

J'ai mis des années à comprendre que la balise canonical n'est pas une incantation magique. C'est un élément d'une architecture cohérente : le sitemap, les liens internes, les redirections et la structure des URL doivent tous raconter la même histoire. Si un seul élément ment, la canonical devient un signal parmi d'autres, et Google fait son propre choix.

Sur mon site, après avoir corrigé le sitemap, harmonisé les liens internes et posé des redirections 301 là où il fallait, le rapport d'indexation est devenu propre : les pages qui devaient l'être sont indexées, les autres sont ignorées ou marquées comme alternatives.

La prochaine fois que vous poserez une balise canonical, posez-vous cette question simple : si je désactivais cette balise demain, est-ce que Google choisirait quand même la bonne URL ? Si la réponse est non, ce n'est pas la balise qu'il faut ajouter, c'est l'architecture qu'il faut corriger. C'est moins gratifiant qu'une ligne de code, mais c'est ce qui fonctionne vraiment.