Un client m'écrit la semaine dernière, paniqué : "Google a choisi une autre URL que celle que j'ai déclarée en canonical. C'est la fin du monde ?" Non. C'est même assez banal. Mais avant de comprendre pourquoi, il faut accepter une vérité que la plupart des articles sur le sujet passent sous silence : votre balise canonical n'est pas un ordre, c'est une suggestion. Et Google se réserve le droit de l'ignorer. Une fois qu'on a intégré ça, tout le reste devient beaucoup plus clair.
Points clés à retenir
- La canonical est un signal, pas une directive. Google peut sélectionner une autre URL que celle que vous déclarez.
- Le diagnostic passe d'abord par GSC : comparez canonicals déclarées et canonicals sélectionnées.
- Ne mélangez jamais canonical et noindex sur la même page — les signaux se contredisent.
- L'auto-référencement n'est pas une décoration : c'est votre filet de sécurité.
- Canonical, redirection 301, noindex et robots.txt ne répondent pas au même problème. Choisir le bon outil, c'est tout le métier.
La balise canonical n'est qu'une suggestion (et ça change tout)
La définition tient en une ligne : la balise canonical indique à Google quelle URL vous considérez comme la version de référence d'un contenu accessible à plusieurs adresses. Le fameux <link rel="canonical" href="..." /> que vous placez dans le <head>. Sur le papier, c'est simple. Dans la vraie vie, on découvre assez vite une nuance : Google traite ce signal comme un indice. Il l'utilise, le pèse, et parfois décide autrement.
Je l'ai vu concrètement sur une boutique que je suivais : la canonical déclarée sur une fiche produit pointait vers la version propre, mais Google avait élu une URL avec un paramètre de filtre. Pourquoi ? Parce que cette version recevait le plus de liens internes. Google ne lit pas votre intention, il lit les signaux.
Pourquoi Google se permet de vous ignorer
Trois raisons reviennent le plus souvent.
- Incohérence entre votre canonical et d'autres signaux (hreflang, maillage interne, sitemap).
- Contenu réellement différent entre les deux URLs — Google considère alors qu'il ne s'agit pas de doublons.
- Liens internes pointant massivement vers l'URL que vous vouliez "écraser".
Le maillage interne, franchement, c'est le coupable numéro un. Vous pouvez déclarer ce que vous voulez, si tous vos menus pointent vers l'autre version, vous vous battez contre vous-même. La canonical n'annule pas la logique de liens.
Canonical ou redirection 301 : le vrai critère de choix
C'est la question qu'on me pose sans arrêt. La réponse tient à la nature du doublon.
Si deux URLs servent exactement le même contenu et que vous voulez que l'une disparaisse complètement aux yeux des utilisateurs, utilisez une redirection 301. La page d'origine n'existe plus, point. Si vos deux URLs doivent continuer à fonctionner (variantes de tri, versions linguistiques, paramètres marketing), la canonical est l'outil adapté. Elle consolide les signaux sans casser l'accès.
| Outil | Quand l'utiliser | Ce qu'il fait |
|---|---|---|
| Canonical | Doublons qui doivent rester accessibles | Consolide les signaux (suggestion) |
| Redirection 301 | Ancienne URL à supprimer définitivement | Transfert obligatoire des signaux |
| noindex | Page à retirer de l'index | Exclusion, mais le crawl continue |
| robots.txt | Bloquer le crawl d'une zone entière | Empêche l'exploration, pas l'indexation |
Petit piège classique : mettre une canonical et un noindex sur la même page. Les deux signaux se contredisent. Google reçoit un message du genre "voici ma version préférée, mais ne l'indexe pas". Résultat : il tranche lui-même, et pas toujours dans votre sens.
Comment auditer ses canonicals sans y passer une semaine
Un audit de canonicals, ce n'est pas sorcier, mais il faut une méthode. Voici celle que j'applique aujourd'hui, dans cet ordre.
Étape 1 : comparer déclarées et sélectionnées dans la Search Console
La Search Console vous donne une information en or : la distinction entre la canonical que vous avez déclarée et celle que Google a sélectionnée. Quand les deux divergent, vous avez votre première piste. Ce rapport est passé relativement discret dans les interfaces, mais c'est votre meilleur point de départ.
Étape 2 : crawler le site et repérer les anomalies
Un crawler comme Screaming Frog (ou son équivalent open source) remonte en quelques minutes les cas problématiques. Ce que vous cherchez :
- Les pages sans auto-référencement — la canonical absente sur une page unique, c'est une invitation à la confusion.
- Les canonicals en URL relative au lieu d'absolue. Fonctionne parfois, mais c'est une source d'erreurs inutile.
- Les canonicals qui pointent vers une page en 404 ou en noindex. Erreur grossière, mais fréquente.
- Les canonicals générées en JavaScript — qu'un rendu côté client mal exécuté peut faire disparaître.
- Les canonicals auto-pointant vers une URL paginée, ce qui étouffe la pagination elle-même.
Étape 3 : traquer les conflits avec les autres signaux
Une canonical isolée ne veut rien dire. Il faut la confronter à son environnement : hreflang, sitemap, structure des paramètres d'URL, directives robots. J'ai mis plusieurs mois à comprendre que sur les sites multilingues, une canonical mal placée peut casser tout le hreflang. La règle : chaque version linguistique doit se canonicaliser vers elle-même, pas vers la version anglaise.
Pour les facettes et paramètres d'URL, c'est le même combat. Une facette de filtre qui génère des milliers d'URLs doit être gérée soit par canonical vers la catégorie principale, soit par une règle robots.txt propre. Faites-le mal et votre budget crawl part en fumée.
Les canonicals dynamiques : là où ça déraille vraiment
Sur les CMS modernes, la canonical est rarement écrite à la main. Elle est générée. Et cette génération, quand elle est mal paramétrée, produit des absurdités que personne ne remarque avant des mois.
Les erreurs que je rencontre le plus souvent
- Une canonical qui pointe systématiquement vers la racine du site au lieu de la page courante. Catastrophique, mais étonnamment courant.
- Des plugins SEO mal configurés qui appliquent la même valeur à toutes les pages d'un modèle.
- Une canonical qui change selon l'utilisateur ou la session — invisible pour vous, visible pour Googlebot.
- Sur les architectures JS, une canonical injectée côté client qui n'apparaît pas dans le HTML rendu une fois sur deux.
Mon conseil : testez toujours le rendu final, celui que voit le robot, pas celui que vous voyez dans votre navigateur connecté à votre compte admin. L'écart entre les deux est souvent là où se cache le problème.
Faut-il une canonical sur chaque page ?
Oui, en auto-référencement. Une page qui se canonicalise vers elle-même ne fait rien de spectaculaire, mais elle prévient tout un tas de dérapages. C'est trois caractères et demi de HTML qui vous économisent des heures de diagnostic. Je ne vois aucune raison de s'en priver.
Ce qu'il faut retenir, en clair
La balise canonical est l'un de ces sujets où la théorie rassure et la pratique surprend. On croit poser une règle, on pose en réalité une intention que Google interprète. C'est frustrant. C'est aussi ce qui rend l'optimisation intéressante : il ne s'agit pas de cocher une case, mais d'aligner tous vos signaux dans la même direction.
Si je devais résumer en une phrase : votre canonical n'a de valeur que si le reste du site lui donne raison. Un maillage interne cohérent, un sitemap propre, un hreflang bien posé, une pagination correcte. Le jour où votre canonical déclarée et celle que Google retient coïncident à 100 % dans la Search Console, vous savez que vous avez fait le travail. Pas avant.
Et ce client paniqué de la semaine dernière ? On a découvert que son menu pointait vers la mauvaise URL depuis huit mois. La canonical n'y était pour rien. C'était le maillage. C'est presque toujours le maillage.
