RFC 9309 : ce que robots.txt impose aux crawlers IA

Tapez « RFC 9309 » dans un moteur de recherche et vous obtenez deux choses : le texte brut en anglais sur rfc-editor.org, ou une fiche SEO qui vous répète la syntaxe de Disallow sans jamais ouvrir le document. Aucune page ne fait ce que ce texte fait clause par clause : dire quelles règles sont obligatoires (MUST), lesquelles sont recommandées (SHOULD), et lesquelles restent une simple faculté (MAY). C'est cette distinction, et elle seule, qui permet de juger un crawler sur des bases solides plutôt que sur une intuition.

Le RFC 9309 est un standard IETF au stade « Proposed Standard », pas « Internet Standard », publié en septembre 2022. Il fixe des règles MUST, SHOULD et MAY précises sur le matching, le cache et la taille du fichier, mais ne prouve la conformité d'aucun crawler nommé : seules les déclarations des éditeurs et une mesure Cloudflare permettent d'en dire quelque chose.

Première correction, et elle change la portée de tout le reste : le RFC 9309 n'est pas un « Internet Standard ». Sur la page datatracker de l'IETF, sa maturité est affichée noir sur blanc, « RFC - Proposed Standard (September 2022) ». C'est une catégorie Standards Track, la première marche d'un processus qui compte plusieurs étapes, pas la dernière. Le SERP le présente pourtant en boucle comme « le standard officiel du web ». Ce n'est pas faux au sens où c'est bien un texte IETF sérieux, avec ses auteurs identifiés (Martijn Koster pour l'origine, Gary Illyes, Henner Zeller et Lizzi Sassman de Google pour la formalisation de 2022). Mais « Proposed Standard » et « Internet Standard » ne sont pas synonymes, et un texte qui vous vend l'un pour l'autre a déjà raté la première ligne de sa lecture.

Le texte lui-même est prudent sur sa propre portée. Il précise que ses règles « ne sont pas une forme d'autorisation d'accès », et que le protocole « ne remplace pas des mesures de sécurité valides ». Autrement dit : le RFC 9309 documente un protocole de politesse entre serveurs et crawlers, pas un mécanisme de contrôle d'accès. Personne ne va en prison pour l'avoir ignoré. Ce qui existe, en revanche, c'est un texte de référence assez précis pour qu'on puisse dire, clause par clause, ce qu'un crawler devrait faire. Pour la syntaxe elle-même, Disallow, Allow, jokers et sitemap, notre guide technique robots.txt et sitemap XML couvre la partie pratique que cet article ne refait pas.

Voici la grille que le SERP ne fait jamais : chaque règle avec son statut normatif exact, tel que défini par la RFC 2119 (les mots en capitales MUST, SHOULD, MAY ont un sens normatif précis dans le vocabulaire IETF, et seulement en capitales).

Trois lignes méritent qu'on s'y arrête, parce que le web les confond en permanence. La sortie de l'interdiction en cas de panne serveur (ligne 2.3.1.4, deuxième occurrence) est un MAY, pas un droit acquis : le texte cite 30 jours « en exemple », pas comme un seuil chiffré. La durée de cache de 24 heures est un SHOULD NOT, avec une exception explicite quand le fichier est injoignable, pas une interdiction sèche. Et le traitement d'une erreur 4xx reste un MAY : un crawler qui choisit de ne rien crawler sur un 404 reste parfaitement conforme, même si la formule inverse circule partout.

Le fait le plus mal compris, c'est sans doute les 500 kibioctets. Le texte les impose au crawler comme plancher d'analyse, pas au site comme plafond de fichier. Rien n'interdit à un éditeur de publier un robots.txt de 2 Mo ; ce que le RFC garantit, c'est qu'un crawler conforme analysera au moins les 500 premiers kibioctets avant de pouvoir s'arrêter. Ne confondez pas non plus ce chiffre avec les 15 Mo que Google documente comme limite de crawl d'un fichier ordinaire : ce sont deux mécanismes distincts, l'un sur le robots.txt lui-même, l'autre sur les pages qu'il autorise à visiter.

Voici l'outil que cet article vous donne, et qui n'existe nulle part ailleurs en français : trois catégories de fait, qui ne se mélangent jamais.

• Norme : ce que dit le texte du RFC 9309, tel quel.
• Déclaration d'éditeur : ce qu'une entreprise écrit sur sa propre documentation. Une déclaration prouve qu'elle l'a écrit, pas qu'elle le fait.
• Mesure : ce qu'une étude identifiée et méthodologique a observé de l'extérieur.

Sur cette base, voici ce que les éditeurs documentent réellement, en les nommant chacun avec leur propre déclaration.

Google documente traiter toutes les erreurs 4xx sauf 429 comme l'absence de robots.txt valide, ce qui reste conforme puisque la clause est un MAY. Sur les erreurs 5xx, Google documente une séquence en trois temps : arrêt du crawl pendant douze heures en gardant les tentatives de fetch, puis usage de la dernière version valide pendant trente jours, et, s'il n'existe aucune version en cache, un comportement d'absence de restriction. C'est la ligne la plus délicate de toute cette lecture : la clause 2.3.1.4 impose un MUST sur l'interdiction complète en cas de panne serveur, et le cas « pas de copie en cache » de Google s'en approche dangereusement. Je ne vais pas écrire que Google viole le RFC : la clause suivante ouvre elle-même une sortie MAY après une période raisonnablement longue, sans fixer où commence le raisonnable. C'est une divergence apparente, pas une non-conformité établie, et la nuance mérite d'être gardée telle quelle.

Un écart, en revanche, se nomme sans détour, parce que c'est Google lui-même qui l'écrit noir sur blanc : AdsBot ignore le groupe user-agent: * avec l'accord de l'éditeur publicitaire, alors que la clause 2.2.1 impose un MUST de repli sur ce groupe. Google documente une exception à une clause obligatoire. C'est le seul écart net de cet article, et il tient parce qu'il est écrit par la source elle-même, pas déduit d'une observation extérieure.

Anthropic documente que ses robots respectent les signaux « do not crawl » en honorant les directives standard du robots.txt, et supporte en plus l'extension non standard Crawl-delay, que le RFC range en MAY sans l'imposer ni l'interdire. OpenAI documente qu'une modification du fichier met environ 24 heures à être répercutée sur ses systèmes. Perplexity documente le même ordre de grandeur, jusqu'à 24 heures. Ce délai de propagation compte double si votre enjeu est la citation par les moteurs génératifs plutôt que le blocage : c'est le terrain de notre article sur llms.txt et son adoption réelle.

Ce que ces trois éditeurs documentent aussi, chacun de son côté, c'est qu'un fetcher déclenché par une requête d'utilisateur (ChatGPT-User chez OpenAI, Perplexity-User chez Perplexity, une catégorie équivalente chez Google) peut ne pas appliquer le robots.txt. Ce n'est pas une violation : le RFC vise explicitement les « crawlers », définis comme des clients automatiques. Un fetcher qui va chercher une page parce qu'un utilisateur l'a demandé n'entre pas dans cette définition, et trois éditeurs sur quatre exploitent exactement cette lecture, sans que le texte la contredise.

Sur ce qu'un crawler nommé fait réellement, clause par clause, sur le terrain, la documentation publique ne dit rien. Ni GPTBot, ni ClaudeBot, ni PerplexityBot ne publient de conformité détaillée à la limite d'analyse, à la règle de matching ou au traitement des pannes serveur. Ce vide est un constat sur l'état de la documentation publique à ce jour, et c'est précisément ce qui rend une accusation de non-conformité indéfendable pour ces trois robots à ce stade. La question de savoir s'il faut bloquer ou laisser passer ces crawlers, elle, est traitée à part dans notre article sur le dilemme bloquer ou autoriser les bots IA, que je ne rejoue pas ici.

La seule mesure de terrain disponible vient de Cloudflare, le 4 août 2025, et elle est partie prenante : Cloudflare vend du blocage de bots. Sa méthode part de plaintes de clients ayant à la fois interdit Perplexity en robots.txt et posé des règles WAF, avec des domaines neufs créés pour le test, non indexés et non découvrables. Cloudflare y écrit que les crawlers déclarés et non déclarés de Perplexity tentaient d'accéder au contenu, contrairement aux normes de crawl du RFC 9309, sur des dizaines de milliers de domaines et des millions de requêtes par jour. Le même protocole appliqué à ChatGPT-User donne un résultat inverse : ChatGPT-User a récupéré le robots.txt et cessé de crawler quand il était interdit. C'est un test ciblé né de réclamations clients, pas un panel représentatif de l'ensemble des crawlers IA, et Cloudflare a depuis retiré Perplexity de sa liste de bots vérifiés. J'attribue ce constat à sa source, et je donne l'autre voix : Perplexity a répondu dans un billet intitulé « Agents or Bots: Making Sense of AI on the Open Web », qui oppose la récupération déclenchée par un utilisateur au crawl automatisé, et un porte-parole a déclaré à TechCrunch que ces robots n'étaient pas ceux de l'entreprise et que le billet de Cloudflare tenait de l'argumentaire commercial. Le cas Perplexity, sous l'angle de la vérification technique cette fois, plages IP et DNS inverse à l'appui, est démonté dans notre article sur l'authenticité des crawlers IA par plage IP.

Un RFC publié n'est pas un texte figé. Celui-ci porte quatre errata, tous au statut « Reported », aucun au statut « Verified » : une coquille de nom de fichier signalée en septembre 2022, un point de code Unicode mal transcrit signalé la même semaine, une incohérence entre la grammaire formelle et un exemple du texte signalée en juin 2024, et un quatrième, plus récent, déposé le 28 avril 2026 par Fabrice Canel, de Microsoft. Ce dernier propose une extension optionnelle pour les listes de user-agents séparées par une virgule dans une même ligne, avec un chiffre de terrain à l'appui : environ 0,3 % des robots.txt contiendraient déjà une virgule dans leurs champs user-agent. Aucun des guides SEO du sujet ne mentionne cet erratum, ni les trois précédents.

Ce que ça dit du texte : le RFC 9309 continue d'être discuté, quatre ans après sa publication, par les mêmes acteurs qui l'ont écrit. Un standard « Proposed » qui reçoit encore des signalements techniques en 2026 n'est pas un texte mort, mais ce n'est pas non plus un texte clos.

C'est la question que le SERP ne pose jamais, alors qu'elle est la seule qui compte pour un éditeur de site : sur quoi peut-on réellement s'appuyer pour dire d'un crawler qu'il ne respecte pas le RFC 9309 ?

Trois fondations, et rien d'autre. Ce que le crawler documente lui-même sur sa propre page, ce qu'une mesure de terrain identifiée et méthodologique a observé, ou une contradiction directe entre les deux. Une plainte non vérifiée sur un forum, une intuition sur un pic de trafic dans les logs, une comparaison avec un autre bot supposé « plus propre » : aucun de ces éléments ne suffit à établir une non-conformité, aussi convaincants qu'ils paraissent sur le moment.

Un chantier IETF distinct existe en ce moment même, le groupe de travail « AI Preferences » (aipref), qui travaille à standardiser l'expression de préférences sur la collecte et le traitement de contenu pour l'IA, avec deux documents, draft-ietf-aipref-vocab et draft-ietf-aipref-attach, que la charte du groupe prévoit de transmettre à l'IESG au 31 août 2026. Ce chantier touche à la fouille de textes et de données et au droit d'auteur, un terrain juridique complètement différent de la conformité technique traitée ici. Je ne le développe pas davantage : le mélanger à la lecture du RFC 9309 serait exactement l'erreur que cet article essaie de corriger. Le protocole voisin qui prétend combler ce vide juridique, TDMRep, mérite sa propre lecture critique : je l'ai faite dans TDMRep, ce qu'il prouve et ce qu'il ne prouve pas.

Le problème, sur ce sujet, c'est qu'on confond trop souvent un protocole technique avec une garantie juridique. Le RFC 9309 dit ce qu'un crawler devrait faire techniquement. Il ne dit rien de ce qu'un tribunal ferait d'une violation, et pour cause : ce n'est pas son terrain.

J'hésite encore à trancher si le vide documentaire sur GPTBot, ClaudeBot et PerplexityBot relève d'une prudence légitime des éditeurs ou d'un choix de ne pas s'exposer à une comparaison publique gênante. Les deux lectures se défendent, et je n'ai pas d'élément qui permette de choisir entre les deux.

Le RFC 9309 est-il un standard officiel de l'Internet ?#

Non, pas au sens strict. Sur datatracker.ietf.org, sa maturité affichée est « Proposed Standard », la première étape d'un processus IETF en plusieurs marches, distincte d'un « Internet Standard ». C'est un texte Standards Track sérieux, mais pas la dernière étape de normalisation.

GPTBot, ClaudeBot ou PerplexityBot respectent-ils le RFC 9309 ?#

Aucune documentation publique ne permet de répondre clause par clause pour ces trois crawlers. Leurs pages officielles ne détaillent ni la durée de cache appliquée, ni la limite d'analyse, ni le traitement des erreurs serveur. Ce que chaque éditeur documente, en revanche, c'est son engagement général à honorer les directives robots.txt.

Les fetchers comme ChatGPT-User violent-ils le RFC en ignorant robots.txt ?#

Non, selon la lecture du texte. Le RFC vise les « crawlers », définis comme des clients automatiques. OpenAI, Perplexity et Google documentent chacun une catégorie de fetchers déclenchés par une requête d'utilisateur, distincte de leurs crawlers automatiques, et le RFC ne tranche pas explicitement ce cas.

Les 500 kibioctets sont-ils une taille maximale de robots.txt ?#

Non. C'est une limite d'analyse imposée au crawler : il doit lire au moins les 500 premiers kibioctets du fichier. Rien n'interdit à un site de publier un fichier plus volumineux. Ne confondez pas ce chiffre avec les 15 Mo que Google documente comme limite de crawl des pages ordinaires.

La mesure Cloudflare sur Perplexity est-elle une preuve définitive de non-conformité ?#

C'est une mesure datée et documentée, mais elle vient d'un acteur qui vend du blocage de bots, née de plaintes clients plutôt que d'un panel représentatif. Cloudflare y écrit avoir observé des crawlers Perplexity accéder à du contenu contrairement aux normes du RFC 9309, sur un test ciblé. C'est un fait attribuable à sa source, pas un verdict indépendant.

• RFC 9309, Robots Exclusion Protocol, consulté le 28 août 2026
• RFC 9309, page datatracker IETF, statut Proposed Standard, consulté le 28 août 2026
• RFC 9309, page des errata, 4 signalements Reported, consulté le 28 août 2026
• The Web Robots Pages, texte d'origine de 1994 de Martijn Koster, consulté le 28 août 2026
• Google Search Central Blog, annonce de la soumission du draft à l'IETF, 1er juillet 2019, consulté le 28 août 2026
• Google, interprétation du Robots Exclusion Protocol, consulté le 28 août 2026
• Google, aperçu des crawlers et fetchers, cas AdsBot, consulté le 28 août 2026
• OpenAI, aperçu des crawlers OpenAI, consulté le 28 août 2026
• Anthropic, centre d'aide, crawl et blocage des robots, consulté le 28 août 2026
• Perplexity, documentation des crawlers, consulté le 28 août 2026
• Cloudflare, blog, crawlers non déclarés de Perplexity, 4 août 2025, consulté le 28 août 2026
• IETF Datatracker, charte du groupe de travail AI Preferences, consulté le 28 août 2026
• TechCrunch, réponse publique de Perplexity au billet Cloudflare, 5 août 2025, consulté le 28 août 2026