Sept fournisseurs de visibilité IA sur soixante-huit déclarent des Content Signals. Aucun n'utilise le nouveau champ.

Les Content Signals sont la seule façon lisible par machine de dire ce qu’un robot d’IA peut faire de votre page après l’avoir lue. Ils vivent dans le robots.txt, ils ont une spécification derrière eux, et ils sont gratuits. Nous avons demandé leur robots.txt aux 69 fournisseurs de notre catalogue le 14 août 2026. Sur les 68 fournisseurs ayant servi un fichier lisible, 7 déclarent des Content Signals et 0 déclarent le quatrième champ.

C’est une catégorie dont le produit entier consiste à être lue correctement par des machines. C’est aussi une catégorie qui, à sept exceptions près, n’a pas utilisé le seul champ conçu pour le dire.

Transparence : EchoWi fait partie des 69 et fait partie des sept, et nous vendons de la mesure de visibilité IA, donc une étude sur qui déclare correctement ses préférences est une étude qui a un intérêt. La méthode est une requête GET sur /robots.txt et une recherche des lignes commençant par Content-Signal:. La date est le 14 août 2026, chaque fournisseur qui déclare est nommé plus bas avec sa formulation exacte, et les comptes sont dans notre registre de mesures. N’importe qui peut le refaire contre nous en une minute, et la section sur ce que notre propre balayage précédent a raté est là parce que nous l’avons d’abord fait tourner contre nous.

La version courte

1. 68 des 69 fournisseurs servent un robots.txt. Un seul renvoie un défi de bot à la place, ce qui est un défi et non un fichier absent, et c’est pour cela qu’il est compté à part.
2. 7 des 68 déclarent des Content Signals. Cela fait environ un sur dix, dans une catégorie bâtie sur le fait d’être lisible par machine.
3. 0 déclarent content-use, le quatrième champ actuellement testé. Pas un seul fournisseur de la catégorie ne l’a adopté.
4. Six des sept déclarent une permissivité totale, une version ou une autre de search oui, ai-input oui, ai-train oui.
5. Un déclare ai-train=no tout en gardant ai-input=yes. Ce n’est pas une contradiction, et le traiter comme telle serait l’erreur facile que cette pièce prend soin de ne pas commettre.
6. Notre propre comptage antérieur de cette même convention se trompait sur ce fournisseur, pour une raison d’instrument que nous décrivons au lieu de la corriger en silence.

Ce qu’est un Content Signal, et le champ qui vient d’apparaître

Un fichier robots.txt a toujours pu dire où un robot peut aller. Il n’a jamais pu dire ce qu’un robot peut faire de ce qu’il trouve. Les Content Signals comblent ce trou avec trois champs, écrits comme une ligne de directive à l’intérieur d’un groupe :

User-Agent: *
Content-Signal: search=yes, ai-input=yes, ai-train=yes
Allow: /

Les trois veulent dire des choses différentes et la différence est précisément la raison d’être :

• search couvre la construction d’un index de recherche sur le contenu.
• ai-input couvre le fait de donner le contenu à un modèle pour produire une réponse en temps réel. C’est celui qui gouverne la citation.
• ai-train couvre l’usage du contenu pour entraîner ou affiner un modèle.

Un éditeur peut tenir n’importe quelle combinaison de positions sur ces trois-là, et le vocabulaire existe pour qu’une position nuancée soit exprimable au lieu d’être approchée en bloquant purement un robot.

Cloudflare teste en ce moment un quatrième champ, content-use, qui décrit ce qui peut être conservé et réutilisé après l’accès. Il prend une de trois valeurs, de la moins à la plus permissive : use=immediate veut dire interagir sans rien garder, use=reference veut dire indexer, citer un extrait et faire un lien retour, et use=full veut dire résumer et reproduire. Le robots.txt géré de Cloudflare écrit lui-même use=reference à côté de son défaut search=yes, ai-train=no.

Le même catalogue a reçu une question voisine le même jour, avec le même instrument : la plupart des domaines qui obtiennent des citations ne publient pas de llms.txt alors que la plupart des fournisseurs si, c’est l’autre convention que vend cette catégorie.

