URL bloquée par le fichier robots.txt : utile ou coûteux pour votre site

« URL bloquée par le fichier robots.txt » (en anglais : « URL blocked by robots.txt ») signifie que Google n'a pas exploré l'URL parce qu'une règle de votre fichier robots.txt l'interdit, et que l'URL ne figure pas dans l'index. Sur la plupart des sites, cet état est justifié : les espaces d'administration, les paniers, la recherche interne et les URL à paramètres sont bloqués volontairement. Il ne vous coûte quelque chose que lorsque la règle attrape une page que vous voulez voir dans les résultats, et tout l'enjeu est de repérer ces pages parmi les blocages voulus.

Jusqu'en 2022, le Rapport de couverture de l'index de Search Console utilisait 2 libellés pour cet état : « URL envoyée bloquée par le fichier robots.txt » pour les URL listées dans un sitemap que vous aviez envoyé, et « Bloquée par le fichier robots.txt » pour les autres. En allemand, la documentation d'aide de Google liste désormais cet état sous « URL wird von der robots.txt-Datei blockiert » ; l'ancien libellé était « Durch robots.txt-Datei blockiert ». Si votre rapport affiche « Indexiert, obwohl durch robots.txt-Datei blockiert » (« Indexée malgré le blocage par le fichier robots.txt »), l'URL est dans l'index malgré le blocage, et cet état fait l'objet de son propre guide.

Ce que signifie cet état selon Google

La documentation de Google sur le Rapport sur l'indexation des pages (consultée en octobre 2026) classe « URL bloquée par le fichier robots.txt » dans le groupe « Non indexées » et indique que la page a été bloquée par le fichier robots.txt de votre site. La même documentation présente l'ensemble du groupe « Non indexées » en précisant que ces pages ne sont pas indexées, « mais pas nécessairement en raison d'une erreur ».

Le blocage a 2 conséquences pour votre décision :

• Le blocage empêche l'exploration, pas l'indexation. La documentation de Google ajoute qu'un blocage ne garantit pas que la page reste hors de l'index. Si Google trouve des informations sur la page sans la charger, par exemple des liens depuis d'autres pages, il existe une faible probabilité qu'elle soit tout de même indexée et passe dans « Indexée malgré le blocage par le fichier robots.txt ».
• Google ne voit jamais la page. Ni titre, ni contenu, ni liens, ni balise canonique, ni noindex. Tout ce que la page dit d'elle-même reste invisible tant que la règle est en place.

Est-ce un problème ? Séparer les blocages voulus des blocages accidentels

Commencez par le filtre situé en haut du Rapport sur l'indexation des pages. Faites-le passer de « Toutes les pages connues » à « Toutes les pages envoyées ». Les URL bloquées qui apparaissent sous « Toutes les pages envoyées » sont listées dans un sitemap que vous avez envoyé : vous demandez à Google de les indexer tout en interdisant leur exploration dans robots.txt. Cette contradiction est presque toujours une erreur, quel que soit l'objectif initial de la règle.

Sur 29 sites externes soumis à un audit SEOReport dont nous avons récupéré les pages du sitemap entre mai et octobre 2026, 2 (7 %) listaient dans leur sitemap des URL que leur propre robots.txt interdit. Ce n'est pas le problème de sitemap le plus fréquent, mais c'est celui qui bloque des pages que le site a lui-même déclarées importantes.

Les schémas accidentels, avant et après

Chaque schéma ci-dessous est une règle qui a fonctionné comme elle était écrite, et qui a bloqué plus que prévu.

1. Le fichier de préproduction mis en ligne. Un site de développement est entièrement bloqué, et le fichier part en production avec le reste du build.

# Before: copied from staging
User-agent: *
Disallow: /

# After: block only what should never be crawled
User-agent: *
Disallow: /cart/
Disallow: /account/

Sitemap: https://www.example.com/sitemap.xml

2. Un préfixe trop court. Google compare une règle depuis le début du chemin de l'URL : Disallow: /search bloque donc /search?q=shoes, mais aussi /search-engine-basics/, un véritable article.

# Before
Disallow: /search

# After: block only the search results
Disallow: /search/
Disallow: /search?

3. Un caractère générique qui attrape des pages de destination. * correspond à n'importe quelle suite de caractères, et la comparaison de Google inclut la chaîne de requête. Disallow: /*? bloque toute URL avec un paramètre, y compris des pages de catégorie paginées comme /shoes/?page=2 que vous voulez peut-être faire explorer pour que les produits qu'elles contiennent soient trouvés.

