Une agence m’a contacté après avoir constaté une chute de trafic sur son blog client, quelques semaines après une migration de thème. En creusant, la balise canonical de chaque article pointait vers l’ancienne structure d’URL, celle du thème précédent. Le thème avait changé, mais un filtre get_canonical_url ajouté des mois plus tôt continuait de reconstruire des adresses obsolètes. Résultat : Google indexait la bonne page, mais son propre signal canonique lui indiquait de préférer une URL qui n’existait plus.
La balise canonical est l’un des outils les plus simples du référencement technique, et l’un des plus faciles à casser silencieusement. WordPress la gère nativement depuis longtemps, ce qui rassure beaucoup de développeurs à tort : nativement ne veut pas dire automatiquement correct dans toutes les configurations.
Ce que WordPress pose par défaut
Sur un article, une page ou un article de type personnalisé affiché en singulier, WordPress ajoute automatiquement une balise <link rel="canonical"> dans le <head>, via la fonction rel_canonical() accrochée au hook wp_head. L’URL utilisée est celle que retourne wp_get_canonical_url(), calculée à partir de la structure des permaliens active.
function rel_canonical() {
if ( ! is_singular() ) {
return;
}
$url = wp_get_canonical_url();
if ( ! empty( $url ) ) {
echo '<link rel="canonical" href="' . esc_url( $url ) . '" />' . "\n";
}
}Sur les singuliers, ce mécanisme fonctionne bien dans la grande majorité des cas. Le vrai sujet se situe ailleurs : sur les archives, les pages de résultats de recherche, et les URL avec paramètres, où WordPress ne pose par défaut aucune balise canonical du tout.
Les archives paginées, angle mort classique
Une archive de catégorie ou de taxonomie paginée (/categorie/actualites/page/2/) n’obtient pas de balise canonical native, car is_singular() renvoie faux sur ce type de page. C’est là qu’une extension SEO complète prend le relais, en posant généralement une canonical auto-référente sur chaque page paginée plutôt qu’une canonical vers la page 1, ce qui est la bonne pratique actuelle : chaque page de résultats reste indexable pour son propre contenu, sans se déclarer doublon d’une autre page.
Sans extension, la situation la plus risquée est un site qui expose la même liste d’articles à plusieurs adresses : une catégorie, une étiquette, et une page d’archive d’auteur qui listent parfois les mêmes contenus dans le même ordre. Sans signal canonique clair, un moteur de recherche peut choisir lui-même quelle version indexer, et ce choix n’est pas toujours celui qu’on aurait souhaité.
Les doublons créés par la structure d’URL elle-même
Certains doublons ne viennent d’aucune extension ni d’aucun filtre, mais de la façon dont le serveur ou WordPress traite certaines variantes d’URL :
- Avec et sans slash final, selon la configuration du serveur web et des règles de réécriture.
- Avec et sans le préfixe
www., quand la redirection n’est pas gérée au niveau du serveur. - Avec des paramètres de suivi (
?utm_source=...) qui créent techniquement une nouvelle URL aux yeux d’un robot, même si le contenu affiché est strictement identique. - En HTTP et en HTTPS, si l’ancien protocole n’est pas correctement redirigé vers le nouveau.
Une balise canonical bien posée absorbe la plupart de ces cas : quelle que soit l’URL exacte tapée par le visiteur, elle indique un point de référence unique. Elle ne remplace toutefois jamais une bonne redirection 301 quand une URL ne devrait tout simplement plus exister.
Vérifier sa propre balise canonical
La méthode la plus rapide reste d’afficher le code source d’une page et de chercher rel="canonical". Trois points à vérifier systématiquement :
- Une seule balise canonical par page, jamais deux (un doublon typique quand le thème et une extension la génèrent chacun de leur côté).
- L’URL indiquée correspond bien à l’URL affichée dans la barre d’adresse, au protocole et au sous-domaine près.
- Sur une page paginée, l’URL canonique correspond à la page courante et non systématiquement à la page 1, sauf choix assumé et documenté.
Sur un projet de migration, je vérifie toujours la balise canonical avant la balise title. Une canonical cassée est invisible pour un visiteur, mais elle peut faire disparaître des pages entières des résultats de recherche en quelques semaines.
En résumé
WordPress pose une balise canonical fiable sur les contenus singuliers, mais laisse un vide sur les archives et les URL avec paramètres, comblé en pratique par les extensions SEO. Le vrai risque ne vient presque jamais du cœur de WordPress lui-même, mais des filtres personnalisés ajoutés au fil des années, qui finissent parfois par contredire la structure réelle du site après une migration ou un changement de thème. Un contrôle régulier du code source, sur quelques gabarits de page représentatifs, suffit à repérer ce genre de dérive avant qu’elle n’ait d’impact mesurable.