Ce quatrième champ est la raison pour laquelle ce balayage valait la peine maintenant plutôt que plus tard. Il est assez neuf pour que l’adoption soit une vraie question, et la réponse est nette.

Ce que disent soixante-neuf fichiers robots.txt

L’instrument demande /robots.txt à l’origine de chaque fournisseur, suit les redirections, et lit toutes les lignes Content-Signal: du corps. Il est délibérément sans éclat, et trois de ses choix comptent :

Il utilise GET, jamais HEAD. Un serveur n’est pas tenu de répondre à une requête HEAD, et ce n’est pas théorique ici : un vérificateur de liens antérieur de ce projet a signalé deux pages parfaitement vivantes comme mortes exactement pour cette raison, avant d’être corrigé.

Un défi n’est pas un fichier absent. Les statuts 401, 403, 429 et 999 signifient qu’un contrôle anti-bot s’est mis en travers. C’est une preuve sur la bordure, pas sur l’existence du fichier, et le ranger dans « pas de robots.txt » fabriquerait un chiffre. Un fournisseur tombe dans ce seau.

Un 200 n’est pas automatiquement un robots.txt. Certains hébergeurs répondent à n’importe quel chemin par une page marketing. Le corps doit contenir une vraie directive avant que la ligne compte.

Les comptes du 14 août 2026 :

Et les sept, avec ce que chacun dit réellement :

Deux choses sont à lire dans ce tableau avant de tirer une conclusion du titre.

La première est qu’un robots.txt porte une ligne Content-Signal par groupe, donc le compte de la colonne du milieu n’est pas décoratif. Rankability en écrit onze, ce qui est un acte délibéré de dire la même chose à onze groupes de robots différents. Omnibound en écrit trois, et elles ne disent pas toutes la même chose.

La seconde est que la déclaration de Rankability omet ai-input entièrement. Selon la spécification un champ absent n’est pas un non, c’est un silence, donc ce n’est pas un refus de la citation. C’est un fournisseur qui a réfléchi à l’entraînement et à la recherche et n’a rien dit du champ qui gouverne le fait d’être utilisé dans une réponse.

Le seul fournisseur qui dit non, et pourquoi c’est la réponse réfléchie

Omnibound est le seul des sept à déclarer une préférence restrictive où que ce soit : ai-train=no, à côté de ai-input=yes.

La lecture tentante est qu’un fournisseur qui vend de la visibilité IA en disant aux robots d’IA de ne pas utiliser son contenu est une contradiction à pointer du doigt. Cette lecture est fausse, et il vaut la peine d’épeler pourquoi, parce que toute la valeur de ce vocabulaire repose sur la distinction qu’il fait.

Entraîner et répondre sont des usages différents. Un modèle entraîné sur votre contenu l’a absorbé dans ses poids, ne cite personne et n’envoie personne. Un modèle qui utilise votre contenu comme entrée d’une réponse peut le citer, l’attribuer et y faire un lien. Un éditeur qui veut le second et pas le premier n’est pas confus. Il exprime exactement la position que les trois champs ont été conçus pour laisser exprimer, et c’est le seul fournisseur de cette catégorie qui a pris la peine de l’exprimer.

Sur les chiffres tels que nous les avons trouvés, Omnibound a la déclaration la plus réfléchie de l’ensemble. Tous les autres qui déclarent quelque chose ont dit oui à tout, ce qui est une position défendable pour une entreprise qui veut la portée machine maximale, et c’est aussi ce qu’on écrit quand on n’a pas pensé à la différence.

L’instrument s’est trompé d’abord, et notre propre comptage antérieur aussi

Nous avons fait tourner une version de ce balayage trois jours plus tôt, le 11 août, dans un audit plus large de ce que cette catégorie livre. Ce comptage-là a enregistré qu’Omnibound déclarait search=yes, point final.

