Comment préparer votre site auto-hébergé aux agents IA

Dans un fil Hacker News consacré au trafic des robots IA, un administrateur d'hébergement a décrit la charge vue du côté de l'opérateur : « environ 6 robots IA plutôt agressifs » qui se coincent régulièrement sur des pages de variantes de produits ou de catégories et se mettent à les frapper à raison d'à peu près une requête par seconde, sur un site où « chaque chargement de page peut prendre une seconde complète d'aller-retour (surtout passée dans MySQL) ». L'effet cumulé, dans le même commentaire : « c'est presque comme si le site se faisait Slashdotter tous les jours ».

Préparer votre site aux agents IA est d'abord un problème de capacité : l'essentiel du travail relève de la configuration serveur, et très peu de la stratégie de contenu. La bonne nouvelle avec ce trafic, c'est qu'il n'est pas anonyme pour la plupart : les entreprises qui le génèrent publient le nom de leurs robots, documentent leur rôle et expliquent comment les désactiver. Voici ce qu'il faut configurer, ce que chaque mécanisme impose réellement, et les deux étapes que je passerais : publier un llms.txt, et ajouter du balisage schema pour l'IA.

En bref

• Le trafic IA se répartit généralement entre l'entraînement, l'indexation pour la recherche IA et les requêtes déclenchées par un utilisateur. OpenAI et Anthropic exposent des jetons distincts pour ces usages, ce qui permet de les contrôler séparément ; certains robots polyvalents regroupent plusieurs rôles sous une seule identité.
• OpenAI, Anthropic, Perplexity et Common Crawl documentent des contrôles robots.txt pour leurs robots automatiques. Les récupérateurs déclenchés par un utilisateur font exception : Anthropic applique robots.txt à Claude-User aussi, OpenAI indique que les règles peuvent ne pas s'appliquer à ChatGPT-User, et Perplexity-User les ignore généralement.
• Le fichier robots.txt est un mécanisme de consentement, pas un contrôle d'accès. RFC 9309 ne lui confère aucun pouvoir d'application propre ; les robots conformes peuvent alléger votre charge en le respectant, mais il ne peut ni brider ni arrêter le trafic non conforme.
• Sur 137 210 domaines issus de la base clients analytics d'Ahrefs, 97 % des fichiers llms.txt publiés n'ont reçu aucune requête en mai 2026. Publiez-en un si vous voulez, mais ne construisez pas d'outillage autour.
• Conservez les données structurées là où elles alimentent les fonctionnalités classiques de la recherche, mais la documentation de Google précise qu'aucun schéma particulier ni fichier texte pour l'IA n'est requis pour ses fonctionnalités IA.
• Rendez côté serveur les contenus critiques si vous voulez qu'OpenAI, ClaudeBot, PerplexityBot ou CCBot les lisent. Vercel a constaté que ces robots n'exécutent pas JavaScript ; Gemini via Googlebot et AppleBot font exception.
• Au-delà des règles coopératives de robots.txt, l'application effective se joue au niveau du reverse proxy, dans un WAF que vous exploitez vous-même, ou derrière un défi de preuve de travail, dans cet ordre de coût.

Ce que cet article n'aborde pas

Il s'agit ici d'un site visité par des agents, pas d'un site qui réalise des transactions avec eux. Quatre sujets voisins sont laissés de côté.

• Le commerce agentique et les tunnels de paiement, un autre problème pour un autre type de site.
• Le débat juridique et de droit d'auteur sur les données d'entraînement, qui relève d'une décision d'entreprise et non d'une configuration serveur.
• Un tutoriel d'implémentation WebMCP, la norme n'étant encore qu'un essai d'origine.
• La configuration propre à chaque CDN, au-delà de l'unique section Cloudflare ci-dessous.

Quels robots IA frappent votre site

GPTBot et ClaudeBot collectent du contenu susceptible de servir à l'entraînement des modèles. OAI-SearchBot et Claude-SearchBot alimentent la recherche et la récupération par IA. ChatGPT-User et Claude-User vont chercher des pages en réponse à une action d'un utilisateur. Ces rôles sont séparés chez certains fournisseurs, mais tous les robots du web ne se rangent pas proprement dans une seule catégorie.

