Comment rédiger un robots.txt qui bloque réellement les scrapers d’IA

La vérité inconfortable sur robots.txt

Un fichier robots.txt n’est pas un verrou. C’est un panneau sur la porte.

Cette distinction compte lorsque des équipes se demandent si elles peuvent « bloquer les scrapers d’IA » avec un petit fichier texte. Pour les robots réputés qui suivent le protocole d’exclusion des robots, oui : un robots.txt correctement rédigé peut leur indiquer de ne pas explorer vos pages. Pour les scrapers inconnus, les imitateurs, l’automatisation de navigateur et les bots qui s’en moquent tout simplement, il ne fera rien à lui seul.

L’objectif pratique n’est donc pas de « rendre le scraping impossible ». Il s’agit de :

• Dire aux robots d’IA conformes de ne pas utiliser votre site.
• Éviter de bloquer par accident les moteurs de recherche ou des services utiles.
• Ajouter des contrôles côté serveur plus robustes contre les abus.
• Garder la politique maintenable à mesure que les noms de robots changent.

C’est la version ennuyeuse. C’est aussi celle qui fonctionne.

Ce que robots.txt peut et ne peut pas faire

Un fichier robots.txt se trouve à la racine d’un site :

https://example.com/robots.txt

Les robots le demandent avant d’explorer le site. Le fichier contient des groupes de règles. Chaque groupe commence par une ou plusieurs lignes User-agent, suivies de directives Allow ou Disallow.

Un blocage simple de tout le site ressemble à ceci :

User-agent: GPTBot
Disallow: /

Cela signifie : si vous êtes GPTBot, n’explorez rien sur ce site.

Mais robots.txt a des limites strictes :

1. Il est volontaire. Les acteurs malveillants peuvent l’ignorer.
2. Il n’empêche pas une URL d’être demandée par un navigateur ou un script ordinaire.
3. Il ne supprime pas le contenu déjà collecté ailleurs.
4. Il ne définit pas à lui seul le droit d’auteur, les licences ou les droits d’entraînement.
5. Il peut être mal configuré et bloquer les mauvais bots.

Si vous avez besoin d’un véritable contrôle d’accès, utilisez l’authentification, l’autorisation, la limitation de débit, des contrôles par IP, la gestion des bots ou des contrôles juridiques. Robots.txt reste utile, mais il s’inscrit dans une stratégie plus large de protection du contenu.

C’est comparable à d’autres problèmes de gouvernance du web : le contrôle visible est rarement l’ensemble du contrôle. Si votre organisation connaît déjà des usages non maîtrisés de l’IA en interne, le même principe s’applique ; un rapide audit de shadow AI est souvent plus utile que de prétendre qu’un seul document de politique règle le problème.

Commencez par votre décision de politique

Avant de modifier le fichier, décidez ce que vous essayez réellement de bloquer.

Il y a au moins quatre choses différentes que les gens entendent par « scraper d’IA » :

• Les robots utilisés pour collecter des données d’entraînement.
• Les robots de recherche IA ou de moteurs de réponses.
• Les récupérateurs déclenchés par l’utilisateur, par exemple lorsqu’une personne demande à un produit d’IA de résumer une URL.
• Les scrapers génériques qui se font passer pour des navigateurs ordinaires.

Vous pouvez vouloir tous les bloquer. Ou vous pouvez vouloir conserver la découverte par les moteurs de recherche tout en refusant l’utilisation pour l’entraînement de modèles. Ce ne sont pas les mêmes politiques.

Par exemple, OpenAI documente des user agents distincts pour différents usages, notamment GPTBot, ChatGPT-User et OAI-SearchBot. Google utilise Google-Extended comme jeton de contrôle pour certains cas d’usage Gemini et Vertex AI, tandis que l’exploration normale de Google Search est gérée par d’autres user agents Googlebot.

Cette séparation est importante. Si vous bloquez négligemment des user agents larges, vous pouvez nuire à votre visibilité dans la recherche ordinaire en essayant de bloquer l’entraînement d’IA.

Un modèle raisonnable de robots.txt pour bloquer l’IA

Voici un point de départ prudent pour bloquer plusieurs robots liés à l’IA couramment documentés, tout en laissant les robots de recherche générale tranquilles :

# AI training and AI product crawlers
User-agent: GPTBot
Disallow: /

User-agent: ChatGPT-User
Disallow: /

User-agent: OAI-SearchBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Claude-Web
Disallow: /

User-agent: PerplexityBot
Disallow: /

User-agent: Amazonbot
Disallow: /

User-agent: Bytespider
Disallow: /

User-agent: Meta-ExternalAgent
Disallow: /

# Default rule for other crawlers
User-agent: *
Allow: /

Ce n’est pas une liste universelle magique. C’est un modèle maintenable.

Quelques remarques :