# Before
Disallow: /*?

# After: keep pagination crawlable, block the rest
Disallow: /*?
Allow: /*?page=

Le même piège vaut pour les extensions de fichier. Sur un site dont les pages se terminent par .php, Disallow: /*.php bloque tout le catalogue.

4. Un groupe Googlebot oublié. La spécification de robots.txt de Google indique qu'un robot ne suit que le groupe le plus spécifique qui le nomme, et que les groupes spécifiques ne sont pas combinés avec le groupe *. Un groupe User-agent: Googlebot écrit pour une migration il y a des années continue de s'appliquer à Googlebot, pendant que l'équipe ne modifie que le groupe * et ne comprend pas d'où vient le blocage.

# Before: Googlebot reads only its own group
User-agent: Googlebot
Disallow: /blog/

User-agent: *
Disallow: /cart/

La solution consiste à supprimer l'ancien groupe ou à y recopier les règles actuelles. La même règle explique un effet secondaire fréquent des politiques visant les robots d'IA : un site qui ajoute des groupes nommés pour certains robots doit répéter chaque règle commune dans chacun d'eux. Notre tableau de décision pour robots.txt et les robots d'IA présente des modèles qui séparent les règles de recherche et d'IA.

5. Des ressources de rendu bloquées. Disallow: /assets/ ou Disallow: /static/ bloque le CSS et le JavaScript que chargent vos pages. L'introduction de Google à robots.txt indique que vous pouvez bloquer des ressources sans importance, mais pas celles dont l'absence rend la page plus difficile à comprendre pour Google. Ces fichiers bloqués apparaissent rarement comme des pages dans le Rapport sur l'indexation des pages : cherchez-les donc du côté des pages. Lancez un test en ligne dans l'outil d'inspection d'URL et ouvrez « Afficher la page testée », puis « Plus d'infos », pour voir les ressources de page que Google a chargées. Vérifiez aussi l'hôte des ressources : robots.txt s'applique par hôte, protocole et port, et les fichiers servis depuis cdn.example.com suivent donc le robots.txt propre à cet hôte. Un script bloqué qui construit le contenu de la page pèse le plus sur les sites rendus dans le navigateur, sujet de notre guide sur le rendu JavaScript.

Comment tester une règle robots.txt sur une URL

Vous n'avez pas besoin d'outil pour prévoir la décision de Google. Sa spécification la ramène à 4 étapes.

flowchart TD
    A["URL à tester"] --> B["Ouvrir le robots.txt du même hôte et du même protocole"]
    B --> C{"Existe-t-il un groupe pour Googlebot ?"}
    C -->|oui| D["Utiliser uniquement ce groupe"]
    C -->|non| E["Utiliser le groupe *"]
    D --> F["Lister chaque Allow et Disallow qui correspond au chemin"]
    E --> F
    F --> G{"Une correspondance ?"}
    G -->|non| H["Autorisée"]
    G -->|oui| I["Le chemin de règle le plus long l'emporte"]
    I --> J{"Allow et Disallow de même longueur ?"}
    J -->|oui| H
    J -->|non| K["Appliquer la règle la plus longue"]

1. Choisissez le fichier. Ouvrez /robots.txt sur l'hôte et le protocole exacts de l'URL. https://www.example.com/robots.txt ne régit pas https://shop.example.com/.
2. Choisissez le groupe. Utilisez le groupe User-agent le plus spécifique qui correspond à Googlebot. Les noms de user-agent ne sont pas sensibles à la casse.
3. Trouvez les règles correspondantes. Une règle correspond si son chemin correspond au début du chemin et de la requête de l'URL. * correspond à n'importe quels caractères, $ marque la fin de l'URL, et les chemins sont sensibles à la casse : /Shop/ ne correspond pas à /shop/.
4. Désignez la gagnante. La règle au chemin le plus long l'emporte. En cas d'égalité entre un Allow et un Disallow, Google applique la moins restrictive, l'Allow.

Voici la méthode appliquée au fichier « après » du schéma 3, avec en plus Disallow: /search :

Pour vérifier la lecture de Google plutôt que la vôtre, lancez l'outil d'inspection d'URL sur l'URL. Dans les détails d'exploration, « Exploration autorisée ? » indique si une règle robots.txt bloque Google, et un test en ligne applique le fichier que Google peut récupérer à cet instant. Google publie aussi son analyseur robots.txt sous forme de bibliothèque open source, que les développeurs peuvent exécuter sur un brouillon de fichier avant sa mise en ligne.

Corriger la règle, puis vérifier

Modifiez le fichier pour que les pages à explorer ne soient plus visées. Restreignez un Disallow trop large, ajoutez un Allow plus long pour l'exception, ou supprimez un groupe obsolète. Ensuite :

1. Récupérez le fichier en ligne pour confirmer que le serveur sert bien votre modification, et non une copie en cache ou figée au moment du build : curl -s https://www.example.com/robots.txt.
2. Demandez une nouvelle exploration de robots.txt depuis le rapport robots.txt de Search Console. Google met généralement le fichier en cache jusqu'à 24 heures, et l'aide de ce rapport cite le déblocage d'URL importantes comme raison de demander une nouvelle exploration. Le rapport indique quand Google a récupéré le fichier pour la dernière fois, ainsi que les éventuelles erreurs ou avertissements ; une ligne en erreur est ignorée.
3. Lancez un test en ligne dans l'outil d'inspection d'URL sur 2 ou 3 URL concernées. « Exploration autorisée ? » doit désormais indiquer oui. Utilisez « Demander une indexation » pour les pages les plus importantes ; l'aide de Google indique que l'indexation peut prendre jusqu'à une ou deux semaines.
4. Cliquez sur « Valider la correction » pour le problème dans le Rapport sur l'indexation des pages une fois la règle corrigée. La documentation de Google indique que la validation prend généralement jusqu'à 2 semaines environ et peut durer beaucoup plus longtemps.

L'aide de Google sur la nouvelle exploration précise que l'exploration peut prendre de quelques jours à quelques semaines : attendez-vous à une baisse progressive du nombre d'URL. Celles qui restent ensuite dans le rapport doivent être celles que vous vouliez bloquer.

Avant de débloquer une page cachée depuis des mois, examinez-la comme le fera un robot d'exploration : son code de statut, sa balise meta robots et sa balise canonique. Une page que personne ne pouvait explorer peut porter un noindex oublié, qui la ferait passer directement dans « URL marquée "noindex" ». Notre analyse des conflits d'indexabilité explique comment ces signaux interagissent.

Search Console vous dit quelles URL sont bloquées. Un diagnostic SEOReport complet confronte les pages listées dans votre sitemap aux règles de votre robots.txt et nomme celles que vous demandez aux moteurs de recherche de trouver tout en leur interdisant de les explorer. Il signale aussi une interdiction globale du site et l'absence de robots.txt. Il lit les règles écrites pour tous les robots : un groupe réservé à Googlebot reste donc à confirmer dans l'outil d'inspection d'URL.

Questions fréquentes

Un grand nombre d'URL bloquées nuit-il à mon site ?

Non, pas en soi. Des milliers d'URL de paramètres ou de recherche bloquées montrent que robots.txt fait son travail. Comptez les URL bloquées listées dans votre sitemap et les pages bloquées que vous voulez positionner : ce sont les seules qui vous coûtent.

Que se passe-t-il si mon robots.txt est absent ou renvoie une erreur ?

La spécification de Google traite une réponse 404 ou toute autre réponse 4xx (sauf 429) comme si robots.txt n'existait pas : rien n'est alors bloqué. Une erreur 5xx est différente : Google cesse d'explorer le site pendant les 12 premières heures, puis utilise la dernière copie valide dont il dispose pendant 30 jours au maximum. Google traite de la même façon les délais d'attente dépassés et les erreurs DNS sur ce fichier : un robots.txt qui ne répond pas à temps peut donc suspendre l'exploration d'un site qui n'a aucune règle de blocage.

Faut-il retirer les URL bloquées de mon sitemap ?

Oui. Un sitemap liste les URL que vous voulez voir indexées : il ne doit contenir aucune URL bloquée par robots.txt. Retirez du sitemap les blocages voulus, et débloquez les blocages accidentels. Notre guide des sitemaps XML détaille ce qui a aussi sa place dans ce fichier.

Peut-on utiliser robots.txt pour retirer une page de Google ?

Non. robots.txt contrôle l'exploration, et Google peut tout de même indexer une URL bloquée vers laquelle d'autres pages renvoient. Pour tenir une page hors de la recherche, laissez Google l'explorer et ajoutez un noindex. Le guide robots.txt et accès à l'exploration explique quel outil fait quoi.

Un robots.txt sur un sous-domaine ou en HTTP affecte-t-il mon site principal ?

Non. Chaque combinaison d'hôte, de protocole et de port a son propre fichier, et Google ne lit pas les fichiers robots.txt placés dans des sous-répertoires. Un fichier bloquant sur staging.example.com ne peut pas bloquer www.example.com, mais le robots.txt de votre hôte de ressources ou de votre CDN détermine bien si Google peut récupérer les fichiers que chargent vos pages.