Les questions fréquentes sur la canonicalisation des URLs : le guide complet

Canonicalisation des URLs : les questions qu'on me pose vraiment

La question qui revient le plus souvent dans ma boîte mail, ce n'est pas « comment fonctionne une balise canonical ». C'est plutôt : « j'ai tout mis en place, et Google choisit quand même une autre URL que la mienne. Pourquoi ? »

Et là, je comprends la frustration. Parce que pendant des années, on nous a vendu la canonical comme un ordre. Un truc qu'on pose dans le <head> et qui règle le problème. Sauf que ce n'est pas un ordre. C'est une indication, un signal qu'on souffle au moteur, qui décide ensuite s'il veut bien l'écouter.

Je vais répondre aux questions qu'on me pose le plus souvent, en essayant d'aller au-delà de la définition qu'on trouve partout.

Une balise canonical, c'est un ordre ou une suggestion ?

Une suggestion. Voilà, c'est dit.

La balise rel="canonical" sert à désigner l'URL que vous considérez comme la version de référence d'une page. Quand plusieurs adresses affichent un contenu identique ou très proche (paramètres de tracking, variations de tri, produit rangé dans trois catégories), elle indique au moteur laquelle doit être indexée et hériter de la popularité des autres.

Mais Google recoupe. Il regarde la canonical, il regarde aussi les liens internes qui pointent vers la page, les redirections, le contenu réellement affiché, la cohérence du maillage, et parfois le sitemap. Si votre canonical dit une chose et que trois autres signaux en disent une autre, il tranche contre vous.

Pourquoi Google choisit parfois une autre URL que celle que je désigne ?

Parce que vos signaux se contredisent. Les cas que je rencontre le plus :

• Vous déclarez A comme canonique, mais tous vos liens internes pointent vers B. Le moteur suit les liens, pas votre déclaration isolée.
• La page A est en noindex. Une canonical qui cible une page non indexable, c'est une contradiction directe.
• Le contenu de A et B diffère suffisamment pour que la canonical paraisse abusive.
• A redirige en 301 vers C. Une canonical vers une URL qui redirige est considérée comme invalide.

La règle que j'applique depuis des années : la canonical doit confirmer ce que le reste du site raconte déjà. Si elle doit corriger une incohérence, c'est qu'il y a un problème ailleurs à régler d'abord.

Faut-il une URL absolue ou relative ?

Les deux fonctionnent. Google résout les relatives sans problème. L'absolue reste plus sûre sur les gros sites, parce qu'une relative mal construite peut pointer vers une URL que vous n'aviez pas prévue à cause d'un <base> oublié. C'est un détail, mais sur un catalogue de 20 000 pages, ce genre de détail fait mal.

La canonical ne se limite pas à la balise HTML

Voilà l'angle que je vois rarement traité, et pourtant il change tout sur les sites techniques.

Il existe au moins trois façons de signaler une URL canonique. La balise dans le <head>, l'en-tête HTTP Link, et le sitemap XML. Sur un PDF, une image ou une ressource non HTML, vous n'avez pas de <head> — seule la méthode HTTP est disponible.

Le piège, c'est quand ces signaux divergent. J'ai audité un site e-commerce où le sitemap listait 4 000 URLs, dont un millier déclaraient dans leur HTML une canonical vers une autre adresse. Résultat : le moteur passe du temps à arbitrer, et le budget de crawl part dans des arbitrages stériles.

Méthode	Où elle s'applique	Point de vigilance
Balise HTML rel="canonical"	Pages HTML classiques	Inutilisable si le rendu JS arrive après coup
En-tête HTTP Link	PDF, images, fichiers non HTML	Doit être envoyé avec le bon code de statut
Sitemap XML	Tout type d'URL	Signal faible : ne remplace pas la balise

Une chose importante : ces trois sources sont traitées comme des indications. Aucune ne force la main. Si elles se contredisent, le moteur choisit selon sa propre logique, et vous perdez la main sur la version indexée.

Et sur un site rendu en JavaScript, ça marche encore ?

Moins bien, oui. Et c'est là que beaucoup de monde se fait piéger sans le savoir.

Si votre canonical est injectée par du JavaScript après le chargement de la page, elle peut très bien ne jamais être vue. Google exécute le JS, mais dans un second temps, avec des ressources limitées. Sur une SPA qui met trois secondes à s'hydrater, la balise peut arriver trop tard ou pas du tout.

