Robots.txt et crawlers IA : Google rappelle quelques règles fondamentales

Gary Illyes et Cherry Prommawin vident le « Non-Canonical Cabinet »

La vidéo s’intitule « What can you actually put in a robots.txt? ». Il s’agit du deuxième épisode de la série « Non-Canonical Cabinet », animée par Gary Illyes et Cherry Prommawin, tous deux chez Google.

Le principe de la série : sortir d’un meuble de classement les questions les plus étranges reçues lors des sessions de questions-réponses de Google. Cette fois, Cherry Prommawin résume les interrogations du public : peut-on rendre ce fichier « joli », y mettre des caractères non anglais, ou demander aux robots d’IA de rester dehors à l’aide d’un emoji panneau stop ?

Pour rappel, le robots.txt est un fichier texte brut placé à la racine d’un site. Gary Illyes le présente comme le premier fichier que consultent Googlebot et les autres crawlers « bien élevés » avant de parcourir un site, pour savoir quelles sections leur sont ouvertes. Ses règles s’appliquent aussi bien aux moteurs de recherche qu’aux robots d’entraînement d’IA. Son fonctionnement est défini par un standard de l’IETF, la RFC 9309, que Google déclare suivre.

Le parser de Google ne lit que quatre règles et jette le reste

Gary Illyes insiste sur la simplicité de la mécanique. Le parser lit le fichier ligne par ligne et ne cherche que quatre règles :

• User-agent : désigne le robot concerné par le groupe de règles qui suit.
• Allow : autorise l’exploration d’un chemin.
• Disallow : demande de ne pas explorer un chemin.
• Sitemap : indique l’emplacement d’un plan de site XML.

Tout le reste est ignoré. Une erreur de formatage ou une mise en forme « créative » des espacements suffit à faire écarter une ligne, sans message d’erreur. L’exemple donné est parlant : si un webmaster écrit « don’t crawl secret page », Google constate que « don’t crawl » n’est pas une règle valide, ignore la ligne et risque d’explorer la page en question.

