Guide : « Bloquée par le fichier robots.txt » dans GSC

TL;DR — « Bloquée par le fichier robots.txt » dans Search Console signifie que Google a trouvé la page sans la lire, car votre fichier robots.txt interdit son accès aux robots. C’est généralement intentionnel et normal : il s’agit du résultat attendu d’un blocage, pas d’une erreur. Le problème existe seulement si vous vouliez indexer la page.

Ce que cet état signifie

Ouvrez le rapport Indexation des pages de Google Search Console, puis la section « Bloquée par le fichier robots.txt » : elle répertorie les URL que Google n’a pas indexées. Google les a découvertes, mais le fichier robots.txt du site interdit aux robots de les récupérer. Evidence for this claim Google reports Blocked by robots.txt when crawling is disallowed and warns that this does not guarantee the URL cannot be indexed by other means. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report Ce libellé signale le blocage de l’exploration ; il ne garantit pas que d’autres signaux ne puissent jamais entraîner l’indexation de l’URL.

Premier conseil : ne paniquez pas. Le libellé source “Blocked by robots.txt,” (traduction) « Bloquée par le fichier robots.txt », décrit un état généralement intentionnel. Si vous, votre CMS ou une extension avez volontairement bloqué des résultats de recherche internes, des URL de navigation à facettes, un chemin de préproduction, un panier ou un paiement, leur présence ici est exactement le résultat attendu. Google confirme le fonctionnement du blocage ; il ne signale pas une erreur.

L’idée essentielle à retenir

robots.txt contrôle l’exploration, pas l’indexation. Ce sont deux opérations différentes. Bloquer une page dans robots.txt empêche Google de la lire ; cela ne la supprime pas Evidence for this claim Google says robots.txt manages crawler access and is not a mechanism for keeping a page out of Google. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: robots.txt introduction de Google et ne constitue pas une méthode de retrait des résultats. J’ai moi-même testé les effets d’un blocage, décrits dans l’onglet Advanced, mais le principe est simple : le blocage arrête l’exploration.

Is it a problem?

Run un vérifier: did vous mean to block ces URLs?

• Oui, volontairement → ne changez rien. Le système fonctionne comme prévu.
• Non, cette page doit figurer dans Google → corrigez ce seul cas. Repérez dans robots.txt la règle qui intercepte l’URL, retirez-la ou assouplissez-la, puis demandez l’indexation.

Un état connexe mais différent peut aussi apparaître : « Indexée malgré le blocage par le fichier robots.txt ». C’est un avertissement, pas une exclusion : Google a tout de même indexé une URL bloquée, généralement parce que d’autres pages pointent vers elle. Même cause, résultat opposé. Cet état fait l’objet d’un article distinct.

Autre limite : robots.txt ne protège pas la confidentialité. C’est une demande, pas un contrôle d’accès. Les robots coopératifs la respectent, mais rien ne les y oblige ni n’empêche l’URL d’apparaître ailleurs — lien, capture ou extracteur qui ignore robots.txt. Protégez tout contenu sensible par une connexion ou un mot de passe, pas par une interdiction.

The mistake to éviter

Beaucoup tentent de retirer une page de Google en la bloquant dans robots.txt, parfois avec une balise noindex supplémentaire. Cette combinaison échoue et se retourne contre eux : si Google ne peut pas explorer la page, il ne voit jamais noindex, et la page peut rester dans l’index. Pour la retirer, faites l’inverse : autorisez l’exploration et ajoutez noindex.

Pour repérer la règle exacte, comprendre le conflit noindex + disallow et consulter mon expérience, passez à l’onglet Advanced.

TL;DR — « Bloquée par le fichier robots.txt » est une exclusion du rapport Indexation des pages : Google a découvert l’URL sans l’explorer, car robots.txt l’interdit ; elle n’est donc pas indexée dans cet état. C’est normalement volontaire et bénin. robots.txt régit l’exploration, pas l’indexation : Disallow ne désindexe jamais. Ne confondez pas cette exclusion avec l’avertissement « Indexée malgré le blocage », où Google indexe tout de même l’URL grâce à des liens entrants. Erreur classique : associer disallow et noindex. Google ne peut alors pas lire noindex, et la page peut rester indexée. Pour retirer une page, autorisez l’exploration et servez noindex. Cet état n’est un bug que si l’URL devait être indexée.

