Comment vérifier l’accès des robots d’IA à votre site ?

Où un robot d’IA peut-il être bloqué ?

À quatre endroits, qui se vérifient dans cet ordre : robots.txt, le pare-feu ou le CDN, le serveur qui répond par une erreur, puis la page elle-même. Un robot autorisé par le premier peut être refusé par le deuxième, et seul le dernier test montre ce que le robot voit réellement.

Comment robots.txt s’applique-t-il aux robots d’IA ?

Il s’adresse à chaque robot par son nom, sous deux conditions : se trouver à la racine du site, et être respecté. Google précise que le fichier doit être en texte UTF-8 à la racine et que ses robots appliquent le groupe qui leur correspond le plus précisément. Rien n’impose le respect du fichier : c’est au robot de l’honorer.

Le tableau suivant regroupe, pour les agents d’IA les plus cités, leur fonction et ce que la documentation dit de leur rapport à robots.txt.

Un changement de robots.txt n’est pas immédiat : OpenAI compte environ 24 heures pour la recherche, Perplexity jusqu’à 24 heures, et Google met généralement le fichier en cache jusqu’à 24 heures.

Un point souvent oublié : robots.txt n’est pas un moyen de cacher une page. Google écrit qu’une page interdite peut tout de même être indexée si d’autres sites pointent vers elle.

Que signifie une erreur 403 pour un robot ?

Que le serveur a compris la requête et refuse de la traiter, sans que s’authentifier y change rien. D’après MDN, un client qui reçoit une erreur 403 doit s’attendre à ce que répéter la même requête échoue de la même façon : un robot refusé ne reviendra pas gagner l’accès tout seul.

Deux mises en garde viennent des documentations. Anthropic prévient que bloquer ses robots par adresse IP peut ne pas produire un retrait fiable, car cela l’empêche de lire robots.txt. Et Google traite les erreurs de la famille 4xx, sauf 429, comme si robots.txt n’existait pas : un 403 sur ce fichier équivaut, pour Google, à l’absence de règles.

curl -sI -A "NomDuRobot" https://votre-site.example/une-page/

Cette commande envoie l’en-tête User-Agent de votre choix et affiche le code de réponse. Elle ne simule pas l’adresse IP d’un robot : un pare-feu qui combine le nom et l’adresse ne réagira pas. Pour un diagnostic complet, consultez aussi les journaux du pare-feu ou du serveur.

Le JavaScript pose-t-il un problème aux robots ?

Cela dépend du robot, et seul Google le documente. Google décrit une file de rendu : les pages sont explorées, mises en file pour le rendu, puis un Chromium exécute le JavaScript. Il ajoute que le rendu côté serveur reste une bonne idée parce que tous les robots ne savent pas exécuter le JavaScript.

Hypothèse de travail : pour les robots d’OpenAI, de Perplexity et d’Anthropic, aucune page consultée ne dit s’ils exécutent le JavaScript. Nous recommandons donc de publier l’essentiel du contenu dans le HTML initial, ce que fait le site d’Abysia, qui n’exécute aucun JavaScript côté client.

Un test simple : afficher le code source de la page, sans interprétation, et chercher le texte principal. S’il y figure, un robot qui n’exécute pas le JavaScript le voit aussi.

Faut-il publier un llms.txt ?

Pas pour être lu : rien, dans les pages consultées, n’établit qu’un service d’IA s’en sert. Le fichier est une proposition, décrite sur llmstxt.org, dont seul le titre principal est obligatoire. Google écrit que Google Search l’ignore et qu’en publier un ne nuit ni ne profite à sa visibilité dans Google.

Le fichier reste utile comme index lisible du site, pour qui voudrait l’exploiter. La documentation de Google rappelle qu’aucun fichier dédié aux IA n’est nécessaire pour apparaître dans ses fonctions d’IA, et une autre page précise qu’il n’y a pas de balisage ni de fichier spécial à créer. Abysia publie un llms.txt, sans en attendre d’effet. Un modèle de llms.txt commenté montre la structure de la proposition.