C’était notre instrument, pas leur fichier. Il lisait la première ligne Content-Signal: et la rapportait comme si elle était la déclaration. Omnibound en a trois, et la première se trouve être la moins intéressante. Le registre publié a donc eu la position d’un fournisseur à l’envers pendant trois jours, et rien n’a alerté, parce qu’une valeur tronquée ressemble exactement à une valeur complète.

Nous ne modifions pas le chiffre antérieur. C’est un fait figé sur ce que notre instrument a vu son jour à lui, et ses comptes sont cités à plusieurs endroits. Ce que nous avons fait à la place, c’est enregistrer le nouveau balayage à part, garder chaque ligne avec son compte à côté, et écrire dans les données elles-mêmes pourquoi les deux dates ne concordent pas. Savoir si Omnibound a changé le fichier entre le onze et le quatorze, ou si notre instrument antérieur l’a simplement mal lu, n’est plus récupérable. Choisir l’explication qui nous arrange serait inventer un fait.

La règle générale que nous en tirons : quand un format permet à un champ d’apparaître plus d’une fois, l’instrument les recueille toutes et le registre garde combien il y en avait. Un compte à côté d’une valeur, c’est ce qui rend la prochaine troncature visible.

Et les sites qui obtiennent vraiment les citations ne font pas mieux

L’objection évidente à tout ce qui précède est que nous avons mesuré les mauvaises personnes. Les fournisseurs vendent de la visibilité, ils ne l’obtiennent pas forcément. Nous avons donc posé la même question aux domaines qui l’obtiennent.

La population est chaque domaine que ce registre a noté comme cité dans trois lignes de sonde ou plus, soit 122 des 1 019 domaines distincts qu’il a vus. Le seuil est arbitraire et nous le déclarons : assez haut pour qu’un domaine ait été cité sur plusieurs questions et pas une seule, assez bas pour laisser un échantillon plus grand que le catalogue de fournisseurs. Sur ces 122, 113 ont servi un fichier lisible, 5 ont renvoyé un défi, 3 n’ont pas résolu et 1 a répondu 200 avec quelque chose qui n’est pas un robots.txt.

9 des 113 domaines cités déclarent des Content Signals. Face aux 7 sur 68 des fournisseurs, c’est le même taux à l’intérieur de toute erreur digne de ce nom.

Cela va contre le cadrage par lequel cette pièce s’ouvre, alors disons-le clairement : la catégorie n’est pas particulièrement négligente avec une convention dont son propre produit dépend. Elle est normale. La normale est simplement très basse, dans les deux populations, et un constat sur un secteur s’écrit moins confortablement qu’un constat sur un ensemble de concurrents.

Deux différences survivent à la comparaison, et l’une est plus petite qu’elle n’en a l’air.

Le quatrième champ existe dehors et pas dans la catégorie. Aucun fournisseur ne déclare content-use. Deux domaines cités le font. Mais les deux écrivent la chaîne identique octet pour octet search=yes,ai-train=no,use=reference, espacement compris, donc deux adoptants ne sont pas la preuve de deux décisions. L’explication la plus probable est un plugin ou un extrait copié, et nous le notons ainsi plutôt que comme une adoption.

Refuser l’entraînement est plus courant hors de la catégorie. Quatre des neuf domaines cités qui déclarent disent ai-train=no, contre un sur sept fournisseurs. Ce sont des comptes et non des taux volontairement : à un seul chiffre un pourcentage serait du théâtre, et l’honnête est de dire que la seule population où dire non à l’entraînement est courant est celle que nous n’avons pas construite.

Ce que ceci ne montre pas

Une convention, un jour, un catalogue. Ce sont 69 fournisseurs que nous suivons, le 14 août 2026. Ce n’est pas un échantillon du web et ce n’est pas une affirmation sur qui que ce soit hors de cette liste.

Déclarer n’est pas respecter, et ne pas déclarer n’est pas bloquer. Les Content Signals expriment une préférence. Ils n’imposent rien, un robot est libre de les ignorer, et un fournisseur sans déclaration n’a rien refusé pour autant. La lecture correcte des 61 qui ne déclarent pas est qu’ils se taisent, pas qu’ils sont hostiles.

