Robots.txt
Glossaire – Définition
Le fichier robots.txt est un fichier texte placé à la racine d’un domaine qui communique aux robots d’exploration (crawlers) quelles URLs ils sont autorisés ou non à parcourir, permettant de gérer le budget de crawl, de protéger certaines zones du site et de guider l’indexation sans pour autant constituer une barrière de sécurité absolue.
Le robots.txt repose sur le Robots Exclusion Protocol (REP), formalisé en 1994 par Martijn Koster et adopté par les principaux moteurs de recherche dès ses débuts. Son principe est simple : le crawler lit ce fichier avant d’explorer un site et adapte son comportement en fonction des instructions qu’il contient. Googlebot, Bingbot, et les crawlers de DuckDuckGo le respectent tous, mais aucune obligation légale ne les y contraint.
Un point que beaucoup de webmasters confondent : le robots.txt ne rend pas une page invisible à Google. Il empêche le crawler d’accéder au contenu, mais si des backlinks pointent vers une URL bloquée, Google peut tout de même l’indexer en se basant sur ces liens externes, sans jamais avoir crawlé la page. Pour retirer définitivement une URL de l’index, c’est la balise noindex qui fait le travail, pas le robots.txt.
Le fichier se génère automatiquement dans la plupart des CMS (WordPress via Yoast SEO ou Rank Math, Shopify, Wix), mais sa configuration par défaut couvre rarement les besoins d’un site avec une architecture complexe. Sur les sites de grande taille, un robots.txt mal configuré peut bloquer des pans entiers du contenu ou gaspiller le budget de crawl sur des pages sans valeur SEO.
Pour bien comprendre :
- Syntaxe et directives du fichier robots.txt
- Robots.txt et budget de crawl
- Les erreurs robots.txt qui coûtent des positions
- Les 5 directives robots.txt à maîtriser
- L’avis de l’expert B-Strong
- Questions fréquentes
Comment fonctionne et se structure le fichier robots.txt
Le robots.txt se compose de blocs appelés « records », chacun ciblant un ou plusieurs user-agents (robots). Chaque record commence par une ligne User-agent suivie des directives Disallow ou Allow. L’ordre des directives dans un record a son importance : Google applique la directive la plus spécifique en cas de conflit.
Exemple de fichier robots.txt avec plusieurs blocs :
User-agent: *
Disallow: /wp-admin/
Disallow: /panier/
Allow: /wp-admin/admin-ajax.php
User-agent: Googlebot-Image
Disallow: /images/privees/
Sitemap: https://www.monsite.com/sitemap.xmlLes quatre directives fondamentales et leur usage :
- User-agent : cible un robot spécifique (
Googlebot,Bingbot) ou tous les robots avec*. On peut créer autant de blocs que nécessaire pour différencier les instructions par crawler. - Disallow : indique les chemins que le robot ne doit pas explorer. Une valeur vide (
Disallow:) signifie « tout autoriser », ce qui est la valeur par défaut si aucune directive n’est présente. - Allow : autorise explicitement un chemin à l’intérieur d’un répertoire bloqué par Disallow. Pris en charge par Googlebot et Bingbot, pas par tous les crawlers.
- Sitemap : indique l’URL du ou des sitemaps XML. Google Search Console permet aussi de soumettre le sitemap directement, mais la déclaration dans le robots.txt reste une bonne pratique additionnelle.
Le fichier robots.txt est accessible publiquement à l’URL https://www.monsite.com/robots.txt. Il doit être encodé en UTF-8, sans BOM, avec des retours à la ligne Unix (LF). Un fichier mal encodé peut générer des erreurs de parsing que Google signale dans le rapport « robots.txt » de Google Search Console.
Robots.txt et optimisation du budget de crawl
Le budget de crawl désigne le nombre de pages qu’un moteur de recherche explore sur un site dans un délai donné. Googlebot l’ajuste en fonction de la taille du site, de sa popularité et de sa santé technique. Sur les sites de plus de 10 000 pages, l’optimisation du robots.txt a un impact direct mesurable sur la vitesse d’indexation des nouvelles pages.
Les pages à exclure du crawl via robots.txt pour préserver le budget sur les URLs utiles :
- Pages de résultats de recherche interne : elles génèrent des milliers d’URLs sans valeur SEO et peuvent saturer le crawl budget sur les gros sites e-commerce.
- URLs de session et de panier :
/panier/,/checkout/, paramètres de session comme?PHPSESSID=ou?session_id=. - Pages d’administration et de back-office :
/wp-admin/,/admin/, interfaces de gestion. - Pages de tests et de staging : si elles sont accessibles en production par erreur, elles consomment du budget et créent du contenu dupliqué.
- URLs de tri et de filtres redondants : celles qui ne génèrent pas de contenu unique et dont les équivalents canoniques sont déjà indexés.
Attention cependant : bloquer une URL dans robots.txt ne l’empêche pas d’apparaître dans les résultats de recherche si elle reçoit des liens entrants. Dans ce cas, Google affiche l’URL sans description (puisqu’il ne peut pas lire le contenu). Pour les pages qu’on veut à la fois non-crawlées et non-indexées, la solution passe par une redirection ou un header noindex servi avant que le crawler soit bloqué, car il ne peut pas lire un noindex sur une page qu’il ne crawle pas.
Les erreurs robots.txt qui fragilisent le référencement
La plus grave erreur robots.txt qu’on rencontre en audit est le blocage accidentel de l’ensemble du site, souvent causé par une règle trop large mise en place sur un environnement de staging puis déployée par erreur en production. Un simple Disallow: / sous User-agent: * coupe tout le crawl Googlebot en quelques heures.
- Blocage des ressources CSS et JavaScript : Google a besoin de crawler ces fichiers pour rendre les pages et évaluer leur expérience utilisateur. Les bloquer via robots.txt dégrade les Core Web Vitals perçus par le moteur.
- Incohérence robots.txt et sitemap : inclure dans le sitemap XML des URLs bloquées dans le robots.txt crée un signal contradictoire que Google signale comme erreur dans Search Console.
- Utilisation de Crawl-delay sur Googlebot : cette directive est reconnue par Bingbot et certains crawlers, mais Google l’ignore officiellement. Pour réduire la pression sur votre serveur, utilisez le réglage de vitesse de crawl dans Google Search Console.
- Caractères spéciaux non échappés : les URLs avec des caractères comme
?,=ou&dans les directives Disallow doivent suivre les règles d’encodage du Robots Exclusion Protocol. Une URL mal formée peut invalider toute la règle. - Confusion entre robots.txt et contrôle d’accès : le robots.txt est une convention, pas une protection. Un attaquant ou un crawler malveillant peut l’ignorer. Pour protéger des données sensibles, seule l’authentification côté serveur est fiable.
Selon une analyse de Semrush sur 800 000 sites (publiée en 2022), 46 % des sites présentaient au moins une erreur dans leur fichier robots.txt, et 12 % bloquaient involontairement des pages importantes pour leur référencement. Screaming Frog identifie ces conflits dès le début d’un audit technique.
Les 5 directives robots.txt à maîtriser
Ces cinq directives couvrent 95 % des configurations rencontrées en pratique. Les connaître permet d’éviter les erreurs les plus coûteuses et d’optimiser le crawl sans sur-bloquer.
| Directive | Rôle | Support | Priorité SEO |
|---|---|---|---|
| User-agent | Cible un ou tous les crawlers | Universel | Indispensable |
| Disallow | Bloque l’accès à un chemin | Universel | Critique |
| Allow | Autorise un sous-chemin dans un répertoire bloqué | Google, Bing | Haute |
| Sitemap | Déclare l’URL du sitemap XML | Google, Bing, Yandex | Haute |
| Crawl-delay | Délai entre deux requêtes du crawler | Bing, Yandex (pas Google) | Basse (GSC préférable) |
L’avis de l’expert B-Strong
Dans mes audits, le robots.txt est souvent le dernier fichier regardé et le premier à causer des problèmes majeurs. J’ai vu des sites perdre 30 % de leur trafic organique en 48 heures à cause d’un robots.txt de staging mis en production par erreur lors d’une migration. Le symptôme est net dans Google Search Console : le taux de pages crawlées s’effondre, les erreurs d’exploration explosent.
Ce que je recommande systématiquement à mes clients : surveiller le fichier robots.txt dans Google Search Console avec les alertes d’erreur activées, et verrouiller sa modification dans les processus de déploiement pour qu’aucune mise en production ne puisse l’écraser sans validation.
Sur les sites e-commerce de plus de 5 000 pages, j’analyse le rapport de couverture GSC en croisant les URLs bloquées par robots.txt avec celles qui reçoivent des liens internes. C’est souvent là qu’on trouve les pages bloquées par erreur qui auraient du potentiel organique. Un audit robots.txt sérieux prend 2 heures et peut débloquer des mois de crawl perdu.
Ce qu’on nous demande souvent
Peut-on bloquer une page dans robots.txt pour l’empêcher d’être indexée ?
Non, bloquer une URL dans robots.txt n’empêche pas son indexation. Si des liens externes pointent vers cette URL, Google peut l’indexer sans jamais l’avoir crawlée, en affichant la page sans description dans les résultats. Pour retirer une URL de l’index Google, la méthode correcte est la balise meta robots avec la valeur « noindex » dans le head de la page, ou l’en-tête HTTP X-Robots-Tag. Le robots.txt et le noindex servent deux objectifs différents et complémentaires.
Comment tester son fichier robots.txt avant de le mettre en ligne ?
Google Search Console intègre un outil de test du robots.txt accessible dans la section « Ancienne Search Console » sous « Exploration » puis « Testeur robots.txt ». Il permet de simuler le comportement de Googlebot sur n’importe quelle URL du site. En dehors de GSC, l’outil en ligne robots.txt Tester de Google (disponible via la documentation officielle) et Screaming Frog (en mode « Custom Extraction ») permettent de vérifier les règles avant déploiement. Après mise en ligne, l’outil d’inspection d’URL dans GSC confirme si une page est bloquée ou non.
Le fichier robots.txt est-il obligatoire pour le référencement ?
Non, le robots.txt n’est pas obligatoire. En son absence, les crawlers explorent le site sans restriction, ce qui est parfaitement acceptable pour les petits sites dont toutes les pages méritent d’être indexées. Il devient utile dès qu’un site génère des URLs sans valeur SEO (résultats de recherche interne, pages de tri, URLs de session) ou dès que le budget de crawl devient un enjeu, c’est-à-dire généralement à partir de quelques milliers de pages indexables.