Le fichier robots.txt

Mis à jour le 23 octobre 2026

Le robots.txt est l’un des plus petits fichiers d’un site, et l’un des plus sensibles. Deux lignes suffisent à rendre un site entier invisible pour les robots. À l’inverse, un fichier trop permissif laisse les robots perdre leur temps dans des milliers de pages inutiles.

Cette page explique la syntaxe, les règles d’interprétation de Google, les usages corrects et les erreurs à éviter. Elle fait partie de mon guide du SEO technique.

Par Alexandre Montenon, consultant SEO depuis 2011

À quoi sert le robots.txt

Le fichier sert à gérer le passage des robots, pas à cacher des pages. Google explique qu’il sert principalement à éviter de surcharger un site de requêtes, qu’il ne permet pas d’exclure une page de Google, et qu’une page bloquée peut encore apparaître dans les résultats, sans description ; pour l’exclure, il faut utiliser une balise noindex ou une protection par mot de passe.

Usages légitimes : empêcher les robots de parcourir les pages de recherche interne, les combinaisons de filtres d’une boutique, les zones d’administration, les paniers et les pages de compte, ou encore des fichiers techniques sans intérêt pour la recherche. Il sert aussi à déclarer l’adresse du sitemap et, désormais, à décider quels robots d’IA peuvent lire le site.

La syntaxe

Un fichier robots.txt est composé de groupes. Chaque groupe commence par une ligne user-agent, qui désigne le robot concerné, suivie de règles disallow et allow. Le caractère « * » désigne tous les robots.

Exemple simple :

User-agent: *
Disallow: /recherche/
Disallow: /panier/
Allow: /panier/aide/

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

Ce fichier demande à tous les robots de ne pas parcourir les pages de recherche interne et de panier, sauf la page d’aide du panier, et indique l’adresse du sitemap XML.

Les règles d’interprétation de Google

Google précise que le fichier doit se trouver à la racine du site, qu’il n’en lit que les 500 premiers Kio, qu’il ne reconnaît que les champs user-agent, allow, disallow et sitemap (crawl-delay n’est pas pris en compte), que les chemins sont sensibles à la casse, que la règle la plus spécifique l’emporte, et qu’il conserve généralement le fichier en cache jusqu’à 24 heures ; il suit le protocole d’exclusion des robots défini par la norme RFC 9309.

Robots.txt ou noindex ?

C’est la confusion la plus fréquente. Les deux outils ne font pas la même chose, et les combiner peut produire l’inverse de l’effet recherché.

Le piège : si une page porte une balise noindex mais est aussi bloquée dans le robots.txt, Google ne peut pas la lire, donc ne voit jamais la balise noindex. La page peut rester indexée. Pour retirer une page, laissez-la accessible le temps que Google voie la balise.

Quel contenu selon le type de site

Site vitrine. Le fichier peut rester très court : aucune restriction, ou seulement les pages de recherche interne et l’espace d’administration, plus la ligne sitemap. Sur un petit site, le principal risque n’est pas de laisser trop de pages ouvertes, mais d’en bloquer par erreur.

Boutique en ligne. C’est là que le fichier rend le plus de services : bloquer le panier, le tunnel de commande, les comptes clients, la recherche interne et surtout les combinaisons de filtres et de tris qui ne correspondent à aucune recherche. Google recommande d’ailleurs cette méthode pour les pages filtrées inutiles en recherche, plutôt que de compter sur les balises canonical.

Site WordPress. WordPress génère un fichier virtuel par défaut, que les extensions SEO permettent de modifier. Vérifiez qu’il ne bloque pas les dossiers contenant les feuilles de style, les scripts ou les images nécessaires à l’affichage. Je détaille les autres réglages dans ma page sur le SEO WordPress.

Site multilingue ou multi-domaines. Chaque domaine et chaque sous-domaine a son fichier, qui doit déclarer son propre sitemap. Les erreurs viennent souvent d’un fichier copié d’un domaine à l’autre sans adaptation.