Un robots.txt est ce que la bordure sert, pas ce que le dépôt contient. Nous le savons d’expérience : notre propre déclaration a été invisible pour un balayage antérieur parce qu’un CDN servait encore une version en cache avec un an de TTL. Une mesure de ce qu’un site déclare est une mesure de ce que son cache distribue ce jour-là.

Zéro adoption d’un champ n’est pas la preuve que le champ est mauvais. content-use est neuf et encore décrit comme un test. Que personne ne l’ait adopté est autant un fait sur le moment que sur le champ, et la chose honnête est de le remesurer plus tard plutôt que de conclure maintenant.

Nous n’avons pas mesuré si tout cela change la citation. Rien ici ne relie une déclaration au fait d’être cité plus ou moins souvent. Cela demanderait un autre dispositif, et nous préférons le dire plutôt que de suggérer le lien.

Questions fréquentes sur les Content Signals

Que sont les Content Signals dans robots.txt ?

Les Content Signals sont des directives lisibles par machine à l’intérieur d’un fichier robots.txt qui indiquent ce qu’un robot peut faire du contenu après y avoir accédé. Il y a trois champs : search pour construire un index de recherche, ai-input pour donner le contenu à un modèle afin de générer une réponse en temps réel, et ai-train pour entraîner ou affiner un modèle. Ils s’écrivent comme une ligne de directive dans un groupe de robots, par exemple Content-Signal: search=yes, ai-input=yes, ai-train=yes, et chaque champ prend yes ou no.

Combien de fournisseurs de visibilité IA déclarent des Content Signals ?

7 des 68 qui ont servi un robots.txt lisible, mesuré le 14 août 2026 sur les 69 fournisseurs de notre catalogue. Un fournisseur de plus a renvoyé un défi de bot au lieu d’un fichier, et nous le comptons à part parce qu’un défi n’est pas la preuve qu’un fichier manque. Les sept sont nommés dans le tableau ci-dessus avec leurs déclarations exactes.

Qu’est-ce que le champ content-use ?

content-use est un quatrième champ des Content Signals actuellement testé, qui décrit ce qui peut être conservé et réutilisé après l’accès. Ses trois valeurs vont de la moins à la plus permissive : use=immediate veut dire interagir sans rien stocker ni réutiliser, use=reference veut dire indexer, citer un extrait et faire un lien retour, et use=full veut dire résumer et reproduire. Au 14 août 2026, aucun des 68 fournisseurs que nous avons pu lire ne le déclare.

Déclarer ai-train=no nuit-il à votre visibilité IA ?

Pas en soi, parce qu’entraîner et répondre sont des usages séparés. ai-train gouverne si votre contenu peut être absorbé dans les poids d’un modèle, tandis qu’ai-input gouverne s’il peut servir de matériau source à une réponse générée, qui est celui qui produit des citations et des liens. Un éditeur peut refuser le premier et permettre le second, et un fournisseur de ce balayage fait exactement cela.

Devrais-je ajouter des Content Signals à mon robots.txt ?

C’est gratuit, c’est une ligne par groupe de robots, et c’est la seule manière normalisée d’énoncer la différence entre être entraîné et être cité. Déclarer de façon permissive ou restrictive est une décision de droits et non une décision technique, donc l’étape utile est de décider ce que vous voulez vraiment pour chacun des trois usages avant d’écrire quoi que ce soit. Déclarer n’impose rien, cela vient donc à côté des contrôles d’accès que vous avez déjà et non à leur place.

Comment vérifier ce qu’un site déclare ?

Demandez /robots.txt à l’origine du site avec un GET, pas un HEAD, et lisez toutes les lignes commençant par Content-Signal:. Il peut y en avoir plusieurs, car un fichier en porte une par groupe de robots, et ne lire que la première est exactement la façon dont nous nous sommes trompés sur la position d’un fournisseur lors d’un balayage antérieur. Si la requête renvoie 401, 403, 429 ou 999, vous avez rencontré un défi de bot et n’avez rien appris sur le fichier.