Robots.txt avec Screaming Frog
auditer et tester tes directives

Le robots.txt contrôle ce que les moteurs explorent. Screaming Frog te permet de vérifier quelles pages sont bloquées, de tester des modifications avec un robots.txt personnalisé, et de corriger avant tout déploiement.

Le piège, c’est qu’une directive Disallow bloque le crawl mais pas toujours l’indexation. Comprendre cette nuance évite les erreurs les plus coûteuses.

À quoi sert le fichier robots.txt

Le fichier robots.txt est un simple fichier texte placé à la racine de ton site. Il donne des instructions aux robots des moteurs de recherche sur les zones qu’ils peuvent ou ne peuvent pas explorer. C’est la première chose que Googlebot consulte en arrivant sur un site. Une directive Disallow lui dit de ne pas crawler un répertoire ou une page ; une directive Allow lui autorise l’accès à une zone sinon bloquée.

Son rôle est d’optimiser le budget de crawl en empêchant les robots d’explorer des zones inutiles : espace d’administration, pages de résultats de recherche interne, paramètres de filtre, fichiers techniques. Bien utilisé, il concentre l’attention des moteurs sur les pages qui comptent vraiment. Mal utilisé, il peut bloquer par erreur des pages stratégiques, voire tout un site, avec des conséquences dramatiques sur le trafic.

C’est justement parce qu’une erreur de robots.txt coûte cher qu’il faut l’auditer avec rigueur. Cette page complète ma méthode de configuration du crawl avec Screaming Frog, car le respect ou non du robots.txt est l’un des réglages fondamentaux de toute exploration. Vérifier tes directives, c’est vérifier ce que Google a le droit de voir.

La nuance cruciale : bloquer le crawl n’empêche pas l’indexation

Voici l’erreur la plus répandue sur le robots.txt, celle qui piège même des référenceurs expérimentés. Une directive Disallow empêche Googlebot de crawler une page, mais elle ne l’empêche pas forcément de l’indexer. Si d’autres sites font des liens vers cette page bloquée, Google peut l’indexer quand même, sans en connaître le contenu, et l’afficher dans les résultats avec une description vide du type page bloquée par le fichier robots.txt.

Pour empêcher réellement l’indexation d’une page, il ne faut pas la bloquer dans le robots.txt : il faut au contraire laisser Google la crawler et y placer une balise meta robots noindex. Le moteur lit alors la directive noindex et retire la page de son index. Bloquer une page dans le robots.txt empêche justement Google de voir cette balise noindex, ce qui produit l’effet inverse de celui recherché.

Cette confusion entre blocage de crawl et blocage d’indexation est la source de nombreux problèmes. Screaming Frog t’aide à les démêler en croisant les deux informations : quelles pages sont bloquées par le robots.txt, et quelles pages portent une directive noindex. Voir les deux côte à côte révèle immédiatement les incohérences de configuration.

Voir les pages bloquées par le robots.txt

Lorsque tu lances un crawl avec Screaming Frog en respectant le robots.txt (le comportement par défaut), l’outil t’indique clairement quelles URLs sont bloquées. Rends-toi dans l’onglet Response Codes et applique le filtre Blocked by Robots.txt. Tu obtiens la liste exhaustive des pages que ton robots.txt empêche d’explorer. C’est le point de départ de tout audit : voir concrètement ce qui est bloqué.

Passe ensuite cette liste en revue avec un œil critique. Chaque page bloquée est-elle réellement censée l’être ? Il n’est pas rare de découvrir qu’une directive Disallow trop large bloque, en plus des pages visées, des pages stratégiques qui devraient être indexables. Une seule ligne mal écrite peut ainsi rendre invisible une catégorie entière de produits ou d’articles, sans que personne ne s’en aperçoive avant une chute de trafic.

• ✓Filtrer Response Codes sur Blocked by Robots.txt
• ✓Vérifier qu’aucune page stratégique n’est bloquée par erreur
• ✓Croiser avec la colonne Indexability pour repérer les incohérences
• ✗Ne jamais bloquer dans robots.txt une page qu’on veut désindexer
• ✓Vérifier que les fichiers CSS et JS ne sont pas bloqués

Le testeur de robots.txt personnalisé : tester sans risque

La fonctionnalité la plus précieuse de Screaming Frog sur ce sujet, c’est le testeur de robots.txt personnalisé. Il te permet de modifier virtuellement le contenu de ton robots.txt à l’intérieur de l’outil, puis de crawler ton site en appliquant cette version modifiée, sans jamais toucher au fichier réel en production. Tu vois immédiatement l’effet de tes changements avant de les déployer pour de vrai.

