Ce qu'un vérificateur de canonique fait réellement
Un vérificateur de canonique récupère une URL, analyse la section HTML <head> pour <link rel="canonical" href="...">, lit l'en-tête HTTP Link: <...>; rel="canonical" et compare les deux. Si les deux sont présents et diffèrent, il y a un conflit. Si aucun n'est présent, la page n'a pas de canonique explicite et risque des problèmes de contenu dupliqué.
Il génère aussi les variantes d'URL courantes et teste chacune. Étant donné https://www.example.com/page, nous testons http://www.example.com/page, https://example.com/page, http://example.com/page, https://www.example.com/page/, et https://www.example.com/page?utm_source=test. Chaque variante peut retourner un canonique différent, une redirection, ou le même canonique que l'original. Notre vérificateur mappe les résultats pour que vous voyiez l'image complète dans un seul tableau.
Trois problèmes apparaissent régulièrement. Le premier est les canoniques inter-domaines — où la balise pointe vers un domaine entièrement différent, généralement après une migration ou une mauvaise configuration CDN. Le second est les chaînes de redirection — où une URL se canonicalise vers une autre URL qui redirige vers une troisième. Le troisième est les canoniques manquants sur les pages paginées ou filtrées, ce qui entraîne des pénalités de contenu dupliqué.
Comment utiliser ce vérificateur de canonique
- Collez votre URL dans Primary URL. Utilisez la version que vous considérez comme canonique — généralement https, www si vous l'utilisez, et pas de barre oblique finale sauf si votre CMS l'exige.
- Collez les variantes supplémentaires dans Extra variants to check si vous voulez tester des URL spécifiques. Une par ligne. Nous générons automatiquement les variantes courantes (protocole, sous-domaine, barre oblique), donc ce champ est facultatif.
- Cliquez sur Check canonicals. Vous obtenez un tableau avec une ligne par URL testée. Chaque ligne affiche l'URL, le code de statut HTTP, le canonique trouvé dans la balise HTML, le canonique trouvé dans l'en-tête HTTP, et s'ils correspondent.
- Regardez la colonne Conflicts. Un drapeau rouge signifie que le canonique HTML diffère du canonique HTTP, ou que l'URL se canonicalise vers elle-même alors qu'elle ne devrait pas, ou que le canonique pointe vers une URL qui retourne 404.
- Cliquez sur Download report pour exporter le tableau en CSV. Utilisez-le pour corriger en masse les canoniques dans votre CMS ou passez-le à un développeur.
Essayez de vérifier https://www.example.com/page sur un site WordPress. Vous pourriez découvrir que la version www se canonicalise vers https://www.example.com/page (non-www) et que la version non-www se canonicalise vers elle-même. Si les deux versions retournent 200, Google pourrait les traiter comme des doublons sauf si l'une redirige vers l'autre. Le vérificateur montre ce conflit en une seule passe.
Pourquoi les variantes d'URL créent du contenu dupliqué
Google traite https://example.com/page, https://www.example.com/page, http://example.com/page, et https://example.com/page/ comme quatre URL distinctes. Si les quatre retournent 200 et affichent un contenu identique, Google doit deviner lequel est l'original. Les balises canoniques éliminent l'incertitude en déclarant une URL comme source. Les trois autres devraient soit rediriger vers le canonique, soit inclure une balise canonique pointant vers lui.
Trois conséquences pratiques.
Dilution du capital de lien. Si la moitié de vos backlinks pointent vers la version www et la moitié vers la version non-www, Google voit deux pages se partageant l'autorité. Un canonique consolide ce capital sur une URL.
Gaspillage de budget de crawl. Si Google crawle toutes les quatre variantes, il utilise quatre requêtes pour indexer une page. Sur les grands sites, cela se multiplie sur des milliers de pages. Les balises canoniques ou les redirections 301 arrêtent la duplication.
Confusion d'index. Google pourrait indexer la mauvaise variante — la version http au lieu de https, ou la version avec barre oblique alors que vous préférez pas de barre. Une balise canonique indique à Google laquelle montrer dans les résultats de recherche.
Canonique HTML vs canonique en en-tête HTTP
Le canonique HTML se trouve dans le <head> : <link rel="canonical" href="https://example.com/page">. Le canonique en en-tête HTTP se trouve dans les en-têtes de réponse : Link: <https://example.com/page>; rel="canonical". Les deux servent le même objectif. Si les deux sont présents et en accord, parfait. Si les deux sont présents et diffèrent, Google en choisit un — généralement l'en-tête HTTP car il est envoyé avant que le HTML ne soit analysé.
Les CDN, les proxies et les redirections côté serveur ajoutent parfois des canoniques en en-tête HTTP sans que le propriétaire du site le sache. Si votre CMS génère un canonique HTML pointant vers l'URL A, mais votre CDN ajoute un en-tête HTTP pointant vers l'URL B, vous avez un conflit silencieux. Notre vérificateur montre les deux pour que vous puissiez détecter les disparités.
Certains CMS et frameworks définissent les canoniques de manière incorrecte par défaut. Shopify canonicalise parfois les URLs de produits vers la première collection dans laquelle ils apparaissent, même si le produit est dans cinq collections. Les installations WordPress multisite peuvent se canonicaliser vers le mauvais sous-domaine si le paramètre d'URL du site est périmé. Tester les variantes révèle ces cas limites.
Canoniques auto-référencés et quand ils importent
Un canonique auto-référencé signifie que la balise canonique de l'URL pointe vers elle-même : <link rel="canonical" href="https://example.com/page"> sur https://example.com/page. C'est correct pour la version canonique d'une page. Cela indique à Google « c'est l'original, pas un doublon ».
Cependant, si une variante s'auto-référence — https://example.com/page/ se canonicalise vers elle-même au lieu de la version sans barre oblique — vous avez un problème. Google voit deux URLs auto-référencées avec un contenu identique et doit en choisir une. La meilleure correction est de rediriger 301 la version avec barre oblique vers la version sans barre oblique, ou de canonicaliser la version avec barre oblique vers la version sans barre oblique.
Les URLs paginées — /blog/page/2, /blog/page/3 — devraient se canonicaliser vers elles-mêmes, pas vers /blog, car chaque page a un contenu unique. Les URLs filtrées ou triées — /products?sort=price — devraient souvent se canonicaliser vers la version non-filtrée /products car le contenu se chevauche. Notre vérificateur n'applique pas automatiquement ces règles ; il montre le canonique que vous avez défini et signale les incohérences. Vous décidez de la politique.
Erreurs courantes
- Chaque URL se canonicalisant vers la page d'accueil. Certains plugins et thèmes utilisent cela par défaut. Cela indique à Google que chaque page est un doublon de la page d'accueil. Vérifiez une page profonde — un article de blog ou un produit — pour confirmer qu'elle se canonicalise vers elle-même, pas vers
/. - Canonique pointe vers un 404. Après une migration ou un changement d'URL, les anciennes pages peuvent encore se canonicaliser vers des URLs qui n'existent plus. Notre vérificateur récupère l'URL canonique et rapporte le code de statut. Si c'est 404, supprimez le canonique ou mettez-le à jour.
- Canonique pointe vers une redirection. Si le canonique est
https://example.com/oldmais cette URL fait 301 vers/new, Google doit suivre la redirection. Mieux vaut canonicaliser directement vers/new. - Utiliser des URLs relatives dans la balise canonique.
<link rel="canonical" href="/page">fonctionne dans la plupart des navigateurs mais est techniquement invalide. Utilisez des URLs absolues :href="https://example.com/page". - Canonicaliser http vers https sans rediriger. Si la version http se canonicalise vers https mais retourne toujours 200, les utilisateurs sur l'URL http voient des avertissements de contenu mixte et restent sur http. Une redirection 301 est préférable à une balise canonique pour les changements de protocole.
- Tester seulement la version canonique. Vous devez tester les variantes pour voir ce qu'elles font. Si la version www ne se canonicalise pas vers la version non-www, vous avez un doublon.
Conseils avancés
- Testez une URL de chaque type de page : page d'accueil, catégorie, produit, article de blog, archive paginée. Les canoniques diffèrent souvent par modèle, et un problème dans un modèle affecte toutes les pages l'utilisant.
- Vérifiez les paramètres de requête.
?utm_source=twitteret?ref=emaildevraient se canonicaliser vers l'URL propre si le contenu est identique. S'ils ne le font pas, vous créez des variantes infinies. - Recherchez les canoniques inter-domaines après une migration. Si vous avez migré de
old-domain.comversnew-domain.commais oublié de mettre à jour les canoniques, les pages du nouveau domaine pourraient encore se canonicaliser vers l'ancien. Cela indique à Google d'indexer l'ancien site. - Si vous utilisez des balises hreflang pour les pages localisées, confirmez que chaque variante de langue se canonicalise vers elle-même. Une erreur courante est que toutes les versions de langue se canonicalisent vers l'URL en anglais.
- Vérifiez en masse les canoniques dans votre sitemap. Si votre sitemap liste 500 URLs, un script peut appeler ce vérificateur en boucle et exporter un CSV de ceux qui ne s'auto-référencent pas. Attrapez les problèmes avant Google.
- Re-vérifiez après le déploiement d'un nouveau thème, plugin ou mise à jour CMS. La logique canonique peut s'arrêter silencieusement quand une dépendance change.
Si votre vérification canonique révèle des conflits, corrigez-les dans les paramètres CMS ou le code du thème, puis re-lancez la vérification. Si vous devez aussi confirmer que votre sitemap ne contient que des URLs canoniques, utilisez le vérificateur de sitemap pour faire une référence croisée. Pour voir comment les métadonnées complètes de votre page — titre, meta description, balises OG et canonique — s'affichent dans Google, Twitter et LinkedIn, le vérificateur de métadonnées de site web les prévisualise côte à côte. Si vous voulez confirmer que Googlebot peut atteindre l'URL canonique et n'est pas bloqué par robots.txt, la liste de vérification SEO exécute 20 vérifications sur page y compris la validation canonique.