La solution que je recommande, et que j'applique sur mes propres projets : rendre la canonical côté serveur (SSR ou pré-rendu). Elle doit être présente dans le HTML initial, avant toute exécution de script. Si vous ne pouvez vraiment pas, l'en-tête HTTP reste un filet de sécurité.

Et le conflit avec hreflang ou les paramètres de langue ?

Cas classique : vous avez monsite.com/page et monsite.com/en/page. La seconde ne doit pas être canonisée vers la première, sinon vous dites au moteur que la version anglaise n'a aucune raison d'exister. Chaque version linguistique est sa propre canonique, et c'est le hreflang qui fait le lien entre elles, pas la canonical.

Je l'ai vu deux fois cette année sur des sites clients. Dans les deux cas, la version anglaise avait disparu des résultats. Le diagnostic a pris dix minutes une fois qu'on savait où regarder.

Comment vérifier que mes canonicals sont bien prises en compte ?

Trois outils, dans cet ordre.

1. La Search Console, section indexation. Le rapport sur les pages en double sans URL canonique sélectionnée vous montre exactement où le moteur a tranché différemment de vous. C'est la source la plus directe.
2. Un crawl complet avec un outil type Screaming Frog. Vous exportez toutes les canonicals déclarées, vous comparez avec le code de statut, le noindex, les redirections. Les incohérences sautent aux yeux sur un tri.
3. Les logs serveur. Ils vous disent quelles URLs le robot visite réellement, et à quelle fréquence. Une page canonique jamais crawlée est un signal d'alarme.

Pour mesurer l'effet d'une correction, je regarde une chose simple : le nombre d'URLs indexées pour un même contenu. Si trois variantes étaient indexées avant et qu'il n'en reste qu'une après, c'est gagné. Le reste (position, trafic) suit avec du décalage.

Doit-on supprimer les anciennes URLs après avoir posé une canonical ?

Non, surtout pas. La canonical et la redirection ne font pas le même travail. Si une URL ne doit plus exister du tout, redirigez en 301. Si elle doit rester accessible mais ne pas être indexée séparément, gardez-la avec sa canonical. Supprimer une URL qui reçoit des liens externes, c'est jeter de la popularité à la poubelle.

Les erreurs qui coûtent le plus cher

Un client m'a envoyé un audit il y a quelques mois. Son catalogue affichait 12 000 URLs indexées pour 2 100 produits réels. Le coupable : des canonicals générées automatiquement qui pointaient vers la page d'accueil dès qu'un paramètre inconnu apparaissait dans l'URL.

Six semaines après correction, le nombre d'URLs indexées était retombé sous 3 000. Le trafic organique, lui, n'a pas bougé d'un iota pendant les deux premières semaines, puis a grimpé de façon régulière sur les trois mois suivants.

Les erreurs que je vois le plus souvent :

• Une canonical qui pointe vers une page en noindex, une 404 ou une redirection. Dans ce cas, le moteur l'ignore purement et simplement.
• Des boucles canoniques : A déclare B comme canonique, B déclare A. Le moteur abandonne les deux.
• Une canonical identique sur toutes les pages d'un site, souvent à cause d'un template mal configuré. Le moteur finit par ne plus faire confiance à aucune.
• La balise placée dans le <body> au lieu du <head>. Elle est alors ignorée.
• Une pagination où la page 2 est canonisée vers la page 1. Vous dites alors au moteur que vos articles suivants n'existent pas.

Un mot sur ce dernier point, tiens. La question de la pagination a longtemps fait débat, et certaines pratiques recommandées autrefois ont été revues. Si vous appliquez encore un schéma trouvé dans un article d'il y a cinq ans, vérifiez qu'il tient toujours. Le sujet a bougé.

Ce qu'il faut retenir de tout ça

La canonicalisation, ce n'est pas une case à cocher. C'est un travail de cohérence.

Posez-vous une seule question avant chaque déploiement : est-ce que tous mes signaux racontent la même histoire ? La balise, les liens internes, le sitemap, le rendu côté serveur. Si un seul élément raconte autre chose, c'est lui que le moteur écoutera peut-être à votre place.

Et si vous devez retenir une chose de cet article, ce serait celle-là : la canonical ne crée pas de la cohérence, elle la confirme. Le jour où vous comprendrez ça, vous arrêterez de vous demander pourquoi Google vous ignore.

La vraie question n'est d'ailleurs peut-être pas « ma canonical est-elle bien posée ». C'est plutôt : « pourquoi mon site laisse-t-il le moteur arbitrer à ma place ? »