Tu accèdes à cette fonction via la configuration, section Robots.txt, en choisissant l’option Custom. Colle-y ton robots.txt actuel, puis modifie une directive : ajoute un Disallow, retire un blocage, ajuste un Allow. Relance le crawl et compare le résultat. Les pages qui étaient bloquées et qui ne le sont plus, ou l’inverse, apparaissent clairement. C’est un bac à sable qui élimine tout risque.

Cette approche est particulièrement précieuse avant une refonte ou un changement de structure. Tu peux valider ton futur robots.txt sur le site réel, vérifier qu’il bloque bien ce qu’il doit bloquer et rien d’autre, puis déployer en toute confiance. Tester avant de déployer devrait être un réflexe systématique sur ce fichier où la moindre erreur se paie cher en trafic perdu.

Ne jamais bloquer les ressources CSS et JavaScript

Une erreur historique, encore fréquente, consiste à bloquer dans le robots.txt les répertoires contenant les fichiers CSS et JavaScript du site. L’intention semble logique : ce ne sont pas des pages, pourquoi laisser Google les crawler ? Le problème, c’est que Google a besoin de ces fichiers pour afficher et comprendre tes pages exactement comme le fait un navigateur. Sans eux, il voit un site cassé, sans mise en forme ni interactivité.

Depuis que Google rend les pages avant de les évaluer, bloquer le CSS et le JavaScript l’empêche de voir la version réelle de ton site. Il peut alors conclure à tort que ton site n’est pas adapté au mobile, ou passer à côté de contenu injecté par JavaScript. C’est une erreur silencieuse qui pénalise le référencement sans laisser de trace évidente dans les rapports classiques.

Screaming Frog te permet de détecter ce problème en filtrant les ressources bloquées dans l’onglet Response Codes. Si tu vois des fichiers en .css ou .js dans la liste Blocked by Robots.txt, c’est un signal d’alerte immédiat. La correction consiste à retirer la directive Disallow qui bloque ces répertoires, pour que Google puisse rendre tes pages fidèlement, comme un vrai visiteur.

Vérifier la référence au sitemap

Le fichier robots.txt a une seconde fonction souvent oubliée : il peut indiquer aux moteurs l’emplacement de ton sitemap XML. Une simple ligne Sitemap suivie de l’URL complète de ton plan de site aide les robots à découvrir toutes tes pages plus rapidement. C’est un petit ajout qui facilite l’exploration, surtout sur les gros sites ou les sites récents encore peu liés depuis l’extérieur.

Quand tu audites un robots.txt avec Screaming Frog, prends l’habitude de vérifier la présence de cette ligne Sitemap et l’exactitude de l’URL qu’elle pointe. Une référence vers un sitemap obsolète, déplacé ou renvoyant une erreur est un défaut fréquent après une migration. L’outil te permet de crawler directement le sitemap pointé pour vérifier qu’il existe et qu’il liste bien les bonnes URLs.

Cette vérification croise deux sujets essentiels de l’exploration : le robots.txt qui autorise ou bloque, et le sitemap qui guide. Un site bien tenu présente un robots.txt cohérent, une référence sitemap valide, et aucune contradiction entre les pages listées dans le sitemap et les pages bloquées par le robots.txt. Ces incohérences, Screaming Frog les repère instantanément en croisant les deux sources.

Les erreurs de robots.txt les plus coûteuses

Au fil de mes audits, certaines erreurs de robots.txt reviennent tellement souvent qu’elles méritent une vigilance particulière. La plus catastrophique est un Disallow sur la racine du site, qui bloque l’intégralité des pages aux moteurs. Elle survient typiquement quand un site de préproduction, volontairement bloqué, est mis en ligne sans que le robots.txt ne soit corrigé. Résultat : le site disparaît des résultats en quelques jours.

D’autres erreurs plus subtiles sont tout aussi pénalisantes. Un Disallow trop large qui attrape des pages stratégiques, une directive contradictoire entre plusieurs blocs User-Agent, une syntaxe incorrecte ignorée par les moteurs. Le tableau suivant résume les erreurs que je rencontre le plus souvent et la façon de les détecter avec Screaming Frog.

Balayez le tableau sur mobile.

Ma routine d’audit du robots.txt

Face à un nouveau site, je suis toujours la même séquence pour auditer le robots.txt. Je commence par crawler en respectant le fichier réel, puis je filtre l’onglet Response Codes sur Blocked by Robots.txt pour voir tout ce qui est bloqué. Je passe cette liste en revue en cherchant les pages stratégiques prises à tort dans un Disallow, et les fichiers CSS ou JavaScript bloqués par erreur.