Ce que the status en réalité reports

Dans le rapport Indexation des pages de Search Console, « Bloquée par le fichier robots.txt » est un état exclu, ni erreur ni avertissement. Google indique que la page “was blocked by your site’s robots.txt file,” (traduction) a été bloquée par le fichier robots.txt de votre site, avec cette réserve : “does not guarantee that the page won’t be indexed through some other means.” (traduction) cela ne garantit pas que la page ne sera pas indexée par un autre moyen. Evidence for this claim Google reports Blocked by robots.txt when crawling is disallowed and warns that this does not guarantee the URL cannot be indexed by other means. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: Page indexing report Cette réserve résume tout le sujet.

Concrètement, Googlebot connaît l’URL grâce à un lien, un sitemap ou son historique, rencontre une directive Disallow correspondante et s’arrête. Sans récupération, aucun contenu n’est disponible pour l’indexation : l’URL reste exclue. C’est le résultat attendu d’un blocage, et la plupart des URL de cette catégorie doivent y figurer.

Exploration n’est pas indexation — pourquoi a disallow doesn’t deindex

Google documents robots.txt as crawl-access contrôler, pas a reliable removal mechanism. Evidence for this claim Google says robots.txt manages crawler access and is not a mechanism for keeping a page out of Google. Scope: Google Search Console report terminology and documented Search behavior; the label alone may not prove the underlying root cause. Confidence: high · Verified: 2026-07-14 Google: robots.txt introduction

C’est le principe essentiel de cet état. robots.txt contrôle l’exploration. Google précise qu’il “is not a mechanism for keeping a web page out of Google.” (traduction) ne constitue pas un mécanisme permettant d’exclure une page Web de Google. Bloquer une URL empêche sa récupération ; cela ne la retire pas de l’index et ne la désindexe pas.

Comme je l’ai écrit dans mon article Ahrefs sur l’état connexe, “crawling and indexing are two different things.” (traduction) L’exploration et l’indexation sont deux opérations distinctes. Une page bloquée peut encore être indexée si d’autres pages pointent vers elle ; Google ne voit alors ni son contenu ni la balise noindex éventuelle. Cela conduit à l’erreur la plus fréquente de ce rapport.

« Bloquée par robots.txt » ou « Indexée malgré le blocage »

Ces deux états sont souvent confondus : ils ont la même cause, mais des résultats opposés.

Si vous voyez l’avertissement — une URL bloquée néanmoins indexée et affichée sans description — il s’agit du cas « indexée malgré le blocage », traité séparément. Cet article porte sur l’exclusion simple : bloquée et non indexée.

Pour les URL utilitaires, une indexation malgré le blocage est souvent sans gravité. À propos d’URL WooCommerce ?add-to-cart=, John Mueller a expliqué qu’elles n’avaient pas besoin d’être indexées, qu’un blocage robots.txt convenait et qu’elles avaient peu de chances d’apparaître, sauf requête très précise qu’aucun utilisateur réel ne lance.

Le conflit noindex + disallow : la correction qui se retourne contre vous

Voici le piège : pour retirer une page, quelqu’un la place sous Disallow dans robots.txt et ajoute une balise meta noindex, par précaution. Cela échoue parce que les deux instructions se contredisent.

Google énonce directement la règle : “For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file, and it has to be otherwise accessible to the crawler.” (traduction) Pour que noindex soit effectif, la page ou ressource ne doit pas être bloquée par robots.txt et doit rester accessible au robot. Si elle est interdite, Google ne l’explore pas, ne voit jamais noindex et peut la laisser indexée. Comme je l’explique dans mon article sur l’état connexe, Google peut encore l’indexer à partir de liens tant qu’il ne peut pas lire la balise.

La séquence de désindexation est donc l’inverse du réflexe habituel :

