En bref. Une erreur serveur sur robots.txt suspend d’abord l’exploration de Google, puis le traitement dépend des règles en cache et de la disponibilité du site, tandis qu’Amazon documente un autre comportement de repli.

Définition : Une erreur serveur sur robots.txt empêche un robot de récupérer le fichier qui régit l’accès pour l’exploration. Google suspend d’abord l’exploration ; la suite dépend des règles en cache et de la disponibilité du site.

Points clés

Au 17 octobre 2026, la spécification robots.txt de Google décrit une suspension initiale de l’exploration de 12 heures en cas d’erreur serveur.
La RFC 9309 de l’IETF impose aux robots de considérer toute exploration comme interdite lorsque robots.txt est inaccessible en raison d’une erreur serveur ou réseau.
La documentation des robots d’Amazon, consultée en octobre 2026, indique que les robots d’exploration automatisée peuvent utiliser un fichier mis en cache au cours des 30 derniers jours et considérer comme absent un fichier qu’ils ne peuvent pas récupérer.
La documentation du rapport robots.txt de Google décrit l’historique des récupérations et la demande de nouvelle exploration après la correction d’une erreur de récupération.

Comment Google gère-t-il une panne prolongée ?

La spécification de Google décrit la séquence suivante pour les erreurs serveur HTTP 5xx :

Pendant les 12 premières heures, l’exploration s’arrête tandis que les tentatives de récupération de robots.txt se poursuivent.
Pendant les 30 jours suivants, Google utilise la dernière version valide tout en réessayant de récupérer le fichier. En l’absence de version en cache, il considère que l’exploration n’est soumise à aucune restriction.
Après 30 jours d’erreurs, un site généralement disponible est traité comme s’il ne possédait pas de fichier robots.txt. En cas de problèmes de disponibilité touchant l’ensemble du site, l’exploration s’arrête. Les vérifications du fichier se poursuivent dans les deux cas.

Une réponse 503 entraîne des tentatives fréquentes. Google traite également les échecs DNS et les dépassements de délai réseau comme des erreurs serveur.

Qu’exige le protocole ?

Le protocole d’exclusion des robots (Robots Exclusion Protocol) est la norme qui permet de communiquer les règles d’accès des robots. La RFC 9309, section 2.3.1.4, classe les réponses HTTP de la plage 500-599 parmi les erreurs serveur et impose d’interdire toute exploration lorsque le fichier est inaccessible.

Après une panne suffisamment longue, avec 30 jours comme exemple, la norme autorise à considérer le fichier comme indisponible ou à continuer d’utiliser une copie en cache. La section 2.4 permet de conserver une version en cache au-delà de 24 heures lorsque le fichier est inaccessible.

La section 2.3 situe le fichier, dont le nom s’écrit en minuscules, à la racine du service et donne cet exemple d’URL :

https://www.example.com/robots.txt

Comment Amazon décrit-il les échecs de récupération ?

La page « About AmazonBot » d’Amazon couvre Amazonbot et Amzn-SearchBot, son robot de recherche. Sa politique d’exploration automatisée autorise la récupération du fichier robots.txt de l’hôte ou l’utilisation d’une copie mise en cache au cours des 30 derniers jours. Elle indique qu’un fichier impossible à récupérer est traité comme inexistant.

Cette formulation concerne les échecs de récupération en général ; Amazon ne fournit pas de calendrier distinct pour chaque code d’erreur serveur. La même page situe les règles au niveau de chaque hôte : example.com et site.example.com possèdent chacun leur propre fichier robots.txt. Les contrôles opérationnels doivent donc porter sur l’hôte demandé par le robot.

Comment vérifier le rétablissement sur un site web ?

Le rapport robots.txt de Google affiche l’URL du fichier, le dernier état de récupération et l’heure de la dernière tentative. Un clic sur un fichier ouvre son dernier contenu récupéré ; l’option Versions affiche les demandes de récupération des 30 derniers jours. L’historique ne consigne une demande que si le fichier récupéré ou le résultat change.

Le rapport distingue Fetch status, qui concerne la récupération, et Issues, qui concerne l’analyse des règles récupérées. Cette distinction permet de différencier un fichier inaccessible d’un fichier contenant des lignes invalides.

Après la correction d’une erreur de récupération, le menu du fichier propose Request a recrawl. La procédure documentée consiste à sélectionner l’icône des paramètres supplémentaires à côté du fichier, puis cette action.

Termes associés

Questions fréquentes

Un fichier absent a-t-il le même effet qu’une erreur serveur ?

La spécification de Google traite les réponses HTTP 4xx, à l’exception de 429, comme un fichier absent, sans restriction d’exploration.

Puis-je consulter la version récupérée par Google avant la panne ?

Oui. La documentation du rapport de Google décrit comment ouvrir le dernier fichier récupéré et sélectionner Versions pour consulter les résultats des récupérations précédentes.

Sources

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

Que se passe-t-il lorsque robots.txt renvoie une erreur serveur ?