Ensuite, je croise avec la colonne Indexability pour repérer les pages à la fois bloquées et censées être désindexées, ce qui révèle les confusions entre crawl et indexation. Je vérifie la ligne Sitemap et l’URL qu’elle pointe. Enfin, si des corrections sont nécessaires, je les teste d’abord avec le robots.txt personnalisé avant de recommander tout déploiement en production.

Cette routine prend quelques minutes mais elle évite les catastrophes silencieuses les plus coûteuses du SEO technique. Un robots.txt mal configuré ne déclenche aucune alerte visible : le site fonctionne, les visiteurs naviguent normalement, et pourtant les moteurs ne voient qu’une partie du site, ou pire, rien du tout. Auditer ce fichier régulièrement fait partie des réflexes de base d’un référencement sain.

Robots.txt et directives meta : la vue d’ensemble

Le robots.txt n’est qu’une partie du contrôle d’exploration et d’indexation. Il faut le lire en complément des directives meta robots présentes dans le code de chaque page, comme noindex et nofollow, et de l’en-tête HTTP X-Robots-Tag. Screaming Frog rassemble toutes ces informations dans une vue unifiée, ce qui permet de comprendre le comportement réel d’indexation de chaque URL, au-delà du seul robots.txt.

L’onglet Directives de l’outil affiche pour chaque page les directives meta robots qu’elle porte. Tu peux ainsi repérer les pages en noindex, celles en nofollow, et surtout les incohérences : une page bloquée par le robots.txt qui porterait par ailleurs un noindex inutile, ou au contraire une page qu’on croit désindexée mais qui reste parfaitement indexable. Croiser le robots.txt et les directives meta évite ces contradictions silencieuses.

La colonne Indexability résume tout cela d’un mot : elle indique si une page est indexable ou non, et pour quelle raison si elle ne l’est pas. C’est un point de départ idéal pour vérifier que ton site expose exactement ce qu’il doit exposer aux moteurs. Aucune page stratégique en non-indexable par erreur, aucune page technique en indexable par oubli. Cette vue d’ensemble est l’un des grands atouts de l’outil sur ce sujet.

Simuler différents robots avec le User-Agent

Un point souvent ignoré : le robots.txt peut définir des règles différentes selon le robot qui se présente. Un bloc peut s’adresser à Googlebot, un autre à Bingbot, un autre à tous les robots. Une directive visée pour un robot précis peut bloquer une zone pour Google tout en la laissant ouverte à Bing, ou l’inverse. Vérifier ces règles différenciées demande de crawler en simulant chaque robot.

C’est là que se combinent deux fonctions de Screaming Frog : le respect du robots.txt et le choix du User-Agent. En crawlant successivement en te faisant passer pour Googlebot puis pour un autre robot, tu vérifies que les directives s’appliquent comme prévu à chacun. C’est un contrôle pointu, mais indispensable sur les sites qui appliquent des règles spécifiques par moteur, une pratique plus fréquente qu’on ne l’imagine.

Cette vérification par robot évite les mauvaises surprises où une zone censée être ouverte à Google se retrouve bloquée par une règle mal ciblée. Sur la plupart des sites, un seul bloc s’adressant à tous les robots suffit et simplifie la gestion. Mais dès qu’un robots.txt se complexifie avec des règles par moteur, tester chaque User-Agent avec Screaming Frog devient le seul moyen fiable de valider le comportement réel du fichier.

Documenter et versionner ton robots.txt

Le robots.txt est un fichier critique dont chaque modification peut avoir des conséquences majeures. Pourtant, sur beaucoup de sites, il est modifié à la volée, sans trace ni documentation, ce qui rend impossible de savoir qui a changé quoi et pourquoi. Adopter une discipline de documentation et de versionnement sur ce fichier fait partie des bonnes pratiques que je recommande systématiquement.

Concrètement, chaque directive du robots.txt devrait être commentée pour expliquer sa raison d’être. Une ligne Disallow sans commentaire est une bombe à retardement : dans six mois, personne ne se souviendra pourquoi elle est là, et on hésitera à la retirer de peur de casser quelque chose. Un robots.txt bien documenté, où chaque règle est justifiée, se maintient et évolue sereinement.

Le testeur de robots.txt personnalisé de Screaming Frog s’intègre parfaitement dans cette discipline. Avant toute modification en production, tu testes la nouvelle version dans l’outil, tu valides son effet sur le crawl, tu documentes le changement, puis seulement tu déploies. Ce processus rigoureux transforme un fichier dangereux en un actif maîtrisé, où chaque évolution est testée et tracée, sans jamais laisser place à l’improvisation risquée.

Robots.txt et budget de crawl sur les gros sites