1. Autorisez l’exploration de l’URL en retirant Disallow.
2. Servez noindex dans une balise meta robots ou un en-tête X-Robots-Tag, puis laissez Google réexplorer la page pour le voir.
3. Une fois la page retirée, laissez-la explorable avec noindex. La rebloquer n’est pas une finition sûre : Google peut perdre de vue noindex, puis réindexer l’URL bloquée à partir de liens, exactement le résultat « indexée malgré le blocage » que vous vouliez éviter. Si le budget d’exploration pose réellement problème, utilisez l’authentification ou une suppression (404/410), pas un retour à robots.txt.

Pour un retrait urgent, l’outil Suppressions de Search Console, une protection par mot de passe ou la suppression de la page avec 404/410 sont plus rapides.

How to trouver qui rule is blocking l’URL

Three outils, chaque doing a différent job — don’t expect un to do the others’ fonctionner:

• Inspection d’URL (GSC). Collez l’URL précise pour savoir rapidement si elle est actuellement bloquée.
• Rapport robots.txt (GSC). Ce rapport de surveillance au niveau de la propriété de domaine — et non un testeur modifiable — affiche les fichiers trouvés pour les principaux hôtes, la dernière récupération, son état, les avertissements d’analyse et une action de réexploration après modification. Il ne teste pas chaque URL.
• Validateur robots.txt ou analyseur open source de Google. Pour connaître la ligne qui s’applique à une URL, utilisez un validateur : la règle correspondante la plus longue et précise l’emporte, et Allow peut supplanter un Disallow plus général.

Une fois la ligne fautive trouvée, la correction dépend de l’emplacement de robots.txt. Si vous contrôlez le fichier, retirez ou corrigez la règle en respectant la syntaxe. Sur Wix, Shopify, Squarespace ou une autre plateforme hébergée, suivez sa documentation : certaines gèrent le fichier pour vous.

My propre experiment: ce que se produit quand vous block une page vous wanted indexé

La question vraiment utile est l’effet d’un blocage accidentel sur une page destinée à se classer. Je l’ai testé directement : le 30 janvier 2023, j’ai bloqué avec robots.txt deux pages déjà classées — « Top Bing Searches » et « Top YouTube Searches » — puis suivi les résultats.

Les dommages étaient réels mais moindres que prévu. Quelques mots-clés ont perdu une ou deux positions, certains en ont gagné, mais toutes les featured snippets ont disparu pendant le blocage puis sont revenues après déblocage. Le résultat affichait « aucune information disponible pour cette page » à la place de la meta description et perdait les titres personnalisés. L’extrait étant moins attractif, les clics ont davantage baissé que les impressions : le CTR a subi l’essentiel du choc.

Mon résumé de l’époque : “We lost a position here or there and all of the featured snippets for the pages. I expected a lot more impact, but the world didn’t end.” (traduction) Nous avons perdu une position ici ou là et toutes les featured snippets ; j’attendais beaucoup plus d’impact, mais le monde ne s’est pas arrêté. Conclusion toujours valable : ne bloquez pas les pages à indexer. Cela fait mal, moins qu’on ne le pense, mais cela fait mal. Si la catégorie ne contient que des blocages voulus, tout va bien ; sinon, débloquez les pages importantes.

Limite de l’expérience : les deux pages étaient déjà classées et indexées. J’ai donc mesuré le passage d’une page indexée à l’état « indexée malgré le blocage », et non le sort d’une URL jamais indexée de cette catégorie d’exclusion. Débloquer une URL jamais indexée permet simplement à Google de l’explorer et de l’évaluer normalement ; elle ne possède aucun historique de featured snippet ou de CTR à perdre.

The decision tree

• Blocage volontaire ? → Ne changez rien.
• URL à indexer ? → Retirez ou assouplissez la règle robots.txt, puis demandez l’indexation.
• URL à retirer de Google ? → N’utilisez pas Disallow. Autorisez l’exploration, servez noindex ou utilisez Suppressions/supprimez la page, puis laissez-la explorable.
• URL bloquée néanmoins indexée ? → Traitez le cas connexe « indexée malgré le blocage ».
• Contenu sensible ou privé ? → robots.txt n’est pas un contrôle d’accès ; utilisez une authentification ou un mot de passe.

Le principe exploration/indexation est universel : Bing respecte lui aussi robots.txt pour l’exploration, et le retrait d’une URL utilise l’outil Bloquer des URL ou noindex sur une page explorable, pas un simple Disallow.

