Deux occurrences de <link rel="canonical"> dans le même document HTML, pointant chacune vers une URL légèrement différente : c’est le symptôme qui a déclenché l’investigation sur un site utilisant un thème premium personnalisé aux côtés d’une extension de référencement installée pour gérer les métadonnées structurées.
Symptôme : deux balises, deux URL
La première balise canonical, générée par le thème, pointait vers l’URL réelle de la page consultée, incluant son paramètre de pagination éventuel. La seconde, générée par l’extension, pointait systématiquement vers la première page de la série, sans tenir compte du contexte de pagination. Aucune des deux équipes, celle qui maintenait le thème et celle qui avait configuré l’extension, n’avait connaissance de l’existence de l’autre mécanisme.
Diagnostic : deux hooks qui ignorent leur propre doublon
WordPress fournit nativement une fonction rel_canonical(), hookée par défaut sur wp_head, qui génère automatiquement une balise canonical pertinente pour la plupart des contextes (article, page, archive). Le thème en question avait retiré ce hook natif pour le remplacer par sa propre implémentation, une pratique courante quand un développeur de thème veut un contrôle plus fin sur la logique de canonicalisation :
remove_action( 'wp_head', 'rel_canonical' );
add_action( 'wp_head', function () {
global $wp;
$url = home_url( add_query_arg( array(), $wp->request ) );
echo '<link rel="canonical" href="' . esc_url( $url ) . '" />' . "\n";
} );Ce remplacement fonctionnait correctement en isolation. Le problème est apparu avec l’installation ultérieure d’une extension de référencement, qui ajoutait elle aussi sa propre balise canonical, sans jamais vérifier au préalable si une balise équivalente existait déjà, une hypothèse raisonnable de la part de l’extension puisque la fonction native rel_canonical avait justement été désactivée par le thème, un fait que l’extension ne pouvait pas détecter depuis son propre code.
Pourquoi ce cas est difficile à repérer
Aucune des deux parties n’était en tort dans l’absolu : le thème respectait la pratique documentée de retirer rel_canonical avant d’ajouter sa propre logique, et l’extension suivait sa propre logique de génération sans supposer l’existence d’un concurrent. Le problème émerge uniquement de la combinaison des deux, un cas que ni l’un ni l’autre composant ne peut détecter isolément puisque chacun ignore ce que fait l’autre au moment de l’exécution.
Vérifier la présence d’un doublon
curl -s https://exemple.fr/categorie/produits/page/3/ | grep -o '<link rel="canonical"[^>]*>'Sur ce site, cette commande retournait bien deux lignes distinctes, confirmant le diagnostic sans ambiguïté possible.
Correctif : un seul point de vérité
La correction retenue a consisté à conserver la logique du thème, jugée plus complète car elle gérait correctement la pagination, et à désactiver la génération de canonical côté extension via son filtre dédié, plutôt que l’inverse :
add_filter( 'extension_seo_desactiver_canonical', '__return_true' );Ce choix illustre une règle générale utile face à ce type de conflit : garder la logique la plus contextuelle et la plus testée, quel que soit le composant qui l’héberge, plutôt que de systématiquement privilégier l’extension sous prétexte qu’elle est dédiée au référencement.
Prévention pour les futurs projets
- Avant d’installer une extension de référencement sur un thème personnalisé, vérifier explicitement si le thème gère déjà la balise canonical.
- Documenter, dans le code du thème, tout retrait d’un hook natif de WordPress, avec une justification claire, pour que la prochaine personne qui installe une extension sache où chercher un éventuel conflit.
- Ajouter un test automatisé qui échoue si plus d’une balise
link rel="canonical"est présente dans une réponse HTML donnée.
Deux mécanismes bien conçus individuellement peuvent produire un résultat cassé une fois combinés, simplement parce qu’aucun des deux ne peut observer l’existence de l’autre. C’est le cas le plus fréquent de bug SEO en environnement multi-composants.
En résumé
Ce type de conflit reste invisible tant que personne n’inspecte directement le code source de la page : aucune alerte dans l’administration WordPress ne signale la présence de deux balises canonical. Une vérification régulière, même simple, sur un échantillon de pages représentatives de chaque gabarit du site permet de détecter ce genre de doublon avant qu’il n’affecte durablement la façon dont les moteurs de recherche regroupent les signaux de pertinence entre les différentes variantes d’une même page.
