Comment lire un fichier robots.txt : guide complet

Notre position : nous sommes Geonode et nous vendons des proxys à des personnes qui collectent des données ; ainsi, robots.txt se trouve au cœur même des activités de nos clients. Pour être honnête, respecter ce fichier est dans votre intérêt, et pas seulement dans celui du site. Un robot d’indexation qui respecte ce fichier, s’identifie et modère son rythme est un robot que les opérateurs de sites peuvent choisir d’autoriser. Un robot qui l’ignore est une nuisance qu’il faut bloquer, et ce blocage est peu coûteux pour eux mais onéreux pour vous. Nous tenons également à préciser ce que la norme elle-même stipule à ce sujet : la RFC indique clairement que ces règles « ne constituent pas une forme d’autorisation d’accès » — le respect de robots.txt est donc nécessaire mais non suffisant, et les conditions d’utilisation constituent une question distincte.

Ce qu'est et ce que n'est pas le fichier robots.txt

La formulation du RFC lui-même est la plus claire qui soit :

Il peut être gênant pour les propriétaires de services que les robots d'indexation explorent l'intégralité de leur espace URI. Ce document précise les règles initialement définies par le « Robots Exclusion Protocol » que les robots d'indexation sont tenus de respecter lorsqu'ils accèdent à des URI.

Ces règles ne constituent pas une forme d’autorisation d’accès.

Cette dernière phrase a une double signification. Elle signifie qu’un chemin interdit n’est pas protégé — rien n’impose le respect de cette règle — et qu’un chemin autorisé n’est pas pour autant validé, car l’autorisation découle de conditions et de la loi plutôt que d’un fichier texte.

La section consacrée à la sécurité explicite clairement la première partie et mérite d’être citée, car beaucoup de gens la comprennent à l’envers :

Le protocole d’exclusion des robots ne remplace pas les mesures de sécurité valides relatives au contenu. Le fait de répertorier des chemins d’accès dans le fichier robots.txt les expose publiquement et les rend ainsi détectables.

Ainsi, Disallow: /admin/secret-reports/ indique au monde entier que ce chemin d’accès existe. Si vous rédigez un fichier « robots.txt », c’est une raison de ne pas y répertorier du tout les chemins d’accès sensibles — utilisez l’authentification, comme le recommande explicitement la RFC.

Le format

Un fichier est constitué d'une séquence de groupes. Chaque groupe commence par une ou plusieurs lignes d'user-agents et est suivi de règles.

User-agent: *
Disallow: /admin/
Disallow: /search?
Allow: /search/help

User-agent: BadBot
Disallow: /

Sitemap: https://example.com/sitemap.xml

Trois caractères spéciaux que les robots d'indexation DOIVENT prendre en charge :

Un groupe vide à la fin a une signification : la RFC précise que « le dernier groupe peut ne comporter aucune règle, ce qui signifie qu’il autorise implicitement tout ». Ainsi, un User-agent: quxbot final sans rien en dessous accorde à ce robot d’indexation un accès illimité.

Un Disallow: vide sans chemin signifie également que tout est autorisé — c’est la manière conventionnelle de dire « aucune restriction ».

Sitemap: ne fait pas partie de la grammaire de base. L’ABNF de la RFC inclut une note à l’intention des développeurs leur demandant de « définir les lignes supplémentaires dont vous avez besoin (par exemple, les Sitemaps) » ; il s’agit donc d’une extension largement prise en charge plutôt que d’une fonctionnalité obligatoire. Crawl-delay appartient à la même catégorie : courante, respectée par de nombreux robots d’indexation, mais non incluse dans la norme.

Comment fonctionne la correspondance de l'en-tête User-Agent

C'est plus précis que ce que la plupart des gens imaginent, et cela vaut la peine de bien comprendre ce principe.

