« Pourquoi Google affiche la mauvaise version de ma page ? » C'est la question qu'on m'a posée trois fois le mois dernier. Trois fois, même réponse : un problème de canonicalisation. Et à chaque fois, la personne devant moi pensait avoir affaire à une pénalité, alors que son site envoyait simplement des signaux contradictoires à Google.
La canonicalisation et le contenu dupliqué forment un couple qu'on croit maîtrisé dès qu'on a posé une balise rel="canonical" sur ses pages. Sauf que la balise n'est qu'un signal. Et un signal qu'on contredit ailleurs — dans le sitemap, dans le maillage interne, dans une redirection — devient un bruit.
Voici ce que j'ai appris en gérant des sites à plusieurs milliers d'URL, souvent avec des équipes qui ne se parlaient pas, et ce que j'ai raté au passage.
Points clés à retenir
- La canonicalisation désigne l'ensemble des mécanismes qui indiquent à Google quelle URL représenter parmi plusieurs variantes proches.
- La balise
rel="canonical"est une indication, pas une directive : Google peut l'ignorer s'il juge les signaux incohérents. - Sur un site e-commerce, les paramètres de tri, les filtres à facettes et les URLs de tracking sont les premières sources de duplication.
- Un canonical qui contredit le sitemap ou le maillage interne ne sera probablement pas suivi.
- Le bon réflexe de diagnostic se trouve dans le rapport « Pages » de Search Console, colonne « URL canonique choisie par Google ».
- Dans la majorité des cas, Google choisit bien la bonne URL tout seul. Le problème apparaît quand on l'empêche de le faire.
Canonicalisation et contenu dupliqué : ce qui se joue vraiment
Deux pages identiques ne sont pas une faute. Un site avec un système de filtres produit mécaniquement des dizaines de versions de la même liste de produits. Ce qui pose problème, c'est quand Google doit décider seul laquelle mérite d'apparaître dans les résultats.
Ce qu'on appelle canonicalisation
La canonicalisation, c'est le processus par lequel un moteur de recherche sélectionne, parmi plusieurs URLs au contenu très proche, celle qui fera office de référence. Cette sélection peut être guidée par ce que vous déclarez, ou décidée sans vous.
Vous connaissez l'outil principal : la balise rel="canonical". Elle s'écrit dans le <head> et pointe vers l'URL que vous considérez comme la version de référence. Ce que beaucoup oublient, c'est qu'il existe d'autres canaux : une redirection 301, une déclaration dans le sitemap, un lien interne qui ne pointe que vers une seule version. Chacun pèse dans la décision.
Duplication interne, duplication externe
Les deux n'ont pas les mêmes conséquences et ne se corrigent pas de la même façon.
- Interne : plusieurs URLs d'un même site affichent un contenu identique ou presque. Paramètre
?orderby=price, pagination mal gérée, version imprimable d'un article, sous-domaine de test resté en ligne. - Externe : un contenu est repris ailleurs sur le web. Syndication de presse, revendeurs qui recopient les fiches produits du fabricant, agrégateurs.
J'ai vu un site B2B perdre des mois de travail sur la seconde catégorie. Son catalogue produits avait été repris à l'identique par une quinzaine de distributeurs. Le site du fabricant se retrouvait en concurrence avec ses propres revendeurs, sur son propre contenu. Le problème, et c'est le point qu'on néglige, ce n'est pas la duplication en soi. C'est le temps que Google passe à arbitrer entre des versions équivalentes au lieu de crawler vos nouvelles pages.
Pourquoi consolider plutôt que multiplier
Google ne classe pas des pages, il classe des contenus. Deux URLs au contenu quasi identique, ce sont deux pages qui se partagent les liens entrants et potentiellement se concurrencent entre elles dans les résultats. Consolider ces signaux sur une seule URL revient à additionner ce qui était divisé.
Cela vaut aussi pour le budget de crawl. Sur un site à plusieurs milliers d'URL, chaque variante inutile visitée par le robot est une page utile qui attend son tour. Sur un de mes projets, un audit avait révélé qu'environ 40 % des URLs visitées quotidiennement étaient des variantes à paramètres sans aucune valeur. La correction n'a pas fait bondir le trafic du jour au lendemain. Mais les nouvelles pages ont commencé à être indexées en quelques heures au lieu de plusieurs semaines.
Conflit de signaux : le vrai casse-tête
Voilà où ça se complique, et c'est précisément le terrain que la plupart des ressources laissent en friche. Un canonical n'est pas lu isolément. Google croise plusieurs déclarations, et quand elles se contredisent, il tranche en faveur de… ce qui lui semble le plus cohérent. Parfois pas ce que vous voulez.
Les contradictions qui tuent un canonical
J'ai passé plusieurs jours sur un cas qui me rendait fou. Une page catégorie pointait en canonical vers une version épurée. Mais dans le sitemap, c'était la version à paramètres qui figurait. Et le menu du site renvoyait lui aussi vers cette version à paramètres. Bref, tout le site disait « la bonne URL, c'est celle-ci » sauf la balise canonical.
Google a choisi la version à paramètres. Évidemment.
La règle que j'en tire, et je la défends : un canonical qui n'est pas confirmé par le reste du site n'a presque aucune valeur. Concrètement, il faut aligner :
- La balise
rel="canonical"elle-même. - Le sitemap XML : n'y déclarer que les URLs canoniques.
- Le maillage interne : tous les liens du site doivent pointer vers la version canonique, jamais vers une variante.
- Les éventuelles directives
hreflang, qui doivent renvoyer vers des URLs cohérentes entre elles. - Le noindex, qui ne doit jamais cohabiter avec un canonical sur la même page.
Ce dernier point mérite qu'on s'y arrête : une page en noindex qui porte un canonical vers une autre URL envoie un message contradictoire. Dans le doute, retirez le canonical et laissez le noindex faire son travail, ou l'inverse. Pas les deux.
Canonical injectée en JavaScript : ce qu'il faut savoir
Les balises ajoutées en JavaScript sont rendues par Google, donc techniquement lisibles. Mais c'est plus fragile qu'on ne le pense. Une canonical injectée après un appel API peut arriver trop tard dans le rendu, ou ne pas arriver du tout si le script échoue.
Mon avis, sans détour : pour une décision aussi structurante que le choix d'une URL canonique, mettez la balise dans le HTML servi au serveur. Le JavaScript, gardez-le pour de l'enrichissement, pas pour un signal fondamental. J'ai vu un site dont le canonical était injecté côté client : quand le script plantait, tout le site se retrouvait sans canonical, et Google choisissait les URLs selon ses propres critères. Résultat des mois plus tard : des dizaines de pages à paramètres indexées à la place des bonnes.
Duplication externe : syndication, marketplaces et reprises de contenu
La duplication interne se corrige avec des règles techniques. La duplication externe, elle, dépend souvent de tiers que vous ne contrôlez pas.
Qui doit porter le canonical quand un partenaire reprend votre contenu ?
Selon le mécanisme, c'est le site repreneur qui doit déclarer votre URL comme canonique. C'est faisable, mais ça demande un accord explicite. Dans la pratique, peu de partenaires le font spontanément.
Ce que j'ai constaté sur un cas de syndication presse : le site d'origine publiait son article, puis un partenaire le reprenait une semaine plus tard. Sans canonical croisé, c'est souvent la version du partenaire — plus ancienne ou mieux maillée — qui remontait. La solution n'était pas technique, elle était contractuelle : intégrer une clause de canonicalisation dans l'accord de reprise.
- Syndication de presse : canonical croisé, à négocier au contrat.
- Fiches produits reprises par des revendeurs : fournir un bloc HTML avec la balise déjà renseignée, ça facilite l'adoption.
- Marketplaces : souvent impossible à négocier, mieux vaut alors se concentrer sur un contenu réellement différenciant que le revendeur ne peut pas recopier.
Quel levier pour quel type de duplication
| Type de duplication | Levier principal | Délai d'effet observé | Point de vigilance |
|---|---|---|---|
| Paramètres de tracking | Balise canonical vers l'URL propre | Quelques jours à quelques semaines | Vérifier que le sitemap ne contient pas les variantes |
| Filtres et facettes | Canonical + robots.txt ou noindex sur les combinaisons sans valeur | Plusieurs semaines | Ne pas bloquer des facettes qui génèrent du trafic longue traîne |
| Pagination | Canonical sur chaque page + liens rel="next/prev" non nécessaires | Immédiat à quelques semaines | Ne jamais canonicaliser toutes les pages vers la page 1 |
| Reprise par un partenaire | Canonical croisé négocié | Variable, dépend du partenaire | Accord écrit indispensable |
| Version imprimable / mobile | Redirection 301 plutôt que canonical | Quelques jours | La redirection est plus fiable qu'un canonical ici |
Comment vérifier l'effet de vos canonicals
Poser une balise, c'est une chose. Savoir si Google l'a suivie, c'en est une autre. Et là, une donnée change tout.
Le rapport « Pages » de Search Console
Dans le rapport « Indexation des pages », chaque URL listée indique l'« URL canonique choisie par Google ». Si cette URL diffère de celle que vous avez déclarée, c'est le signal clair que quelque chose coince. J'en fais mon premier réflexe de diagnostic, avant même d'aller inspecter le HTML page par page.
Sur un audit récent, ce rapport a révélé qu'un tiers des pages d'une catégorie étaient indexées sous une version que personne dans l'équipe n'avait jamais identifiée comme canonique. Le coupable : un ancien plan de redirections, oublié, qui renvoyait tout vers une URL de test.
Ce qu'aucun rapport ne vous dira
Search Console ne dit pas pourquoi Google a choisi telle URL. Elle constate. Pour comprendre la cause, il faut croiser plusieurs sources : inspecter le HTML, vérifier le sitemap, suivre le maillage interne depuis une page de référence.
Avouons-le, c'est fastidieux. Mais c'est souvent la seule façon de repérer une incohérence qu'aucun outil ne signalera comme telle.
Ce que je ferais différemment aujourd'hui
Une erreur que je regrette : avoir traité la canonicalisation comme une tâche technique isolée, confiée à une seule personne, alors qu'elle touche au sitemap, au maillage, aux redirections, parfois aux contrats de partenariat. Sur un site à forte volumétrie, cette fragmentation est la première cause de signaux contradictoires.
Deuxième erreur, plus discrète : avoir voulu canonifier trop agressivement. Sur certaines facettes qui généraient un trafic longue traîne réel, un canonical en bloc a fait disparaître de bonnes pages des résultats. Corriger a pris du temps, et le trafic n'est pas revenu d'un coup. Depuis, je vérifie systématiquement les requêtes associées avant de déclarer une facette « inutile ».
La leçon tient en une phrase : un canonical est une déclaration d'intention. Elle n'a de poids que si tout le reste du site la confirme.
Et une dernière chose, qui remet les choses en perspective. Google est plutôt doué pour repérer la bonne version d'une page quand on ne l'en empêche pas. La plupart des problèmes de canonicalisation que j'ai rencontrés venaient moins d'un manque de balises que d'un excès de signaux incohérents. Avant d'ajouter une énième directive, demandez-vous si vous n'en avez pas déjà trop.