Fichier robots.txt : le guide complet pour bien le maîtriser

Un client m'appelle lundi dernier, paniqué. Son site a perdu 60 % de son trafic en une semaine. Google Search Console affiche des centaines d'URL « bloquées par robots.txt » qu'il n'a jamais voulues bloquées. Verdict : un plugin WordPress avait ajouté deux lignes fatales dans le fichier robots.txt lors d'une mise à jour. Deux lignes. Une nuit de travail pour réparer.

Ce genre d'incident arrive plus souvent qu'on ne le croit, et c'est précisément pourquoi le fichier robots.txt mérite mieux qu'un coup d'œil distrait. C'est un fichier minuscule, lu en quelques millisecondes par des dizaines de robots, et capable de faire disparaître un site entier des résultats de recherche. Voici ce qu'il faut vraiment savoir pour ne pas se retrouver du mauvais côté de cette ligne de code.

Robots.txt : c'est quoi, au juste, et à quoi ça sert vraiment

Imaginez un panneau à l'entrée d'un bâtiment qui dirait : « Chers visiteurs automatisés, ce couloir est réservé au personnel, merci de ne pas y aller. » C'est exactement le rôle de ce fichier. Il ne verrouille rien. Il demande poliment.

Concrètement, quand le robot de Google arrive sur votre domaine, il cherche votresite.fr/robots.txt avant toute autre chose. Ce fichier texte lui indique quelles zones explorer et lesquelles éviter. Un robot respectueux s'y conforme. Un robot malveillant, un scraper de données ou un aspirateur de contenu, s'en moque totalement. Voilà la nuance que 90 % des articles oublient de préciser.

Exploration et indexation : ne confondez pas

Une page bloquée par Disallow peut parfaitement apparaître dans Google. Je l'ai vu arriver trois fois chez des clients persuadés du contraire. Pourquoi ? Parce que Google peut indexer une URL à partir des liens qui pointent vers elle, même sans jamais l'explorer. Le titre et le snippet affichés seront alors vides ou approximatifs. Résultat : une page moche dans les résultats, plus difficile à déloger qu'une page normale.

Pour retirer réellement une page, il faut la laisser explorer et poser un noindex dans le code HTML, ou la protéger par mot de passe. Bloquer l'exploration et demander le déindexage en même temps, c'est se tirer une balle dans le pied : le robot ne lira jamais la consigne noindex puisqu'il n'entre pas.

Un exemple de fichier robots.txt prêt à copier

Voici la structure que j'utilise sur la majorité des sites que je gère. Elle tient en une vingtaine de lignes et couvre l'essentiel.