Les commentaires, eux, sont autorisés. Toute ligne commençant par un dièse (#) est ignorée par les crawlers. Gary Illyes concède donc qu’il est techniquement possible d’y glisser un grand dessin en art ASCII, tout en qualifiant ce choix de « discutable ». Cherry Prommawin évoque un site dont le robots.txt était composé à 97 % de dessin et à 3 % de directives : le fichier n’a pas cassé le parser, mais il gaspillait de la bande passante.

À noter, en complément des propos tenus dans la vidéo : la documentation de Google indique que Googlebot ne traite que les 500 premiers Kio d’un fichier robots.txt et ignore ce qui dépasse. Un fichier gonflé par des commentaires décoratifs peut donc, à l’extrême, repousser des directives au-delà de cette limite.

Emojis et caractères non latins doivent être encodés

La vidéo distingue deux cas : le nom du robot visé et les chemins d’URL cités dans les règles.

Dans le user-agent, aucune tolérance

Cherry Prommawin demande s’il serait possible d’écrire un emoji poulet dans la ligne user-agent, au cas où un robot l’utiliserait comme jeton d’identification. La réponse de Gary Illyes est claire : les jetons user-agent ne peuvent contenir que des lettres et des tirets. Un emoji est un caractère UTF-8 multi-octets qui ne peut pas respecter cette contrainte, la règle ne fonctionnera donc pas. Il en va de même pour tout caractère non anglais.

Dans les chemins d’URL, Google s’adapte mais pas forcément les autres

Le cas des chemins est plus nuancé. Les URL contenant des umlauts allemands, une cédille portugaise ou des alphabets entiers comme l’arabe, le hindi, le japonais ou le chinois relèvent, selon Gary Illyes, exactement de la même logique que les emojis.

Cherry Prommawin explique que Googlebot traite ces caractères comme le ferait n’importe quel client HTTP. Le parser de Google est souple : il encode automatiquement les caractères chinois, les umlauts ou les emojis, comme il le fait lors de l’exploration. Mais d’autres crawlers, ou des robots plus anciens, peuvent ne pas savoir le faire.

D’où cette recommandation : écrire dans le robots.txt la forme encodée en pourcentage (percent-encoding), c’est-à-dire celle que le serveur attend réellement. Concrètement, un chemin comme /poulet-épicé s’écrit /poulet-%C3%A9pic%C3%A9 dans la règle, le « é » correspondant aux octets UTF-8 C3 A9. Cherry Prommawin avertit que certains robots, incapables de traiter un caractère brut, pourraient ignorer toute la ligne disallow et donc explorer ce qu’on cherchait à protéger.

Le robots.txt encadre l’accès, pas l’usage des contenus par l’IA

C’est la question la plus attendue : peut-on autoriser un robot d’IA à explorer un site tout en lui interdisant d’utiliser les contenus pour entraîner ses modèles ? Gary Illyes répond par la définition même du protocole. Selon la RFC 9309, le robots.txt est un protocole de préférence d’accès : il indique seulement si un robot peut ou non explorer une page. Il ne dit rien de ce que le système fait des données une fois l’exploration réalisée.

Autrement dit, un disallow signifie « n’entrez pas dans la pièce », rien de plus. Pour empêcher un crawler d’IA d’accéder aux pages, il faut cibler explicitement son jeton user-agent dans le fichier. Inventer une règle personnalisée, du type « ne pas utiliser mon journal intime pour l’IA », ne sert à rien : le parser l’écartera comme n’importe quelle ligne invalide.

Barry Schwartz en tire, dans son article dédié sur Search Engine Roundtable, une recommandation qui relève de son analyse : séparer le contrôle de l’exploration de la politique d’entraînement des IA. Bloquer un crawler n’équivaut pas à demander à une entreprise de ne pas entraîner ses modèles sur des contenus qu’elle a déjà récupérés.

Ce cadrage éclaire plusieurs initiatives récentes, qui ne sont pas évoquées dans la vidéo. Google propose depuis 2023 le jeton Google-Extended, qui permet de refuser l’usage des contenus pour ses modèles Gemini sans toucher à l’indexation dans la recherche ; il s’agit d’un jeton de contrôle et non d’un robot distinct. De son côté, Cloudflare a proposé une ligne « Content-Signal » pour exprimer des préférences d’usage par l’IA . Or, à la lumière des propos de Gary Illyes, une ligne non prévue par la RFC 9309 est simplement ignorée par un parser conforme : son effet dépend entièrement de la volonté de chaque acteur de la lire.

Ce que les référenceurs doivent vérifier dans leur fichier

La vidéo se conclut sur trois rappels de Gary Illyes : les crawlers bien élevés, Googlebot compris, utilisent le robots.txt pour limiter l’exploration ; le fichier doit respecter la RFC 9309 ; les emojis et caractères non anglais doivent être encodés en pourcentage dans les chemins. Barry Schwartz y ajoute plusieurs points de vigilance tirés de l’écoute de la vidéo :

1. Tester plutôt que relire : une règle compréhensible pour un humain n’est pas forcément valide. Il faut valider la syntaxe et tester les motifs d’URL réellement concernés.
2. Contrôler les URL internationales : les incohérences d’encodage peuvent neutraliser une règle, surtout d’un crawler à l’autre.
3. Utiliser le bon nom de robot : chaque règle visant un crawler d’IA doit reprendre son jeton user-agent reconnu, tel que publié par l’éditeur.
4. Ne pas confondre robots.txt et sécurité : le fichier demande aux robots respectueux de ne pas accéder à certains chemins, il n’empêche pas l’accès d’un client non autorisé et ne garantit pas que tous les robots s’y conformeront.

Ce dernier point vaut surtout pour les crawlers d’IA, dont le respect du robots.txt varie selon les éditeurs. Cherry Prommawin renvoie vers deux liens de documentation placés en description de la vidéo. A noter que le prochain épisode du « Non-Canonical Cabinet » portera sur les erreurs 404.