Le tableau de la conformité est plus précis que ne le laisse croire le raccourci courant. la documentation d'Anthropic sur ses robots indique que ClaudeBot, Claude-User et Claude-SearchBot respectent robots.txt. la documentation d'OpenAI sur ses bots indique que ses robots automatiques disposent de contrôles indépendants, mais que les règles robots.txt peuvent ne pas s'appliquer à ChatGPT-User, car ces requêtes sont déclenchées par une personne. la documentation de Perplexity sur ses robots fait une distinction similaire : PerplexityBot suit les contrôles des webmasters, tandis que Perplexity-User ignore généralement robots.txt. L'affirmation globale selon laquelle les bots IA ignorent robots.txt mélange donc des robots documentés qui respectent le fichier, des récupérateurs déclenchés par l'utilisateur dont le comportement varie selon le fournisseur, et des scrapers qui ne s'identifient jamais.

Le tableau ci-dessous est à jour au moment de la rédaction. De nouveaux jetons apparaissent plus vite qu'un article ne peut les suivre : voyez-le comme une carte de départ à durée de vie courte.

Écrire des règles robots.txt pour les robots IA

RFC 9309 précise que les règles de robots.txt ne constituent pas une forme d'autorisation d'accès. L'IETF a normalisé la syntaxe, l'analyse et la mise en cache en septembre 2022 ; elle n'a pas transformé le fichier en mécanisme d'application. Les détails qui comptent vraiment se situent sous la syntaxe : le fichier doit être encodé en UTF-8, les analyseurs doivent traiter au moins 500 kibioctets, et en cas de conflit entre directives, c'est la correspondance de chemin la plus spécifique qui l'emporte. La position d'une règle dans le fichier n'a aucune incidence.

Un robots.txt pour robots IA utilise le même fichier et la même syntaxe que ceux dont vous disposez déjà ; ce qui change, c'est la liste des jetons. Organisez les règles par intention et elles survivront au casting des fournisseurs. Si votre objection porte sur l'entraînement, bloquez les jetons d'entraînement et laissez les indexeurs tranquilles :

# Block training, keep AI search indexing
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

Si vous voulez envoyer un signal de refus valable pour tout le site à chaque jeton nommé dans le tableau, regroupez-les sous une seule règle. Inutile de répéter le Disallow onze fois :

# Send a site-wide opt-out signal to named AI tokens
User-agent: GPTBot
User-agent: OAI-SearchBot
User-agent: ChatGPT-User
User-agent: OAI-AdsBot
User-agent: ClaudeBot
User-agent: Claude-User
User-agent: Claude-SearchBot
User-agent: PerplexityBot
User-agent: Perplexity-User
User-agent: Google-Extended
User-agent: CCBot
Disallow: /

Cela ne constitue toujours pas un blocage universel. Anthropic applique robots.txt à Claude-User, mais OpenAI indique que les règles peuvent ne pas s'appliquer à ChatGPT-User, et Perplexity-User les ignore généralement. Si ces récupérations déclenchées par un utilisateur doivent être arrêtées et pas seulement découragées, appliquez cette décision au niveau du proxy ou du WAF.

Google-Extended est le jeton le plus souvent mal compris, et la distinction compte si le trafic de recherche paie vos factures. la documentation de Google sur ses robots le décrit comme un jeton produit autonome déterminant si le contenu exploré peut servir à l'entraînement et à l'ancrage de Gemini en dehors de la recherche, et précise qu'il n'affecte ni l'inclusion ni le classement d'un site dans Google Search. Le bloquer ne touche en rien au comportement de Googlebot pour la recherche.

Tenir une liste de jetons à jour à la main n'est pas la meilleure façon d'occuper son après-midi. Le dépôt ai.robots.txt maintenu par la communauté suit les agents utilisateurs IA et génère des configurations pour robots.txt, nginx, Caddy, HAProxy, Lighttpd et Apache. Les administrateurs Apache peuvent déposer le bloc généré à côté de leurs autres règles .htaccess au niveau du répertoire.

Astuce de pro : ne faites pas confiance à la chaîne user-agent. C'est un en-tête, et les en-têtes se falsifient gratuitement. La documentation CCBot de Common Crawl avertit que des robots se font passer pour CCBot. Pour l'IPv4, vérifiez avec un DNS inverse confirmé en aval sous *.crawl.commoncrawl.org ; pour l'IPv6, utilisez les plages d'adresses publiées par Common Crawl, car le DNS inverse n'y est pas encore pris en charge. Les pages fournisseurs citées plus haut publient également les plages d'adresses actuelles des autres robots nommés. C'est un chemin de vérification documenté chez ces fournisseurs, pas une propriété des robots IA en général.

llms.txt sert-il à quelque chose ?