User-agent: *
Disallow: /admin/
Disallow: /panier/
Disallow: /*?s=
Allow: /

Sitemap: https://exemple.fr/sitemap.xml

Trois choses à comprendre dans ce bloc. Le User-agent: * s'adresse à tous les robots. Les directives Disallow listent les chemins à éviter. Le Sitemap est une simple indication d'emplacement, pas une règle d'exploration.

Les jokers et la syntaxe avancée

Deux caractères spéciaux changent tout quand on maîtrise la syntaxe :

• remplace n'importe quelle séquence de caractères. /.pdf$ bloque tous les PDF.
• $ marque la fin d'une URL. /page$ ne bloque que l'URL exacte, pas /page/2.
• L'ordre importe : la règle la plus longue et la plus spécifique l'emporte. Allow: /blog/public/ gagne contre Disallow: /blog/.

Attention à un piège fréquent : Disallow: / bloque absolument tout le site. Sans user-agent spécifique devant, c'est la catastrophe garantie. J'ai vu un stagiaire faire ça en production un vendredi après-midi. Le lundi matin, Search Console affichait 4 200 pages bloquées.

Comment trouver le fichier robots.txt d'un site

La méthode est bête comme chou : tapez l'adresse du site suivie de /robots.txt dans la barre du navigateur. lemonde.fr/robots.txt, par exemple. Vous verrez immédiatement le contenu brut.

Deux vérifications complémentaires valent le détour :

1. Testez la version avec www et sans www. Ce sont deux hôtes distincts pour un robot, et certains sites n'en déclarent qu'un seul.
2. Vérifiez le sous-domaine si le site en a un. blog.exemple.fr possède son propre robots.txt, indépendant de celui de exemple.fr.

Un fichier absent renvoie une erreur 404. Ce n'est pas grave en soi : les robots considèrent alors que tout est autorisé. Mais c'est un signal à surveiller, car certains crawlers interprètent parfois une 404 comme une erreur de configuration.

Tester son fichier robots.txt : la checklist que j'applique

Avant toute mise en ligne, je passe par trois étapes systématiques. Elles prennent cinq minutes et évitent des semaines de récupération.

Les outils de test

• Search Console : l'outil « Tester robots.txt » de Google affiche le fichier tel qu'il est perçu et permet de vérifier une URL précise.
• Les testeurs en ligne gratuits : pratiques pour valider la syntaxe, à utiliser avec prudence car certains renvoient des erreurs fantômes.
• Un simple curl https://exemple.fr/robots.txt en ligne de commande, le plus fiable pour vérifier le code HTTP de réponse.

Les erreurs que je vois le plus souvent

Sur une trentaine d'audits réalisés, les mêmes problèmes reviennent :

• Un fichier accessible en 500 ou 503 au lieu de 200. Google considère alors les règles comme temporairement inaccessibles et explore tout, y compris ce que vous vouliez cacher.
• Un nom de fichier en majuscules : Robots.txt ne fonctionne pas, la casse compte.
• Un bloc User-agent vide ou mal orthographié qui annule la règle suivante.
• Des directives noindex glissées dans le fichier. Elles n'y ont aucun effet, personne ne les lit.

Robots.txt et WordPress : le piège du plugin

Par défaut, WordPress génère un fichier virtuel relativement sain. Le problème arrive avec les extensions SEO ou de sécurité, qui y ajoutent leurs propres règles. Et parfois, une mise à jour décide de réécrire tout le fichier à sa façon.

C'est exactement le scénario du client dont je parlais en ouverture. Une extension avait inséré Disallow: / pour une raison inconnue lors d'une mise à jour automatique. Deux lignes, une nuit blanche.

Ma règle : je vérifie le fichier après chaque mise à jour majeure d'un plugin SEO, et je garde une sauvegarde manuelle du contenu validé. Sur un site à fort trafic, un monitoring externe qui contrôle le code HTTP et le contenu du fichier chaque heure vaut l'investissement. Un changement non désiré détecté en une heure se répare en une heure.

Bloquer les robots d'IA : le sujet dont personne ne parlait il y a deux ans

Voici l'angle qui a le plus changé récemment. Depuis que les modèles de langage parcourent le web pour s'entraîner, votre fichier robots.txt est devenu le seul point de contrôle à votre disposition pour dire non.

Robot	Éditeur	Usage principal	Blocage courant
GPTBot	OpenAI	Collecte pour entraînement	Disallow: /
ClaudeBot	Anthropic	Collecte pour entraînement	Disallow: /
Google-Extended	Google	Contrôle de l'usage IA (Gemini)	Disallow: /
CCBot	Common Crawl	Corpus public ouvert	Disallow: /
OAI-SearchBot	OpenAI	Indexation pour la recherche IA	Souvent laissé passer

La nuance importante : bloquer GPTBot coupe la collecte pour l'entraînement, mais ne bloque pas forcément l'apparition de votre site dans ChatGPT Search, qui dispose de ses propres robots. Si votre objectif est d'être cité dans les réponses IA, il faut autoriser les robots de recherche et bloquer uniquement ceux d'entraînement. C'est une distinction que peu de gens font encore, et qui change complètement votre visibilité.

Mon opinion, et je l'assume : pour un site de contenu éditorial, bloquer les aspirateurs d'entraînement tout en laissant passer les robots de recherche est la stratégie la plus équilibrée. On protège le travail original, on garde la visibilité conversationnelle. Pour un e-commerce, la question est plus délicate, car les recommandations IA génèrent déjà du trafic qualifié.

Faut-il passer par un générateur de robots.txt ?

Franchement, non. Un générateur en ligne produit des fichiers génériques qui ajoutent souvent des règles inutiles ou trop larges. Écrire ces 15 lignes à la main prend dix minutes et garantit que vous comprenez ce que vous publiez. Un fichier qu'on ne comprend pas est un fichier qu'on ne saura pas déboguer quand ça casse.

Les seules bonnes pratiques qui comptent vraiment : rester concis, commenter les règles inhabituelles (les lignes commençant par # sont ignorées), vérifier le fichier après chaque changement de configuration, et ne jamais compter sur lui pour cacher quelque chose de sensible. Un répertoire administratif doit être protégé par un mot de passe, pas par une ligne de texte.

Ce fichier de quelques octets est un contrat de confiance avec les robots. Respecté par les uns, ignoré par les autres, il reste le premier point de contact entre votre site et les machines qui le lisent. La prochaine fois qu'une mise à jour vous tentera, ouvrez-le. Deux secondes de lecture valent mieux qu'une nuit blanche.