"Indexée malgré le blocage par le fichier robots.txt" : que faire ?
Vous bloquez une page dans votre robots.txt pour la tenir à l'écart de Google. Et pourtant, dans la Search Console, elle s'affiche : « Indexée malgré le blocage par le fichier robots.txt ». Google l'a indexée quand même.
C'est déroutant, et le réflexe est souvent le pire : ajouter une balise noindex. On verra pourquoi, dans ce cas précis, cela ne change rien.
Ce statut n'est pas toujours un problème. Tout dépend de ce que vous vouliez faire de la page. Mais il révèle presque toujours un malentendu sur ce que robots.txt fait vraiment. On va le lever, voir les deux cas de figure, et surtout comment trier vos pages pour corriger chacune correctement.
Que signifie "Indexée malgré le blocage par le fichier robots.txt" ?
Ce statut signifie que Google a indexé votre URL sans jamais la crawler. Le fichier robots.txt bloque l'exploration, pas l'indexation : Google ne lit pas le contenu de la page, mais il en connaît l'existence et il l'a ajoutée à son index. Dans bien des cas, ce n'est pas une erreur.
C'est le point que presque tout le monde rate. Google l'écrit noir sur blanc dans sa documentation : « A robots.txt file tells search engine crawlers which URLs the crawler can access on your site… it is not a mechanism for keeping a web page out of Google. » Le robots.txt dit à Googlebot quoi explorer, pas quoi indexer.
Résultat : une page peut être interdite d'exploration et quand même apparaître dans les résultats, généralement sans description (Google n'a pas lu le contenu, il ne peut pas en extraire un extrait). D'où l'extrait vide ou le texte « Aucune information n'est disponible pour cette page ».
Pourquoi une page bloquée se retrouve-t-elle indexée ?
Parce que Google a trouvé l'URL ailleurs que sur la page elle-même. La cause la plus fréquente : des liens externes. Si d'autres sites pointent vers votre URL, Google la découvre, la juge digne d'intérêt, et l'indexe, même sans pouvoir la crawler. Un sitemap qui liste l'URL produit le même effet.
Là encore, c'est documenté : « A page that's disallowed in robots.txt can still be indexed if linked to from other sites. While Google won't crawl or index the content blocked by a robots.txt file, we might still find and index a disallowed URL if it is linked from other places on the web. »
Autrement dit, le blocage robots.txt empêche Google de lire la page, mais pas de la référencer s'il en entend parler par ailleurs. C'est exactement ce qui crée ce statut.
Est-ce un problème ? Ça dépend de ce que vous vouliez
Il n'y a pas de réponse unique : tout dépend de votre intention pour la page. Deux cas, deux décisions opposées. Tant que vous n'avez pas tranché entre les deux, vous ne pouvez pas corriger correctement.
Cas A : vous vouliez cette page privée. Pages de panier, de compte, de recherche interne, espace de préproduction… Vous l'aviez bloquée pour la cacher, et elle fuite quand même dans Google, avec un extrait vide qui fait mauvais effet. Là, l'objectif est de la sortir de l'index pour de bon.
Cas B : vous vouliez cette page indexée. Une page utile s'est retrouvée bloquée par erreur (une règle Disallow trop large, un blocage hérité d'une préproduction jamais retiré). Elle est dans l'index, mais Google n'en lit pas le contenu, donc elle ne se positionnera jamais correctement. Ici, l'objectif est l'inverse : la débloquer pour que Google la crawle enfin.
Le tri entre A et B est le vrai travail. Et avant de corriger le cas A, il faut connaître un piège.
Le piège : poser un noindex ne suffit pas
Pour sortir une page de l'index, le bon outil est la balise noindex, pas le robots.txt. Mais il y a un piège : si la page reste bloquée par robots.txt, Google ne verra jamais votre noindex. Il faut d'abord autoriser le crawl, sinon votre instruction reste lettre morte.
C'est l'erreur la plus courante sur ce statut, et Google la décrit précisément dans sa doc sur le noindex : « For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file… If the page is blocked by a robots.txt file or the crawler can't access the page, the crawler will never see the noindex rule, and the page can still appear in search results. »
La logique est implacable : le robots.txt empêche Google de lire la page ; or le noindex est dans la page. Tant que le blocage est là, Google ne peut pas voir l'instruction qu'il est censé suivre. Vous ajoutez un noindex, vous attendez, et rien ne se passe.
La marche à suivre correcte pour désindexer (cas A) est donc contre-intuitive :
- Retirez la règle
Disallowdu robots.txt (oui, vous débloquez la page). - Ajoutez le
noindex, soit en balise meta<meta name="robots" content="noindex">, soit en en-tête HTTPX-Robots-Tag: noindex(les deux ont le même effet). - Laissez Google recrawler la page, voir le noindex, et la retirer de l'index.
- Une fois désindexée, vous pouvez éventuellement re-bloquer dans robots.txt.
Pour les pages réellement sensibles, Google recommande aussi la protection par mot de passe, plus radicale qu'un noindex.
Reste la vraie difficulté : repérer, parmi vos pages, lesquelles sont dans ce statut et lesquelles ont un noindex qui ne sert à rien.
💡 Vous voulez savoir quelles URLs sont « indexées malgré le blocage » et si votre noindex est seulement visible par Google ? IndexProbe le montre en une analyse. Tester IndexProbe en accès anticipé →
Identifier les pages concernées sur la liste que vous analysez
C'est là que la Search Console atteint ses limites : elle vous fait inspecter les URLs une par une. Pour trier vite, il faut croiser, pour chaque URL, trois informations : son statut d'indexation, son statut robots.txt (autorisée ou bloquée) et son statut noindex. C'est exactement ce que fait IndexProbe, sur la liste d'URLs que vous lui fournissez (import CSV, sitemap, etc.), et sur celle-là seulement : il n'explore pas le site pour découvrir d'autres URLs.
Deux lectures, selon la liste que vous apportez :
- Une sélection de pages stratégiques (vos pages clés, votre sitemap). Vous vérifiez si l'une d'elles est « indexée malgré le blocage » : c'est le cas B, une page utile bloquée par erreur, à débloquer en priorité.
- Un export complet de vos URLs (sitemap entier, export de crawl). Là, vous voyez l'ensemble des pages bloquées-mais-indexées, et surtout vous pouvez croiser avec le statut noindex pour repérer les noindex inefficaces : une page avec un
noindexposé alors que robots.txt la bloque. Google ne le voit pas, la page reste indexée. C'est le piège de la section précédente, rendu visible d'un coup d'œil.
Ce croisement statut d'indexation × robots.txt × noindex, aucun autre outil ne le donne à l'échelle.
La GSC, elle, vous fait ouvrir chaque statut séparément et plafonne ses rapports à 1 000 URLs. C'est le mur qu'IndexProbe fait sauter, sur le périmètre que vous choisissez.
Corriger selon la branche
Une fois vos pages triées, la correction dépend du cas. Ne mélangez pas les deux : la bonne action pour une page privée est l'exact opposé de celle pour une page utile.
Sortir la page de l'index (cas A)
Suivez la marche à suivre vue plus haut : retirez le Disallow, posez un noindex, laissez Google recrawler, puis re-bloquez si vous le souhaitez une fois la page désindexée. Pour les pages très sensibles, préférez la protection par mot de passe. En cas d'urgence (donnée exposée), l'outil Suppressions de la Search Console masque la page sous quelques heures, le temps que la désindexation définitive opère.
Faire indexer la page (cas B)
C'est plus simple : retirez la règle Disallow qui bloque la page dans votre robots.txt, et assurez-vous qu'aucun noindex ne traîne dessus. Google pourra enfin la crawler, lire son contenu, et l'indexer correctement.
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 le noindex page par page, utilisez le champ dédié de Yoast SEO, Rank Math ou All in One SEO.
- Shopify. Le robots.txt de Shopify bloque par défaut
/cart,/account,/checkout,/orders(des pages qu'on ne veut effectivement pas indexer). Pour ajuster les règles, éditez le fichierrobots.txt.liquid; pour le noindex d'un modèle de page, passez par les balises du thème.
Différence avec "Bloquée par le fichier robots.txt"
On confond sans cesse ces deux statuts de la Search Console. La différence tient à une chose : 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 et n'indexe pas. La page n'apparaît pas dans les résultats. |
| Indexée malgré le blocage par le fichier 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 premier statut est le comportement « propre » d'un blocage volontaire (article sur « Bloquée par le fichier robots.txt » à venir). Le second signale que le blocage n'a pas suffi à tenir la page hors de l'index, et c'est précisément lui qui demande la marche à suivre de cet article.
Vérifier que la correction a fonctionné
Après vos corrections, confirmez à l'échelle. Réinspectez vos URLs et comparez deux analyses : les pages que vous vouliez sortir doivent quitter le statut « Indexée malgré le blocage » (et l'index), et les pages utiles que vous avez débloquées doivent passer en indexées normales.
C'est la boucle complète : comprendre, trier A/B, corriger sans tomber dans le piège du noindex, vérifier.
Questions fréquentes
« Indexée malgré le blocage par le fichier robots.txt », est-ce grave ? Pas forcément. Si la page n'avait pas vocation à être indexée et qu'elle n'expose rien de sensible, ce n'est qu'un extrait peu flatteur dans Google. Cela devient un problème dans deux cas : la page est privée et fuite dans les résultats, ou c'est une page utile bloquée par erreur qui ne se positionnera jamais tant qu'elle n'est pas crawlée.
Pourquoi une page bloquée par robots.txt est-elle quand même indexée ? Parce que le robots.txt bloque seulement l'exploration, pas l'indexation. Si Google découvre l'URL via des liens externes ou votre sitemap, il peut l'indexer sans en lire le contenu. C'est documenté par Google lui-même.
Comment désindexer une page bloquée par robots.txt ?
Contre-intuitif mais nécessaire : retirez d'abord le blocage du robots.txt, ajoutez un noindex (balise meta ou en-tête X-Robots-Tag), laissez Google recrawler la page pour qu'il voie le noindex, et attendez la désindexation. Si vous laissez le blocage, Google ne verra jamais votre noindex.
Pourquoi mon noindex ne fonctionne-t-il pas ?
Très probablement parce que la page est encore bloquée par robots.txt. Le noindex est dans le code de la page ; si Google ne peut pas la crawler, il ne peut pas le lire. Débloquez la page, et le noindex prendra effet au prochain passage.
Comment corriger sur WordPress ou Shopify ?
Sur WordPress, décochez « Demander aux moteurs de ne pas indexer » dans Réglages → Lecture, et gérez le noindex via Yoast ou Rank Math. Sur Shopify, ajustez les règles dans robots.txt.liquid ; les pages /cart, /account et /checkout sont bloquées par défaut, ce qui est normal.
Quelle différence avec « Bloquée par le fichier robots.txt » ? « Bloquée par le fichier robots.txt » signifie que la page n'est ni crawlée ni indexée : le blocage a fonctionné. « Indexée malgré le blocage » signifie que la page est indexée alors qu'elle est bloquée au crawl : Google l'a trouvée ailleurs. Le second demande une action, le premier souvent non.
Arrêtez de deviner quelles pages fuitent dans Google. IndexProbe se branche sur l'API officielle de la Search Console et inspecte votre liste d'URLs : statut d'indexation, statut robots.txt et statut noindex côte à côte. Vous repérez en quelques minutes les pages bloquées-mais-indexées, les noindex inefficaces, et vous vérifiez vos corrections d'une analyse à l'autre.