Tapez « contenu dupliqué » dans Google depuis la France. Le 14 août 2026, un AI Overview occupe le haut de l'écran, un panneau de graphe de connaissances affiche une définition sur la droite, et huit résultats organiques suivent. Le premier est Wikipédia. Et le panneau de droite reprend exactement la définition de Wikipédia, avec deux liens vers le même article.

Sur un sujet qui traite de la reproduction de contenu, Google duplique donc lui-même le passage qu'il classe en première position.

Restent sept résultats. Un billet d'agence de mai 2021, une page de décembre 2025, et deux pages qui n'affichent aucune date. Puis deux listes d'outils, intitulées « 10 outils pour détecter le contenu dupliqué en SEO » et « 10 outils pour prévenir le duplicate content », et une entrée de lexique SEO. S'y ajoutent trois vidéos YouTube datées de 2021, 2022 et 2023. Les trois questions People Also Ask que Google attache à cette recherche sont « Quels sont les 3 types de SEO ? », « C'est quoi le contenu SEO ? » et « Quels sont les 4 piliers du SEO ? ». Aucune des trois ne porte sur le contenu dupliqué.

Et voici le relevé qui a décidé du sujet de cet article. J'ai récupéré le texte des huit résultats, découpé chaque page en phrases, puis compté les phrases contenant à la fois un mot du sujet (dupliqué, duplicate, canonical, syndication) et un mot des moteurs génératifs (ChatGPT, Perplexity, génératif, AI Overview, AI Mode, LLM, Gemini, Claude).

Résultat : zéro. Sur les huit pages, pas une phrase ne croise les deux vocabulaires.

Il y a bien quelques occurrences de « ChatGPT » ou « Perplexity » dans ces pages, mais elles sont toutes ailleurs : dans un menu de navigation, dans un bouton « résumer cet article avec l'IA », dans le titre d'un article connexe sans rapport. Le corps des huit pages traite le contenu dupliqué comme un problème d'index Google, exactement comme en 2015.

Ce n'est pas une négligence. C'est que la réponse française à cette question est bonne, et qu'elle répond à une autre question que celle que les moteurs génératifs posent.

Ce que « contenu dupliqué » veut dire chez Google : un mécanisme d'index en trois temps

Commençons par la position officielle, parce qu'elle est ancienne, stable et souvent mal citée.

Le 12 septembre 2008, sur le blog Search Central, Google publie un billet intitulé « Demystifying the "duplicate content penalty" ». Il est toujours en ligne. Le passage que tout le monde connaît est celui-ci :

There's no such thing as a "duplicate content penalty."

Le reste du billet est beaucoup plus instructif que cette phrase, et c'est lui qui compte pour notre sujet. Google y explique pourquoi le contenu dupliqué a quand même un effet, et l'explication n'a rien à voir avec une sanction :

Most search engines strive for a certain level of variety; they want to show you ten different results on a search results page, not ten different URLs that all have the same content. To this end, Google tries to filter out duplicate documents so that users experience less redundancy.

Autrement dit, le traitement du contenu dupliqué est une exigence de variété de la page de résultats. Pas une punition, une contrainte de présentation. Retenez cette phrase, elle va servir deux fois.

Le billet enchaîne en citant le mécanisme en trois temps :

When we detect duplicate content, such as through variations caused by URL parameters, we group the duplicate URLs into one cluster. We select what we think is the "best" URL to represent the cluster in search results. We then consolidate properties of the URLs in the cluster, such as link popularity, to the representative URL.

Regrouper, élire, consolider. Ces trois verbes décrivent tout ce que le SEO appelle depuis vingt ans la gestion du contenu dupliqué, et ils ont une propriété commune qu'on ne remarque pas parce qu'elle va de soi : les trois se passent dans l'index.

C'est là que la balise canonical intervient. La documentation Google sur la canonicalisation est explicite sur son statut :

You can indicate your preference to Google using these techniques, but Google may choose a different page as canonical than you do, for various reasons. That is, indicating a canonical preference is a hint, not a rule.

Une indication, pas une règle. La portée de la balise se lit dans cette phrase : elle adresse un signal à l'étape 2 d'un processus interne à Google, et rien de plus. Elle vote pour l'URL représentante du cluster. En SEO, le canonical est donc un bulletin de vote, pas un verrou, et il ne parle à personne d'autre qu'à Google.

C'est cette machinerie qui rend la syndication de contenu confortable en SEO. Vous publiez chez vous, un partenaire reprend l'article, il pose un canonical vers votre URL, Google regroupe les deux, élit la vôtre, consolide les signaux dessus. Le mécanisme travaille pour vous.

Les trois étapes n'ont aucun équivalent en récupération directe

Maintenant posons la question que les huit résultats de la SERP ne posent pas. Que devient ce mécanisme quand la page est lue par ChatGPT ou par Perplexity ?

