Décider de bloquer les robots d’exploration IA est une décision commerciale dont de nombreux professionnels de la recherche discutent actuellement. Mais une fois que vous avez pris la décision, quelle est la meilleure façon de bloquer ces robots ?
Il existe deux approches principales à considérer pour bloquer les robots d’exploration : via robots.txt et au niveau de la pile du serveur.
Les deux approches
Ces deux approches ont leurs avantages et leurs inconvénients. Commençons par examiner leur fonctionnement et les différences entre les deux.
Blocage via le fichier Robots.txt
Bloquer les robots d’exploration IA à l’aide de robots.txt est exactement le même processus que celui que vous utiliseriez pour bloquer tout type de bot.
Chaque robot IA a son propre nom d’identification, par exemple GPTBot et OAI-SearchBot d’OpenAI. Pour les bloquer, il vous suffit d’ajouter une règle d’interdiction précisant le nom du robot. Par exemple, pour empêcher GPTBot d’explorer n’importe quelle partie de votre site Web, vous devez ajouter :
Agent utilisateur : GPTBot
Interdire : /
S’il n’y a que certaines parties de votre site Web que vous souhaitez empêcher l’exploration des robots IA, vous pouvez les appeler de la même manière. Par exemple, pour empêcher GPTBot d’explorer vos pages de produits, vous devez inclure le dossier dans lequel se trouvent ces pages, par exemple :
Agent utilisateur : GPTBot
Interdire : /produits/
Blocage au niveau du serveur
Il existe plusieurs façons de bloquer les robots au niveau du serveur : via le serveur lui-même, le CDN ou le WAF.
Dans ce cas, le serveur lira la requête entrante, comme l’adresse IP, l’en-tête, etc. du bot, et appliquera les règles spécifiques que vous avez configurées pour cet agent (refuser, autoriser, rediriger). Par exemple, vous pouvez spécifier que GPTBot reçoive une commande « refuser ». Cela empêcherait le bot d’accéder au contenu de votre site.
Pour le Content Delivery Network (CDN), le concept est le même mais il se produit à un stade antérieur de la visite d’un bot. Le CDN intercepte une demande de contenu provenant d’un bot avant qu’elle n’atteigne le serveur. Cela permet essentiellement d’économiser la bande passante du serveur, car le bot n’interagit jamais réellement avec lui. Certains CDN proposent cette technologie de manière native sans que vous ayez à faire grand-chose pour la configurer. Par exemple, Cloudflare propose un blocage prédéfini selon qu’un bot est un robot de recherche, un agent ou utilisé pour la formation, ainsi qu’un réglage plus fin bot par bot.
Au niveau du Web Application Firewall (WAF), les robots sont plus scrutés que le CDN. Le WAF agit comme une couche de sécurité capable d’analyser le comportement des requêtes, et pas seulement les en-têtes utilisés par les robots. Cela signifie qu’il est capable de détecter les robots qui usurpent d’autres agents utilisateurs. Il s’agit du moyen le plus efficace parmi la plupart des piles technologiques pour identifier les robots d’exploration d’IA plus sophistiqués qui cherchent à passer sous le radar des tentatives de blocage. Le WAF que votre entreprise utilise peut faire partie de votre CDN, par exemple Cloudflare WAF, ou une application autonome comme AWS WAF.
Robots.txt : avantages et inconvénients
Le fichier robots.txt est probablement le moyen le plus accessible aux professionnels de la recherche pour contrôler les robots. En règle générale, les référenceurs ont accès à la modification du fichier robots.txt pour leurs domaines ou peuvent facilement demander une mise à jour rapide par l’équipe de développement.
Cependant, l’utilisation de cette méthode présente d’autres avantages.
Avantages
Le mécanisme d’interdiction des robots.txt est officiellement pris en charge par les plus grandes sociétés d’IA réputées. Par exemple, GPTBot et OAI-SearchBot d’OpenAI, ClaudeBot, Claude-User et Claude-SearchBot d’Anthropic, Google-Extended de Google et PerplexityBot de Perplexity.
Cette méthode vous permet de choisir de manière sélective les pages à empêcher les robots de visiter, et également d’affiner le blocage en fonction de chaque robot.
Inconvénients
Cette méthode présente cependant certains inconvénients. Le plus grand risque est que le respect du fichier robots.txt soit entièrement volontaire et ne soit pas surveillé de manière centralisée. Autrement dit, même si les créateurs de robots IA peuvent prétendre que leurs robots respectent le fichier robots.txt, il ne s’agit que d’un ensemble de requêtes, et non d’un véritable blocage. Considérez-le comme un panneau d’interdiction de propriété devant un portail ouvert. Rien n’arrête réellement les robots, seulement leur codage pour respecter les règles du fichier robots.txt.
Le fichier robots.txt peut être configuré pour interdire très facilement les robots de certaines pages s’il existe des contrôles robots.txt dans le CMS du site Web. Cela signifie que les parties prenantes non techniques peuvent accidentellement bloquer plus de robots que prévu avec une règle d’interdiction erronée. Cela peut être catastrophique si le fichier robots.txt est mis à jour pour interdire tous les robots, par exemple en implémentant :
Agent utilisateur : *
Interdire : /
Le fichier robots.txt n’est pas automatiquement mis à jour lorsque de nouveaux agents utilisateurs sont publiés. Cela signifie que quelqu’un devra ajouter manuellement de nouvelles interdictions chaque fois que vous souhaitez empêcher un nouveau robot IA d’accéder à votre site.
Pile de serveurs : avantages et inconvénients
Le blocage des robots au niveau d’un serveur, d’un CDN ou d’un WAF présente différents avantages selon l’implémentation.
Avantages
Les implémentations CDN et WAF arrêteront les requêtes des robots avant qu’elles n’atteignent le serveur. Cela permettra d’économiser la bande passante du serveur, réduisant ainsi la pression sur le serveur et réduisant les coûts associés.
Le plus grand avantage des implémentations de pile de serveurs, quel que soit celui que vous choisissez, est qu’elles constituent un bloc définitif. Si le robots.txt est un signe poli « interdiction d’intrusion », les blocs du serveur, du CDN et du WAF sont un cadenas sur la porte. Ces méthodes de mise en œuvre ne nécessitent pas la conformité d’un robot d’exploration ; ils détectent les robots et les empêchent d’accéder au contenu, que le robot soit conforme ou non.
Un autre avantage de cette méthode est que les logiciels installés à ces niveaux fournissent souvent des rapports sur les robots bloqués. Le « cadenas » enregistre les tentatives de déverrouillage. Cela peut être utile pour analyser quels robots tentent d’accéder à votre site Web. Pour les sites qui reçoivent beaucoup d’attention indésirable des robots IA, cela peut être utilisé dans des discussions, parfois juridiques, avec les propriétaires de ces robots.
Inconvénients
Les inconvénients des méthodes de mise en œuvre de la pile de serveurs sont principalement les frais de maintenance. La plupart des serveurs de sites Web sont assez verrouillés, de sorte que seuls ceux qui savent vraiment ce qu’ils en font seront autorisés à accéder aux fichiers du serveur, WAF ou CDN. Cela signifie que les modifications apportées aux blocs devront probablement passer par un développeur, plutôt que d’être mises en œuvre directement par un référenceur. Ce besoin d’intermédiaire s’accompagne d’implications en termes de temps, de ressources et de coûts, surtout si le serveur est géré par un tiers comme une agence de développement.
Pour chaque couche de sécurité, l’usurpation d’identité par un robot est possible. Bien que le WAF constitue la ligne de défense la plus solide, il est toujours possible que des robots très avancés puissent contourner ses contrôles de validation. Cela signifie qu’il n’existe pas de méthode totalement infaillible pour bloquer les robots IA malveillants via la pile du serveur. Cependant, ils restent très efficaces pour la plupart.
Alors, lequel devrions-nous utiliser ?
Il n’y a pas de réponse unique à cette question. Cela dépend de la configuration, des coûts et de la structure de gestion de votre site Web.
Dans un monde idéal, vous bloqueriez les robots à chaque niveau de la pile serveur. Le serveur constitue un bon moyen de bloquer les agents utilisateurs connus et peut détecter des modèles simples de comportement des robots. Les blocs CDN sont largement efficaces et empêcheront les robots de consommer la bande passante du serveur. WAF est le plus efficace pour repérer les robots usurpés et empêcher les grattoirs IA avancés d’accéder au site. Cependant, vous n’aurez peut-être pas un accès facile pour configurer votre WAF, si votre site en possède un.
Le fichier robots.txt est la méthode la plus simple pour déclarer le souhait de certains robots de ne pas accéder à votre site Web, et il est efficace pour les robots responsables. Cependant, elle peut tout simplement être ignorée et constitue donc une méthode de dissuasion et non de prévention.
En résumé, si vous avez un besoin urgent de bloquer certains robots d’exploration IA, je vous recommande d’aller le plus haut possible dans la pile du serveur ; blocage via le WAF si vous le pouvez, le CDN si vous ne pouvez pas, et via le serveur en dernier recours.
Si vous n’avez besoin de bloquer qu’un ou deux des robots d’exploration d’IA les plus réputés, vous pourrez probablement vous fier uniquement au fichier robots.txt comme moyen de dissuasion. Cependant, je suggérerais également de surveiller les journaux de votre serveur pour voir si l’un de ces robots dépasse votre interdiction robots.txt.
Plus de ressources :