Au vu des données actuelles, presque rien. llms.txt est un fichier texte proposé à la racine de votre site, qui offre aux modèles de langage un résumé organisé de votre contenu. En publier un ne coûte pas cher, mais les données actuelles vous donnent peu de raisons d'y investir, et la documentation de Google indique que vous n'en avez pas besoin pour ses fonctionnalités de recherche IA.

Le format est minimal. La proposition llms.txt date de septembre 2024, se trouve à /llms.txt, et ne rend obligatoire qu'une seule section : un H1 portant le nom du site ou du projet.

C'est des mesures que vient le verdict. L'étude d'Ahrefs sur 137 210 domaines a établi que 28 % des domaines mesurés publiaient un fichier llms.txt et que 97 % de ces fichiers n'ont reçu aucune requête en mai 2026. Parmi les requêtes effectivement arrivées, 19,5 % provenaient d'outils IA identifiés. Ahrefs prévient aussi qu'une récupération ne prouve pas que le fichier a réellement été utilisé.

Ma lecture de ces chiffres, c'est que llms.txt est un pari sur une convention que les systèmes visés n'ont pas largement adoptée. Publiez-le si vous aimez les racines bien rangées. Mais ne construisez pas de chaîne de génération autour, ne le laissez pas devenir une étape bloquante de votre déploiement, et considérez quiconque le vend comme un levier de classement ou de citation comme ayant une bonne longueur d'avance sur les preuves.

Point clé : dans l'étude d'Ahrefs, 97 % des fichiers llms.txt publiés n'ont reçu aucune requête en mai 2026.

Rendre vos pages lisibles par les machines

La mesure des robots réalisée par Vercel a établi que les robots d'OpenAI, ClaudeBot, PerplexityBot, Meta-ExternalAgent, Bytespider et CCBot n'exécutent pas JavaScript. Gemini via Googlebot et AppleBot, si. Pour les robots qui n'exécutent rien, le contenu qui n'apparaît qu'après hydratation côté client est invisible : rendez donc côté serveur tout ce qui est critique. Le balisage est la question la plus simple, et les conseils de Google à ce sujet sont d'une franchise inhabituelle :

« Vous n'avez pas besoin de créer de nouveaux fichiers lisibles par les machines, de fichiers texte pour l'IA ni de balisage pour apparaître dans ces fonctionnalités. Il n'existe pas non plus de données structurées schema.org particulières que vous devriez ajouter. »

Les recommandations IA de Google Search Central

Le gain de visibilité de 40 % parfois cité à l'appui du schéma FAQ provient de l'article GEO , accepté à KDD 2024. L'article fait état de gains allant jusqu'à 40 %, mais les interventions testées portent sur des changements de contenu comme les citations, les extraits cités, les statistiques, la terminologie technique et la fluidité de la rédaction, et non sur FAQPage ni sur aucun autre balisage Schema.org. Le chiffre est exact ; son rattachement au balisage schema ne l'est pas.

Conservez les données structurées là où elles alimentent une fonctionnalité classique de la recherche et correspondent à la page visible. Google indique que l'éligibilité à ses fonctionnalités IA passe par l'indexation normale de la recherche, sans exigence de balisage distincte. Simplement, rien n'a montré qu'elles influençaient la citation par les IA.

Quand robots.txt ne suffit plus : limitation de débit et WAF au niveau du serveur

Les directives fonctionnent sur les robots qui ont accepté de jouer le jeu. Dans le même fil Hacker News, plusieurs exploitants ont décrit le trafic qui ne joue pas le jeu : des robots qui répartissent leurs requêtes sur de vastes pools de blocs d'adresses IP et font tourner leurs user agents pour ressembler à des visiteurs ordinaires, ce qui met en échec aussi bien les limites naïves par IP que la correspondance sur user agent. Traitez cela comme un témoignage communautaire ; personne dans le fil ne publiait de mesures. Mais cela décrit bien la population que robots.txt n'a jamais eu vocation à atteindre.

Avant de gravir cette échelle, il existe une manœuvre moins coûteuse pour le trafic qui coopère encore. Ralentissez-le :

User-agent: ClaudeBot
Crawl-delay: 1

Astuce de pro : limitez avant de bloquer. La documentation d'Anthropic prend en charge Crawl-delay pour ClaudeBot , de sorte que vous pouvez ralentir un robot gourmand mais bien élevé tout en le gardant. La même page indique que le blocage par IP n'est pas un mécanisme de refus durable. Ces deux points sont propres à Anthropic ; Crawl-delay n'est pas une directive universelle, alors consultez d'abord la documentation de chaque fournisseur.

