Contenu dupliqué WordPress : repérer, corriger et éviter la cannibalisation SEO

Deux articles, une page catégorie et une archive de tag qui racontent la même chose : c’est le scénario le plus courant sur WordPress, et il coûte du classement sans qu’aucune pénalité ne soit visible. Voici comment repérer le contenu dupliqué, le distinguer de la cannibalisation, corriger chaque cas avec le bon outil, et le piège que la plupart des audits ratent complètement : votre propre cache qui rejoue l’ancienne version après la correction.

Contenu dupliqué et cannibalisation SEO : deux problèmes qu’on confond

Le contenu dupliqué, c’est une même page accessible sous plusieurs URL. La cannibalisation, c’est l’inverse : deux pages différentes qui visent la même requête. Les deux diluent votre classement, mais ne se corrigent pas de la même façon, et confondre les deux fait perdre un temps considérable en diagnostic.

Soyons précis sur un point que beaucoup de guides laissent flou : Google ne pénalise pas le contenu dupliqué involontaire. Il choisit une version, ignore les autres pour le classement, et dilue le signal entre elles. Pas de sanction manuelle, sauf copie délibérée à grande échelle. L’impact réel est plus sournois : PageRank interne divisé, confusion sur la page à afficher, et parfois la mauvaise version qui gagne.

D’où vient le contenu dupliqué sur un site WordPress

WordPress en génère structurellement, sans qu’aucun plugin ne soit en cause. Un article rattaché à une catégorie et à trois tags devient visible sur quatre archives différentes en plus de son URL propre, chacune reprenant le même extrait.

Taxonomies et archives

Catégories, tags, archives par date et par auteur listent les mêmes titres et extraits sur des URL séparées. Un article associé à dix tags se retrouve référencé sur dix pages distinctes qui ne se différencient que par leur URL. Les pages de pièces jointes d’image, générées automatiquement pour chaque média inséré, ajoutent une couche supplémentaire de contenu quasi vide et redondant. C’est aussi pourquoi une architecture de cocon sémantique pensée en amont limite mécaniquement le risque : une catégorie par cluster, jamais l’inverse, évite de multiplier les archives concurrentes sur la même thématique.

Variantes techniques de l’URL

Sans redirection propre, www.site.fr et site.fr sont deux sites distincts pour Google, tout comme http:// et https:// après une installation SSL mal terminée, ou /page et /page/ selon la présence du slash final. Chacune de ces variantes peut être crawlée et indexée séparément si rien ne la redirige.

Paramètres d’URL et pagination

Les paramètres de tri, de filtre ou de suivi (?orderby=, ?utm_source=, ?replytocom= sur les réponses aux commentaires) créent des variantes crawlables de la même page. La pagination des archives (/categorie/page/2/) partage une bonne partie de son contenu avec la première page sans être une duplication parfaite, ce qui brouille encore le signal.

Détecter le problème avant qu’il coûte du trafic

Trois outils suffisent pour la plupart des sites, à condition de savoir lire leurs libellés.

Google Search Console, la source la plus fiable

Dans l’onglet Indexation puis Pages, deux libellés annoncent un vrai problème : « Dupliquée, Google a choisi une URL canonique différente » (Google ignore votre choix) et « Dupliquée sans URL canonique sélectionnée par l’utilisateur » (vous n’avez rien précisé). À l’inverse, « Exclue par balise canonique » est normal : c’est votre canonical qui fonctionne comme prévu, rien à corriger. Si vous découvrez ces libellés pour la première fois, un audit SEO WordPress complet permet de cartographier l’ensemble du problème avant de corriger au cas par cas.

Un crawl complet avec Screaming Frog

Un crawl du site avec Screaming Frog (gratuit jusqu’à 500 URL) révèle les canonicaux manquants, les redirections en chaîne, les conflits entre canonical et noindex, et les duplications de title/meta description qui trahissent souvent une auto-cannibalisation. L’onglet Content propose des filtres « Exact Duplicates » et « Near Duplicates » avec un pourcentage de similarité par groupe de pages.

Une vérification rapide avec Siteliner

