Balise canonical en double sur WordPress : comment trouver le vrai coupable
Deux balises canonical sur la même page. Google n'en garde qu'une, au hasard. La question qui compte n'est pas « y a-t-il un conflit » mais « qui l'a causé » — et presque aucun outil n'y répond.
Vous inspectez le code source d'une page. Vous voyez ceci :
<link rel="canonical" href="https://votresite.fr/chambre-double/">
<link rel="canonical" href="https://votresite.fr/chambre-double/?elementor_library=…">Deux balises canonical. Google n'en garde qu'une, au hasard de son propre jugement — et ce n'est pas forcément la bonne.
Question simple. Réponse presque jamais évidente : qui a écrit la deuxième ?
Pourquoi c'est plus dur qu'il n'y paraît
Sur un site WordPress typique, au moins quatre acteurs peuvent écrire une balise <head> sur la même page, le même jour, sans se parler :
- Votre plugin SEO (Yoast, Rank Math, SEOPress, Livada…)
- Votre thème, qui a souvent son propre bloc SEO minimal intégré
- Elementor ou Elementor Pro, qui génère ses propres méta-données sur certains templates
- Un snippet ajouté un jour dans functions.php ou via un plugin de code, et oublié depuis
Chacun agit « légitimement » de son point de vue. Le résultat, lui, ne l'est pas.
Ce que la plupart des outils vous disent (et ce qu'ils ne disent pas)
Un audit SEO classique — le vôtre inclus, probablement — vous dira : « canonical en double détecté ». C'est le symptôme. Il ne vous dit presque jamais l'origine : quel plugin, quel hook, quel fichier.
Vous finissez par désactiver des plugins un par un pour trouver le coupable. Ça marche, mais ça prend une heure sur un site que vous ne connaissez pas par cœur — et c'est risqué en production.
Comment Provenance Watch répond à la question différemment
Provenance Watch ne se contente pas de détecter qu'une balise existe deux fois. Il remonte la chaîne d'exécution WordPress (le mécanisme des hooks/actions qui construit chaque page) pour identifier :
- Quel composant a produit la balise — plugin, thème, ou noyau WordPress
- Le fichier dans lequel ce code vit réellement (via la Reflection PHP, pas une supposition basée sur un nom de fonction qui ressemble à quelque chose)
- La priorité à laquelle il s'est exécuté — utile pour comprendre lequel des deux a « gagné » dans l'ordre d'affichage
Balise détectée
<link rel="canonical" href="…">
Origine
Elementor Pro — en conflit avec Livada SEO
Le fichier responsable est identifié — pas juste un nom de plugin.Ce que ça prouve, précisément : le fichier et le composant qui ont réellement inscrit la balise, résolus par le moteur PHP lui-même. Ce que ça ne prétend pas faire : donner un numéro de ligne exact dans ce fichier — l'attribution s'arrête au fichier et à son propriétaire, pas plus loin.
Ce que ça change concrètement
Au lieu de désactiver des plugins à l'aveugle, vous savez en 30 secondes où intervenir : un réglage à changer dans Elementor, un filtre à retirer d'un snippet oublié, ou simplement la confirmation que le conflit vient de deux plugins SEO actifs en même temps (cas fréquent après une migration incomplète — voir notre guide sur la migration vérifiable).
Sur un site client, c'est aussi la différence entre « je pense que c'est réglé » et « voici exactement ce qui causait le problème, et pourquoi ça ne reviendra pas ».
Voir Provenance Watch en action →
Rédigé à partir du code réel de Livada SEO v1.50.3 (class-hook-attribution.php, class-provenance-watch.php), vérifié le 22/08/2026.
Envie d'arrêter de perdre du temps ?
Livada SEO + Cockpit vous donnent les outils pros pour passer à l'action — testés sur des vrais hôtels et campings.