Le robots.txt et les robots des IA

Chaque éditeur d’IA utilise ses propres robots, souvent plusieurs : un pour la recherche et les citations, un pour l’entraînement des modèles, un pour les visites déclenchées par un utilisateur. Le robots.txt permet de les autoriser ou de les bloquer séparément. Bloquer un robot d’entraînement n’a pas le même effet que bloquer un robot de recherche, qui conditionne la présence dans les réponses. Je détaille les noms et les rôles de ces robots dans ma page sur les crawlers IA.

Vérifier son fichier

Ouvrez l’adresse /robots.txt de votre site dans un navigateur : le fichier doit s’afficher en texte brut et répondre normalement. Dans la Search Console, le rapport consacré au robots.txt indique la version lue par Google, la date de la dernière lecture et les éventuelles erreurs. L’outil d’inspection d’URL permet de vérifier si une page précise est bloquée.

Pour une vérification plus complète, lancez un crawl du site avec un outil qui respecte le robots.txt, puis un second en l’ignorant. Les pages présentes dans le second mais absentes du premier sont celles que votre fichier bloque. Parcourez cette liste : chaque page importante qui s’y trouve est une erreur à corriger, et chaque page inutile qui n’y figure pas est une règle à ajouter.

Testez systématiquement le fichier après une mise en ligne, une refonte, un changement d’hébergeur ou l’installation d’une extension de sécurité : ce sont les moments où les erreurs apparaissent.

Les cas particuliers

Les sous-domaines. Chaque sous-domaine a son propre fichier : celui de www.exemple.fr ne s’applique pas à boutique.exemple.fr.

Les ressources CSS et JavaScript. Ne les bloquez pas : Google en a besoin pour afficher les pages comme un visiteur.

Les erreurs serveur. Si le fichier répond par une erreur serveur de façon persistante, Google peut cesser de parcourir le site. Un fichier absent (erreur 404) est traité comme l’absence de restriction.

Les sites de préproduction. Un fichier « Disallow: / » protège mal un site de test : mieux vaut un mot de passe. Et surtout, ce fichier ne doit jamais partir en production avec le site.

Les erreurs fréquentes

« Disallow: / » oublié en production. Le site entier est bloqué.

Bloquer une page pour la désindexer. Elle reste dans les résultats, sans description.

Bloquer les fichiers CSS ou JavaScript. Google voit une page mal affichée.

Une erreur de casse ou de barre oblique. « Disallow: /Admin » ne bloque pas « /admin ».

Bloquer tous les robots d’IA par réflexe. Le site disparaît aussi des réponses avec citations.

Compter sur crawl-delay pour ralentir Google. La directive est ignorée par Google.

Documenter et contrôler les modifications

Le robots.txt est souvent modifié par plusieurs personnes : le développeur, l’agence, une extension installée par quelqu’un d’autre. C’est ce qui rend les erreurs fréquentes et difficiles à retracer. Je recommande de désigner une personne responsable du fichier, de noter chaque modification avec sa date et sa raison, et de vérifier systématiquement le fichier en production après toute mise en ligne.

Avant d’ajouter une règle, posez-vous deux questions. Quelles adresses exactes cette règle va-t-elle bloquer, y compris celles que vous n’aviez pas en tête ? Et une page bloquée par cette règle aurait-elle dû apparaître dans les résultats ? Si vous hésitez sur la seconde, la règle n’est probablement pas la bonne solution.

Exemple fictif : une boutique de cosmétiques

Pour illustrer, un cas inventé. Une boutique de cosmétiques veut retirer de Google ses anciennes pages de promotions et les bloque dans le robots.txt. Trois mois plus tard, elles apparaissent toujours dans les résultats, sans description. Elle retire le blocage, ajoute une balise noindex sur ces pages, attend qu’elles disparaissent de l’index, puis les supprime avec une redirection vers la page des offres en cours. Les éléments de cet exemple sont inventés pour l’illustration.

Questions fréquentes sur le robots.txt