Il faut d'abord rappeler la distinction qui structure tout le sujet, et que j'ai développée dans l'article sur le schema.org et le GEO : les moteurs génératifs ne lisent pas tous les pages de la même façon. Les surfaces IA de Google exploitent l'index Google. Les moteurs en récupération directe vont chercher l'URL et lisent ce qu'ils reçoivent, sans index intermédiaire, et sans exécuter le JavaScript comme je l'ai détaillé dans l'article sur le rendu JavaScript.

Pour un moteur en récupération directe, il n'y a pas de cluster, parce qu'il n'y a pas d'index où regrouper des URL. Il n'y a pas d'élection, parce qu'il n'y a rien à représenter. Il n'y a pas de consolidation, parce qu'il n'y a pas de signaux accumulés à reporter. Les trois étapes tombent ensemble.

Reste une balise <link rel="canonical"> dans le <head>, qui est un texte parfaitement lisible et dont rien n'indique qu'il soit lu.

J'ai vérifié ce que les éditeurs en disent. Le geste est celui que j'applique à chaque article de ce blog : récupérer la page, retirer les balises, aplatir, compter, puis afficher le contexte de chaque occurrence pour écarter celles qui viennent du menu de navigation.

Sur la documentation des robots d'OpenAI (developers.openai.com/api/docs/bots, 65 295 caractères) et sur celle de Perplexity (docs.perplexity.ai/guides/bots, 62 233 caractères), voici les comptages, sur la page entière et non sur le seul corps :

terme          OpenAI   Perplexity
canonical           0            0
duplicate           0            0
syndication         0            0
attribution         0            0
cite                0            0

Aucun des deux éditeurs ne mentionne la canonicalisation, la duplication ou l'attribution dans sa documentation destinée aux propriétaires de sites.

La documentation Google « AI features and your website » mérite un mot de plus, parce qu'elle constitue un piège. Le grep brut y trouve 10 occurrences de « canonical » et 4 de « duplicate », ce qui semble contredire ce que je viens d'écrire. En affichant le contexte, les 14 occurrences se rangent dans la même catégorie :

...tooltip > Canonicalization <a href=".../301-redirects
...<li class="devsite-nav-item devsite-nav-expandable">
...data-label="Responsive Tab: Canonicalization"
...consolidate-duplicate-urls" class="devsite-nav-title"

Ce sont des entrées du menu latéral du site de documentation, reconnaissables à leurs attributs devsite-nav et track-metadata. Dans le corps de la page, le compte est de zéro pour les deux termes, et de zéro également pour « syndication ». C'est le même résultat que celui obtenu sur cette même documentation pour l'E-E-A-T, pour le balisage FAQ et pour Wikipédia. Il se lit avec la même prudence dans les deux sens. Cela n'établit pas que la canonicalisation soit sans effet sur les surfaces IA de Google. Cela établit que Google ne la présente pas comme une clé d'entrée quand il parle de ces surfaces.

La conséquence pratique. Quand un moteur en récupération directe cite une page, il cite l'URL qu'il a récupérée. Si votre article existe à trois endroits et que le robot en a récupéré un, c'est celui-là qui apparaît dans la réponse, quelle que soit la balise que vous avez posée dans les deux autres. La balise canonical protège votre classement. Elle ne dit rien de votre citation.

La déduplication ne disparaît pas, elle change d'unité et de test

On pourrait s'arrêter là et conclure que le contenu dupliqué n'est plus un sujet devant les moteurs génératifs. Ce serait faux, et pour une raison intéressante.

Souvenez-vous de la phrase de 2008 : les moteurs veulent afficher dix résultats différents. Cette exigence de variété n'est pas propre à une page de résultats bleus. C'est une contrainte générale de tout système qui doit sélectionner un petit nombre d'éléments dans un grand ensemble, et elle est formalisée dans la littérature de la recherche d'information depuis 1998, soit dix ans avant le billet de Google.

Jaime Carbonell et Jade Goldstein publient cette année-là, dans les actes de la 21e conférence ACM SIGIR, un article de deux pages intitulé « The use of MMR, diversity-based reranking for reordering documents and producing summaries » (août 1998, pages 335 et 336). Son résumé définit le critère en une phrase :

The Maximal Marginal Relevance (MMR) criterion strives to reduce redundancy while maintaining query relevance in re-ranking retrieved documents and in selecting appropriate passages for text summarization.

Réduire la redondance tout en maintenant la pertinence. Et notez la fin de la phrase : le critère s'applique au reclassement de documents récupérés et à la sélection de passages. L'introduction précise le cas d'usage :

in cases where there is a vast sea of potentially relevant documents, highly redundant with each other or (in the extreme) containing partially or fully duplicative information we must utilize means beyond pure relevance for document ranking