Pour la syntaxe, les jokers, l’emplacement et les limites du fichier, consultez le guide robots.txt. Pour les décisions d’indexation en amont, consultez le hub Indexation.

Résumé par l’IA

Une synthèse de la version avancée :

• « Bloquée par le fichier robots.txt » est une exclusion d’indexation. Google a découvert l’URL sans l’explorer parce que robots.txt l’interdit ; elle n’est donc pas indexée dans cet état. C’est le résultat normal d’un blocage généralement voulu.
• robots.txt contrôle l’exploration, pas l’indexation. Google précise : “it is not a mechanism for keeping a web page out of Google.” (traduction) Ce n’est pas un mécanisme permettant d’exclure une page Web de Google. Une interdiction empêche la récupération ; elle ne désindexe pas une page.
• Ne confondez pas cet état avec “Indexed, though blocked by robots.txt.” (traduction) « Indexée malgré le blocage par le fichier robots.txt ». La cause est identique, mais le résultat opposé : une URL bloquée a tout de même été indexée, généralement grâce à des liens entrants. Pour les URL utilitaires, cela est souvent sans conséquence dans les résultats ordinaires.
• Le piège principal est d’associer noindex et disallow. Google ne peut pas explorer une page interdite et ne voit donc jamais son noindex. Pour fonctionner, noindex doit se trouver sur une page non bloquée par robots.txt.
• Pour retirer réellement une page : autorisez l’exploration, servez noindex, laissez Google réexplorer la page, puis gardez-la explorable. La rebloquer peut masquer la directive et permettre son indexation via des liens. En urgence, utilisez l’outil Suppressions, une protection par mot de passe ou supprimez la page.
• Trouvez la règle bloquante avec l’Inspection d’URL et un validateur robots.txt : la règle correspondante la plus longue et précise l’emporte. Le rapport robots.txt de GSC surveille la récupération du fichier ; il ne teste pas chaque URL. La correction dépend ensuite de l’endroit où le fichier est géré.
• L’expérience de Patrick : le blocage de deux pages déjà indexées et bien classées a coûté quelques positions et tous leurs extraits optimisés ; les clics ont davantage baissé que les impressions. L’expérience décrit une page devenue « indexée malgré le blocage », pas une URL qui n’avait jamais été indexée.
• robots.txt n’est pas un dispositif de sécurité. Les robots peuvent ignorer cette demande. Protégez le contenu sensible par authentification, pas avec une interdiction.
• Règle de décision : blocage voulu → ne rien changer ; indexation voulue → débloquer et demander l’indexation ; retrait voulu → autoriser l’exploration et servir noindex.

Documentation officielle

Documentation de première main publiée par les moteurs de recherche.

Google

• Rapport Indexation des pages — le rapport qui définit “Blocked by robots.txt” (traduction) « Bloquée par le fichier robots.txt » et l’état connexe.
• Débloquer une page bloquée par robots.txt — la procédure de Google pour trouver et corriger la règle qui bloque une URL.
• Rapport robots.txt — le rapport indiquant les fichiers trouvés, leur état de récupération, les avertissements et la demande de réexploration.
• Présentation de robots.txt — ce que fait et ne fait pas robots.txt, notamment son incapacité à exclure à lui seul une page de Google.
• Bloquer l’indexation avec noindex — la règle selon laquelle noindex ne fonctionne que sur une page non bloquée par robots.txt.

Bing / Microsoft

• Aide de Bing Webmaster Tools — Bing respecte également robots.txt pour l’exploration ; ses outils suivent la même distinction entre exploration et indexation.

Citations de la source

Déclarations officielles de Google. Chaque lien mène directement au passage cité sur la page source.

Google — ce que signifie cet état

• “This page was blocked by your site’s robots.txt file. You can verify this using the robots.txt tester. Note that this does not guarantee that the page won’t be indexed through some other means.” (traduction) Cette page a été bloquée par le fichier robots.txt de votre site. Vous pouvez le vérifier avec le testeur robots.txt. Cela ne garantit pas que la page ne sera pas indexée par un autre moyen. — Aide Google Search Console, rapport Indexation des pages. Accéder à la citation

