Un client m'appelle, paniqué : son trafic organique a chuté de 40 % en trois semaines. Pas de pénalité manuelle dans la Search Console. Pas de refonte. Pas de perte de backlinks. On a fini par trouver la cause : un plugin de filtres produits qui générait, à chaque combinaison de couleur et de taille, une URL indexable. 14 000 pages quasi identiques sur un catalogue de 300 références. Le CMS faisait très bien son travail. C'est justement ça, le problème.
Le duplicate content technique, quand on administre un système de gestion de contenu, ce n'est presque jamais une faute de rédaction. C'est une configuration par défaut. Une case cochée un jour, une extension installée pour gagner du temps, une taxonomie laissée libre parce que « on verra plus tard ». Et six mois après, on passe une semaine à désindexer à la main.
Points clés à retenir
- Sur un CMS, la duplication vient du moteur, pas du rédacteur : archives, pagination, paramètres d'URL, recherche interne.
- La balise canonical règle beaucoup de cas, mais elle est une indication, pas un ordre.
- Un audit de crawl mensuel coûte moins cher qu'une déindexation massive en urgence.
- Les facettes e-commerce et les taxonomies mal réglées sont les deux gisements de duplication les plus sous-estimés.
- Désindexer sans rediriger casse des liens internes. Toujours vérifier l'arborescence avant de cliquer.
Pourquoi votre CMS génère du duplicate content technique sans que vous le sachiez
Un blog géré à la main produit peu d'URL. WordPress, Drupal, Joomla ou Shopify, en revanche, produisent des URL tout seuls. Chaque article, c'est une adresse canonique… plus un flux RSS, plus une déclinaison AMP si le thème l'a prévue, plus une version « imprimable », plus une entrée dans les archives mensuelles et par auteur.
Pour un seul billet, j'ai déjà compté 11 adresses accessibles dans un back-office mal configuré. Onze portes d'entrée pour un seul contenu.
Les sources de duplication que presque personne ne surveille
- Les archives (par mois, par année, par auteur) : listent des extraits, parfois le texte complet selon le thème.
- Les taxonomies : catégories, étiquettes, et surtout les pages « tag » créées automatiquement à chaque mot-clé saisi à la va-vite.
- La recherche interne :
?s=sur WordPress génère une page indexable pour chaque requête tapée. - La pagination :
/page/2/,/page/3/… qui reprennent les mêmes titres et extraits. - Les paramètres d'URL : tri, filtres, session, utm mal nettoyés côté serveur.
- Les versions multilingues sans hreflang correct, où chaque langue pointe vers elle-même en canonique.
Le point commun de tout ça : le duplicate content est structurel. Il n'apparaît pas parce que vous avez copié un texte. Il apparaît parce que le moteur sait générer une page pour tout.
Interne ou externe : la distinction qui change la méthode
La duplication interne (deux de vos pages se ressemblent) se traite dans le CMS : canonical, noindex, redirections. La duplication externe (votre texte est repris ailleurs) se traite par la relation avec le site qui reprend, ou par la canonical vers la source d'origine. Confondre les deux fait perdre des semaines. J'ai vu des équipes marteler des canonical internes alors que le vrai problème était un flux RSS syndiqué sur douze annuaires.
Les réglages CMS qui suppriment 80 % des doublons
Avant de toucher au contenu, il faut colmater le moteur. C'est chiant. C'est efficace.
La balise canonical : bien la poser, pas juste la cocher
Sur WordPress, Yoast et Rank Math posent une canonique automatique sur chaque page. Sur Drupal, c'est le module Metatag. Sur Shopify, c'est un champ caché par défaut dans le thème. Le piège, c'est de croire que c'est réglé.
Une canonical qui pointe vers une URL elle-même redirigée, c'est une canonical cassée. Une canonical posée sur une page paginée qui pointe vers la page 1 : Google l'accepte depuis des années, mais le contenu de la page 3 devient invisible. Et une canonical relative mal construite (sans le domaine complet) peut envoyer vers une URL qui n'existe pas.
Mon conseil, après avoir passé des heures à débugger ça : vérifiez vos canoniques avec un crawl complet, pas à l'œil sur trois pages. Un Screaming Frog ou un Oncrawl sort les incohérences en dix minutes.
Noindex, robots.txt et désindexation : l'ordre compte
Deux erreurs classiques, dans cet ordre :
- Bloquer une URL dans le robots.txt en pensant la désindexer. Résultat : le robot ne peut plus lire le
noindex, et la page reste indexée pendant des mois. - Balancer un
noindexsans vérifier les liens internes qui pointent vers la page. Résultat : des liens qui mènent à une page fantôme.
La bonne séquence : d'abord vérifier l'absence de liens internes critiques, ensuite poser le noindex, et attendre la désindexation effective avant toute redirection. Comptez plusieurs semaines sur un gros site.
Les facettes et filtres e-commerce
Sur une boutique Shopify ou WooCommerce, chaque combinaison de filtre peut générer une URL. J'ai réglé un cas où le paramètre ?orderby=price créait quatre variantes de chaque catégorie. Quatre, ça paraît anodin. Multiplié par 80 catégories, ça fait 320 pages qui se disputent le même contenu.
La solution est côté serveur : désactiver l'indexation des paramètres de tri et de filtre, garder uniquement les facettes qui ont un intérêt de recherche réel (une couleur, une taille, un usage), et poser une canonique vers la catégorie mère pour tout le reste.
Auditer et détecter les doublons sans y passer trois semaines
Une méthode que j'applique systématiquement, et qui prend une demi-journée par site de taille moyenne :
- Crawl complet avec un outil qui sort les titres et les descriptions. Deux pages avec le même
<title>: suspect immédiat. - Analyse des similarités de contenu : Siteliner pour de petits sites, une comparaison de hash sur les balises principales pour les gros.
- Rapport de couverture dans la Search Console : les pages « explorée, non indexée » sont souvent des doublons que Google a déjà repérés à votre place.
- Journal des URLs paramétrées : filtrez les
?et les&, c'est là que ça saigne.
| Outil | Ce qu'il détecte bien | Limite |
|---|---|---|
| Screaming Frog | Titres et canoniques dupliqués, paramètres, redirections | Version gratuite plafonnée à 500 URL |
| Siteliner | Similarité de contenu sur site entier | Peu efficace au-delà de quelques milliers de pages |
| Search Console | Pages explorées non indexées, doublons signalés par Google | Aucune vue sur le pourquoi |
| Oncrawl | Segmentation par template, analyse de clusters | Payant, courbe d'apprentissage |
Sur un site de 400 pages, ce genre d'audit m'a fait remonter 60 doublons réels en deux heures. Sur 12 000 pages, comptez une journée.
Faut-il indexer les pages de catégories ?
Oui, dans la very grande majorité des cas. Une catégorie bien construite avec un texte d'intro unique et une liste d'articles est une page utile pour l'utilisateur et pour le référencement. Le problème n'est pas la catégorie, c'est la catégorie vide ou la catégorie qui affiche le texte intégral de chaque article. Le premier cas se règle en enrichissant la page, le second en réglant l'extrait tronqué dans les paramètres du thème.
Que faire d'un contenu déjà dupliqué ?
Trois options, par ordre de préférence :
- Fusionner et rediriger en 301 si la page doublon n'apporte rien de plus.
- Réécrire et enrichir si la page a un potentiel propre (une catégorie qui pourrait devenir une vraie page pilier).
- Noindex + canonical si la page doit exister pour l'utilisateur mais pas pour le moteur (pagination, archives, pages de recherche).
Ce que je déconseille formellement : supprimer sans rediriger. Une suppression sèche, c'est perdre les liens entrants et créer des 404 en cascade dans l'arborescence.
Bonnes pratiques éditoriales : le volet humain du problème
La configuration ne fait pas tout. Il arrive qu'un rédacteur, en toute bonne foi, produise deux articles très proches parce qu'il n'a pas vu l'ancien. Sur un blog de plus de 200 billets, c'est même fréquent.
Ce que j'ai fini par instaurer sur les sites que je gère : une recherche systématique du mot-clé cible dans le back-office avant d'écrire un nouvel article. Trente secondes. Ça évite de rédiger 1 500 mots sur un sujet déjà traité six mois plus tôt. Et ça m'a évité, à moi aussi, de refaire le même article trois fois — je plaide coupable.
Autre habitude : quand un ancien article est daté mais toujours pertinent, on le met à jour et on le republie plutôt que d'en écrire un nouveau. Le contenu s'épaissit, l'URL reste stable, et la duplication disparaît par construction.
Checklist à appliquer dès aujourd'hui sur votre CMS
- Vérifier que les paramètres d'URL (tri, filtre, recherche) sont en
noindexou bloqués au niveau serveur. - Poser une canonical absolue (avec domaine complet) sur toutes les pages paginées.
- Désactiver l'indexation des archives par auteur et par mois si elles n'apportent rien.
- Contrôler que la recherche interne ne génère pas d'URL indexables.
- Nettoyer les taxonomies : supprimer les tags à usage unique.
- Lancer un crawl mensuel et comparer les résultats avec le mois précédent. Un doublon nouveau signale un changement de configuration.
- Sur les boutiques, lister les facettes d'URL à conserver et désindexer le reste au cas par cas.
Sur un site que j'administre, cette routine a fait passer le nombre de pages indexées de 8 400 à 2 300 en deux mois. Le trafic n'a pas bougé d'un point. Il a même grimpé de 11 % sur les six semaines suivantes, mais je reste prudent sur la causalité : je ne peux pas prouver que c'est uniquement le nettoyage.
Ce que je peux prouver, en revanche, c'est le temps gagné. Avant, chaque passage de Googlebot dans la Search Console était une source d'angoisse. Maintenant, je regarde le rapport une fois par mois, je ferme l'onglet, et je retourne écrire. C'est tout ce que je demande à un CMS : produire du contenu, pas du bruit.