Cette technique n'est pas restée dans les archives académiques. Elle est exposée sous son nom dans les bibliothèques de récupération courantes. Dans le coeur de LangChain, le fichier vectorstores/base.py propose un paramètre search_type qui accepte trois valeurs, 'similarity', 'mmr' et 'similarity_score_threshold', et la méthode max_marginal_relevance_search porte cette docstring :

Maximal marginal relevance optimizes for similarity to query AND diversity among selected documents.

Son paramètre lambda_mult est décrit comme un nombre entre 0 et 1 « that determines the degree of diversity among the results », 0 correspondant à la diversité maximale et 1 à la diversité minimale. La suppression de la redondance est donc un réglage, disponible par défaut, dans l'outillage standard.

Voici le point que la SERP française ne dit nulle part. Entre 2008 et aujourd'hui, la déduplication n'a pas disparu : elle a changé deux fois de nature.

Elle a changé d'unité. En 2008, on regroupait des URL. Un système qui sélectionne des passages déduplique des passages, ce qui est la conséquence directe de la divergence entre unité de publication et unité de récupération que j'ai décrite dans l'article sur le query fan-out.

Et elle a changé de test. Détecter du contenu dupliqué au sens classique, c'est comparer des chaînes de caractères : des empreintes, des blocs de mots communs, un pourcentage de recouvrement. C'est ce que mesurent tous les outils listés par les deux articles « 10 outils » de la SERP. Mesurer une redondance entre vecteurs, c'est comparer des positions dans un espace sémantique.

Ces deux tests ne donnent pas le même résultat, et l'écart va dans un sens précis : vous pouvez être écarté comme redondant par rapport à un passage qui ne partage aucun mot avec le vôtre. Le contenu dupliqué classique exige du texte recopié. La redondance sémantique n'exige rien de tel. Deux passages qui disent la même chose avec un vocabulaire entièrement différent sont distincts pour un détecteur de plagiat et interchangeables pour un système de récupération.

Ce qui inverse complètement l'enjeu. Le risque n'est plus une sanction, il n'y en a jamais eu. Le risque n'est même plus de perdre une position au profit d'une copie de votre texte. Le risque est de ne pas être le sélectionné parmi plusieurs passages équivalents, dont aucun n'est une copie de quoi que ce soit.

Trois situations que le mot « dupliqué » confond

Le vocabulaire français range sous une seule expression trois situations qui n'ont ni la même cause, ni le même enjeu, ni le même remède devant les moteurs génératifs. C'est le même défaut de vocabulaire que celui que j'ai relevé pour les contenus fermés, où un seul mot recouvrait trois protocoles distincts.

Vos propres doublons internes. Paramètres d'URL, pagination, versions avec et sans slash, variantes de tri. C'est le cas que le billet de 2008 traite explicitement, avec son exemple de skates.asp?color=black&brand=riedell. Google le règle bien, la balise canonical fonctionne, et l'enjeu génératif est faible : un robot en récupération directe atteint une URL et lit son contenu, il ne s'égare pas dans vos facettes. Le seul point à surveiller est l'accessibilité, et il relève de l'entretien des liens et des redirections, dont j'ai montré l'importance dans l'article sur le maillage interne.

La syndication vers des tiers. Communiqués de presse, reprises par un média partenaire, republication sur une plateforme de publication, tribunes reprises ailleurs. C'est ici que se joue l'exposition réelle, et c'est le cas que la section suivante traite. Notez au passage que les règles anti-spam de Google mentionnent la syndication une seule fois, et pour l'exclure d'une infraction : parmi les exemples de ce qui n'est pas de l'abus de réputation de site, elles citent « News publications that have syndicated news content from other news publications ». Le sujet est traité sous l'angle de la conformité, pas sous celui de l'attribution.

Le fait d'être copié sans votre accord. Le billet de 2008 sépare nettement les deux directions, dans une parenthèse qui a très bien vieilli : « while scraping content from others is discouraged, having others scrape you is a different story ». En SEO, être copié est un problème modéré parce que l'élection du cluster vous favorise en général. Devant un moteur en récupération directe, la copie est une URL comme une autre, et elle est récupérable.

La syndication se joue sur deux fichiers robots.txt, pas sur une balise

Voici la conséquence opérationnelle la plus utile de tout ce qui précède, et je ne l'ai vue formulée nulle part.

Quand vous syndiquez un article, vous négociez habituellement deux choses : que le partenaire pose un canonical vers votre URL, et qu'il vous attribue le texte. Ces deux clauses règlent le SEO. Aucune des deux ne détermine qui sera cité par un moteur génératif. Une syndication de contenu se joue donc ailleurs que dans le contrat que vous avez signé.

