"Bloquée par le fichier robots.txt" : erreur ou blocage voulu ? (Search Console)
Dans le rapport « Indexation des pages » de la Google Search Console, « Bloquée par le fichier robots.txt » ne déclenche en général aucune inquiétude. La plupart de ces URLs ont été écartées du crawl volontairement — pages d'administration, panier, filtres — et le rapport affiche précisément lesquelles. Le blocage joue son rôle.
Le sujet devient moins évident quand on y regarde de plus près. Comment repérer, dans une liste de centaines de blocages légitimes, la page stratégique attrapée par une règle Disallow trop large ? Pourquoi une URL interdite au crawl se retrouve-t-elle parfois indexée quand même ? Et bloquer une page dans le robots.txt suffit-il vraiment à la faire disparaître de Google ?
Trois questions simples en apparence, dont les réponses séparent les blocages sains des vrais problèmes.
Que signifie « Bloquée par le fichier robots.txt » ?
Ce statut signifie que Google a renoncé à explorer l'URL parce qu'une règle Disallow de votre fichier robots.txt le lui interdit. La page n'est donc ni crawlée, ni indexée : le blocage a fait exactement ce qu'on lui demandait. Dans la plupart des cas, ce n'est pas une erreur.
Concrètement, Googlebot a vu l'URL — souvent via un lien ou votre sitemap — mais ne l'a pas téléchargée : il s'est arrêté à la directive Disallow qui la couvre. La Search Console liste les URLs concernées, et l'inspection d'URL indique quelle ligne du robots.txt s'applique. Vous savez donc déjà ce qui est bloqué ; reste à trancher si ce blocage était voulu.
C'est le comportement normal d'un blocage volontaire. La question n'est donc jamais « comment faire disparaître ce statut », mais « ces pages avaient-elles vocation à être bloquées ? ».
Crawl bloqué n'est pas un jugement sur la page
Premier malentendu à lever : ce statut ne dit rien de la qualité de votre page. Google ne l'a pas lue. Il n'a pas comparé son contenu, pas évalué sa pertinence, pas décidé qu'elle ne méritait pas l'index. Il s'est arrêté à la porte, parce que votre robots.txt lui demandait de ne pas entrer.
C'est ce qui distingue ce statut des statuts de qualité comme « Explorée, actuellement non indexée », où Google a bel et bien lu la page avant de l'écarter. Ici, il n'y a pas de verdict : il y a une consigne que Google a suivie.
Conséquence pratique : si une page importante se retrouve dans ce statut, ce n'est jamais son contenu qu'il faut retoucher. C'est le blocage qu'il faut retirer.
Est-ce un problème ? Cela dépend de votre intention
Il n'y a pas de réponse unique. Tout dépend de ce que vous vouliez faire de la page. Deux cas, deux décisions opposées. Tant que vous n'avez pas tranché entre les deux, vous ne pouvez pas appliquer la bonne correction.
Cas A : le blocage est voulu, tout va bien. Pages d'administration, panier, tunnel de commande, comptes clients, résultats de recherche interne, pages de filtres et de tri à l'infini, environnement de préproduction… Vous les avez bloquées pour économiser le budget de crawl et garder ces URLs hors de Google. Les voir listées en « Bloquée par le fichier robots.txt » est exactement le résultat attendu. Il n'y a rien à corriger.
Cas B : une page utile est bloquée par erreur. Une page que vous vouliez voir dans Google se retrouve prise dans une règle Disallow trop large, ou dans un blocage hérité d'une préproduction jamais retiré. Tant qu'elle est bloquée, Google ne peut pas la crawler, donc ne l'indexera jamais correctement. Ici, l'objectif est l'inverse du cas A : retirer le blocage pour que Google puisse enfin lire la page.
Le tri entre A et B est tout le travail. Et avant de l'aborder, il faut lever une confusion qui fait perdre un temps fou.
« Bloquée » vs « Indexée malgré le blocage » : ne pas confondre
Deux statuts de la Search Console parlent de robots.txt et se confondent en permanence. La différence tient à une seule question : Google a-t-il fini par indexer l'URL malgré le blocage ?
| Statut GSC | Page crawlée ? | Page indexée ? | Ce que ça veut dire |
|---|---|---|---|
| Bloquée par le fichier robots.txt | Non | Non | Google respecte le blocage. La page n'apparaît pas dans les résultats. Le blocage a fonctionné. |
| Indexée malgré le blocage par robots.txt | Non | Oui | Google a découvert l'URL ailleurs (liens, sitemap) et l'a indexée sans la lire. Elle apparaît, souvent sans description. |
Le statut de cet article est le « propre » des deux : le blocage tient, la page reste hors de l'index. Si, à l'inverse, vos pages bloquées apparaissent quand même dans Google, vous êtes face à l'autre statut, qui demande une tout autre marche à suivre : on le détaille dans « Indexée malgré le blocage par robots.txt ».
Cette distinction éclaire un piège classique : robots.txt n'est pas un outil de désindexation. Bloquer l'exploration empêche Google de lire la page, pas forcément de la référencer s'il en entend parler ailleurs. Google le dit noir sur blanc : le robots.txt « n'est pas un mécanisme pour tenir une page web hors de Google ». Pour retirer une page de l'index, l'outil est la balise noindex, pas le robots.txt — et pour que Google voie ce noindex, la page ne doit justement pas être bloquée au crawl. (Un article dédié au statut « Exclue par la balise noindex » est à venir.)
Pourquoi une page utile se retrouve bloquée (cas B)
Quand une page que vous vouliez indexer tombe dans ce statut, la cause est presque toujours une règle robots.txt trop large ou oubliée. Les déclencheurs les plus fréquents :
- Une règle
Disallowtrop générale.Disallow: /blogbloque non seulement/blogmais tout ce qui commence par ce chemin, y compris/blog/mon-article-strategique. Un préfixe mal délimité emporte des pages que vous vouliez garder. - Un caractère générique mal maîtrisé. Les motifs avec
*(ex.Disallow: /*?) bloquent des familles entières d'URLs. Pratique pour les paramètres, dangereux quand le motif attrape des pages légitimes. - Un blocage hérité de la préproduction. Pendant le développement, le site est souvent protégé par un
Disallow: /global. Si cette ligne passe en production sans être retirée, tout le site se retrouve bloqué. - Un CMS ou un plugin mal réglé. Sur WordPress, l'option « Demander aux moteurs de recherche de ne pas indexer ce site » (Réglages → Lecture) ajoute un blocage global. Certains thèmes et extensions génèrent aussi leurs propres règles.
- Un mauvais chemin de ressources. Bloquer
/wp-content/ou un dossier d'assets peut empêcher Google de charger le CSS et le JavaScript nécessaires au rendu de la page.
Le fil rouge : quelque part dans votre robots.txt, une ligne dit « n'explore pas ces URLs » alors que vous vouliez l'inverse. Tout l'enjeu est de trouver laquelle, et sur quelles URLs elle frappe.
Maintenant que vous connaissez les causes, identifiez précisément quelles pages sont concernées — avant de décider quoi débloquer.
Identifier les pages concernées sur la liste que vous analysez
C'est là que la Search Console montre sa limite : son outil d'inspection d'URL ne traite qu'une seule URL à la fois. Pour savoir, page par page, laquelle est bloquée et par quelle règle, vous inspectez, vous lisez, vous passez à la suivante. Sur quelques pages, c'est jouable. Sur des centaines, vérifier qu'aucune page stratégique n'est piégée devient impraticable.
C'est le mur qu'IndexProbe fait sauter. IndexProbe est la version en masse de l'outil d'inspection d'URL de Google : il interroge l'API officielle de la Search Console pour inspecter, en une seule analyse, la liste d'URLs que vous lui fournissez (import CSV, sitemap, copier-coller). Pour chaque page, il affiche son statut d'indexation, son statut robots.txt (autorisée ou bloquée), le segment d'URL et les liens internes reçus.
Ce que vous en tirez dépend de la liste que vous apportez. IndexProbe n'explore pas votre site pour découvrir des URLs : il inspecte celles que vous lui donnez, et celles-là seulement.
- Une sélection de pages stratégiques (vos pages clés, votre sitemap des pages à indexer). Toute page importante qui ressort « Bloquée par le fichier robots.txt » est un cas B immédiat : une page que vous vouliez indexer, fermée au crawl par erreur. Vous la repérez sans rien présumer du reste du site.
- Un export complet de vos URLs (sitemap entier, export de crawl…). La segmentation par type de pages montre alors où le blocage se concentre — un coup d'œil suffit pour voir que l'admin, le panier et les facettes sont massivement bloqués (sain), tandis que les produits et le blog ne devraient presque jamais l'être.
C'est exactement le tri qu'IndexProbe est conçu pour rendre possible : séparer le blocage volontaire de la page utile piégée, sur toutes vos URLs d'un seul regard.
💡 Vous voulez savoir lesquelles de vos URLs sont bloquées par robots.txt, et si une page stratégique est prise au piège ? IndexProbe inspecte votre liste d'URLs et vous donne la réponse en une analyse. Tester IndexProbe en accès anticipé →
Corriger selon le cas
Une fois vos pages triées, la correction dépend du cas. Ne mélangez pas les deux : la bonne action pour une page utile est l'exact opposé de « ne touchez à rien ».
Faire crawler une page utile (cas B)
L'objectif est de retirer le blocage qui empêche Google de lire la page.
- Trouvez la règle exacte qui bloque l'URL. Dans la Search Console, l'inspection d'URL indique quelle ligne du
robots.txts'applique. Repérez la directiveDisallowresponsable. - Affinez ou retirez cette règle. Si elle est trop large (
Disallow: /blog), resserrez-la sur ce que vous vouliez réellement bloquer, ou ajoutez une exception (Allow:) pour la page à libérer. Si c'est un blocage hérité de préproduction (Disallow: /), supprimez-le. - Vérifiez qu'aucun
noindexne traîne sur la page : une fois débloquée, elle doit pouvoir être indexée. - Demandez une réinspection dans la Search Console, puis laissez à Google le temps de recrawler. Le statut ne change qu'au prochain passage de Googlebot.
Laisser ou affiner un blocage voulu (cas A)
Pour les pages que vous vouliez effectivement bloquer, il n'y a rien à corriger : le statut est le résultat attendu. Profitez-en simplement pour vérifier que vos règles ne sont ni trop larges (elles risqueraient d'attraper une page utile) ni trop étroites (elles laisseraient passer des URLs à blocage souhaité). Et rappelez-vous : si une de ces pages doit en plus disparaître de l'index parce qu'elle y a fuité, le robots.txt ne suffit pas — il faut un noindex, donc débloquer d'abord (voir « Indexée malgré le blocage »).
Selon votre CMS
- WordPress. Vérifiez d'abord Réglages → Lecture : la case « Demander aux moteurs de recherche de ne pas indexer ce site » ajoute un blocage global, à décocher en production. Pour éditer les règles, utilisez le
robots.txtvirtuel géré par Yoast SEO, Rank Math ou un fichier physique à la racine. - Shopify. Les règles par défaut bloquent
/cart,/checkout,/account(des pages qu'on ne veut effectivement pas indexer). Pour ajuster, éditez le fichierrobots.txt.liquiddu thème — avec prudence, en ne libérant que ce qui doit l'être.
« Bloquée » vs « Indexée malgré le blocage » vs « Exclue par noindex »
Trois statuts de la Search Console se ressemblent et se règlent très différemment. La grille de lecture :
| Statut GSC | D'où vient le blocage | Page indexée ? | Action |
|---|---|---|---|
| Bloquée par le fichier robots.txt | robots.txt (crawl interdit) |
Non | Rien si voulu ; débloquer si page utile piégée |
| Indexée malgré le blocage par robots.txt | robots.txt, mais URL trouvée ailleurs |
Oui | Débloquer puis noindex pour désindexer |
| Exclue par la balise 'noindex' | balise noindex dans la page |
Non | Rien si voulu ; retirer le noindex si page utile |
Les trois ont une logique différente : le premier bloque le crawl, le deuxième révèle que le blocage n'a pas suffi à tenir la page hors de l'index, le troisième est une exclusion volontaire au niveau de la page. Les confondre, c'est appliquer la mauvaise correction. (L'article « Exclue par la balise noindex » est à venir.)
Vérifier que la correction a fonctionné
Après avoir débloqué vos pages du cas B, confirmez à l'échelle que Google est repassé. Réinspectez vos URLs et comparez deux analyses dans le temps : les pages que vous avez libérées doivent quitter le statut « Bloquée par le fichier robots.txt », se faire crawler, puis basculer en indexées.
C'est la boucle complète : comprendre que le blocage est souvent normal, trier A/B, débloquer sans tomber dans le piège du noindex, vérifier.
Questions fréquentes
« Bloquée par le fichier robots.txt », est-ce grave ? Pas en soi. Dans la majorité des cas, c'est un blocage volontaire qui fonctionne : pages d'admin, panier, filtres… qu'on ne veut pas dans Google. Cela ne devient un problème que si une page que vous vouliez indexer se retrouve bloquée par erreur.
Pourquoi une de mes pages importantes est-elle bloquée ?
Presque toujours à cause d'une règle Disallow trop large, d'un motif générique mal réglé, ou d'un blocage hérité de préproduction. Inspectez l'URL dans la Search Console pour voir quelle ligne du robots.txt s'applique, puis affinez ou retirez cette règle.
Comment débloquer une page bloquée par robots.txt ?
Trouvez la règle Disallow responsable dans votre robots.txt, retirez-la ou resserrez-la (au besoin avec une directive Allow), vérifiez qu'aucun noindex ne traîne sur la page, puis demandez une réinspection dans la Search Console.
Faut-il utiliser robots.txt ou noindex ?
Cela dépend de l'objectif. Le robots.txt empêche le crawl (utile pour économiser le budget de crawl sur des pages sans intérêt). Le noindex empêche l'indexation (utile pour qu'une page n'apparaisse pas dans les résultats). Pour désindexer une page, il faut un noindex visible par Google, donc une page non bloquée au crawl.
Quelle différence avec « Indexée malgré le blocage par robots.txt » ? « Bloquée » signifie que la page n'est ni crawlée ni indexée : le blocage tient. « Indexée malgré le blocage » signifie que Google a indexé l'URL malgré la règle, parce qu'il l'a trouvée ailleurs. Le second demande une action ; le premier, le plus souvent non.
Comment vérifier ce statut sur un grand nombre d'URLs ?
L'inspecteur d'URL de la Search Console ne traite qu'une URL à la fois. Pour trier à l'échelle, un outil comme IndexProbe inspecte la liste d'URLs que vous lui fournissez (CSV, sitemap) et affiche, pour chacune, le statut d'indexation, le statut robots.txt et les liens internes reçus.
Arrêtez de deviner quelles pages sont bloquées pour de bon. IndexProbe se branche sur l'API officielle de la Search Console et inspecte votre liste d'URLs en une seule analyse : statut d'indexation, statut robots.txt et statut noindex côte à côte. Vous séparez en quelques minutes les blocages volontaires des pages utiles prises au piège, et vous vérifiez vos corrections d'une analyse à l'autre.