Réduire le contenu dupliqué sous WordPress

Cet article date de 2012. Les conseils de base étaient bons — canonical, noindex — mais WordPress a beaucoup évolué depuis. Le core intègre maintenant la balise canonical nativement, Yoast a réécrit ses réglages avancés, et Google a officiellement abandonné rel=prev/next en 2019. Il était temps de remettre tout ça à plat.

Qu’est-ce que le contenu dupliqué ?

Le duplicate content, c’est un contenu identique ou très similaire accessible depuis plusieurs URL distinctes. Google doit alors choisir quelle version indexer et laquelle afficher dans les résultats — et il ne choisit pas toujours la bonne.

Il existe deux types de duplication :

• Interne : deux pages de votre propre site affichent le même contenu. C’est le cas le plus fréquent sous WordPress.
• Externe : un autre site reprend votre contenu mot pour mot, avec ou sans votre accord. C’est le plagiat classique — un problème différent, qui se gère avec une réclamation DMCA.

Ce guide traite uniquement du duplicate interne, qui est à la fois le plus facile à corriger et le plus souvent négligé.

Deux précisions importantes avant d’aller plus loin. Premièrement, Google ne pénalise pas le duplicate content en tant que tel. Il dilue le jus de lien entre les URL concurrentes et crée de la confusion sur quelle page mérite de ranker.

Deuxièmement, une grande partie des sites WordPress génèrent du duplicate sans que le propriétaire le sache — simplement parce que WordPress crée de nombreuses URL pour un même article.

Les sources de duplicate content dans WordPress

WordPress est une machine à créer des URL. Un seul article peut être accessible via sa permalink, sa catégorie, ses tags, ses archives de date, ses archives d’auteur, et en version paginée si les commentaires dépassent une certaine limite. Autant de sources potentielles de duplication.

Les archives, catégories et tags

C’est la source numéro un. Un article publié dans la catégorie "SEO" avec le tag "WordPress" est techniquement accessible depuis au moins trois URL différentes :

• /mon-article/ (permalink directe)
• /seo/mon-article/ (si la structure inclut la catégorie)
• /tag/wordpress/ (liste des articles du tag)

Les archives de date (/2024/, /2024/03/) posent le même problème. Elles listent des articles déjà présents ailleurs, avec les mêmes titres et les mêmes extraits.

La pagination

La page /categorie/ et /categorie/page/2/ partagent souvent des articles en commun si votre blog est ancien et que les catégories sont larges. Ce n’est pas une duplication parfaite, mais les premières pages se ressemblent suffisamment pour créer de la confusion.

www vs non-www

Sans redirection 301 correcte, http://www.votresite.com/ et http://votresite.com/ sont deux sites différents aux yeux de Google. Si les deux sont accessibles, le PageRank se divise entre eux. C’est une erreur de configuration basique, mais elle est encore courante sur des sites hébergés sans accompagnement.

HTTP vs HTTPS

Même logique. Si votre certificat SSL est en place mais que http://votresite.com/ répond encore au lieu de rediriger vers HTTPS, vous avez deux versions de votre site indexées. Migrer WordPress de HTTP vers HTTPS règle le problème définitivement — l’article détaille la procédure complète, redirection .htaccess incluse.

Le trailing slash

Sur wpformation.com, tous les slugs se terminent par un slash (/slug/). C’est un choix délibéré. Sans configuration cohérente, /mon-article et /mon-article/ sont deux URL distinctes. Choisissez l’une ou l’autre, puis forcez la redirection.

Les paramètres d’URL

WordPress génère des paramètres comme ?replytocom=21493 pour les réponses aux commentaires, ou ?s=wordpress pour les recherches internes. Ces paramètres créent des variantes d’URL qui peuvent être crawlées et indexées. Yoast propose depuis longtemps une option pour supprimer le paramètre ?replytocom — c’est l’un des premiers réglages à activer.

Le canonical natif de WordPress

Bonne nouvelle : depuis WordPress 4.4 (décembre 2015), le core génère automatiquement une balise rel=canonical sur chaque page. Pas besoin de plugin pour ça. La balise pointe vers l’URL canonique de la page, ce qui indique à Google quelle version prendre en compte.

Voici ce que WordPress injecte dans le <head> d’un article :

<link rel="canonical" href="https://votresite.com/mon-article/" />

C’est suffisant pour les cas simples. Là où ça devient insuffisant, c’est sur les archives, les pages de tags, et les pages de résultats de recherche — qui pointent vers elles-mêmes plutôt que vers le contenu original. C’est là qu’intervient Yoast.

Pour les sites avec beaucoup d’articles et une structure taxonomique complexe, le silo SEO sous WordPress offre une approche plus structurée : on organise les thématiques en profondeur, ce qui réduit naturellement les risques de cannibalisation entre catégories et tags.

Yoast SEO et le duplicate content

Yoast n’est pas obligatoire — le canonical natif de WordPress fonctionne. Mais si vous avez déjà Yoast en place (et c’est probable sur la plupart des sites WordPress), ses réglages avancés permettent de gérer finement tout ce que le core ne couvre pas.

