L'idée reçue du mois Publié le 23 août 2026 · sources vérifiées le 15 août 2026

Votre robots.txt est en panne : Amazon considère que tout est autorisé, Google arrête d'explorer. Deux philosophies opposées

L'essentiel

Question que personne ne se pose : que font les robots quand votre robots.txt ne répond plus (erreur serveur, panne, mauvaise configuration) ?
Amazon documente sa réponse : un fichier injoignable est traité comme s'il n'existait pas. Porte ouverte, tout est autorisé.
Google documente l'inverse, en escalier : d'abord il arrête d'explorer le site (12 heures), puis il utilise sa dernière version connue du fichier (30 jours), et n'ouvre tout qu'en dernier recours.
Et le standard officiel du protocole, lui, a tranché : sur une erreur serveur, un robot conforme DOIT présumer l'interdiction totale. La prudence de Google suit le standard ; la phrase d'Amazon, prise à la lettre, est plus permissive que lui.
Conséquence pratique : vos règles ne valent que si le fichier RÉPOND. La disponibilité de robots.txt est un sujet de surveillance à part entière.

Wen DasnoisFondateur de Rank Press. J'ai ouvert et lu chaque source citée ici le 15 août 2026. LinkedIn · Ma page auteur

Tout ce que cette série a documenté sur robots.txt (qui le lit, qui l'ignore, qui hérite des règles des autres) suppose une chose qu'on ne questionne jamais : que le fichier réponde. Or un robots.txt tombe en panne comme n'importe quelle adresse : erreur serveur, pare-feu trop zélé, migration ratée. Que se passe-t-il alors ? J'ai la réponse documentée de deux opérateurs, et elles sont opposées.

Amazon : la panne vaut autorisation

« They will fetch host-level robots.txt files or use a cached copy from the last 30 days. When a file can't be fetched, they will behave as if it does not exist. »

Ma traduction : ils récupèrent le fichier robots.txt du site, ou utilisent une copie en cache des 30 derniers jours. Quand un fichier ne peut pas être récupéré, ils se comportent comme s'il n'existait pas. Source : Amazon, « Amazonbot », developer.amazon.com, sans date de mise à jour affichée, consultée le 15 août 2026.

La logique d'Amazon : pas de fichier lisible, pas de restriction. Un site sans robots.txt est un site ouvert (c'est la convention du web), donc un site dont le robots.txt est en panne est traité pareil. Cohérent, mais lourd de conséquences : vos interdictions disparaissent avec la panne, au mieux amorties par la copie en cache des 30 derniers jours si Amazon en a une.

Google : la panne vaut prudence, en escalier

« If Google finds a robots.txt file but can't fetch it, Google follows this behavior: For the first 12 hours, Google stops crawling the site but keeps trying to fetch the robots.txt file. If Google can't fetch a new version, for the next 30 days Google will use the last good version, while still trying to fetch a new version. [...] If there's no cached version available, Google assumes there's no crawl restrictions. »

Ma traduction : si Google trouve un fichier robots.txt mais ne peut pas le récupérer : pendant les 12 premières heures, Google arrête d'explorer le site tout en réessayant de récupérer le fichier. S'il n'y parvient pas, pendant les 30 jours suivants il utilise la dernière bonne version connue, tout en continuant d'essayer. S'il n'existe aucune version en cache, Google considère qu'il n'y a pas de restriction d'exploration. Source : Google, « How Google interprets the robots.txt specification », developers.google.com, dernière mise à jour affichée le 8 juillet 2026, consultée le 15 août 2026.

La philosophie inverse : dans le doute, Google présume que vous vouliez peut-être tout interdire, et il s'arrête. Douze heures de gel complet de l'exploration, puis le filet de la dernière version connue pendant un mois. L'ouverture totale n'arrive qu'en tout dernier recours, quand aucune mémoire du fichier n'existe.

Le même incident, deux mondes

Mettez les deux côte à côte : pendant une panne de robots.txt, Amazon explore tout, Google n'explore rien (les 12 premières heures). Et sur ce cas précis, contrairement à beaucoup d'autres, le standard officiel du protocole a un avis, et il est tranché.

Ce que dit le standard : l'interdiction totale, obligatoire

« If the robots.txt file is unreachable due to server or network errors, this means the robots.txt file is undefined and the crawler MUST assume complete disallow. For example, in the context of HTTP, server errors are identified by status codes in the 500-599 range. »