Pour un premier balayage sans installation, Siteliner (gratuit sous 250 pages) donne un pourcentage de contenu dupliqué interne par page. Un taux élevé sur des archives est attendu et sans gravité ; le même taux sur des articles ou des pages de service signale un vrai problème à traiter.

Corriger : canonical, noindex ou redirection, quelle méthode pour quel cas

Google documente lui-même une hiérarchie claire de signaux pour choisir une URL de référence, de la plus forte à la plus faible : les redirections permanentes et la balise rel="canonical" priment (signal très fort), l’inclusion en sitemap ne pèse que faiblement, et les signaux implicites (cohérence des liens internes, préférence pour HTTPS) arbitrent en dernier recours.

La balise canonical, native depuis WordPress 4.4

Depuis décembre 2015, WordPress ajoute automatiquement un <link rel="canonical"> sur chaque page, généralement auto-référencé. C’est suffisant pour les cas simples (un article, une page), mais insuffisant sur les archives de tags et de recherche interne, qui pointent par défaut vers elles-mêmes plutôt que vers le contenu original qu’elles listent. La règle d’or de Google est stricte sur ce point : ne jamais poser un canonical différent selon deux méthodes concurrentes (HTML et en-tête HTTP, ou sitemap et balise HTML) sous peine de signal contradictoire.

Le noindex, pour les pages sans valeur propre

Le canonical convient quand deux URL doivent rester accessibles aux visiteurs mais qu’une seule doit être indexée. Le noindex, lui, s’applique aux pages qui n’ont aucune valeur pour un visiteur venant de Google : archives d’auteur sur un site à un seul rédacteur, archives par date sans logique éditoriale, résultats de recherche interne. Google déconseille explicitement le noindex pour trancher entre deux pages actives et similaires : il est fait pour retirer une page de l’index, pas pour départager deux versions d’un même contenu.

Sous Yoast, ce réglage se trouve dans SEO puis Apparence dans les recherches, onglet Archives et onglet Taxonomies. Sous Rank Math, l’équivalent est dans Titres et Méta puis Archives, avec une bascule directe pour désindexer les archives d’auteur et de date en un clic.

La redirection 301, réservée aux pages abandonnées

Google est catégorique : la redirection permanente ne s’utilise que pour des pages qu’on abandonne définitivement, pas pour arbitrer entre deux versions actives d’un contenu qu’on veut garder visitable. Pour les variantes techniques (www/non-www, HTTP/HTTPS, slash final), une redirection unique combinant les deux corrections en une seule règle .htaccess évite les chaînes de redirection qui ralentissent le chargement et diluent le signal.

Une erreur à éviter absolument, que Google signale explicitement : ne jamais utiliser le fichier robots.txt pour trancher un choix de canonique. Le robots.txt bloque le crawl, pas l’indexation ; une page bloquée au crawl peut encore apparaître dans les résultats sans description, ce qui aggrave la confusion plutôt que de la résoudre.

Cannibalisation : le problème frère que le canonical ne règle pas

Deux pages différentes qui ciblent le même mot-clé ne sont pas un problème de duplication : ce sont deux contenus concurrents sur votre propre site, et Google peut très bien classer la moins bonne des deux, ou faire alterner les deux dans les résultats sans jamais en installer une durablement.

Le diagnostic se fait dans Search Console, onglet Performances, en filtrant par requête et en observant si plusieurs URL de votre domaine apparaissent en alternance sur les mêmes mots-clés sur plusieurs semaines : c’est souvent le signe que deux contenus ont été rédigés sans avoir clairement identifié l’intention de recherche qui aurait dû les différencier dès le départ. Une fois le doublon confirmé, quatre solutions, du plus radical au plus léger : fusionner les deux pages en gardant les meilleurs éléments de chacune avec une redirection 301 de la perdante vers la gagnante ; rediriger purement et simplement si l’une n’apporte rien ; réécrire l’une des deux pour cibler une intention ou une sous-thématique distincte (avec des mots-clés et un plan Hn différents, pas seulement des synonymes) ; ou renforcer le maillage interne vers la page qu’on veut voir gagner, pour envoyer un signal de priorité sans toucher au contenu.