Google — robots.txt contrôle exploration, pas indexation

• “it is not a mechanism for keeping a web page out of Google.” (traduction) Ce n’est pas un mécanisme permettant d’exclure une page Web de Google. — Google Search Central, présentation de robots.txt. Accéder à la citation

Google — pourquoi noindex et Disallow sont incompatibles

• “For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file, and it has to be otherwise accessible to the crawler.” (traduction) Pour que la règle noindex soit efficace, la page ou la ressource ne doit pas être bloquée par un fichier robots.txt et doit rester accessible au robot d’exploration. — Google Search Central, bloquer l’indexation avec noindex. Accéder à la citation

Statistiques et données de première main à citer

• Le blocage de pages classées cause des dégâts réels, mais surmontables. Dans mon expérience commencée le 30 janvier 2023, deux pages déjà classées et indexées ont perdu quelques positions et tous leurs extraits optimisés. Le résultat affichait “no information is available for this page,” (traduction) aucune information n’est disponible pour cette page, et les clics ont davantage baissé que les impressions. Mon résumé était : “I expected a lot more impact, but the world didn’t end” (traduction) je m’attendais à un impact bien plus fort, mais le monde ne s’est pas arrêté ; néanmoins, ne bloquez pas les pages que vous voulez indexer. Cette expérience ne prédit pas le sort d’une URL qui n’a jamais été indexée. Source
• Les URL utilitaires bloquées puis indexées sont généralement sans danger. Selon John Mueller, bloquer dans robots.txt les URL de type ajout au panier convient ; même indexées malgré le blocage, elles apparaissent rarement pour des requêtes ordinaires. Coverage
• Fréquence du blocage robots.txt sur le Web — données sur les robots que près de 140 millions de sites interdisent le plus, issues de mon étude avec Xibeijia Guan. Source

L’erreur caractéristique : noindex avec Disallow

Erreur : associer Disallow et noindex pour tenter de retirer une page. L’état source “Blocked by robots.txt,” (traduction) « Bloquée par le fichier robots.txt », est souvent lié à cette erreur. Elle semble offrir une double protection, mais se retourne contre son objectif. Google énonce la règle clairement : “For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file, and it has to be otherwise accessible to the crawler.” (traduction) Pour que la règle noindex soit efficace, la page ou la ressource ne doit pas être bloquée par un fichier robots.txt et doit rester accessible au robot. Si la page est interdite, Google ne l’explore pas, ne voit jamais noindex et peut la laisser indexée. La correction suit la logique inverse : autorisez l’exploration, puis servez noindex.

Mythe : « Une interdiction dans robots.txt est un outil de désindexation. » C’est faux. Google précise que robots.txt “is not a mechanism for keeping a web page out of Google.” (traduction) Ce n’est pas un mécanisme permettant d’exclure une page Web de Google. Bloquer une URL arrête sa récupération sans la retirer de l’index. Une page bloquée mais liée peut encore apparaître. Pour un retrait, utilisez noindex sur une page explorable ou l’outil Suppressions.

Mythe : « Toutes les URL de cette catégorie sont des problèmes à corriger. » C’est généralement l’inverse. Cet état est le résultat attendu d’un blocage volontaire : résultats de recherche internes, paramètres de navigation à facettes ou chemins de préproduction. Seule une URL que vous vouliez indexer mérite d’être corrigée.

Erreur : bloquer une page à classer sans mesurer d’abord le coût. Bloquer une page importante pour « faire le ménage » ou économiser le budget d’exploration est risqué. Dans mon expérience, les deux pages ont perdu tous leurs extraits optimisés et les clics ont davantage baissé que les impressions, car le résultat affichait “no information is available for this page.” (traduction) aucune information n’est disponible pour cette page. Traitez ce blocage comme une vraie décision, pas comme une simple opération d’entretien.

Liste de contrôle pour « Bloquée par le fichier robots.txt »

Parcourez cette liste dans l’ordre lorsque vous ouvrez cet état dans Search Console :

