Mise en cache de robots.txt et gestion des erreurs

L'équipe Citead, mis à jour le

En bref. Les robots peuvent réutiliser les règles robots.txt en cache si la récupération échoue, tandis que Google documente une séquence de nouvelles tentatives assortie de délais en cas d’erreur serveur.

Définition : La mise en cache de robots.txt consiste, pour un robot d’exploration (crawler), à réutiliser un fichier de règles d’exploration précédemment récupéré. La gestion des erreurs détermine si un échec de récupération conduit le robot à réutiliser ces règles, à suspendre l’exploration ou à poursuivre sans restriction d’exploration.

Points clés

  • La RFC 9309 recommande de ne pas utiliser un fichier robots.txt en cache pendant plus de 24 heures, sauf si le fichier est injoignable.
  • Au 17 octobre 2026, la documentation de Google sur robots.txt décrit une suspension de l’exploration de 12 heures après une erreur serveur, suivie de la réutilisation de la dernière version valide pendant les 30 jours suivants.
  • La RFC 9111, HTTP Caching, définit la directive de réponse max-age en secondes ; celle-ci indique à partir de quand une réponse est périmée.

Qu’exige la RFC 9309 après un échec de récupération ?

Le protocole d’exclusion des robots (Robots Exclusion Protocol) définit la manière dont les robots interprètent robots.txt. Ses règles relatives aux résultats d’accès distinguent un fichier indisponible d’un fichier injoignable. « Indisponible » signifie que le serveur renvoie une réponse indiquant que la ressource est indisponible, par exemple une erreur client. « Injoignable » signifie qu’une erreur serveur ou réseau empêche l’accès ; les erreurs HTTP de la plage 500-599 en sont un exemple. Pour un fichier injoignable, la RFC impose aux robots de considérer que toute exploration est interdite.

La RFC autorise également la mise en cache. Sa recommandation de ne pas utiliser une copie de plus de 24 heures prévoit explicitement une exception lorsque le fichier est injoignable. Après un échec prolongé, avec 30 jours donnés à titre d’exemple, un robot peut considérer le fichier comme indisponible ou continuer à utiliser une copie en cache. Cet exemple laisse au robot le choix de la mise en œuvre.

Une erreur d’analyse syntaxique entraîne un autre résultat : les robots doivent tenter d’analyser chaque ligne et utiliser les règles qu’ils peuvent interpréter. Une ligne mal formée laisse donc les autres règles exploitables en vigueur.

Comment Google traite-t-il les erreurs serveur et réseau ?

Le tableau de Google sur la gestion des erreurs décrit la marche à suivre en cas d’erreur serveur :

  1. Pendant les 12 premières heures, Google cesse d’explorer le site tout en continuant à tenter de récupérer robots.txt.
  2. Si la récupération échoue toujours, Google utilise la dernière version valide pendant les 30 jours suivants et poursuit ses tentatives. Sans version en cache, il considère qu’aucune restriction d’exploration ne s’applique durant cette étape.
  3. Si les erreurs persistent après 30 jours, la disponibilité du site détermine la suite. Pour un site généralement disponible, Google agit comme si robots.txt était absent et continue de rechercher un nouveau fichier. Si le site présente des problèmes généraux de disponibilité, il cesse l’exploration tout en demandant périodiquement robots.txt.

La même documentation assimile les défaillances DNS et les problèmes réseau, notamment les délais d’attente dépassés et les connexions interrompues, à des erreurs serveur. Elle indique également qu’une réponse 503 entraîne des tentatives assez fréquentes.

Que change la mise en cache lors d’une modification des règles ?

La documentation de Google sur la mise en cache indique qu’une réponse en cache peut être partagée entre plusieurs robots. Google conserve généralement le fichier en cache pendant 24 heures au maximum et peut le conserver plus longtemps si l’actualisation échoue. La directive max-age de l’en-tête de réponse HTTP Cache-Control peut augmenter ou réduire cette durée.

La syntaxe des règles de la RFC permet le fichier suivant, qui demande aux robots relevant du groupe désigné par le caractère générique d’éviter tous les chemins :

User-agent: *
Disallow: /

Comme les robots peuvent réutiliser une copie antérieure, la publication de ces lignes ne remplace pas immédiatement les règles en cache. Après un téléchargement réussi, la RFC impose au robot de respecter les règles interprétables du fichier récupéré.

Termes associés

Questions fréquentes

Pouvez-vous utiliser une réponse 403 pour bloquer l’exploration de Google via robots.txt ?

La documentation de Google sur les erreurs client indique que les réponses 4xx autres que 429 impliquent l’absence de restrictions d’exploration. Renvoyer une réponse 403 pour robots.txt conduit donc Google à considérer le fichier comme absent.

La durée de conservation des règles en cache de Google est-elle strictement limitée à 24 heures ?

La même documentation de Google autorise une conservation plus longue lorsque l’actualisation échoue. Elle permet également d’ajuster la durée de conservation en cache en fonction des en-têtes de réponse max-age.

Sources

  1. IETF, « RFC 9309: Robots Exclusion Protocol », septembre 2022
  2. Google, « How Google interprets the robots.txt specification », mis à jour le 31 août 2026
  3. IETF, « RFC 9111: HTTP Caching », juin 2022

Vérifiez comment une page se lit pour les moteurs de réponse. Ouvrir l’analyseur de score GEO

Testez une page et voyez quoi corriger en premier

L'analyse prend en général moins de 10 secondes et ne demande pas de compte.

400 000+ pages notées dans le benchmark public