Ce billet analyse le trafic généré par les bots d’intelligence artificielle sur un blog PHP, en comparant les politiques définies dans le robots.txt avec la réalité des logs. L’auteur, après avoir constaté l’absence de données concrètes, a examiné 13,5 jours de logs (108 217 requêtes) pour évaluer l’efficacité de sa stratégie de blocage. Malgré une politique robots.txt restrictive et des outils comme Caddy et CrowdSec, les crawlers d’entraînement (comme Amazonbot) ont persisté, tandis que GPTBot (OpenAI) était absent.
L’étude révèle des limites méthodologiques, notamment l’impossibilité de tracer un tiers du trafic (lié à Docker) et l’absence de données vérifiables pour certains bots (comme ceux d’Anthropic). Les crawlers d’entraînement, bien que minoritaires (1,4 % des requêtes), ont consommé une bande passante non négligeable (13,4 Mo). L’auteur souligne l’importance de mesurer avant d’agir, une approche qu’il qualifie de "règlement affiché sans vérification".
Enfin, le billet conclut que les bots d’IA n’ont apporté aucun trafic référent (referral), remettant en cause leur utilité pour un site personnel. L’auteur envisage de durcir sa politique, tout en gardant une approche réversible, et invite à une réflexion sur l’équilibre entre ouverture et protection des données.
Un concurrent de Anubis, pour bloquer les scanbots des boîtes d'IA
L'article présente Anubis, une solution élégante pour contrer les bots qui parcourent le web et surchargent les sites en récupérant des données pour l'entraînement des IA. Anubis fonctionne comme un reverse proxy, utilisant JavaScript pour imposer une preuve de travail aux visiteurs, bloquant ainsi efficacement les bots qui ne gèrent pas JavaScript ou qui sont détectés comme tels. Cette méthode permet de protéger les sites web contre la surconsommation de ressources et est déjà adoptée par plusieurs grandes organisations. L'auteur a implémenté Anubis pour protéger son instance publique de SearXNG, réduisant ainsi la charge CPU et le trafic réseau causés par les bots
.