• Ouvrez le rapport Indexation des pages, puis cette catégorie pour afficher la liste réelle des URL touchées.
• Pour chaque URL ou motif d’URL, demandez-vous : ce blocage était-il voulu ?
• Si oui — recherche interne, facettes, préproduction, panier ou paiement — ne changez rien. Cet état est le résultat attendu pour cette URL.
• Si non ou en cas de doute, utilisez Inspection d’URL pour confirmer que l’URL est actuellement bloquée et qu’il ne s’agit pas d’un ancien relevé.
• Trouvez la règle précise avec le testeur robots.txt ou un autre validateur. La règle correspondante la plus longue et précise l’emporte, et Allow peut supplanter un Disallow plus général.
• Vérifiez que vous ne comptez pas aussi sur noindex pour cette URL interdite : cette association ne fonctionne pas. Pour un retrait, autorisez l’exploration puis servez noindex.
• Retirez ou assouplissez la règle, directement si vous contrôlez robots.txt ou à l’aide de la documentation de votre plateforme, par exemple Wix, Shopify ou Squarespace.
• Demandez l’indexation de l’URL corrigée dans Search Console une fois le blocage levé.
• Vérifiez que vous ne confondez pas cet état avec « Indexée malgré le blocage par le fichier robots.txt », qui décrit le résultat opposé et exige une autre correction.
• Contrôlez de nouveau la catégorie quelques semaines plus tard pour vérifier la tendance attendue : baisse pour les URL corrigées, stabilité pour les blocages voulus.
• Si une URL contient des données sensibles, ne comptez pas sur l’interdiction pour la garder privée : ajoutez une authentification ou un mot de passe.

Suivre l’arbre de décision

Répondez à une question à la fois afin de choisir la bonne action pour une URL de cette catégorie.

Les modèles mentaux

1. Exploration ≠ indexation. Toute confusion disparaît lorsque ces notions restent distinctes. robots.txt contrôle l’exploration, c’est-à-dire la récupération d’une page par Googlebot. Il ne contrôle pas directement l’indexation. Une page interdite n’est pas indexée grâce à son contenu, mais peut encore l’être sans contenu si d’autres pages créent des liens vers elle.

2. Le tri en une question. Avant toute action, demandez-vous : ce blocage était-il voulu ? Oui : ne changez rien, tout fonctionne comme prévu. Non : c’est le cas à corriger. Cette seule question classe correctement presque toutes les URL de la catégorie.

3. Pour retirer une page, inversez le réflexe habituel. Associer une interdiction à noindex semble plus sûr, mais produit l’effet inverse. Google ne peut pas voir une directive sur une page qu’il ne récupère jamais. La bonne séquence est : autoriser l’exploration, puis servir noindex.

4. robots.txt gère le budget d’exploration, pas les résultats de recherche. Utilisez-le pour éloigner les robots des espaces d’URL sans valeur ou infinis, comme la recherche interne, les facettes et la préproduction. Pour agir sur les résultats, utilisez noindex, une protection par mot de passe ou la suppression.

Suivre le volume de la catégorie, pas seulement son existence

Le nombre à surveiller est celui des URL présentes dans cette ligne du rapport Indexation des pages au fil du temps. Un relevé isolé ne montre ni l’effet d’une correction ni l’apparition progressive de nouveaux blocages involontaires.

Nombre d’URL bloquées par robots.txt au fil du temps

• Mesure — Le nombre d’URL de cette catégorie dans le rapport Indexation des pages, suivi dans le temps.
• Ce qu’elle indique — Si la catégorie évolue comme prévu. Pour les URL bloquées volontairement, le nombre devrait rester assez stable ; une hausse soudaine révèle souvent qu’une nouvelle section correspond par erreur à un motif Disallow. Une URL débloquée pour être indexée devrait disparaître après l’exploration suivante.
• Où l’obtenir — Dans le rapport Indexation des pages de GSC, filtré sur cette ligne ; contrôlez quelques URL avec Inspection d’URL pour confirmer l’état actuel.
• Référence réaliste — Il n’existe aucune cible universelle. Le bon objectif est zéro URL bloquée que vous vouliez réellement indexer, et une tendance stable pour le reste. Établissez votre propre valeur de départ avant d’évaluer un changement.
• Fréquence — Vérifiez après chaque modification de robots.txt ; sinon, un contrôle mensuel suffit à la plupart des sites pour détecter une dérive.

