Fichier robots.txt : guide de configuration pour éviter les erreurs SEO

Un fichier robots.txt mal compris casse plus de sites qu’il n’en protège. La syntaxe elle-même tient sur une page ; ce qui échappe à la plupart des guides, c’est ce que Google fait réellement quand ce fichier tombe en erreur, un scénario bien plus fréquent qu’on ne le pense sur un hébergement qui a un mauvais jour.

Ce qu’un robots.txt fait (et ne fait pas)

Le fichier robots.txt donne des instructions d’exploration aux robots respectueux du protocole (Robots Exclusion Protocol, 1994) : quelles zones du site ils peuvent parcourir, lesquelles ils doivent éviter. Il ne garantit en aucun cas qu’une page bloquée reste hors de l’index de Google : une page interdite au crawl peut malgré tout apparaître dans les résultats de recherche, sans titre ni description, si elle reçoit des liens externes. Pour retirer une page de l’index de façon fiable, c’est la balise meta noindex qu’il faut utiliser, pas le robots.txt : la nuance est souvent inversée par erreur, avec des conséquences que la section suivante détaille.

La syntaxe exacte, directive par directive

Deux caractères génériques changent tout : * remplace n’importe quelle séquence de caractères (Disallow: /*? bloque toute URL contenant un paramètre), $ ancre la règle en fin d’URL (Disallow: /*.pdf$ bloque uniquement les fichiers qui se terminent par .pdf, pas une URL qui contiendrait « .pdf » au milieu d’un chemin). Les règles sont sensibles à la casse et les robots les traitent dans l’ordre du fichier, groupe de User-agent par groupe de User-agent : en cas de conflit entre deux règles qui s’appliquent au même robot, c’est la règle la PLUS SPÉCIFIQUE (le chemin le plus long) qui l’emporte, pas la dernière écrite dans le fichier.

Emplacement, encodage et limites techniques

Le fichier doit impérativement se trouver à la racine du domaine (exemple.fr/robots.txt), jamais dans un sous-dossier : un fichier placé sur exemple.fr/blog/robots.txt est simplement ignoré. Chaque sous-domaine a son propre fichier, distinct du domaine principal. L’encodage doit être UTF-8, et Google impose une limite de taille de 500 kibioctets : tout contenu au-delà de cette limite est purement et simplement ignoré, ce qui peut laisser certaines règles inactives sur un fichier généré automatiquement et devenu trop volumineux avec le temps sur un très gros catalogue.

Ce qui se passe vraiment quand votre robots.txt tombe en erreur

Erreur 404 : Google explore tout, sans restriction

Si votre robots.txt renvoie une erreur 4xx, à l’exception du code 429, Google la traite comme l’absence pure et simple de fichier robots.txt : aucune restriction d’exploration n’est supposée, et le site est crawlé sans aucune limite. Un robots.txt qui disparaît accidentellement (mauvaise migration, permaliens cassés) ne bloque donc rien, à l’inverse de l’intuition : le vrai risque est que des zones normalement interdites au crawl (panier, recherche interne, back-office) se retrouvent brutalement explorées.

Panne serveur (5xx) : une dégradation en trois phases sur 30 jours

Une erreur serveur (5xx), y compris une erreur réseau ou un timeout, déclenche un protocole en plusieurs étapes bien plus prudent : durant les 12 premières heures, Google suspend le crawl du site et retente régulièrement de récupérer le fichier. Si la panne se prolonge, Google utilise la DERNIÈRE version valide du robots.txt mise en cache, et ce pendant 30 jours. Ce n’est qu’au-delà de 30 jours de panne continue que Google traite la situation soit comme l’absence de robots.txt (si le reste du site répond normalement), soit comme l’arrêt complet du crawl (si le site entier semble indisponible). Concrètement : une panne d’hébergeur de quelques heures qui touche votre robots.txt n’a aucun impact SEO immédiat, Google continue de respecter vos anciennes règles. C’est une panne qui s’étire sur des semaines qui devient un vrai sujet, sans qu’aucune alerte visible ne le signale avant que le délai ne soit écoulé.

Sur un site qui vient de connaître une non-indexation inexpliquée, ce protocole de dégradation mérite d’être vérifié avant toute autre hypothèse : notre guide sur les pages non indexées détaille les autres causes possibles une fois le robots.txt écarté.

robots.txt et noindex : la confusion qui neutralise l’un des deux

Une page bloquée par Disallow ne peut PAS être explorée par Google, ce qui signifie que le robot ne peut pas non plus lire la balise <meta name="robots" content="noindex"> présente dans son <head> : les deux directives combinées sur une même page s’annulent partiellement, puisque le blocage empêche la lecture de l’instruction de désindexation. Pour retirer proprement une page de l’index, la bonne séquence est l’inverse de ce que beaucoup appliquent par réflexe : laisser la page explorable, poser le noindex, attendre la désindexation effective, et SEULEMENT ensuite la bloquer au crawl si nécessaire. Cette même logique de signaux qui s’annulent entre eux touche aussi la balise canonical : notre guide sur les erreurs de canonical détaille un cas voisin, où cumuler canonical, noindex et robots.txt sur les mêmes pages produit l’effet inverse de celui recherché.

Le cas des robots IA

Depuis l’essor des moteurs conversationnels, une famille de robots distincte des crawlers de recherche traditionnels lit aussi votre robots.txt : GPTBot et OAI-SearchBot (OpenAI), Google-Extended (entraînement des modèles Google, distinct de Googlebot), ClaudeBot (Anthropic), PerplexityBot et Perplexity-User, Applebot-Extended. Chacun peut être ciblé individuellement par sa propre ligne User-agent, ce qui permet par exemple d’autoriser l’indexation classique tout en refusant l’entraînement de modèles sur votre contenu (blocage de Google-Extended et GPTBot uniquement, sans toucher à Googlebot). Un malentendu fréquent consiste à croire que ces robots ont besoin de règles Allow spécifiques : ce n’est pas le cas, ils respectent le même protocole d’exclusion que les crawlers historiques.

Ce qu’il est pertinent de bloquer

1. Back-office et zones d’administrationAucune valeur SEO, risque de fuite d’information sur la structure technique du site si elles s’indexent.
2. Recherche interne et filtres à facettesGénèrent un volume d’URLs à paramètres qui consomment du budget de crawl sans apporter de contenu réellement distinct. Notre guide sur le budget de crawl détaille comment chiffrer ce gaspillage avant de décider quoi bloquer.
3. Panier, compte client, tunnel de commandePages transactionnelles propres à chaque visiteur, sans intérêt pour un moteur de recherche.
4. Environnements de test ou de préproductionÀ bloquer intégralement (Disallow: /) sur le sous-domaine de test, jamais sur le domaine de production par erreur de copier-coller lors d’une mise en ligne.

Tester et surveiller votre fichier

1. Vérifiez l’accès directOuvrez exemple.fr/robots.txt dans un navigateur : le fichier doit répondre en HTTP 200 et afficher du texte brut lisible, jamais une page d’erreur habillée par le thème du site.
2. Utilisez le rapport dédié de Search ConsoleIl signale les erreurs de syntaxe et les avertissements sans attendre un audit manuel.
3. Testez une URL précise avec l’outil d’inspectionConfirmez qu’une page stratégique n’est pas bloquée par inadvertance par une règle trop large.
4. Surveillez le fichier après chaque mise en productionUn Disallow: / resté actif après un déploiement depuis un environnement de recette est l’une des causes les plus fréquentes de désindexation totale d’un site, souvent découverte trop tard.

Erreurs qui cassent le SEO

1. Bloquer les fichiers CSS et JavaScriptEmpêche Google de rendre correctement la page pour évaluer son contenu réel, un héritage de pratiques obsolètes qui reste étonnamment fréquent.
2. Oublier un Disallow global après une mise en ligneLa règle héritée d’un environnement de recette bloque tout le site en production sans qu’aucune alerte immédiate ne prévienne l’équipe.
3. Multiplier les caractères génériques sans tester leur portée réelleUn * mal placé peut bloquer un chemin bien plus large que prévu, y compris des pages stratégiques qui partagent un segment d’URL avec la zone visée.
4. Confondre robots.txt et désindexationBloquer une page déjà indexée sans poser d’abord le noindex la laisse apparaître dans les résultats sans titre ni description, au lieu de disparaître proprement de l’index.

Questions fréquentes

Ce qu’il faut retenir

La syntaxe d’un robots.txt se maîtrise en une lecture. Ce qui distingue un fichier bien géré, c’est la compréhension du comportement de Google face aux erreurs, à la confusion avec le noindex, et aux robots IA qui s’ajoutent désormais à l’équation : trois zones où une hypothèse intuitive mais fausse coûte plus cher qu’une syntaxe mal maîtrisée.