Le jeton est une sous-chaîne de votre en-tête User-Agent. Exemple tiré de la RFC : un en-tête de type Mozilla/5.0 (compatible; ExampleBot/0.1; https://www.example.com/bot.html) correspond à une ligne « robots.txt » de type user-agent: ExampleBot, et il est précisé que « le jeton de produit (ExampleBot) est une sous-chaîne de l’en-tête HTTP User-Agent ».

La correspondance ne tient pas compte de la casse. « Les robots d’indexation DOIVENT utiliser une correspondance insensible à la casse pour trouver le groupe qui correspond au jeton de produit, puis respecter les règles de ce groupe. »

Les groupes de correspondance multiples sont fusionnés. « S’il existe plusieurs groupes correspondant à l’agent utilisateur, les règles des groupes correspondants DOIVENT être combinées en un seul groupe. » Ainsi, deux blocs User-agent: ExampleBot distincts dans le même fichier produisent un ensemble de règles combiné, plutôt que le second ne remplace le premier.

Vous obtenez un seul groupe, et non plusieurs. Si un groupe mentionne votre jeton, vous utilisez ce groupe et ignorez complètement le groupe * — le caractère générique est une solution de secours, et non une base à laquelle s’ajoutent des règles spécifiques. Cela surprend souvent les utilisateurs : un robot d’indexation disposant de son propre groupe n’est pas également soumis aux règles générales.

Et si aucune correspondance n’est trouvée : « Si aucun groupe ne correspond au token du produit et qu’il n’existe aucun groupe comportant une ligne user-agent avec la valeur *, ou s’il n’y a tout simplement aucun groupe, aucune règle ne s’applique. »

La correspondance se fait par spécificité, et non par ordre

C'est la règle la plus souvent mal interprétée dans tout ce domaine.

Pour déterminer si l'accès à un URI est autorisé, un robot d'indexation DOIT comparer les chemins figurant dans les règles « allow » et « disallow » à l'URI. La correspondance DEVRAIT tenir compte de la casse. La correspondance DOIT commencer par le premier octet du chemin. La correspondance la plus spécifique trouvée DOIT être utilisée. La correspondance la plus spécifique est celle qui comporte le plus d’octets.

Ce n’est pas la première correspondance qui l’emporte. Ce n’est pas la dernière correspondance qui l’emporte. C’est la correspondance la plus longue qui l’emporte.

Exemple tiré de la RFC :

User-Agent: foobot
Allow: /example/page/
Disallow: /example/page/disallowed.gif

Pour example.com/example/page/disallowed.gif, la ligne Disallow est plus longue, elle s’applique donc — bien qu’elle apparaisse en deuxième position et malgré la présence d’une règle Allow couvrant le chemin parent.

Inversez l’ordre dans le fichier et rien ne change. L’ordre n’a aucune importance.

Deux règles supplémentaires complètent le tableau. En cas d’égalité, la règle « Allow » prévaut : « Si une règle « allow » et une règle « disallow » sont équivalentes, alors la règle « allow » DOIT être utilisée. » Et l’absence de correspondance signifie que l’accès est autorisé : « Si aucune correspondance n’est trouvée parmi les règles d’un groupe pour un user-agent donné, ou s’il n’y a pas de règles dans le groupe, l’URI est autorisé. »

Un autre détail utile à connaître : « L’URI /robots.txt est implicitement autorisé », de sorte qu’un fichier qui interdit tout ne s’interdit pas lui-même.

La correspondance des chemins d’accès implique également une normalisation par encodage en pourcentage. Les octets hors ASCII et ceux de la plage réservée « DOIVENT être encodés en pourcentage » avant la comparaison, et un octet ASCII encodé en pourcentage dans l’URI « DOIT être décodé avant la comparaison », sauf s’il est réservé. En pratique : utilisez une bibliothèque mise à jour plutôt que d’écrire ce code vous-même.

Les codes d'état changent tout

Les règles en la matière sont précises, souvent ignorées, et la différence entre deux d'entre elles est considérable.

Succès. « Si le robot d'indexation parvient à télécharger le fichier robots.txt, il DOIT suivre les règles analysables. »

Redirections. « Les robots d’indexation DEVRAIENT suivre au moins cinq redirections consécutives, même entre différentes entités. » Un fichier accessible après cinq redirections « DOIT être récupéré, analysé, et ses règles respectées dans le contexte de l’entité initiale ». Au-delà de cinq, un robot d’indexation « PEUT supposer que le fichier robots.txt n’est pas disponible. »

Indisponible — 4xx. « Si un code d’état du serveur indique que le fichier robots.txt est indisponible pour le robot d’indexation, celui-ci PEUT alors accéder à toutes les ressources du serveur. » Un code 404 signifie qu’il n’y a aucune restriction.

Inaccessible — 5xx. C’est celui que les gens comprennent souvent mal : « Si le fichier robots.txt est inaccessible en raison d’erreurs de serveur ou de réseau, cela signifie que le fichier robots.txt est indéfini et que le robot d’indexation DOIT supposer une interdiction totale. »

Un code 5xx signifie un arrêt total. Pas « continuer comme avant », ni « utiliser la copie mise en cache indéfiniment » — interdiction totale. La RFC autorise toutefois une solution de contournement à long terme : si le fichier est indéfini « pendant une période raisonnablement longue (par exemple, 30 jours), les robots d’exploration PEUVENT supposer que le fichier robots.txt n’est pas disponible… ou continuer à utiliser une copie mise en cache. »

Erreurs d’analyse. « Les robots d’indexation DOIVENT essayer d’analyser chaque ligne du fichier robots.txt. Les robots d’indexation DOIVENT utiliser les règles analysables. » Une ligne mal formée n’invalide pas le fichier ; on utilise ce qu’on peut lire.

Conséquence pratique pour quiconque développe un robot d’indexation : une indisponibilité temporaire du site cible doit interrompre votre exploration, et non l’accélérer. Ne pas respecter ce principe revient à surcharger un site qui est déjà en difficulté.

Mise en cache et limites

Deux exigences opérationnelles qui posent problème aux implémentations développées en interne.

Actualisation au moins quotidienne. « Les robots d'indexation PEUVENT mettre en cache le contenu du fichier robots.txt récupéré… Les robots d'indexation NE DOIVENT PAS utiliser la version mise en cache pendant plus de 24 heures, sauf si le fichier robots.txt est inaccessible. »

Récupérer le fichier une seule fois au démarrage de votre robot d’indexation et le laisser fonctionner pendant une semaine n’est pas conforme. Les sites modifient leurs règles, et une tâche s’exécutant sur une longue durée doit en tenir compte.

Analyse d’au moins 500 KiB. « La limite d’analyse DOIT être d’au moins 500 kibibytes. » Les grands sites ont des fichiers volumineux, et un analyseur qui tronque à une taille arbitrairement plus petite passera inaperçue certaines règles — ce qui constitue le pire scénario possible ici, car cela produit un robot d’indexation qui se croit conforme alors qu’il ne l’est pas.

Lecture d'un fichier réel

Examen d'un exemple concret.

User-agent: *
Disallow: /search
Allow: /search/about
Disallow: /*?sessionid=
Disallow: /*.pdf$
Crawl-delay: 2

User-agent: GPTBot
Disallow: /

User-agent: PartnerBot
Disallow:

Sitemap: https://example.com/sitemap_index.xml

Ligne par ligne :

**Disallow: /search

** bloque /search

, /search/

, /search/results

— tout ce qui commence par cette chaîne, car la correspondance commence au premier octet et il n'y a pas de $

.

**Allow: /search/about

** est plus long, il l'emporte donc pour ce chemin spécifique. C'est la correspondance la plus longue qui prime, et non l'ordre.

**Disallow: /*?sessionid=

** utilise le caractère générique pour bloquer tout chemin contenant un paramètre de session, quel que soit ce qui le précède.

**Disallow: /*.pdf$

** bloque les URL se terminant par .pdf

. Sans le $

, cela bloquerait également /report.pdf.html

.

**Crawl-delay: 2

** est une extension plutôt qu’une norme, et il est recommandé de la respecter.

**User-agent: GPTBot

avec Disallow: /

** exclut totalement ce robot d’exploration. Notez que GPTBot ne se voit appliquer que cette règle — il n’est pas soumis au groupe *

, donc la règle Crawl-delay

ci-dessus ne s’applique pas à lui.

**User-agent: PartnerBot

avec un champ « Disallow:

» vide ** accorde un accès illimité.

**Sitemap:

** pointe vers l’inventaire des URL, ce qui constitue la ligne la plus utile dans la plupart des fichiers. Nous avons expliqué comment l’utiliser dans comment trouver toutes les pages d’un site web.

Respecter ces principes dans le code

Utilisez un analyseur syntaxique régulièrement mis à jour. La règle de correspondance de spécificité est à elle seule une source fréquente de bogues, et la normalisation par encodage en pourcentage est encore plus problématique.

Python : urllib.robotparser fait partie de la bibliothèque standard et convient pour les cas simples ; l’analyseur open source de Google robotstxt et ses liaisons Python implémentent la RFC 9309 à la lettre. Scrapy intègre RobotsTxtMiddleware, qui est activé par défaut dans les nouveaux projets — vérifiez que personne ne l’a désactivé.

Node : plusieurs paquets maintenus implémentent la norme.

Go : il existe des bibliothèques qui respectent les règles de correspondance de la RFC.

Quel que soit l’outil utilisé, veillez à respecter ces quatre points :

Actualisez toutes les 24 heures, et non pas une seule fois au démarrage. Considérez les codes 5xx comme une interdiction totale, et les 404 comme l’absence de restriction. Effectuez la correspondance avec votre jeton de produit réel, et assurez-vous que votre en-tête User-Agent le contient. Suivez jusqu’à cinq redirections, en appliquant les règles dans le contexte de l’hôte d’origine.

Et un cinquième point qui ne figure pas dans la RFC mais qui est tout aussi important : consignez ce que vous avez ignoré. Un robot d’indexation qui exclut silencieusement la moitié d’un site à cause d’une règle à laquelle vous ne vous attendiez pas est un robot dont les données manquantes ne seront découvertes que plusieurs semaines plus tard, par quelqu’un qui se demandera pourquoi un rapport semble erroné.

Ce que le fichier robots.txt ne couvre pas

Il convient d’être explicite, car les gens ont tendance à en faire une interprétation excessive dans les deux sens.

Il ne dit rien sur ce que vous pouvez faire avec les données que vous récupérez. Les droits d’auteur, les droits sur les bases de données et les conditions d’utilisation s’appliquent tous indépendamment.

Il ne s’agit pas d’une autorisation. La RFC le précise clairement. Un chemin autorisé est un chemin que le site n’a pas demandé aux robots d’exploration d’éviter, ce qui n’équivaut pas à un consentement à la collecte massive.

La norme ne prévoit aucune limite de fréquence. Crawl-delay est une extension. C’est à vous de faire preuve de courtoisie.

Elle ne fait pas de distinction entre les finalités. Un fichier ne peut pas indiquer « indexation oui, entraînement d’IA non » dans la syntaxe standard, bien que de nombreux sites s’en approchent désormais en désignant des jetons spécifiques pour les robots d’IA. Le cadre européen relatif à l’exploration de textes et de données envisage des réserves de droits lisibles par machine, et les mécanismes permettant de les exprimer sont encore en cours d’élaboration.

Cela ne peut empêcher personne d’agir. Il s’agit d’une demande. La mise en application passe par la limitation de débit, le blocage et les procédures judiciaires — ce qui explique concrètement pourquoi un opérateur choisit d’autoriser un robot d’indexation plutôt que de devoir l’empêcher d’agir.

Questions fréquentes

Le fichier robots.txt a-t-il une valeur juridique contraignante ?

Pas en soi. La norme RFC 9309 précise que ses règles « ne constituent pas une forme d’autorisation d’accès » : il s’agit d’une demande que les robots d’indexation sont invités à respecter. Les obligations légales découlent des conditions d’utilisation, du droit d’auteur, des droits sur les bases de données et de la législation propre à chaque juridiction, qui s’appliquent toutes indépendamment du contenu du fichier.

Les règles du fichier robots.txt sont-elles appliquées dans l’ordre ?

Non, et c’est l’erreur la plus couramment répandue à ce sujet. La spécification exige que « la correspondance la plus spécifique trouvée DOIT être utilisée », où « la plus spécifique » signifie le plus grand nombre d’octets. C’est la correspondance la plus longue qui prévaut, l’ordre n’a aucune importance, et en cas d’égalité, la priorité est donnée à Allow.

Que se passe-t-il si le fichier robots.txt renvoie un code 404 ?

Le fichier est « indisponible », et la RFC stipule que le robot d’indexation « PEUT accéder à toutes les ressources du serveur ». L’absence de fichier signifie l’absence de restrictions. Cela diffère d’une erreur de serveur.

Que se passe-t-il si le fichier robots.txt renvoie un code 500 ?

Le fichier est « inaccessible » et indéfini, et le robot d’indexation « DOIT considérer que l’accès est totalement interdit ». Une erreur de serveur signifie qu’il faut s’arrêter complètement, et non continuer. Après une longue période — la RFC suggère 30 jours —, un robot d’indexation peut le traiter comme indisponible ou continuer à utiliser une copie mise en cache.

À quelle fréquence dois-je récupérer le fichier robots.txt ?

Au moins toutes les 24 heures. La RFC stipule que les robots d’indexation « NE DOIVENT PAS utiliser la version mise en cache pendant plus de 24 heures, sauf si le fichier robots.txt est inaccessible ». Récupérer le fichier une seule fois au démarrage et l’utiliser pendant une semaine n’est pas conforme.

Un groupe d’agents utilisateurs spécifique remplace-t-il le groupe « wildcard » ?

Il le remplace. Si un groupe désigne le jeton de votre produit, vous suivez ce groupe et ignorez complètement le groupe « * » — les règles spécifiques ne s’ajoutent pas aux règles générales. Deux groupes désignant le même jeton sont fusionnés en un seul.

Que signifient « * » et « $ » dans le fichier robots.txt ?

« * » correspond à zéro ou plusieurs caractères quelconques, et « $ » marque la fin du motif de correspondance. Les robots d’exploration DOIVENT prendre en charge ces deux caractères. « Disallow: /*.pdf$ » bloque les URL se terminant par « .pdf » ; sans « $ », cela bloquerait également « /file.pdf.html ».

Puis-je utiliser le fichier robots.txt pour masquer des pages sensibles ?

Non, et cela ne ferait qu’empirer les choses. La section sur la sécurité de la RFC précise que « le fait de répertorier des chemins d’accès dans le fichier robots.txt les expose publiquement et les rend ainsi détectables ». N’importe qui peut lire ce fichier. Utilisez plutôt l’authentification, que la spécification recommande explicitement.

Conclusion : la méthode «

robots.txt» est concise, normalisée et systématiquement mal mise en œuvre. Trois règles sont à l’origine de la plupart des erreurs.

C’est la correspondance la plus longue qui l’emporte, et non la première ni la dernière. Une correspondance «Disallow» située plus bas dans le fichier peut prévaloir sur une correspondance «Allow» située au-dessus, et inversement, uniquement en fonction de la longueur. Un code 5xx signifie un refus total, ce qui est le contraire de ce que ferait une implémentation intuitive : un site en difficulté devrait recevoir moins de trafic de votre part, et non la même quantité. Et le fichier doit être actualisé au moins une fois par jour, car les sites changent d’avis et une copie mise en cache datant d’une semaine n’est pas conforme.

Utilisez un analyseur syntaxique maintenu plutôt que d’écrire le vôtre, assurez-vous que votre en-tête User-Agent contient bien le jeton sur lequel vous vous attendez à ce qu’il y ait une correspondance, et consignez ce que vous avez ignoré afin que les données manquantes relèvent d’une décision et non d’une surprise.

Et gardez à l’esprit la mise en garde propre à la norme. Ces règles « ne constituent pas une forme d’autorisation d’accès » — les respecter fait de votre robot un outil avec lequel un opérateur peut s’accommoder, mais cela ne règle pas les questions distinctes de ce que les conditions autorisent et de ce que vous pouvez faire avec les données que vous collectez.