Vérificateur de balise canonical

Colle une URL publique et vois tout le tableau canonical : la balise déclarée, le statut de sa cible, tout noindex ou second canonical caché, les redirections et les variantes http/https/www/slash.

Un vérificateur de canonical audite le canonical tel qu'il est en ligne sur une URL publique en ce moment, pas la balise qu'un plugin prétend poser. La plupart des bugs de canonical, ce n'est pas la balise elle même, c'est ce vers quoi elle pointe, donc cet outil regarde plus large. Colle une URL et il lit le canonical déclaré, confirme si cette cible répond avec un 200 propre, attrape un noindex ou un second canonical caché sur la destination, trace comment l'URL saisie redirige, et parcourt les variantes habituelles http, https, www et trailing-slash pour confirmer qu'elles convergent toutes vers une seule page. Il note le résultat et liste les corrections à faire en premier, exactement ce que tu veux le lendemain d'une migration ou d'une modif de permaliens.

Les requêtes passent par le service de lookup PeopleAreGeek. Nous ne journalisons rien.

Audit canonical et variantes d'URL

La plupart des bugs de canonical que j'ai traqués ? Ce n'était pas la balise. C'était ce vers quoi elle pointait. Du coup, cet outil regarde plus large. Est-ce que ton URL déclare un canonical qui tient la route, est-ce que cette cible répond vraiment avec un 200 propre, est-ce qu'elle traîne discrètement un noindex ou un deuxième canonical que tu avais oublié, comment l'URL que tu as tapée redirige, et est-ce que les variantes habituelles http/https/www/trailing-slash atterrissent toutes sur la même page. Colle une URL publique. Un seul passage, et tu vois tout.

Un canonical, c'est une indication. Pas un ordre. Google a toujours le dernier mot, point. Lis le à côté du statut de la réponse, des redirections, de tes signaux robots et de ce que le sitemap liste vraiment avant d'en croire un seul mot.

Ce qu'un vérificateur de canonical devrait trancher en premier

Un vérificateur de canonical répond à une seule question. Quand plusieurs URLs mènent au même contenu, laquelle compte ? Ça a l'air simple. Ça ne l'est pas, parce que cette question te tombe dessus sans arrêt : après une migration HTTPS, le jour où quelqu'un touche aux permaliens WordPress, la première fois qu'un lien de campagne se greffe un ?utm. Les templates de catégorie. Les archives paginées. Franchement, partout où un thème ou un plugin va discrètement fourrer des métadonnées dans le head pendant que tu regardes ailleurs.

Lire le texte de la balise ne te sauvera pas pour autant. Je veux bien voir que la page déclare quelque chose, d'accord. Mais l'URL qu'elle nomme, est-ce qu'elle est seulement vivante, est-ce qu'elle se cache derrière un noindex, est-ce qu'elle se retourne pour canonicaliser ailleurs encore, est-ce que les variantes http/www/slash convergent toutes vers un même endroit. Ce décalage (une balise existe versus la configuration est digne de confiance), c'est là que j'ai perdu le plus de mes après midis.

Self canonical et cross canonical sont deux décisions différentes

Tout ce que je veux vraiment voir ranker (un vrai article, une page d'outil) reçoit un self canonical par défaut. L'URL préférée pointe sur elle même et il ne reste plus rien à remettre en question. Le cross canonical a sa place aussi. Une page de campagne jetable qui se replie sur l'article evergreen qu'elle a copié, par exemple. Le cross canonical n'est pas le problème, cela dit. Le problème, c'est d'oublier que tu en as posé un. De le viser vers une URL qui fait un 301 ou qui porte un noindex. Ou, et celle là je l'ai personnellement faite, copier coller un template et saigner discrètement des signaux de ranking vers une page que tu n'as jamais voulu nourrir. Il m'a fallu une éternité pour repérer le truc.

Les redirections et les variantes comptent autour des balises canonical

Les gens oublient cette partie. Une balise canonical ne remplace pas un routage propre. Si tes versions http, https, www, non www et trailing-slash rebondissent encore à travers des redirections que personne n'a regardées depuis 2019, la balise ne fait que masquer un bazar que tu devrais plutôt corriger. Je veux que l'URL préférée soit évidente sous tous les angles. Tes liens internes l'utilisent. Le sitemap la liste. Chaque redirection y atterrit. Et oui, le canonical la nomme aussi. Je suis peut être tatillon, mais quand tout s'aligne, les approximations s'évaporent en grande partie.

Un workflow canonical concret

  1. Commence par l'URL exacte que quelque chose a signalée. Search Console, l'analytics, un lien interne, peu importe ce qui t'a traîné jusqu'ici.
  2. Lis le canonical déclaré et trace le chemin de la réponse avant de dire que c'est bon. Ne suppose pas, simplement.
  3. Suis la cible du canonical. Est-ce qu'elle répond ? Est-ce qu'elle est en noindex ? Est-ce qu'elle a son propre canonical ?
  4. Après chaque migration ou modif de permaliens, parcours les variantes host/protocole/slash. C'est là que les gremlins aiment se cacher.
  5. Ensuite, aligne tes liens internes et ton sitemap sur l'URL que tu veux vraiment voir indexée. La plomberie d'abord, la balise en dernier.

Questions fréquentes

Est-ce qu'une balise canonical est une redirection ?

Non. Et les confondre cause de vrais maux de tête. Une redirection déplace physiquement la requête, donc le navigateur finit réellement ailleurs. Un canonical, lui, se contente de souffler une suggestion aux moteurs de recherche sur quelle URL mérite le crédit quand le même contenu vit à plusieurs adresses. Ton visiteur ne bouge pas. Seul le calcul de l'indexation change sous le capot.

Est-ce qu'un canonical peut pointer vers une autre page ?

Bien sûr, si les pages sont de vrais doublons ou des quasi jumelles et que tu l'as fait exprès. Parfaitement légitime. Ce qu'il ne faut pas faire, c'est viser un canonical vers une page sans rapport, plus costaude, en espérant que le jus de lien déteigne. Google est devenu plutôt bon pour ignorer ce coup là. Dans le meilleur des cas, tu viens juste de lui dire d'oublier la page que tu voulais réellement voir ranker. Ce qui, tu vois, va à l'encontre du but.

Est-ce qu'un canonical garantit l'indexation ?

Non. Et le traiter comme tel finira par te brûler. Vois ça comme un seul bulletin dans une élection bien plus large. Est-ce que la page peut seulement être crawlée, est-ce que le contenu vaut la peine d'être gardé, est-ce que des liens internes pointent vers elle, que disent tes règles robots, est-ce qu'elle est dans le sitemap. Ensuite le moteur de recherche prend sa propre décision. Un canonical propre améliore tes chances. Il ne force la main de personne.

Que se passe-t-il si mon canonical pointe vers la mauvaise URL ?

C'est celle là qui fait vraiment mal. Les moteurs de recherche ont tendance à te prendre au mot, donc nomme la mauvaise URL et ils pourraient discrètement abandonner la bonne page à son profit. Et voilà un contenu parfaitement valable qui glisse hors de l'index sans raison évidente. Donc avant de faire confiance à un canonical, vérifie qu'il atterrit sur une page vivante, indexable, en statut 200. C'est exactement ce que cet outil vérifie pour toi.