Balises canoniques : la solution simple contre le contenu dupliqué

Une question revient sans arrêt quand on audite un site : « pourquoi Google refuse d'indexer ma page préférée alors qu'elle est en ligne ? » Et neuf fois sur dix, la réponse tient à trois lignes de code dans le

, que personne n'a relues depuis des mois. La balise canonique. Petit bout de HTML anodin, capable de faire disparaître une page de l'index sans le moindre message d'erreur.

Je l'ai appris à mes dépens. Sur un ancien projet e-commerce, j'avais deux fiches produit quasi identiques — une déclinaison de couleur, l'autre de taille — qui se tiraient dans les pattes depuis des semaines. Google avait choisi d'en indexer une seule, et pas celle que je voulais. Résultat : mes pages catégories ont perdu 40 % de trafic organique pendant deux mois avant que je comprenne le mécanisme. Voilà ce que cet article va vous éviter.

Balises canoniques : comprendre ce que Google fait vraiment de votre déclaration

Ce que 90 % des tutos oublient de dire : la canonical n'est pas un ordre, c'est une suggestion. Google s'en sert comme signal, pas comme commande. Et c'est justement là que ça devient embarrassant, parce qu'une suggestion mal formulée peut être suivie à la lettre — y compris quand elle est fausse.

Ce que la balise fait concrètement

Quand vous placez ceci dans le

de la page B :

<link rel="canonical" href="https://exemple.fr/page-a/">

Vous dites à Google : « la version officielle de cette page, c'est l'URL de page A ». Google va alors fusionner les signaux des deux versions — PageRank, liens entrants, historique — vers page A. Page B peut continuer d'exister, d'être visitée par des humains, mais elle n'apparaîtra plus dans l'index sous sa propre URL.

Le problème ? Google peut ignorer votre canonical et décider lui-même. « Peut ». En pratique, quand les signaux sont cohérents (contenu identique, liens internes pointant vers la même URL, sitemap aligné), il suit votre déclaration. Quand ils ne le sont pas, il tranche seul — et pas toujours en votre faveur.

Canonical et redirection 301 : la différence que tout le monde confond

La redirection 301 déplace l'utilisateur. La canonical, non. Si votre page B a des liens entrants (backlinks, partages sociaux, signets), une redirection 301 les fait basculer entièrement vers A. Une canonical, elle, laisse la page B accessible mais demande à Google de considérer A comme prioritaire pour l'indexation.

Autrement dit : la 301 est un transfert, la canonical est une déclaration. Les deux ne se remplacent pas. Sur un site que j'ai repris l'an dernier, le précédent prestataire avait posé des canonicals sur des URLs qui auraient dû rediriger proprement. Résultat : les anciennes URLs continuaient d'exister, de répondre en 200, et Google devait gérer un arbitrage à chaque crawl. On a perdu deux semaines de budget crawl pour rien.

Les signaux canoniques : le classement que personne ne donne

Voilà l'information que je n'ai trouvée nulle part quand j'ai commencé. Tous les guides disent « utilisez une canonical », aucun ne précise dans quel ordre Google hiérarchise ses signaux quand ils se contredisent.

Du plus fort au plus faible

1. La redirection 301 — signal le plus fort. Google traite l'URL source comme définitivement déplacée.
2. La balise canonical — signal principal quand aucune redirection n'existe.
3. Les liens internes — si 15 pages de votre site pointent vers l'URL A et 2 vers l'URL B, Google comprend où va votre préférence.
4. Le sitemap XML.
5. La similarité de contenu (analyse sémantique automatique).

Cette hiérarchie explique des situations qui paraissent absurdes. J'ai vu un site où la canonical déclarait A, mais où le menu principal, le fil d'Ariane et le sitemap pointaient tous vers B. Google a indexé B. La canonical était « respectée » au sens où elle existait — mais elle a été neutralisée par des signaux plus cohérents entre eux.

Application concrète

Avant de poser une canonical, vérifiez trois choses :