• Disallow: / signifie « n’explorez aucun chemin ».
• User-agent: * s’applique aux robots qui ne correspondent pas à un groupe plus spécifique.
• Allow: / n’est pas strictement nécessaire pour le groupe par défaut, mais rend votre intention claire.
• Gardez les commentaires courts. Certains parseurs sont tolérants, mais robots.txt doit rester sobre.
• N’incluez pas d’URL privées dans robots.txt. Le fichier est public, et lister des chemins sensibles peut les faire connaître.

Le dernier point mérite d’être répété. Robots.txt n’est pas un mécanisme de confidentialité. Si /client-contracts/ ne doit pas être public, protégez-le par authentification. Ne vous contentez pas de le désautoriser.

Soyez prudent avec Google-Extended

Google-Extended est largement mal compris. Ce n’est pas la même chose que bloquer Google Search.

Selon la documentation de Google, Google-Extended est un jeton de produit autonome que les éditeurs peuvent utiliser pour gérer si le contenu du site peut contribuer à améliorer certaines capacités de Gemini et Vertex AI. Le bloquer ne devrait pas, en soi, empêcher Googlebot d’explorer le site pour Search.

Cela dit, ne remplacez pas toutes les directives Google par un blocage large comme celui-ci, sauf si c’est vraiment ce que vous voulez :

User-agent: Googlebot
Disallow: /

Cela dirait au robot principal de Google Search de ne pas explorer votre site. Pour la plupart des sites web publics, ce n’est pas ce que vous souhaitez.

La même distinction s’applique ailleurs. Certains fournisseurs séparent les robots d’entraînement des navigateurs déclenchés par l’utilisateur ou des robots de recherche IA. D’autres non. Vous devez lire la documentation des bots qui vous importent et traiter votre robots.txt comme un fichier vivant, et non comme une case à cocher ponctuelle.

Testez le fichier comme du code de production

Robots.txt paraît simple, ce qui explique pourquoi il est facile à casser.

Les erreurs courantes incluent :

• Le téléverser au mauvais endroit, par exemple /assets/robots.txt au lieu de /robots.txt.
• Utiliser des guillemets typographiques copiés depuis un éditeur de documents.
• Bloquer tous les robots avec User-agent: * et Disallow: / par accident.
• Supposer que le fichier d’un domaine s’applique à un autre sous-domaine.
• Oublier que les hôtes http://, https://, www et sans www peuvent être traités différemment selon votre configuration.

Pour les sites multi-domaines, vérifiez chaque hôte canonique. Un fichier robots à https://www.example.com/robots.txt ne régit pas automatiquement https://app.example.com/robots.txt.

Lors du débogage, inspectez la réponse HTTP réelle, pas seulement ce qu’affiche l’aperçu de votre CMS. Vous voulez une réponse 200 OK, un type de contenu text/plain si possible, et exactement le fichier attendu. Si des redirections, du cache ou des règles de CDN interviennent, l’inspection brute des en-têtes aide. Le flux de travail décrit dans déboguer les redirections et les en-têtes HTTP en production s’applique directement ici.

Ajoutez des contrôles côté serveur pour les bots qui ignorent les règles

Si le robot est conforme, robots.txt est le signal le plus propre. Si le robot est abusif, il vous faut de l’exécution.

Les contrôles pratiques incluent :

Limitation de débit

Définissez des seuils pour les schémas de requêtes inhabituels : trop de pages par minute, parcours profond de pagination, 404 répétées ou volume élevé de requêtes depuis un petit ensemble d’IP. Les limites doivent être assez généreuses pour ne pas pénaliser les vrais utilisateurs, et assez strictes pour rendre l’extraction massive coûteuse.

Filtrage par user-agent

Vous pouvez bloquer les user agents de robots d’IA documentés au niveau du serveur web, du proxy inverse, du CDN ou de la couche applicative. C’est plus fort que robots.txt, car cela renvoie une véritable réponse de refus.

Par exemple, Nginx peut bloquer un motif de user agent, même si les règles de production doivent être testées avec soin :

if ($http_user_agent ~* "GPTBot|CCBot|ClaudeBot|Bytespider") {
    return 403;
}

Ce n’est pas infaillible. Les chaînes user-agent sont faciles à falsifier. Mais cela arrête le trafic honnête ou paresseux et réduit la charge.

Contrôles IP et ASN

Certains opérateurs publient des plages d’IP, mais beaucoup d’écosystèmes de scraping ne le font pas. Le blocage par IP peut fonctionner contre les abus évidents, surtout depuis des plages d’hébergement cloud sans trafic utilisateur normal, mais il peut aussi créer des faux positifs. Utilisez les journaux avant les règles.

Authentification et paywalls

Si du contenu ne doit pas être copié à grande échelle, ne placez pas le contenu complet sur une URL publique. Robots.txt ne convient pas aux informations confidentielles, aux bases de données sous licence, aux communautés privées ou aux archives payantes.