Ce qui le détermine, c'est lequel des deux sites laisse entrer les robots. Si votre partenaire autorise GPTBot et que vous le bloquez, vous venez de lui offrir votre citation sur un texte que vous avez écrit. Si c'est l'inverse, la copie est invisible et vous gardez tout. La distinction entre robots d'entraînement, robots de recherche et robots déclenchés par l'utilisateur, que j'ai détaillée dans l'article sur le robots.txt et les crawlers IA, devient donc une clause de contrat de syndication.

Cela se vérifie en deux commandes. La première contrôle ce que le SEO vous a promis, la seconde contrôle ce qui décide de la citation, sur les deux sites à la fois :

# 1. Le partenaire pointe-t-il bien vers vous ?
curl -s https://partenaire.example/article-repris/ \
  | grep -o -E '<link[^>]*rel="canonical"[^>]*>'

# 2. Qui laisse entrer les robots des moteurs ?
for site in partenaire.example votre-site.example; do
  echo "--- $site"
  curl -s "https://$site/robots.txt" \
    | grep -i -E "GPTBot|OAI-SearchBot|PerplexityBot|ClaudeBot"
done

Un résultat vide à la seconde commande ne veut pas dire « bloqué », il veut dire « aucune règle nommée », donc autorisé par défaut. C'est le sens de la lecture d'un robots.txt, et c'est aussi pour cela que les logs serveur restent la seule preuve de ce qui est réellement passé, comme je l'ai développé dans l'article sur l'analyse des logs.

Le reste est une décision éditoriale, et elle se résume à une phrase : ne syndiquez pas le passage qui porte votre substance. Si l'analyse originale, les chiffres, la méthode et les réserves restent chez vous, et que la reprise est une version courte qui renvoie vers l'original, alors les deux versions ne sont plus équivalentes pour un système qui sélectionne des passages. L'une contient quelque chose que l'autre n'a pas. Vous ne vous protégez pas de la déduplication par une balise, vous vous en sortez en n'étant pas le doublon de vous-même.

Ce que cet article n'affirme pas

Trois réserves, parce que le sujet se prête aux raccourcis et que ce blog distingue ce qui se mesure de ce qui se raisonne.

Je n'affirme pas que ChatGPT, Perplexity ou AI Mode appliquent MMR ou une déduplication sémantique à la récupération. Aucun des trois ne publie son pipeline. La technique est documentée depuis 1998, elle porte sur les passages, elle est disponible par défaut dans l'outillage courant : cela rend l'hypothèse raisonnable, et rien de plus.

Rien ici ne démontre non plus qu'une copie syndiquée soit citée à la place de l'original. Il faudrait pour cela un protocole avec groupe témoin, et sur un changement de ce type l'unité randomisable manque. Mon constat est plus modeste : aucun document publié par OpenAI ou par Perplexity ne prend d'engagement sur la canonicalisation, donc rien ne garantit le contraire.

Enfin, la balise canonical reste parfaitement utile. Elle fait exactement ce que sa documentation décrit, sur le périmètre qu'elle décrit. La difficulté a toujours été ailleurs : dans l'extension silencieuse de sa garantie à des systèmes qui ne la lisent pas.

Le contrôle avant publication

Cinq questions, dans l'ordre où elles coûtent le moins cher.

Où votre contenu existe-t-il ailleurs, et sous quel accord ? La réponse est souvent plus longue que prévu, entre communiqués, reprises partenaires et plateformes de publication oubliées.

Sur chacun de ces emplacements, qui laisse entrer les robots des moteurs ? C'est la commande ci-dessus, et c'est la question qui décide.

La version que vous gardez contient-elle quelque chose que la version syndiquée n'a pas ? Si les deux sont identiques, vous avez deux passages interchangeables et vous ne contrôlez pas lequel gagne.

Vos passages sont-ils redondants entre eux, à l'intérieur de votre propre site ? Trois articles qui redisent la même chose se concurrencent devant un sélecteur de passages, sans qu'aucun ne soit une copie des autres. C'est le cas que les outils de détection ne voient pas.

Et enfin : ce que vous mesurez, le mesurez-vous au bon endroit ? Un outil de détection de plagiat mesure un recouvrement lexical. Il ne dira jamais si vous êtes cité, ce qui relève du suivi des citations.

Cet article ouvre le troisième volet d'une série sur ce qui est cité en dehors de votre domaine, après Reddit et Wikipédia. Les deux premiers montraient que les domaines les plus cités le sont pour des raisons non reproductibles. Celui-ci ajoute une remarque du même ordre : quand votre propre contenu se retrouve sur un domaine tiers, ce n'est plus votre SEO qui décide de la suite.

Si vous voulez faire le tri sur votre site, c'est l'un des points que couvre notre audit GEO, et la différence entre les deux disciplines est détaillée sur notre page GEO vs SEO.