Procédure : retirer réellement une page de Google

Une séquence reproductible lorsqu’une URL doit réellement sortir de l’index de Google, et pas seulement être bloquée lors des explorations futures.

1. Confirmez que l’objectif est le retrait, pas seulement le contrôle de l’exploration. Si vous voulez uniquement économiser le budget d’exploration, une interdiction dans robots.txt convient et cette procédure ne s’applique pas. Utilisez-la seulement si la page doit réellement quitter l’index.

2. Autorisez l’exploration. Retirez ou assouplissez la règle Disallow qui bloque l’URL. Vérifiez avec le testeur robots.txt que l’URL est désormais autorisée.

3. Servez noindex. Ajoutez une balise meta robots noindex ou un en-tête HTTP X-Robots-Tag à la page maintenant explorable. C’est la véritable instruction de retrait.

4. Laissez Google réexplorer la page. Google doit récupérer la page pour voir noindex. Hormis une demande dans Search Console, vous ne pouvez pas imposer une récupération immédiate ; attendez l’exploration suivante.

5. Confirmez le retrait. Consultez l’état d’indexation dans Inspection d’URL. Lorsque la page est signalée comme exclue à cause de noindex, le retrait a réussi.

6. Ne considérez pas le rétablissement du blocage comme l’étape finale. Une fois la page retirée, rétablir Disallow peut masquer de nouveau noindex. Une URL bloquée mais liée peut alors revenir dans l’index. Si le budget d’exploration vous préoccupe, comparez ce risque ou choisissez l’authentification ou la suppression.

7. En urgence, n’attendez pas. Si la page doit disparaître immédiatement, utilisez l’outil Suppressions de Search Console, protégez-la par mot de passe ou supprimez-la avec 404/410.

Prompts prêts à l’emploi

Copiez-collez ces prompts pour analyser un blocage robots.txt avec un LLM. Considérez la réponse comme une hypothèse et confirmez les points importants avec le testeur robots.txt ou l’Inspection d’URL avant d’agir.

Déterminer quelle règle bloque quelle URL

Here is my robots.txt file and a list of URLs. For each URL, tell me whether it
is blocked or allowed, and quote the exact line in robots.txt responsible
(remember: the longest, most specific matching rule wins, and an Allow can
override a broader Disallow). If a URL isn't matched by any rule, say so.

ROBOTS.TXT:
[paste]

URLS:
[paste list, one per line]

Vérifier si un blocage semble volontaire

I run a [type of site]. Here is my robots.txt file. For each Disallow rule, tell
me what kind of URLs it likely targets (e.g. internal search, faceted
navigation, staging, cart/checkout, admin) and flag any rule that looks broad
enough it might be catching content pages by accident. Don't guess about pages
you can't see — just reason from the rule pattern and ask me to confirm
anything ambiguous.

ROBOTS.TXT:
[paste]

Préparer la séquence noindex puis réexploration pour une page précise

I need to remove [URL] from Google. It's currently blocked by this robots.txt
rule: [paste rule]. Walk me through the exact sequence of changes in order
(robots.txt edit, meta tag or header change, what to check in Search Console at
each step) so I don't accidentally leave the noindex tag unseen by Google.

Tester une URL par rapport aux règles robots.txt

Avant toute modification, confirmez précisément la règle qui s’applique à une URL. Le testeur robots.txt utilise un moteur adapté de l’analyseur open source de Google et affiche la règle gagnante pour chaque URL. Pour une vérification manuelle rapide, voici la logique essentielle en Python :

import re

def rule_matches(path, rule):
    """Very simplified robots.txt path matcher: '*' = wildcard, '$' = end anchor."""
    pattern = re.escape(rule).replace(r'\*', '.*')
    if pattern.endswith(r'\$'):
        pattern = pattern[:-2] + '$'
    return re.match(pattern, path) is not None

def find_blocking_rule(path, disallow_rules, allow_rules):
    """Longest matching rule wins; ties go to Allow (mirrors Google's documented
    precedence). Returns the winning rule string, or None if nothing matches."""
    matches = [r for r in disallow_rules if rule_matches(path, r)]
    matches += [r for r in allow_rules if rule_matches(path, r)]
    if not matches:
        return None
    return max(matches, key=len)