Minimisation du contenu

Parfois, la meilleure protection est architecturale. N’exposez pas d’API inutiles, de gros payloads JSON, de métadonnées cachées, d’endpoints de brouillon ou d’archives complètes si la page publique n’a besoin que d’un petit sous-ensemble. Les sites riches en images devraient aussi réfléchir aux métadonnées qu’ils publient ; la logique de confidentialité de suppression des métadonnées EXIF avant de partager des photos en ligne s’applique aussi aux opérations de contenu.

Utilisez les balises meta robots pour les règles au niveau des pages

Robots.txt contrôle l’exploration. Les balises meta robots et les en-têtes X-Robots-Tag contrôlent l’indexation et le comportement des extraits pour les moteurs de recherche et robots conformes.

Par exemple :

<meta name="robots" content="noindex, noarchive">

Ou comme en-tête HTTP :

X-Robots-Tag: noindex, noarchive

Ce ne sont pas des boucliers spécifiques à l’IA. Ils sont utiles lorsque vous voulez qu’une page soit accessible mais non indexée. Toutefois, si vous empêchez un robot de récupérer une page dans robots.txt, il peut ne jamais voir la balise meta au niveau de la page. Ne vous fiez pas à une balise noindex sur une URL qu’un robot n’a pas le droit d’explorer.

La règle approximative :

• Utilisez robots.txt pour réduire ou empêcher l’exploration.
• Utilisez meta robots ou X-Robots-Tag pour contrôler le comportement d’indexation.
• Utilisez des contrôles côté serveur pour faire respecter l’accès.

Surveillez les journaux après publication

Publier le fichier n’est que la première étape. Ensuite, vérifiez vos journaux.

Recherchez :

• Des requêtes vers /robots.txt provenant des user agents que vous avez nommés.
• Une exploration qui continue après la diffusion des règles de désautorisation.
• Des user agents suspects avec un volume élevé.
• Des user agents ressemblant à des navigateurs qui demandent des milliers de pages à la suite.
• Des accès répétés aux flux, sitemaps, pages de recherche et paginations.

Si un bot demande robots.txt, voit une interdiction complète, puis s’arrête, robots.txt a fait son travail. S’il continue, faites passer ce bot à l’exécution : limites de débit, blocages ou authentification.

Examinez aussi l’exposition de vos sitemaps. Les sitemaps sont utiles pour les moteurs de recherche, mais ce sont aussi des cartes pratiques pour les scrapers. Cela ne signifie pas que vous devez les retirer des sites ordinaires. Cela signifie que vous ne devez pas y inclure d’URL que vous ne voulez pas que des systèmes publics découvrent.

Gardez le fichier court et revu

Robots.txt a tendance à se dégrader. Une équipe marketing ajoute un microsite de campagne. Un développeur ajoute un chemin de staging. Un fournisseur change le nom de son robot. Deux ans plus tard, personne ne sait pourquoi la moitié des règles existent.

Traitez-le comme de la configuration :

• Stockez-le dans un système de contrôle de version lorsque c’est possible.
• Ajoutez un court commentaire pour chaque groupe de robots d’IA.
• Révisez-le tous les trimestres.
• Vérifiez la documentation des fournisseurs avant d’ajouter des règles larges.
• Testez après des changements de CDN, de CMS ou d’hébergement.

Si votre site publie du contenu assisté par l’IA, séparez aussi la politique d’exploration de la transparence éditoriale. Bloquer les scrapers d’IA concerne l’accès et la réutilisation. La divulgation concerne la confiance des lecteurs. Les deux se recoupent sur le plan éthique, mais ce n’est pas le même contrôle. Une approche pratique de la divulgation est présentée dans à quoi ressemble une divulgation honnête de l’IA sur un petit site web.

<!-- tool-cta:start -->

💡 Essayez ceci : Après avoir ajouté des règles pour les crawlers d’IA, vérifiez la syntaxe avec Robots.txt Tester afin de ne pas bloquer accidentellement aussi des bots légitimes.

<!-- tool-cta:end -->

En résumé

Un bon fichier robots.txt bloquera les robots d’IA conformes. Il n’arrêtera pas le scraping déterminé, les chaînes user-agent copiées, les navigateurs compromis ni les personnes qui collent manuellement votre contenu dans des systèmes d’IA.

Cela ne le rend pas inutile. Cela en fait une couche.

Rédigez des règles explicites pour les robots d’IA documentés. Évitez les blocages larges qui nuisent à la visibilité dans la recherche. Testez le fichier servi, pas le brouillon. Surveillez les journaux. Faites respecter vos règles avec des contrôles côté serveur lorsque le comportement passe d’indésirable à abusif.

Le web a toujours fonctionné avec un mélange de protocole, de normes et d’exécution. Robots.txt est la couche des normes. Utilisez-le, mais ne le prenez pas pour un mur.