• Le lien interne qui mène à la page pointe-t-il vers l'URL canonique (pas une variante) ?
• Le sitemap liste-t-il la bonne URL ?
• Si la page A et la page B sont vraiment quasi identiques, une 301 ne serait-elle pas plus propre ?

La règle que j'applique maintenant sans réfléchir : si je peux rediriger, je redirige. Si je ne peux pas (parce que je veux garder la page accessible), je canonicalise. Et je ne fais jamais les deux en même temps.

Quand la canonical se retourne contre vous

Un client m'a envoyé un mail paniqué il y a quelques mois : « mes 300 fiches produit ont disparu de Google en une nuit ». Vérification faite, elles étaient bien là — mais l'index n'en affichait plus que 12. Le développeur qui avait géré une refonte avait copié-collé un template avec une canonical codée en dur vers la page d'accueil. Toutes les fiches produit déclaraient donc l'accueil comme version de référence.

Google a suivi. Trop bien suivi.

Ce cas illustre la règle que tout le monde devrait connaître : Google respecte les canonicals erronées dans la grande majorité des cas. Il ne se demande pas si vous avez fait exprès. Il lit ce que vous déclarez et il agit en conséquence.

Les erreurs qui coûtent cher

• URL relative au lieu d'absolue — /page-a/ au lieu de https://exemple.fr/page-a/. Ça fonctionne parfois, ça casse souvent, et vous ne saurez jamais pourquoi.
• Plusieurs canonicals sur la même page — Google ignore les deux. Vous perdez tout contrôle.
• Canonical pointant vers une 404 — le signal tombe dans le vide.
• Canonical + noindex sur la même page — configuration contradictoire. La page est retirée de l'index et les signaux ne sont pas transférés. C'est le pire scénario possible.
• Canonical vers une URL bloquée en robots.txt — Google ne peut pas lire la cible, il abandonne le signal.

Canonical et hreflang : le duo qui se marche dessus

Sur un site multilingue, une erreur classique consiste à pointer la canonical de exemple.fr/produit vers exemple.com/product. Mauvaise idée pour deux raisons. D'abord, vous demandez à Google de ne conserver qu'une version linguistique dans l'index. Ensuite, vous entrez en conflit avec les balises hreflang qui, elles, déclarent que les deux versions doivent coexister pour servir des audiences différentes.

La règle est simple : sur un site multilingue bien construit, chaque version linguistique doit avoir une canonical vers elle-même. L'auto-référence est votre amie.

Le cas e-commerce : facettes et paramètres d'URL

Imaginez une boutique en ligne avec 800 produits. Chaque produit peut être filtré par couleur, taille, prix, disponibilité, marque. Chaque combinaison génère une URL distincte. En théorie, ça fait plusieurs centaines de milliers d'URLs possibles. En pratique, Google en crawl une fraction — mais cette fraction peut être la mauvaise.

La méthode que j'utilise

1. Lister les paramètres actifs — ceux qui modifient réellement le contenu affiché.
2. Décider pour chacun — indexable ou non. Un filtre de couleur qui génère une page avec les mêmes textes que la page mère ? Non. Un filtre de marque qui affiche des produits différents ? Peut-être.
3. Poser une canonical vers la page mère sur les combinaisons que vous ne voulez pas indexer.
4. Bloquer le crawl des paramètres de tri, de session, de tracking — ces derniers génèrent des URLs infinies et n'apportent aucune valeur SEO.

Sur un site que j'ai suivi, ce nettoyage a fait baisser le nombre d'URLs crawlées par Google de 82 % en un mois. Le budget crawl économisé est allé aux pages qui comptaient vraiment.

Diagnostiquer les problèmes de canonical sur son propre site

On ne corrige bien que ce qu'on sait détecter. Voici une procédure en quatre étapes, celle que je déroule systématiquement quand je reprends un site inconnu.

Étape 1 : le rapport « Pages en double, URL canonique différente »

Dans la Search Console, section Indexation. Ce rapport liste les URLs que Google a crawlées, qui ressemblent à une autre, et pour lesquelles une canonical a été détectée. Si vous y voyez des URLs que vous vouliez indexer, il y a un problème. Si vous y voyez exactement les URLs que vous avez volontairement canonicalisées, tout va bien.