# Example
disallow = ["/search", "/*?*sort="]
allow = ["/search/help"]
print(find_blocking_rule("/search/help", disallow, allow))  # -> "/search/help" (Allow wins, longer)
print(find_blocking_rule("/search/results", disallow, allow))  # -> "/search" (Disallow, no competing Allow)

Il s’agit d’une simplification du moteur réel de Google, qui gère davantage de cas limites liés à l’échappement et à la sélection des groupes. Utilisez-la pour vérifier votre raisonnement, puis confirmez tout point important avec le véritable testeur.

Outils pour diagnostiquer et corriger cet état

• Google Index Checker — après la correction d’un blocage, vérifiez les signaux observables d’indexabilité : code d’état, redirections, noindex et canonique, puis consultez Search Console pour la réponse de Google.
• Inspection d’URL (Google Search Console) — la référence pour savoir si une URL précise est actuellement bloquée, connaître son indexabilité testée en direct et vérifier si Google l’a reprise après correction.
• Rapport robots.txt (Google Search Console) — une vue au niveau de la propriété de domaine sur les fichiers robots.txt trouvés, leur dernière récupération et leur état, avec une action permettant de demander une réexploration après modification.

Testez vos connaissances : blocage par robots.txt

Cinq questions sur cet état et les erreurs fréquentes. Choisissez une réponse pour chacune, puis vérifiez votre résultat.

Prouver que le retrait a réellement fonctionné

Dire « j’ai ajouté noindex » ou « j’ai modifié robots.txt » ne prouve rien. Seul compte l’état que reflète ensuite l’index de Google. Ces tests distinguent votre modification du résultat effectivement obtenu.

Test 1 — L’exploration est réellement autorisée

• Test à exécuter — Passez l’URL dans le testeur robots.txt après avoir modifié le fichier.
• Résultat attendu — L’URL est autorisée, sans règle Disallow correspondante, ou avec un Allow plus précis qui l’emporte sur un Disallow général.
• Interprétation d’un échec — Une autre règle plus précise bloque encore l’URL, ou la modification n’a pas été déployée. Vérifiez le contenu réellement servi.
• Fenêtre de contrôle — Immédiate : il s’agit d’un contrôle statique du fichier servi.
• Seuil d’arrêt — Sans objet : corrigez la règle avant le test suivant ; rien ne peut fonctionner tant que l’exploration reste interdite.

Test 2 — noindex est servi correctement

• Test à exécuter — Lancez Inspection d’URL → Test en direct dans Search Console, ou récupérez directement la page et examinez ses en-têtes et son HTML.
• Résultat attendu — Le test montre noindex, dans une balise meta robots du <head> ou dans un en-tête HTTP X-Robots-Tag.
• Interprétation d’un échec — Sans noindex, le retrait n’aura jamais lieu ; autoriser l’exploration ne retire rien à lui seul.
• Fenêtre de contrôle — Immédiate : le test en direct reflète la page actuellement servie.
• Seuil d’arrêt — Sans objet : ce test doit réussir avant que Google puisse agir.

Test 3 — Google a réellement retiré la page

• Test à exécuter — Contrôlez périodiquement le champ d’état indexé dans Inspection d’URL, et pas seulement le test en direct, après les deux premiers tests.
• Résultat attendu — L’état devient exclu à cause de noindex, et l’URL cesse d’apparaître dans une recherche site: ou dans vos données de suivi des positions.
• Interprétation d’un échec — Une page encore indexée après un cycle complet indique souvent un délai de cache ou de propagation. Google doit réexplorer la page.
• Fenêtre de contrôle — Une à trois semaines selon la fréquence d’exploration ; n’évaluez pas le résultat dès le lendemain du déploiement.
• Seuil d’arrêt nommé — Si la page reste indexée après un cycle complet et apparaît comme récemment explorée dans les journaux, cessez d’invoquer la propagation et reprenez les tests 1 et 2 : cache robots.txt obsolète, en-tête X-Robots-Tag retiré par le CDN ou seconde règle contradictoire sont les causes habituelles.

Journal des modifications