Au-delà, tout relève d'une application que vous gérez vous-même, en trois barreaux de coût et d'efficacité croissants. Chacun apporte quelque chose et concède quelque chose.

Barreau 1 : directives de reverse proxy et limitation de débit

La limitation de débit des robots IA commence au reverse proxy, le premier élément de votre pile qui voit une requête et peut la ralentir avant que l'application ou la base de données ne fasse le moindre travail. La documentation de NGINX sur la limitation de débit précise que les requêtes dont la clé est vide ne sont pas comptées : une directive map peut n'attribuer une clé de limitation qu'aux jetons de robots que vous voulez brider, en laissant les requêtes non concordantes en dehors de limit_req_zone.

# /etc/nginx/nginx.conf, inside the http block
map $http_user_agent $ai_rate_key {
    default              "";
    ~*GPTBot             $binary_remote_addr;
    ~*OAI-SearchBot      $binary_remote_addr;
    ~*ClaudeBot          $binary_remote_addr;
    ~*Claude-SearchBot   $binary_remote_addr;
    ~*PerplexityBot      $binary_remote_addr;
    ~*CCBot              $binary_remote_addr;
}

limit_req_zone $ai_rate_key zone=ai_slowlane:10m rate=20r/m;

# /etc/nginx/sites-available/example.conf, inside the server block
location / {
    limit_req zone=ai_slowlane burst=10 nodelay;
    proxy_pass http://127.0.0.1:8080;
}

Le duo à régler est burst=10 nodelay : les requêtes au-dessus du débit moyen peuvent consommer la rafale immédiatement, et celles qui la dépassent reçoivent un 503 par défaut. Réglez trop serré et vous éjecterez un robot légitime en plein parcours, un problème plus lent à diagnostiquer qu'une panne. Caddy exprime les deux mêmes idées avec un matcher et un handler ; si vous hésitez entre les deux, les fichiers de configuration côte à côte sont plus utiles qu'un chiffre de débit synthétique.

La limite de ce barreau, c'est que la voie lente dépend toujours du user agent déclaré. Un scraper déguisé en Chrome contourne entièrement cette clé propre aux robots ; attraper ce trafic demande une limitation plus large fondée sur le comportement IP/chemin, ou le barreau WAF ci-dessous.

Barreau 2 : un pare-feu applicatif que vous exploitez vous-même

Un WAF déplace la décision d'un simple en-tête vers un jeu de règles qui lit ensemble les motifs de requêtes, les chemins et les débits, ce qu'il vous faut dès que le trafic cesse de s'annoncer. En exploiter un sur votre propre machine garde les règles et les journaux sur votre disque, là où vous pouvez les grepper à trois heures du matin. BunkerWeb est l'un de ces projets, SafeLine en est un autre, et tous deux tournent sur un VPS dès lors que la machine répond aux exigences d'architecture et de ressources du projet ; nous proposons des versions en un clic des deux pour vous épargner l'installation, même si l'empaquetage n'est pas ce qu'il y a de plus intéressant.

C'est aussi ce que coûte ce barreau. Les règles demandent de l'entretien, et une règle assez serrée pour attraper un scraper déterminé finira par attraper une personne. Les modes Monitor, Balanced et Strict de SafeLine rendent ce compromis explicite : commencez par observer le trafic assez longtemps pour repérer les faux positifs avant de laisser le WAF renvoyer automatiquement des réponses 403.

Barreau 3 : défis de preuve de travail

Anubis contourne entièrement le problème de l'identification. Pour le trafic que vous choisissez de défier, il fait payer à la requête un petit coût de calcul avant que l'origine ne la serve. Son système de politiques peut aussi autoriser, refuser ou soumettre à un défi les requêtes selon des règles de correspondance. Le README du projet le présente comme un utilitaire de pare-feu web contre l'IA, bâti autour de défis pour protéger les ressources en amont des robots scrapeurs. Il fonctionne sans exiger que chaque bot s'identifie correctement.

Le projet lui-même qualifie l'approche de réponse nucléaire, et la réserve est méritée. La taxe retombe sur tout le trafic que votre politique met au défi, ce qui peut inclure des humains sur des appareils lents ou des robots légitimes si les règles sont trop larges. Gardez ce barreau en réserve pour un trafic réellement hostile. Un robot enthousiaste est en général un problème de limitation de débit, et vous avez déjà la limitation.

Dimensionner pour le pic