Je regarde ce rapport une fois par mois sur les sites que je gère. Les nouvelles lignes sont souvent le signe qu'un module a été mis à jour ou qu'un paramètre a été ajouté à l'insu de l'équipe technique.

Étape 2 : un crawl complet

Avec un outil comme Screaming Frog (ou équivalent), je crawle le site entier et je filtre sur les balises canonical. Je cherche trois choses :

• Les canonicals absentes sur des pages qui en auraient besoin.
• Les canonicals pointant vers une URL qui n'est pas en 200 (erreur, redirection, 404).
• Les canonicals vers une URL différente du rel=canonical auto-référent attendu.

Étape 3 : croisement avec le sitemap

Un sitemap qui déclare une URL différente de celle vers laquelle pointe la canonical génère un conflit inutile. J'exporte les deux listes, je fais un diff. Le nombre de divergences me donne une idée de la propreté générale du site.

Étape 4 : test en live

Pour deux ou trois pages critiques, j'inspecte l'URL dans la Search Console et je regarde « URL canonique déclarée par l'utilisateur » et « URL canonique sélectionnée par Google ». Quand ces deux champs divergent, vous avez identifié la cause de votre problème d'indexation.

Tableau comparatif : canonical, 301, noindex, robots.txt

Méthode	Ce qu'elle fait	Quand l'utiliser	Effet sur le PageRank
Canonical	Déclare une version de référence, page source reste accessible	Variantes de paramètres, pages quasi identiques devant coexister	Consolidation vers la cible
Redirection 301	Déplace définitivement l'URL source vers la cible	Refonte, fusion de pages, changement d'URL	Transfert complet
noindex	Retire la page de l'index	Pages à ne jamais afficher dans les résultats	Aucun transfert
robots.txt (Disallow)	Empêche le crawl de l'URL	Paramètres techniques, dossiers sensibles	Aucun transfert, signaux perdus

Note importante sur la combinaison noindex + canonical : elle est presque toujours contre-productive. Si vous voulez que la page B disparaisse de l'index mais que ses signaux aillent vers A, utilisez une 301. Le combo canonique + noindex est un piège dans lequel je suis tombé une fois — et je ne le referai pas.

La checklist que je passe avant chaque mise en ligne

Personne n'a envie de relire 400 balises canonical à la main. Mais cinq minutes de vérification ciblée évitent trois semaines de galère. Voilà ce que je vérifie systématiquement :

• Une seule balise canonical par page, dans le .
• URL absolue, en HTTPS, sans paramètre de tracking.
• Cohérence avec la version canonique déclarée dans le sitemap.
• Pas de conflit avec noindex ou hreflang.
• Test sur trois pages types : accueil, page catégorie, fiche produit.
• Vérification post-déploiement dans la Search Console, 48h après.

Ce dernier point est celui que je vois le plus souvent sauté. Le déploiement passe, tout semble normal, et l'équipe passe à autre chose. Trois semaines plus tard, quelqu'un remarque une baisse de trafic. Le lien de cause à effet est déjà difficile à reconstituer.

Ce qui reste après toutes ces vérifications

La balise canonique n'a rien de magique. C'est une déclaration de préférence. Elle ne fait que dire à Google : « si tu dois choisir entre ces deux pages, prends celle-là ». Le reste — le crawl, l'indexation, l'arbitrage final — reste du côté de Google.

Ce que j'ai fini par comprendre en gérant plusieurs sites, c'est que la canonical est surtout un révélateur. Quand elle est mal posée, ce n'est presque jamais un problème de balise. C'est un problème de structure : une arborescence floue, des URLs qui ne suivent pas de logique claire, un sitemap généré automatiquement qui ne correspond plus à la réalité. La balise ne fait qu'exposer ce désordre.

Alors avant de plonger dans votre fichier

pour tout réécrire, posez-vous une question différente : si vous deviez expliquer à un nouvel arrivant quelle URL représente quoi sur votre site, sauriez-vous le faire en moins de deux minutes ? Si la réponse est non, aucun correctif technique ne tiendra longtemps.