Tapez exemple.fr/robots.txt dans votre navigateur. Vous tomberez sur un fichier qui ressemble à ça : trois lignes, parfois cinq, écrites en anglais basique. Pas de mise en page, pas de couleurs. Et pourtant, ce petit fichier décide si Google va explorer votre site ou l'ignorer en partie. Je l'ai appris à mes dépens il y a quelques années, quand j'ai découvert que la moitié de mon catalogue produits était invisible dans les résultats de recherche. Cause du problème : une ligne Disallow: / oubliée dans un fichier de préproduction. Deux mois pour m'en rendre compte.
Donc, comprendre le fichier robots.txt, ce n'est pas un exercice théorique. C'est la différence entre un site qui se fait crawler correctement et un site qui disparaît silencieusement. Voici ce que j'ai fini par comprendre, à la dure.
Points clés à retenir
- Le robots.txt est un fichier texte brut, déposé à la racine du site, qui donne des instructions aux robots d'exploration.
- Il pilote l'exploration (crawl), pas l'indexation. Une URL bloquée peut quand même apparaître dans les résultats.
- La syntaxe tient en quelques directives :
User-agent,Disallow,Allow,Sitemap. - Un fichier mal écrit peut mettre un site entier hors de portée des moteurs.
- Ce n'est pas un outil de sécurité. Aucun mot de passe, aucune donnée sensible là-dedans.
- Chaque hôte (sous-domaine, http vs https) a son propre fichier.
Comment lire un fichier robots.txt sans se perdre
La première fois que j'ai ouvert un robots.txt, j'ai cru à un fichier cassé. Aucune balise, aucun style. Juste du texte aligné à gauche. C'est normal : c'est un fichier de texte brut, et c'est précisément ce que les robots attendent.
Prenons un exemple réel, commenté ligne par ligne. Celui-ci vient d'un site e-commerce que j'ai audité :
User-agent: * Disallow: /panier/ Disallow: /recherche-interne/ Allow: /panier/checkout Sitemap: https://exemple.fr/sitemap.xml
Décortiquons. La première ligne, User-agent: *, s'adresse à tous les robots sans exception. L'astérisque est un joker. Ensuite, chaque Disallow interdit une zone. Ici : les pages de panier et la recherche interne. Logique — ces pages n'ont aucune valeur dans un moteur de recherche, elles créent juste du contenu dupliqué et infini.
Puis vient le Allow. Et là, ça devient intéressant. On interdit /panier/ mais on réautorise /panier/checkout. Pourquoi ? Parce que la page de paiement, elle, peut générer du trafic qualifié. C'est un cas classique de override : le Allow est plus spécifique, donc il gagne.
Dernière ligne, le Sitemap. Il n'a rien à voir avec les permissions : il indique simplement où se trouve votre plan de site. Un rappel gratuit pour les robots.
Comment voir le robot txt d'un site ?
Trois méthodes, de la plus simple à la plus technique.
La première : ouvrez un onglet et tapez l'adresse du site suivie de /robots.txt. C'est tout. Un fichier s'affiche, ou vous obtenez une erreur 404 — ce qui signifie qu'il n'y en a pas.
La deuxième, si vous gérez votre propre site : la Search Console de Google propose un rapport dédié. Vous y voyez l'état du fichier, les erreurs de syntaxe détectées, et vous pouvez tester une URL précise pour savoir si elle est autorisée ou bloquée.
La troisième, pour les développeurs : une simple ligne de commande.
curl -I https://exemple.fr/robots.txt
Le -I renvoie juste les en-têtes HTTP. Si vous voyez 200 OK, le fichier existe. 404, il n'existe pas. 403, il existe mais est protégé — mauvaise idée, on y reviendra.
Franchement, pour 90 % des besoins, la première méthode suffit. Mais quand un problème de crawl traîne, le test d'URL de la Search Console reste mon outil de prédilection : il vous dit noir sur blanc si Google peut explorer une page donnée, et pourquoi.
C'est quoi un fichier txt, au fond ?
Un fichier TXT est un document de texte brut, sans mise en forme, ne contenant que des caractères alphanumériques. Son extension .txt est reconnue par pratiquement tous les logiciels existants, ce qui en fait le format de référence pour stocker du texte.
Ce qui le rend intéressant ici, c'est son universalité. Un robots.txt n'a ni gras, ni titre, ni couleur. Il doit pouvoir être lu par des milliers de robots écrits dans des langages différents, sur des serveurs différents, depuis une trentaine d'années. Le format TXT garantit cette compatibilité. C'est pour ça qu'on n'écrit pas un robots.txt en HTML ou en JSON : tout le monde doit pouvoir le lire.
Notez un détail que j'ai mis des années à intégrer : le sens de lecture est de haut en bas, ligne par ligne. Aucune notion de priorité entre les directives, sauf pour la spécificité du chemin. Pas de bloc imbriqué, pas d'héritage. Un robot lit, applique, avance.
Les erreurs qui font vraiment mal
J'ai compilé ici les erreurs que j'ai commises ou vues commettre. Elles coûtent cher.
- Fichier absent (404). Pas dramatique en soi — un robot suppose qu'il peut tout explorer. Mais vous perdez tout contrôle sur les zones sensibles.
- Disallow trop large. Un
Disallow: /est une mise à mort. J'ai vu une équipe bloquer tout son site pendant 11 jours après un déploiement. Trafic organique divisé par trois. - Conflit avec noindex. La balise meta robots
noindexdemande de retirer une page de l'index. Mais si le robots.txt empêche l'exploration de cette même page, le robot ne verra jamais la balise. Résultat : la page reste indexée. Piège classique. - Mauvais sous-domaine. Un robots.txt sur
www.exemple.frn'a aucun effet surblog.exemple.frni surm.exemple.fr. Chaque hôte a son propre fichier. J'ai perdu une semaine sur ce problème à mes débuts. - Protéger le fichier par mot de passe. Une erreur 403 sur le robots.txt n'empêche pas le crawl : elle le rend imprévisible. Laissez ce fichier public.
Le point commun de toutes ces erreurs ? Elles sont silencieuses. Aucun avertissement dans le navigateur, aucune alerte automatique. Vous vous en apercevez des semaines plus tard, en voyant les statistiques s'effondrer.
Robots.txt et robots d'IA : le nouveau terrain
En 2026, la question qui revient le plus souvent dans mes échanges avec d'autres webmasters n'est plus "comment bloquer Googlebot", mais "comment gérer GPTBot et compagnie".
Le principe est identique. Les robots des grands modèles de langage — GPTBot pour OpenAI, CCBot pour Common Crawl, ClaudeBot pour Anthropic, Google-Extended pour les usages IA de Google — respectent, pour la plupart, les directives du robots.txt. Vous pouvez donc les cibler nommément.
User-agent: GPTBot Disallow: / User-agent: CCBot Disallow: /
Deux stratégies s'opposent. Bloquer : vous refusez que vos contenus nourrissent les modèles. Autoriser : vous acceptez d'être cité, potentiellement comme source dans les réponses générées. Aucune des deux n'est meilleure — c'est un choix éditorial et économique.
Mon avis personnel ? Sur un site de contenu éditorial original, je pencherais pour une autorisation sélective. Bloquer tout par principe, c'est renoncer à une visibilité qu'on ne sait pas encore mesurer. Mais chaque cas est différent, et je ne prétends pas avoir la réponse définitive. Le paramètre technique, lui, est simple : une ligne User-agent et une ligne Disallow, et c'est réglé.
Pourquoi Google demande-t-il si je suis un robot ?
Ce n'est pas le robots.txt qui produit ce message. Confusion fréquente, et je la comprends.
Quand Google affiche "Je ne suis pas un robot" avec une case à cocher, c'est un CAPTCHA. Il apparaît quand vous soumettez un formulaire, faites une recherche inhabituelle ou vous connectez depuis une adresse IP suspecte. Son objectif : distinguer un humain d'un script automatisé qui tenterait d'exploiter le service.
Le robots.txt, lui, n'affiche rien. Il n'interroge personne. C'est un fichier de consignes déposé sur votre serveur, que les crawlers choisissent de consulter. La seule ressemblance entre les deux, c'est le mot "robot". Le premier est un portail qu'on doit franchir, le second un panneau indicateur qu'on peut ignorer.
Et c'est justement ce "peut ignorer" qui déroute. Un crawler mal intentionné n'a aucune obligation de respecter votre fichier. Les grands moteurs le font par convention, depuis l'initiative de 1994 standardisée plus tard par l'IETF. Un scraper quelconque, non. D'où l'importance de ne jamais y mettre de données confidentielles.
Robots.txt, meta robots, X-Robots-Tag : qui fait quoi
Les trois outils se ressemblent, mais ils n'agissent pas au même niveau. Confondre leurs rôles est une source classique de bugs d'indexation.
| Outil | Niveau d'action | Effet principal | Empêche l'indexation ? |
|---|---|---|---|
| robots.txt | Fichier serveur, niveau site | Autorise ou bloque l'exploration | Non |
| Meta robots | Balise dans la page (HTML) | Contrôle l'indexation et le suivi des liens | Oui, si noindex |
| X-Robots-Tag | En-tête HTTP | Même rôle que meta robots, mais pour PDF, images, vidéos | Oui, si noindex |
La règle à retenir : le robots.txt bloque l'accès, les deux autres retirent de l'index. Si votre objectif est de faire disparaître une page des résultats de recherche, utilisez noindex, pas Disallow. Et si vous combinez les deux, le noindex ne sera jamais lu puisque le robot n'aura pas accès à la page. Contre-productif.
Pour les fichiers non-HTML — un PDF confidentiel, une image privée — l'en-tête X-Robots-Tag est la seule option, puisqu'on ne peut pas y insérer de balise.
Multi-domaines, sous-domaines et protocoles : le casse-tête
Un point sur lequel presque tous les débutants se cassent les dents : il n'y a pas un robots.txt par site, mais un par hôte.
Concrètement, chacun de ces cas possède son propre fichier, indépendant des autres :
https://exemple.fr/robots.txthttps://www.exemple.fr/robots.txthttp://exemple.fr/robots.txt(version non sécurisée)https://blog.exemple.fr/robots.txt(sous-domaine)
Si vous migrez de http vers https, ou de non-www vers www, vous devez reproduire vos directives sur le nouvel hôte. Sinon, une partie de votre configuration disparaît du jour au lendemain. J'ai vu une migration www mal menée laisser un sous-domaine boutique sans aucune protection pendant trois semaines.
Pour vérifier, la méthode est simple : ouvrez chaque variante dans votre navigateur, une par une. Fastidieux, mais radical.
Ce qu'il faut vraiment retenir
Le fichier robots.txt n'est pas un document magique. C'est un panneau indicateur accepté par convention, lu par les robots bien élevés, ignoré par les autres. Il ne protège rien, il ne classe rien. Il organise le travail des crawlers.
Si vous ne retenez qu'une chose de cet article, que ce soit celle-ci : avant de bloquer quoi que ce soit, demandez-vous si votre objectif est d'empêcher l'exploration ou l'indexation. Ce sont deux mécanismes distincts, et les confondre est la source de la majorité des catastrophes SEO que j'ai pu observer.
Et si vous héritez d'un site sans savoir qui a écrit son robots.txt ni pourquoi certaines lignes y figurent, ne le modifiez pas sans sauvegarde. Un fichier de cinq lignes peut faire plus de dégâts qu'une refonte complète.