Sur un petit site, le robots.txt joue un rôle marginal : Google explore tout sans effort. Sur un gros site de plusieurs dizaines de milliers d’URLs, il devient un levier stratégique de gestion du budget de crawl. Chaque répertoire inutile que tu bloques, chaque zone à faible valeur que tu écartes, c’est du budget réorienté vers les pages qui comptent vraiment pour ton référencement.

Screaming Frog t’aide à repérer les zones qui gaspillent ce budget. En croisant les URLs crawlées avec les logs serveur, tu vois où Googlebot passe le plus de temps. Si le robot explore massivement des pages de filtre, des résultats de recherche interne ou des variantes paramétrées sans valeur, il y a là un chantier de blocage à mener via le robots.txt, pour concentrer l’exploration sur le contenu utile.

Attention toutefois : bloquer au robots.txt empêche l’exploration mais pas toujours l’indexation. Une URL bloquée mais liée depuis l’extérieur peut apparaître dans les résultats sans description. Pour désindexer vraiment une page, la balise meta noindex reste plus sûre, à condition que la page soit crawlable. Bien articuler robots.txt et noindex selon l’objectif est un point que j’explique systématiquement à mes clients pour éviter les contresens.

Les erreurs de robots.txt qui coûtent le plus cher

Certaines erreurs de robots.txt sont catastrophiques parce qu’elles passent inaperçues. La plus redoutée reste le blocage total hérité d’un environnement de pré-production. Lors d’une mise en ligne, on oublie de retirer la ligne qui interdisait tout aux robots, et le site production reste invisible pendant des semaines. Le trafic organique s’effondre sans explication apparente, jusqu’à ce qu’on pense à vérifier ce fichier.

Screaming Frog détecte immédiatement ce cas : dès le lancement du crawl, l’outil signale qu’il est bloqué par le robots.txt et ne remonte quasiment aucune URL. C’est un signal d’alarme que tout auditeur doit connaître. Un crawl qui s’arrête aussitôt, avec un message de blocage, doit toujours déclencher une vérification manuelle du fichier avant de conclure quoi que ce soit sur le site.

D’autres erreurs sont plus subtiles : un caractère mal placé, un chemin trop large qui bloque plus que prévu, une casse incorrecte sur un répertoire. Ces fautes ne bloquent pas tout le site mais amputent silencieusement une section entière. Tester chaque directive avec l’outil de test intégré de Screaming Frog, URL par URL, est la seule façon de garantir que le fichier fait exactement ce que tu crois qu’il fait, ni plus ni moins.

Le sitemap XML, complément du robots.txt

Robots.txt et sitemap XML forment un couple indéissociable dans la communication avec les moteurs. Le premier dit ce qu’il ne faut pas explorer, le second indique ce qu’il faut absolument découvrir et indexer. Une bonne pratique consiste à déclarer l’emplacement du sitemap directement dans le robots.txt, via la directive Sitemap, pour que les robots le trouvent immédiatement dès leur première visite.

Screaming Frog permet de crawler un sitemap XML en mode List et de vérifier sa cohérence. Toutes les URLs qu’il contient doivent être indexables : pas de 404, pas de redirection, pas de noindex, pas de blocage robots.txt. Une URL bloquée au robots.txt mais présente dans le sitemap envoie un signal contradictoire à Google, exactement le genre d’incohérence que l’outil met en lumière en quelques secondes.

Je vérifie toujours que le sitemap et le robots.txt racontent la même histoire. Ce qui est bloqué ne doit jamais figurer dans le sitemap, et ce qui est dans le sitemap doit être pleinement accessible. Cette cohérence entre les deux fichiers est un marqueur de site techniquement soigné, et Screaming Frog reste l’outil le plus simple pour la contrôler en croisant les deux sources.

Un dernier réflexe utile : re-crawler le robots.txt après chaque mise en production. Trop de régressions viennent d’un déploiement qui écrase silencieusement le fichier par une version de test. Intégrer ce contrôle à ta checklist de mise en ligne, au même titre que la vérification des balises noindex, évite le scénario catastrophe du site rendu invisible sans que personne ne s’en aperçoive avant des semaines.

Le robots.txt est un fichier minuscule au pouvoir immense : une seule ligne peut rendre tout un site invisible aux moteurs. Screaming Frog est l’outil idéal pour l’auditer, grâce au filtre Blocked by Robots.txt qui révèle les pages bloquées, et surtout grâce au testeur de robots.txt personnalisé qui permet de valider des modifications sans jamais toucher à la production.

Mon conseil pour démarrer : crawle ton site en respectant le robots.txt, filtre sur Blocked by Robots.txt, et vérifie qu’aucune page stratégique ni aucun fichier CSS ou JavaScript n’est bloqué par erreur. Avant tout changement, teste-le d’abord avec le robots.txt personnalisé. Ce fichier ne pardonne pas l’improvisation.