Noindex des archives et des taxonomies

Depuis Yoast SEO > Apparence dans les recherches > Types de contenu > Archives, vous pouvez passer les archives de dates et d’auteur en noindex. C’est la configuration recommandée pour la grande majorité des sites :

• Archives d’auteur : à passer en noindex si vous êtes le seul auteur du site — la page /author/votrenom/ liste exactement les mêmes articles que votre page d’accueil.
• Archives de dates : à passer en noindex sauf si vous tenez un journal ou un blog d’actualité où la date a une vraie valeur éditoriale.
• Tags : à évaluer selon votre utilisation. Si vos tags sont précis et peu nombreux, gardez-les indexables. Si vous en avez des centaines avec un seul article chacun, passez-les en noindex.

Le réglage se trouve dans Yoast SEO > Apparence dans les recherches > Taxonomies. Pour chaque taxonomie (catégories, tags, formats), vous pouvez définir le meta robots par défaut.

Suppression des paramètres parasites

Dans Yoast SEO > Avancé > Permaliens, activez "Supprimer le paramètre replytocom". Cette option enlève le paramètre ?replytocom=XXXX des URL générées pour les réponses aux commentaires. Le fonctionnement des commentaires n’est pas affecté pour les utilisateurs avec JavaScript activé (soit 99 % de vos visiteurs).

Le canonical sur les pages paginées

Yoast gère aussi le canonical sur les archives paginées. La page /categorie/page/2/ reçoit automatiquement un canonical qui pointe vers elle-même — et non vers la première page, ce qui serait une erreur fréquente dans les vieilles configurations manuelles.

Pour approfondir la configuration complète de Yoast, le guide complet Yoast SEO détaille chaque réglage section par section.

Le cas rel=prev/next : c’est terminé

Pendant des années, la recommandation standard pour la pagination était d’ajouter rel="prev" et rel="next" dans le head. L’idée : indiquer à Google que ces pages font partie d’une série et qu’il devait les traiter comme un ensemble cohérent.

En mars 2019, Google a officiellement annoncé qu’il ignorait ces balises depuis des années. John Mueller l’a confirmé sur Twitter : Google comprenait la pagination sans ces hints. Yoast a retiré leur génération automatique dans la foulée.

Si vous avez encore des balises rel=prev/next dans votre thème ou votre plugin SEO, elles ne font pas de mal — elles ne servent simplement plus à rien pour Google. Bing les prend encore en compte théoriquement, mais c’est anecdotique dans la pratique.

Ce qui compte pour la pagination aujourd’hui : avoir une balise canonical correcte sur chaque page de la série, et s’assurer que les pages 2, 3, 4… apportent suffisamment de valeur différentielle pour mériter d’être indexées (ou les passer en noindex si c’est simplement une liste d’articles).

Les redirections : www, HTTP, trailing slash

Les redirections 301 règlent définitivement la duplication liée aux variantes d’URL. L’objectif est simple : une seule version de votre site doit être accessible, les autres doivent rediriger vers elle.

www vers non-www (ou l’inverse)

Choisissez une convention et tenez-vous y. Sur la plupart des configurations Apache, voici comment forcer le non-www dans le .htaccess :

RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
RewriteRule ^ https://%1%{REQUEST_URI} [R=301,L]

Si vous préférez forcer le www, inversez simplement la logique. Dans WordPress, allez aussi dans Réglages > Général et assurez-vous que l’URL du site correspond à votre convention.

HTTP vers HTTPS

Si votre site est en HTTPS (et il devrait l’être), toutes les requêtes HTTP doivent être redirigées. Dans le .htaccess :

RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Combinez les deux redirections (HTTP+www vers HTTPS sans www) pour éviter les doubles redirections en chaîne. Une redirection 301 directe de http://www.votresite.com/ vers https://votresite.com/ est plus propre qu’une redirection en deux étapes. Le guide de sécurisation WordPress aborde aussi la configuration SSL dans le détail.

Trailing slash cohérent

Si votre WordPress est configuré avec trailing slash (ce qui est la valeur par défaut avec les permalinks propres), votre .htaccess redirige déjà automatiquement /mon-article vers /mon-article/. Vérifiez que c’est bien le cas avec un test rapide dans votre navigateur ou avec curl.

Auditer le duplicate content de votre site

Avant de corriger, il faut mesurer. Trois outils couvrent l’essentiel :

Screaming Frog SEO Spider

C’est l’outil de référence pour crawler votre site comme Google le fait. Screaming Frog identifie les pages avec des balises canonical manquantes, les redirections en chaîne, les URLs dupliquées, et les pages qui s’auto-cannibalisent (même title ou même meta description sur plusieurs URL).

La version gratuite crawle jusqu’à 500 URL — suffisant pour la plupart des petits sites. Pour un audit sérieux sur un site de plusieurs centaines d’articles, la licence annuelle vaut l’investissement.

