Les robots d'IA sur votre site de petites annonces : ce qui décide vraiment lesquels bloquer
Les robots dans vos journaux de serveur qui ne sont pas Google
Il suffit d'ouvrir le journal d'accès brut d'un annuaire de petites annonces, même pour une seule journée, pour constater que la liste des visiteurs ne ressemble plus vraiment à une liste de personnes. À côté de Googlebot et des navigateurs habituels, on trouve GPTBot, ClaudeBot, PerplexityBot, Bytespider, CCBot, et une demi-douzaine de noms qui ne disent rien tant qu'on ne les a pas recherchés. Ils visitent chaque page d'annonce, y compris celles qui ont changé une heure plus tôt, et ils le font selon un rythme qu'aucun visiteur humain ne suit.
Un annuaire de petites annonces pour adultes constitue une cible plus intéressante pour ce type d'exploration que la plupart des sites, pour des raisons qui n'ont rien à voir avec le caractère adulte du contenu. Les annonces changent constamment, la structure par ville et par catégorie multiplie le nombre de pages distinctes, et chacune contient des photos et du texte qu'un robot peut récolter en un seul passage. Les mêmes caractéristiques qui rendent le site utile pour un visiteur le rendent efficace à aspirer.
Le fichier robots.txt est censé régler cette question : une liste de règles en texte brut indiquant à chaque robot nommé ce qu'il a le droit de récupérer. Il se trouve à la racine du domaine, n'importe quel robot peut le lire, et ceux conçus par des entreprises qui affirment le respecter, OpenAI, Anthropic, Google, le font généralement. Mais ce fichier constitue une demande, pas un verrou. Rien dans le protocole n'empêche un robot de récupérer quand même une page interdite, et rien côté site web ne fait appliquer la règle, sauf si l'exploitant ajoute un dispositif supplémentaire par-dessus.
Cet écart compte plus qu'avant, car les robots qui apparaissent dans ce journal ne forment pas une catégorie unique. Certains veulent entraîner un modèle sur la page. D'autres veulent répondre à une question à son sujet, dans l'instant. D'autres encore relaient la propre requête d'une personne via un assistant. Traiter ces trois cas de la même façon, en bloquant tout ou en ne bloquant rien, revient à renoncer à un choix que l'exploitant peut réellement faire.
Entraînement, réponse en direct et « un utilisateur a demandé » : trois missions différentes sous un même nom
OpenAI fait tourner trois robots distincts, et les confondre est l'erreur la plus fréquente dans un robots.txt rédigé à la hâte. GPTBot collecte des pages susceptibles de servir à entraîner de futurs modèles, et la documentation d'OpenAI indique elle-même que l'interdire exclut le contenu du site de ces données d'entraînement. OAI-SearchBot n'a rien à voir avec l'entraînement : c'est lui qui permet à une page d'apparaître comme source citée dans la fonction de recherche de ChatGPT, et il est contrôlé séparément de GPTBot, si bien qu'un site peut bloquer l'entraînement tout en restant éligible à la citation. ChatGPT-User n'est ni l'un ni l'autre : il se déclenche quand une personne pose réellement une question directe à ChatGPT sur une page, et OpenAI précise clairement que les règles du robots.txt peuvent ne pas s'appliquer dans ce cas, car la requête répond à une demande humaine précise plutôt qu'à une exploration automatisée.
Anthropic applique la même distinction en trois volets, sous d'autres noms. ClaudeBot explore à des fins d'entraînement, et la documentation d'assistance d'Anthropic indique que ses robots respectent les directives du robots.txt sur ce point. Claude-User et Claude-SearchBot couvrent respectivement les questions posées en direct et les citations issues de la recherche, chacun disposant de son propre mécanisme de refus.
La version de Google est plus restreinte, mais facile à comprendre à l'envers. Google-Extended n'est pas du tout un robot ; c'est un jeton ajouté au robots.txt qui détermine si le contenu déjà récupéré par Googlebot peut servir à entraîner Gemini ou à nourrir ses réponses. L'interdire ne touche ni au classement du site ni à sa présence dans les résultats ordinaires de Google Search, car Googlebot continue d'explorer exactement comme avant. Ce qui modifie réellement les chances d'un annuaire de petites annonces d'apparaître lorsque la question d'un internaute reçoit sa réponse dans les Présentations générées par IA de Google plutôt que dans une liste de liens bleus relève d'un réglage distinct, pas de Google-Extended : ces présentations s'appuient sur l'exploration classique de Googlebot, si bien que bloquer le jeton Extended retire un site de l'entraînement de Gemini sans l'exclure de ces présentations. Le seul levier qui agit à la fois sur ces présentations et sur les extraits de recherche ordinaires est la famille de balises nosnippet, un compromis plus lourd que ce que la plupart des exploitants imaginent avant de l'activer.
En pratique, un exploitant peut donc rédiger un robots.txt qui interdit chaque robot d'entraînement nommé tout en laissant intacts les robots de recherche et de citation, obtenant ainsi l'un des résultats sans l'autre. Personne ne met en place cette distinction par accident ; elle doit être écrite à la main, robot par robot.
Ce que la nouvelle politique de Cloudflare apporte, et ce qu'elle ne peut toujours pas faire
Le robots.txt a été conçu pour répondre à une seule question : quelles pages peut-on récupérer. Il n'a jamais été conçu pour répondre à une seconde : ce qu'on a le droit de faire de la page une fois qu'on l'a récupérée. La Content Signals Policy de Cloudflare, introduite en septembre 2025, ajoute précisément cette seconde couche. Un site peut désormais ajouter une ligne Content-Signal sous n'importe quel groupe user-agent, avec trois valeurs, search, ai-input et ai-train, chacune réglée sur yes ou no. Omettre l'une d'elles signifie que l'exploitant n'a pas exprimé de préférence pour cet usage, pas que la réponse est non.
Cela s'avère utile précisément parce que cela permet à un exploitant de dire, en un seul endroit, « indexez ceci pour la recherche, mais ne l'injectez pas dans un modèle et ne vous entraînez pas sur ce contenu », une distinction que l'ancienne syntaxe du robots.txt n'avait aucun moyen d'exprimer. Les sites utilisant le service de robots.txt géré par Cloudflare ont reçu automatiquement l'ajout search=yes, ai-train=no, pour les quelque 3,8 millions de domaines concernés ; tous les autres peuvent écrire ces lignes à la main ou les générer sur contentsignals.org.
La limite, honnêtement reconnue, figure dans la description que Cloudflare fait elle-même de cette politique : il s'agit de préférences déclarées, pas d'une barrière technique, et un robot qui choisit de les ignorer ne rencontre aucun obstacle au-delà de ce que le site a mis en place séparément, comme une règle de pare-feu ou un outil de gestion des robots.
Cette limite a cessé d'être théorique un mois avant même le lancement de la politique. En août 2025, Cloudflare a publié un rapport accusant Perplexity de faire fonctionner ce qu'elle a appelé des robots furtifs : des bots qui ne récupéraient pas le robots.txt avant d'explorer des domaines de test pourtant interdits, et qui basculaient vers une signature de navigateur générique de type Chrome une fois le PerplexityBot déclaré bloqué, en passant par des plages d'adresses IP que Perplexity n'avait pas publiées. Cloudflare a exclu Perplexity de son programme de robots vérifiés à la suite de ces constats. Perplexity a qualifié ce rapport de coup médiatique et contesté l'attribution, sans toutefois réfuter point par point les preuves précises concernant le user-agent et les adresses IP. Quel que soit le camp le plus dans son droit, cet épisode est la démonstration la plus claire disponible qu'une règle déclarée, dans un robots.txt ou dans une ligne Content-Signal, ne lie qu'un robot qui a décidé de s'y soumettre.
Les deux coûts que l'exploitant supporte réellement
Le premier coût est celui qui apparaît sur une facture. Un annuaire de petites annonces hébergé sur un VPS d'entrée de gamme ou un plan d'hébergement partagé, ce qui correspond à la situation de la plupart des exploitants de cette catégorie, dispose généralement d'un quota mensuel de transfert de données plutôt que d'une bande passante illimitée, et un robot consomme ce quota exactement comme le ferait un visiteur payant. Un robot d'entraînement qui récupère à intervalles réguliers chaque annonce et chaque photo d'un annuaire couvrant plusieurs villes ajoute une charge qui n'a rien à voir avec les personnes que le site est censé servir, et la même fragilité d'infrastructure qui permet à un hébergeur ou à un CDN de mettre fin à une activité de petites annonces par une simple notification de résiliation signifie aussi qu'un compte qui déclenche une suspension liée à l'usage à cause du trafic de robots s'expose exactement à ce type de fermeture brutale. Imperva, un éditeur spécialisé dans la gestion des robots, a indiqué dans son 2026 Bad Bot Report que le trafic automatisé représentait un peu plus de la moitié de l'ensemble du trafic web mesuré, dont environ 40 % classés comme malveillants ; ce chiffre provient d'un seul acteur ayant un intérêt commercial dans la question, mais la tendance qu'il décrit, à savoir qu'une part non négligeable de la facture de bande passante d'un site ne correspond à aucun trafic humain, concorde avec ce que révèle n'importe quel journal d'accès brut.
Le second coût, lui, n'apparaît sur aucune facture. Une demande de suppression visant la propre base de données de l'annuaire est quelque chose qu'un exploitant peut réellement exécuter : retrouver la fiche, la supprimer, confirmer qu'elle a disparu. Une photo et une biographie déjà collectées par un robot d'entraînement dans un ensemble de données destiné à enseigner des régularités générales à un modèle n'ont, elles, aucune démarche équivalente à entreprendre. Il n'existe aucune adresse de support pour un corpus d'entraînement, ni aucune confirmation que l'image d'un annonceur donné a été, ou non, conservée une fois sortie du serveur. C'est une version différente, et plus difficile à maîtriser, du problème de contrôle qui s'applique déjà à ce qu'un site de petites annonces révèle sur un annonceur par les métadonnées ordinaires attachées à une photo : une fois le contenu sorti, la capacité de l'exploitant à retracer son parcours chute fortement, et un annonceur qui demande « où finit la photo de mon annonce » mérite une réponse honnête sur cette limite plutôt qu'une assurance que l'exploitant ne peut pas garantir.
Ce qu'il faut concrètement faire
Commencez par lire le robots.txt actuel, sans présumer de son contenu. Un nombre surprenant de sites de petites annonces construits à partir d'un modèle n'ont tout simplement aucun fichier, ce qui laisse chaque robot fixer lui-même ses propres limites, ou conservent une unique règle générale « User-agent: *, Disallow: / » oubliée d'un environnement de préproduction, qui bloque Googlebot en même temps que tout le reste et réduit silencieusement à néant l'ensemble du canal de recherche organique du site, sans le moindre message d'erreur pour le signaler.
Tranchez d'abord la question de l'entraînement, car c'est celle qui admet une réponse tranchée. Rédigez des règles d'interdiction explicites pour GPTBot, ClaudeBot, Google-Extended, Bytespider et CCBot au minimum, puisqu'ils couvrent les principaux robots d'entraînement des modèles de fondation disposant de chaînes user-agent publiques et documentées. C'est une décision que l'exploitant peut prendre délibérément plutôt que par défaut.
Tranchez séparément la question de la recherche et de la citation, et tranchez-la réellement plutôt que de reprendre la règle appliquée à l'entraînement. OAI-SearchBot, Claude-SearchBot et PerplexityBot déterminent si l'annuaire peut être cité lorsqu'une personne pose à un assistant IA une question à laquelle une annonce pourrait répondre ; les bloquer sacrifie cette visibilité, les autoriser la préserve, et rien n'oblige à aligner cette réponse sur celle donnée à GPTBot et ClaudeBot sur la ligne précédente.
Si le site fonctionne sous Cloudflare, vérifiez si les lignes Content-Signal ont été ajoutées automatiquement et si les valeurs par défaut correspondent réellement à la préférence de l'exploitant, car le réglage automatique est raisonnable mais générique, pas adapté à un site en particulier. Si ce n'est pas le cas, ces lignes peuvent être écrites à la main en quelques minutes, ou générées sur contentsignals.org puis collées.
Enfin, considérez les règles du robots.txt et du Content-Signal comme la part facile, disons quatre-vingt-dix pour cent du travail, et acceptez que les robots restants, ceux prêts à faire ce que Cloudflare a reproché à Perplexity de faire, ne seront arrêtés par aucun fichier texte, quel que soit le soin apporté à sa rédaction. Pour les repérer, il faut surveiller l'arrivée du nom d'un robot déclaré depuis une adresse IP extérieure à sa plage publiée, ce qu'une fonction de gestion des robots d'un CDN peut signaler automatiquement si le budget le permet, ou ce qui ressort manuellement du journal d'accès pour quiconque le consulte régulièrement. Dans tous les cas, l'objectif n'est pas d'éliminer tous les robots indésirables, ce qui est hors de portée ; c'est de s'assurer que ceux qui sont réellement disposés à écouter savent clairement laquelle des trois missions ils ont le droit d'accomplir.