La charge des robots arrive souvent par à-coups, mais qu'elle pèse sur le CPU, la base de données ou les E/S dépend de l'application et des URL parcourues. Dans l'exemple WordPress ci-dessus, l'exploitant a attribué l'essentiel de la seconde de rendu à MySQL : cet incident précis était donc un goulot d'étranglement de base de données déguisé en problème de trafic.

Le dimensionnement devient donc une question d'allocation, et une question inconfortable : vous payez la marge en continu, et elle ne justifie son coût que pendant un pic que vous ne contrôlez pas. Provisionnez quand même pour ce pic. Si BunkerWeb partage une machine avec l'application et la base de données, ne prenez pas les 8 Go pour une recommandation valable pour toute la pile. Le guide de démarrage rapide de BunkerWeb recommande 2 vCPU et 8 Go de RAM pour les tests ou les déploiements comptant très peu de services, et au moins 4 vCPU avec 16 Go de RAM pour les environnements de production protégeant de nombreux services. Ajoutez par-dessus le pic CPU de votre application, la mémoire de la base de données et la marge d'E/S.

Des cœurs à fréquence plus élevée aident quand le traitement des requêtes ou l'exécution des requêtes SQL est limité par le CPU ; davantage de cœurs aident quand vous avez besoin de plus de travail simultané en vol. Dimensionnez à partir de la concurrence de pointe, du temps de réponse p95, du CPU et de l'attente d'E/S de la base de données, et du taux d'échec de cache, plutôt que du seul trafic des robots.

Exploiter cette couche vous-même demande deux choses à la machine en dessous : un accès root, puisque chaque mécanisme ci-dessus est un fichier de configuration que vous modifiez et un service que vous redémarrez, et assez de marge pour qu'un pic ne fasse pas tomber le site pendant que les règles font leur travail. Si vous dimensionnez ou déplacez une machine pour cela, notre Linux VPS vous donne l'accès root exigé par cette pile et vous permet de tester la configuration proxy et WAF avant de vous engager sur une taille à long terme.

Développez sur un VPS Linux avec accès root, NVMe et la puissance AMD EPYC.

Voir les plans Linux

Les nouveaux réglages par défaut de Cloudflare pour le trafic IA

Cloudflare a réparti le trafic IA en catégories Search, Agent et Training dans son annonce de juillet 2026 sur le trafic IA. À compter du 15 septembre 2026, les nouveaux domaines qui rejoignent Cloudflare voient Training et Agent bloqués par défaut sur les pages affichant des publicités, tandis que Search reste autorisé. Les clients existants peuvent modifier le réglage au préalable, et les contrôles sont disponibles sur toutes les formules.

Ce qu'il faut retenir, c'est la complication que Cloudflare nomme dans sa propre annonce. Googlebot, Applebot et Bingbot combinent chacun le travail de recherche et d'entraînement dans la classification de Cloudflare : un client qui bloque la catégorie Training bloque donc aussi ces robots, y compris le comportement de recherche qu'il voulait conserver. C'est le même piège qui guette tout contrôle par catégorie traitant un robot polyvalent comme s'il n'avait qu'un seul rôle.

Si votre site n'est pas derrière Cloudflare, rien de tout cela n'est un levier à votre portée. Sachez que cela arrive, car les schémas de trafic vont bouger en septembre ; vos leviers restent les jetons robots.txt et la couche proxy évoquée plus haut.

WebMCP : à surveiller, pas encore à intégrer

WebMCP est le pendant côté navigateur du Model Context Protocol, la convention que les agents utilisent pour appeler des outils structurés au lieu de deviner. L' annonce de l'essai d'origine WebMCP par Chrome formule l'objectif sans détour : au lieu qu'un agent devine à quoi sert un bouton ou un champ de formulaire, un site peut exposer des fonctions structurées et des contrôles annotés que l'agent peut appeler directement.

C'est la première tentative crédible pour donner aux agents autre chose à faire sur votre site que de le lire, ce qui en fait l'élément le plus intéressant de cet article. C'est aussi expérimental et inachevé : un essai d'origine dans Chrome 149, ouvert en juin 2026. Surveillez la spécification. N'expédiez pas encore de dépendance de production autour, et laissez-la hors de votre plan de capacité.

Foire aux questions

User-agent: GPTBot
Disallow: /

grep -ohE 'GPTBot|ClaudeBot|CCBot|PerplexityBot|OAI-SearchBot|ChatGPT-User' \
  /var/log/nginx/access.log | sort | uniq -c | sort -rn