Le piège que les audits ratent : le cache qui annule votre correction

Ce que ni la documentation Google ni les guides classiques ne couvrent : sur un WordPress équipé d’un plugin de cache (WP Rocket, WP Fastest Cache, LiteSpeed Cache, W3 Total Cache), corriger un canonical, poser un noindex ou changer une redirection ne suffit pas. Tant que la page concernée n’a pas été régénérée, le cache continue de servir la version HTML figée avant votre correction, canonical erroné inclus, à chaque visiteur ET à chaque passage de Googlebot qui la recrawle entre-temps.

C’est un angle mort classique parce que le symptôme trompe : vous vérifiez votre modification dans l’éditeur, elle est bien enregistrée en base de données, mais la page servie au navigateur reste l’ancienne version tant que son fichier de cache n’a pas expiré ou été purgé. Un simple rechargement ne suffit pas à distinguer les deux : le navigateur peut lui-même mettre en cache localement.

Comment vérifier que ce n’est pas votre cas

La méthode fiable consiste à comparer le code source réellement servi (clic droit, afficher le code source, ou une requête curl depuis un terminal) avec ce que vous attendez après correction, en ajoutant un paramètre anti-cache à l’URL testée si le plugin le permet. Si la balise canonical ou la directive noindex affichée diffère de ce que vous venez de configurer, le cache sert toujours l’ancienne version.

Purger le bon périmètre, pas tout le site

La tentation est de vider le cache entier après chaque correction. C’est une erreur de fréquence : une purge totale régulière force la régénération de toutes les pages à la prochaine visite, ce qui ralentit temporairement l’ensemble du site pour les premiers visiteurs (et pour Googlebot) après chaque purge. La bonne pratique est une purge ciblée, page par page, disponible dans la plupart des plugins de cache récents via une option « vider le cache de cette page » directement depuis la barre d’administration WordPress. Réservez la purge globale aux changements qui touchent réellement tout le site (thème, en-tête, pied de page, feuille de style globale).

Une fois la page repurgée, comptez un nouveau passage de Googlebot avant que le correctif soit pris en compte dans l’index : l’inspection d’URL dans Search Console permet de demander une nouvelle exploration pour accélérer ce recrawl, sans garantie de délai.

Checklist et délais réels

1. Unifier l’URL du siteDans Réglages puis Général, fixez une seule version (www ou non, HTTPS) et redirigez toutes les autres en 301.
2. Vérifier le canonical de chaque type de pageArticles, pages, archives de catégorie et de tag : chaque type doit avoir une règle de canonical cohérente, jamais contradictoire entre deux méthodes.
3. Passer les archives inutiles en noindexAuteur (site mono-rédacteur), date, recherche interne, pièces jointes : via Yoast ou Rank Math, sans toucher aux articles qu’elles listent.
4. Nettoyer les paramètres parasitesDésactiver ?replytocom dans les réglages avancés du plugin SEO, exclure les paramètres de suivi du crawl interne si le volume le justifie.
5. Purger le cache de la page corrigée, pas tout le siteUtilisez l’option de purge ciblée du plugin de cache, puis vérifiez le code source réellement servi.
6. Surveiller Search Console pendant plusieurs semainesLe passage de « Dupliquée » à « Exclue par balise canonique » prend généralement plusieurs semaines, le temps que Google recrawle et réévalue.

Ce qu’il faut retenir

Le contenu dupliqué sur WordPress se corrige par étages : unifier l’URL du site, choisir canonical ou noindex selon que la page doit rester visitable ou non, ne jamais confondre avec la cannibalisation qui appelle une fusion ou une réécriture, et vérifier systématiquement que le cache ne rejoue pas l’ancienne version après votre correction. C’est cette dernière étape, la plus souvent oubliée, qui explique pourquoi certains audits ne voient jamais leurs corrections produire d’effet. Si le problème revient régulièrement d’un article à l’autre, la cause est souvent en amont, dans un plan éditorial qui ne prévoit pas d’arbitrage entre créer et mettre à jour.