Dans Screaming Frog, regardez en priorité : l’onglet "Canonical" pour vérifier que chaque page a bien une balise canonical correcte, et l’onglet "Directives" pour repérer les éventuels conflits entre canonical et noindex.

Google Search Console

L’onglet Couverture dans Search Console liste les pages exclues de l’index, avec la raison. Si vous voyez des centaines de pages "Exclue par balise canonique", c’est normal — ça signifie que le canonical fonctionne.

En revanche, si vous voyez des pages "Dupliquée, Google a choisi une canonique différente", c’est un signal que Google ne fait pas confiance à vos balises canonical déclarées.

L’outil d’inspection d’URL vous permet de vérifier une page spécifique : Google l’a-t-elle crawlée ? Quelle URL considère-t-il comme canonique ? C’est particulièrement utile pour déboguer les cas isolés.

Pour une analyse SEO complète qui intègre Search Console et les problèmes de cannibalisation, le guide SEO WordPress donne le cadre complet, et l’article sur la sémantique SEO et WordPress aide à comprendre comment structurer son contenu pour éviter la cannibalisation à la source.

Siteliner

Siteliner (siteliner.com) scanne votre site et identifie le contenu dupliqué interne — il vous donne un pourcentage de similarité entre vos pages. C’est gratuit pour les sites de moins de 250 pages, et l’interface est beaucoup plus simple que Screaming Frog pour cette tâche spécifique.

Attention à l’interpréter correctement : un taux de duplication élevé sur les pages d’archives est normal et attendu (elles listent des extraits). Ce qui pose problème, c’est quand ce taux est élevé sur des pages qui devraient être uniques (articles, pages de service, landing pages).

Checklist anti-duplicate content

Voici une liste des actions à effectuer sur n’importe quel site WordPress pour réduire le duplicate content au minimum :

• Vérifier que WordPress est configuré sur une seule URL dans Réglages > Général (www ou non-www, HTTPS)
• Activer la redirection 301 HTTP→HTTPS dans le .htaccess
• Activer la redirection 301 www→non-www (ou l’inverse) dans le .htaccess
• Vérifier que chaque page a bien une balise rel=canonical dans le <head>
• Passer les archives d’auteur en noindex dans Yoast (si site mono-auteur)
• Passer les archives de dates en noindex dans Yoast (sauf site d’actualité)
• Supprimer le paramètre ?replytocom dans Yoast > Avancé > Permaliens
• Vérifier dans Search Console que Google ne signale pas de pages "Dupliquée, Google a choisi une canonique différente"
• Crawler le site avec Screaming Frog pour détecter les canonical manquants ou incorrects

Ce n’est pas une liste à effectuer une seule fois. Revisitez-la à chaque refonte ou changement de structure d’URL.

---

FAQ — Duplicate content WordPress

Le duplicate content pénalise-t-il directement le référencement ?

Non, Google ne pénalise pas le duplicate content au sens strict. Il choisit une URL canonique parmi les versions dupliquées et n’indexe que celle-là. Le problème réel, c’est la dilution du PageRank entre plusieurs URL qui se font concurrence, et la difficulté pour Google de déterminer quelle version mérite de ranker. Le résultat est un affaiblissement indirect du positionnement, pas une pénalité manuelle.

Est-ce que WordPress gère automatiquement le canonical ?

Oui, depuis WordPress 4.4. Le core injecte une balise rel=canonical dans le <head> de chaque page, qui pointe vers l’URL canonique déclarée. C’est suffisant pour les articles et les pages. En revanche, pour les archives, les taxonomies et les résultats de recherche, il faut compléter avec Yoast SEO ou un plugin équivalent pour configurer le comportement souhaité.

Faut-il encore utiliser rel=prev/next pour la pagination ?

Non. Google a officiellement confirmé en mars 2019 qu’il ignorait ces balises depuis des années. Bing les supporte encore théoriquement, mais leur impact est négligeable. Pour la pagination, concentrez-vous sur la balise canonical et sur le fait de s’assurer que chaque page paginée a une valeur propre suffisante pour être indexée — ou passez-les en noindex si elles ne font que lister des articles déjà présents ailleurs.

Comment savoir si mon site a du contenu dupliqué ?

Trois méthodes complémentaires : Google Search Console (onglet Couverture, cherchez les pages "Dupliquée, Google a choisi une canonique différente"), Screaming Frog pour un audit complet du site avec analyse des canonical, et Siteliner pour une vue rapide du taux de similarité entre vos pages. Commencez par Search Console — c’est gratuit, vous avez déjà les données, et c’est la source la plus fiable puisque c’est Google qui vous dit ce qu’il voit réellement.

Le noindex sur les archives supprime-t-il les articles eux-mêmes de l’index ?

Non, le noindex s’applique uniquement à la page d’archive, pas aux articles qui y sont listés. Passer /categorie/wordpress/ en noindex ne retire pas vos articles WordPress de l’index. Chaque article a son propre canonical et ses propres directives robots, indépendamment des archives qui le référencent. C’est une confusion fréquente, mais les deux sont complètement décorrélés.