Ma traduction : si le fichier robots.txt est injoignable à cause d'erreurs serveur ou réseau, le fichier est réputé indéfini et le robot DOIT présumer l'interdiction totale. Par exemple, en HTTP, les erreurs serveur sont les codes 500 à 599. Source : RFC 9309, « Robots Exclusion Protocol », section sur le statut injoignable, rfc-editor.org, septembre 2022, consultée le 15 août 2026. La section suivante ajoute la soupape : si le fichier reste indéfini « pendant une période raisonnablement longue (par exemple, 30 jours) », les robots PEUVENT alors le traiter comme absent, ou continuer d'utiliser une copie en cache.

Précision importante : ce « MUST » vise la panne (erreur serveur ou réseau), pas l'absence. Un robots.txt qui répond « fichier introuvable » (404) est, pour le standard aussi, un site sans restriction : là-dessus, tout le monde est d'accord. La divergence porte sur l'erreur serveur, et elle se lit maintenant clairement : la prudence en escalier de Google suit la logique du standard (interdiction d'abord, soupape ensuite), tandis que la phrase d'Amazon, qui ne distingue pas la panne de l'absence, est prise à la lettre plus permissive que ce que le standard exige pour les erreurs serveur. C'est l'illustration la plus nette de ce que cette série répète : même quand un standard existe et parle, ce qui s'applique à votre site est ce que CHAQUE opérateur documente chez lui.

La conséquence qu'on ne voit qu'en y pensant : une panne de robots.txt peut ressembler à une chute de trafic. Si votre fichier renvoie des erreurs serveur, Google gèle l'exploration du site : vos nouvelles pages ne sont plus découvertes, vos mises à jour plus vues, et la courbe finit par s'en ressentir, sans qu'aucun contenu ait changé. C'est exactement la famille « problème technique » du guide de diagnostic des baisses de trafic publié hier dans cette série. Avant de chercher une pénalité, vérifiez que votre robots.txt répond, avec un vrai code 200.

Ce que ça change pour vous

Surveillez la disponibilité de votre robots.txt comme celle de votre page d'accueil : c'est le fichier dont la panne change le comportement de TOUS les robots, chacun à sa façon. Un contrôle automatique qui vérifie qu'il répond en 200 coûte une ligne dans n'importe quel outil de surveillance.

Ne « protégez » jamais votre robots.txt derrière un pare-feu, une protection anti-robot ou une règle de blocage : un fichier qui répond une erreur aux robots EST le scénario de panne décrit ici, en permanence. Il doit être l'adresse la plus accessible du site.

En cas de migration ou de refonte : gardez le fichier joignable pendant toute l'opération. Douze heures d'indisponibilité suffisent à geler l'exploration de Google, et trente jours suffisent à faire tomber vos interdictions chez Amazon.

Comment j'ai travaillé

Les deux pages officielles et le texte du standard (RFC 9309) ont été téléchargés et analysés en texte intégral le 15 août 2026. Les citations sont reprises mot pour mot, avec ma traduction annoncée comme telle ; la coupe dans la citation de Google est signalée et ne retire qu'un détail de fréquence de réessai. La page d'Amazon n'affiche pas de date de mise à jour : je le signale plutôt que d'en inventer une.

Détail de méthode : l'ancienne adresse de la page de Google sur robots.txt ne répond plus (la documentation a déménagé vers la nouvelle section dédiée à l'infrastructure d'exploration) ; la version citée ici est la page vivante, retrouvée depuis la navigation officielle, datée du 8 juillet 2026. C'est un rappel de plus qu'une documentation se cite depuis sa page vivante, jamais depuis une adresse recopiée.

Cet article ne contient aucune mesure de notre part et n'utilise aucune donnée d'aucun site utilisateur.

Sources

Primaire Amazon, « Amazonbot » (le fichier injoignable traité comme inexistant ; la copie en cache des 30 derniers jours). Sans date de mise à jour affichée. developer.amazon.com. Consultée et analysée en texte intégral le 15 août 2026.
Primaire Google, « How Google interprets the robots.txt specification » (le comportement en escalier sur fichier injoignable : gel de 12 heures, dernière bonne version pendant 30 jours, absence de restriction en dernier recours). Dernière mise à jour affichée : 8 juillet 2026. developers.google.com. Consultée et analysée en texte intégral le 15 août 2026.
Primaire RFC 9309, « Robots Exclusion Protocol » (le MUST d'interdiction totale sur erreur serveur ou réseau ; la soupape des 30 jours ; le traitement du fichier absent). Septembre 2022. rfc-editor.org. Consulté et analysé en texte intégral le 15 août 2026.