Journal Tenter de limiter les nuisances liées aux robots d'IA

J'ai un modeste serveur Gemini. Le protocole Gemini qui est antérieur à l'assistant IA de Google du même nom a été conçu contre le « pourrissement du web », et par un malheureux hasard Google a eu l'idée d'utiliser ensuite le même nom pour son service, rendant d'autant plus difficile les recherches sur le protocole et entretenant une petite confusion. Quelle ironie ! Niveau "marketing", pour le protocole, c'est devenu absolument nul, mais je ne pense pas qu'ils changeront le nom à l'avenir.

Pour faciliter la vie des internautes, et aussi pour ouvrir les informations contenue sur un serveur gemini, en attendant que le protocole Gemini conquiert un jour le monde, il est courant de rajouter une passerelle web, qui transcrit les pages et les rend lisible depuis n'importe quel navigateur. J'ai installé htmgem qui fonctionne plutôt bien.

=> https://gmi.sbgodin.fr/htmgem/docs/installation-fr.gmi

Mes pages qui fonctionnaient correctement on finit par afficher ces derniers jours une erreur 500, je n'ai pas trop analysé ce qui s'est passé, mais après consultation rapide des logs et installation de php8.2-mbstring, qui n'était pas présent, cela a refonctionné. Il aurait fallu étudier si c'est lié à une erreur lors d'une mise à jour, ou si c'est à cause d'une intrusion (je n'ai rien remarqué, j'ai fail2ban et la configuration de base de yunohost), quoi qu'il en soit, cela m'a poussé à remarquer dans les logs d'accès aux pages qu'il y avait une quantité de bot IA qui récupéraient de manière aggressive et très récurrente mes pages, bouffant ma bande passante par la même occasion.

Par exemple :

216.73.216.140 - - [06/Nov/2025:13:34:19 +0100] "GET /gemlog/2022-09-18.gmi HTTP/2.0" 200 3057 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)"

Le bot Amazon notamment allait scanner chaque jour les mêmes pages. Je n'ai pas envie de cela.

Il y a aussi des tentatives de récupération de fichiers qui n'existent pas, probablement pour scanner des failles de sécurité :

4.216.107.25 - - [06/Nov/2025:14:25:08 +0100] "GET /file2.php HTTP/1.1" 301 162 "-" "-"
4.216.107.25 - - [06/Nov/2025:14:25:08 +0100] "GET /file2.php HTTP/1.1" 404 27 "-" "-"
4.216.107.25 - - [06/Nov/2025:14:25:08 +0100] "GET /vee.php HTTP/1.1" 301 162 "-" "-"
4.216.107.25 - - [06/Nov/2025:14:25:08 +0100] "GET /vee.php HTTP/1.1" 404 27 "-" "-"

En me renseignant un peu, j'ai vu qu'évidemment certains robots ia ne respectent pas la directive robots.txt, mais il y a des idées lorsqu'ils s'identifient avec un user-agent déclaré :

=> https://rknight.me/blog/blocking-bots-with-nginx/
=> https://phpc.social/@stefanzweifel/112608837688404741

Faute de mieux, j'ai donc rajouté dans mon fichier de configuration nginx ces informations :

/etc/nginx/conf.d/site.d/my_capsule.conf

location = /robots.txt {
    alias /var/www/site/robots.txt ;
}

location / {

  # Path to source
  alias /var/www/my_capsule/www/;

  # Default indexes and catch-all
  index index.gmi index.php index.html;

  if ($http_user_agent ~* (AdsBot-Google|Amazonbot|anthropic-ai|Applebot|Applebot-Extended|AwarioRssBot|AwarioSmartBot|Bytespider|CCBot|ChatGPT-User|ClaudeBot|Claude-Web|cohere-ai|DataForSeoBot|Diffbot|FacebookBot|FriendlyCrawler|Google-Extended|GoogleOther|GPTBot|img2dataset|ImagesiftBot|magpie-crawler|Meltwater|omgili|omgilibot|peer39_crawler|peer39_crawler/1.0|PerplexityBot|PiplBot|scoop.it|Seekr|YouBot|dotbot|HaloBot|Barkrowler|babbar|Baiduspider|amazon|bot)) {
        return 404;
}

J'ai mis une erreur 404 (page absente) au lieu de la 403 préconisée (forbidden, accès interdit), car je me suis dit que cela pouvait mettre la puce à l'oreille aux robots si on leur bloque directement l'accès.

J'ai aussi déclaré le location = /robots.txt avant la racine, dans le cas où des robots respecteraient les directives de ce fichier (on peut toujours rêver), ils peuvent y accéder, sinon cela aussi serait caché.

J'ai trouvé une méthode encore plus radicale ici :

=> https://melkat.blog/p/unsafe-pricing

où un fichier de 10 Go est renvoyé lors de l'accès aux pages. J'ai donc remplacé le "return 404" par :

return 301 https://hil-speed.hetzner.com/10GB.bin;

Mais je ne pense pas que cela soit la meilleure idée, en consultant les logs ce matin, j'ai vu qu'un robot amazon était bien tombé sur le 301 :

18.214.238.178 - - [12/Nov/2025:07:41:51 +0100] "GET /cyoa/section53.gmi HTTP/1.1" 301 162 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; Amazonbot/0.1; +https://developer.amazon.com/support/amazonbot) Chrome/119.0.6045.214 Safari/537.36"

et 3 minutes plus tard, avec une autre ip et un identifiant similaire, mais en omettant "Amazonbot" dans l'user-agent, la même page avait été récupérée quand même :

3.230.224.12 - - [12/Nov/2025:07:44:19 +0100] "HEAD /cyoa/section53.gmi HTTP/1.1" 200 0 "-" "Mozilla/5.0 AppleWebKit/605.1.15 (KHTML, like Gecko) Chrome/139.0.0.0 Safari/605.1.15"

C'est peut-être juste une coïncidence, mais je pense qu'amazon triche à ce niveau.

C'est de toute façon un fait avéré que certains "mentent" sur leur user-agent, comme démontré ici :
https://rknight.me/blog/perplexity-ai-is-lying-about-its-user-agent/

Quoi qu'il en soit, on peut trouver une liste des IA particulièrement aggressives ici, cela peut donner une idée de filtrage à essayer d'utiliser : https://github.com/ai-robots-txt/ai.robots.txt/tree/main

Sur un site j'ai donc utilisé la redirection 404 et sur un autre la redirection vers le fichier de 10 Go, on verra ce que ça donne au final, si une méthode est mieux que l'autre ou si c'est peine perdue…

Si vous avez de meilleures idées ou des réflexions à ce sujet, n'hésitez pas :)