Indexée malgré le blocage par le fichier robots.txt : causes et solutions

« Indexée malgré le blocage par le fichier robots.txt » signifie que Google a placé une URL dans son index sans lire la page, parce que votre robots.txt en interdit l'exploration alors que des liens pointent toujours vers elle. Le résultat s'affiche généralement avec peu ou pas de description. Que ce soit un problème dépend d'une seule décision : si la page doit se positionner, supprimez le blocage ; si elle doit rester hors de la recherche, robots.txt n'est pas le bon outil, et la solution consiste à autoriser l'exploration et à utiliser noindex.

Dans l'interface allemande de Search Console, ce même état s'intitule « Indexiert, obwohl durch robots.txt-Datei blockiert », et dans l'interface anglaise « Indexed, though blocked by robots.txt ».

Ce que signifie cet état selon Google

La documentation de Google sur le Rapport sur l'indexation des pages (consultée en octobre 2026) décrit cet état en une ligne : la page a été indexée bien qu'elle soit bloquée par le fichier robots.txt du site. Elle ajoute que Google respecte toujours robots.txt, mais que cela n'empêche pas forcément l'indexation si quelqu'un d'autre crée un lien vers la page : Google ne demande pas la page, et indexe l'URL à partir des informations de la page qui pointe vers elle.

Google classe cet état parmi les avertissements, pas parmi les erreurs. Sa documentation précise que les avertissements n'empêchent pas une page d'être indexée, mais réduisent la capacité de Google à la comprendre et à l'indexer. L'URL est dans l'index. Ce qui manque, c'est tout ce que Google aurait appris en la récupérant : le titre tel que vous l'avez rédigé, le texte, les données structurées et toute balise meta robots.

La documentation indique aussi que l'extrait d'une telle page sera probablement très limité. L'introduction de Google à robots.txt est plus directe : une URL bloquée peut tout de même apparaître dans les résultats, mais sans description.

Comment une page bloquée finit indexée

robots.txt contrôle l'exploration. Il ne contrôle pas l'indexation. L'introduction de Google à robots.txt précise qu'il sert principalement à éviter de surcharger un site de requêtes, et qu'il ne constitue pas un moyen de tenir une page à l'écart de Google.

sequenceDiagram
    participant L as Lien vers l'URL
    participant G as Googlebot
    participant R as robots.txt
    participant I as Index Google
    L->>G: URL découverte
    G->>R: Ce chemin est-il autorisé ?
    R-->>G: Une règle Disallow correspond
    Note over G: Page jamais récupérée, donc un éventuel noindex reste non lu
    G->>I: URL indexée à partir des signaux de liens
    I-->>I: Listée avec peu ou pas de description

Voilà pourquoi une configuration bien intentionnée se retourne contre vous. Une équipe veut retirer une page de la recherche, ajoute une balise noindex, puis bloque aussi le chemin dans robots.txt par précaution. Le blocage empêche Google de récupérer la page : le noindex n'est donc jamais lu. La documentation de Google sur le blocage de l'indexation le dit clairement : pour que noindex fonctionne, la page ne doit pas être bloquée par robots.txt.

Les 5 causes habituelles

1. Un blocage volontaire sur des pages qui reçoivent toujours des liens. Les résultats de recherche interne, les listes filtrées et triées, les pages de panier et de compte et les chemins d'administration sont couramment interdits. Lorsque votre navigation, votre sitemap ou un autre site renvoie vers elles, Google apprend que ces URL existent et peut en indexer certaines. WordPress, par exemple, génère un robots.txt qui interdit son chemin d'administration lorsque le site n'a pas son propre fichier robots.txt : une URL d'administration qui reçoit un lien peut donc apparaître avec cet état.

2. noindex et Disallow sur la même page. C'est la configuration décrite plus haut : 2 instructions sur 1 URL. Elle produit exactement le résultat qu'elle devait empêcher.

3. Une règle plus large que prévu. Les chemins de robots.txt sont comparés depuis le début du chemin de l'URL, et la comparaison est sensible à la casse. Disallow: /shop bloque /shop/, mais aussi /shop-guide/ et /shopping-tips/. Un préfixe court écrit pour une section peut attraper des pages de contenu d'une autre.

4. Le sitemap liste des URL bloquées. Un sitemap indique à Google qu'une URL existe et qu'elle compte, puis robots.txt en interdit l'exploration. 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. Sur ces mêmes 29 sites, 8 (28 %) avaient au moins une URL de sitemap qui redirige, qui est marquée noindex ou qui est bloquée par robots.txt.

5. Un blocage global ajouté alors que le site était déjà indexé. Un robots.txt de préproduction contenant Disallow: / copié en production ne retire pas les pages que Google connaît déjà. Elles peuvent rester listées avec peu ou pas de description, puisque Google ne peut plus les lire.

Est-ce un problème ? Corriger, corriger autrement ou laisser

La réponse dépend de la fonction de la page, pas de l'état lui-même.

La troisième ligne est un vrai compromis. Si vous bloquez des millions d'URL à paramètres pour protéger votre serveur, les débloquer pour que Google puisse lire un noindex provoque justement l'exploration que vous vouliez éviter. Une poignée de ces URL dans cet avertissement, sans impressions, est généralement acceptable. Une page de contenu dans cet état doit toujours être corrigée : Google ne l'a pas lue, et elle apparaît sans description pour inciter au clic.

flowchart TD
    A["Indexée malgré le blocage par le fichier robots.txt"] --> B{"Cette page doit-elle apparaître dans la recherche ?"}
    B -->|oui| C["Trouver la règle de blocage"]
    C --> D["Vérifier que la page ne cache pas un noindex"]
    D --> E["Supprimer ou restreindre la règle"]
    B -->|non| F{"Le blocage sert-il à limiter la charge d'exploration ?"}
    F -->|non| G["Autoriser l'exploration et ajouter noindex"]
    F -->|oui| H["Laisser, cesser les liens, retirer du sitemap"]
    G --> I["Facultatif : outil Suppressions pour environ 6 mois"]
    E --> J["Valider la correction dans Search Console"]
    G --> J

Comment confirmer la cause pour une URL précise

Lancez l'outil d'inspection d'URL sur l'URL concernée. Dans les détails de l'indexation de la page, « Exploration autorisée ? » vous indique si une règle robots.txt bloque Google, et lors d'un test en ligne, « Récupération de la page » affiche un échec pour une URL bloquée. « Page de provenance » et « Sitemaps », dans la même section, montrent comment Google a pu trouver l'URL, ce qui vous dit quel lien ou quelle entrée de sitemap la maintient connue. Ignorez ici « Indexation autorisée ? » : l'aide de Google précise que ce champ affiche toujours « Oui » pour une page bloquée, puisque Google ne peut pas voir un noindex sur une page qu'il n'a pas le droit de récupérer.

Trouvez la règle exacte. Ouvrez votre robots.txt à la racine de l'hôte, du protocole et du port exacts qui servent l'URL, car les règles de chaque fichier ne s'appliquent qu'à cet endroit :

curl -s https://www.example.com/robots.txt

Lisez-le ensuite comme Google le fait, selon sa spécification de robots.txt :

• Googlebot ne suit que le groupe User-agent correspondant le plus spécifique. Si votre fichier contient un groupe User-agent: Googlebot, le groupe User-agent: * est entièrement ignoré pour Googlebot.
• Au sein de ce groupe, la règle dont le chemin correspondant est le plus long l'emporte. Lorsqu'un Allow et un Disallow correspondent à égalité, Google applique le moins restrictif.
• * correspond à n'importe quelle suite de caractères et $ marque la fin de l'URL.

Le rapport robots.txt de Search Console liste les fichiers robots.txt que Google a trouvés pour les 20 principaux hôtes de votre site, la date de dernière exploration de chacun et les éventuels avertissements ou erreurs. Cela permet de repérer le cas où Google lit une autre version que celle que vous modifiez.

Vérifiez ce qui se cache derrière le blocage. Avant de débloquer quoi que ce soit, regardez ce que Google verra une fois qu'il pourra récupérer la page :

curl -sI https://www.example.com/page/ | grep -i x-robots-tag
curl -s https://www.example.com/page/ | grep -i '<meta name="robots"'

Une page bloquée depuis des mois peut porter un noindex oublié, une redirection ou une erreur 404 que personne n'a remarqués, puisque personne ne pouvait les voir.

La solution pour chaque cas

La page doit être indexée. Supprimez ou restreignez la règle Disallow. Si une règle large reste nécessaire, ajoutez une règle Allow plus longue pour les pages à explorer :

User-agent: *
Disallow: /shop/
Allow: /shop/guides/

/shop/guides/ est la correspondance la plus longue : elle l'emporte donc pour ces URL, tandis que le reste de /shop/ reste bloqué. Gardez l'URL dans votre sitemap et dans vos liens internes.

La page doit rester hors de la recherche. Supprimez la règle Disallow pour cette page et ajoutez une directive noindex :

<meta name="robots" content="noindex">

Pour les PDF et les autres fichiers non HTML, envoyez plutôt la directive dans un en-tête de réponse :

X-Robots-Tag: noindex

Retirez aussi l'URL de votre sitemap. Une fois que Google a réexploré la page et lu le noindex, l'URL sort de l'index et passe dans « URL marquée "noindex" », dans le groupe « Non indexées », ce qui est le bon état final. Laissez la page explorable. Si vous la bloquez de nouveau, le noindex redevient invisible et des liens peuvent faire revenir l'URL avec le même avertissement. Supprimer la page avec un code 404 ou 410, ou la placer derrière une authentification, sont les autres options permanentes que cite Google. L'outil Suppressions de Search Console masque une URL pendant environ 6 mois ; l'aide de Google précise que cet outil seul ne constitue pas une suppression définitive.

Le blocage sert à contrôler l'exploration. Gardez la règle, cessez de créer des liens vers ces URL depuis vos templates, et gardez-les hors du sitemap pour ne pas annoncer ce que vous interdisez.

Comment vérifier la correction

Google met généralement robots.txt en cache jusqu'à 24 heures. Après avoir modifié le fichier, vous pouvez en demander une nouvelle exploration depuis le rapport robots.txt. Lancez ensuite un test en ligne dans l'outil d'inspection d'URL : « Exploration autorisée ? » doit désormais indiquer oui. Pour une page que vous voulez voir indexée, utilisez « Demander une indexation ».

Une fois toutes les URL concernées traitées, ouvrez le problème dans le Rapport sur l'indexation des pages et cliquez sur « Valider la correction ». La documentation de Google indique que la validation prend généralement jusqu'à deux semaines environ et peut durer beaucoup plus longtemps. Comptez de quelques jours à quelques semaines avant que le nombre ne baisse, et ne cliquez pas de nouveau sur « Valider la correction » tant que la validation en cours n'a pas réussi ou échoué.

Cet état passe facilement inaperçu depuis un navigateur ou une conversation avec un assistant, car la page elle-même semble normale ; le conflit se trouve dans un fichier distinct, un angle mort expliqué dans ce que voit réellement un agent IA quand il vérifie votre page. Search Console vous indique quelles URL sont concernées. Un diagnostic SEOReport complet confronte les pages listées dans votre sitemap aux règles que votre robots.txt fixe pour tous les robots, et nomme celles que votre sitemap annonce alors que robots.txt les bloque : c'est la contradiction à l'origine de nombreuses URL indexées sans avoir été explorées. Il signale aussi une interdiction globale du site.

Questions fréquentes

Google retirera-t-il de lui-même une page bloquée des résultats ?

Pas de façon fiable. Google respecte le blocage : il ne peut donc rien lire qui lui demanderait d'écarter la page, et les liens maintiennent l'URL connue. Utilisez un noindex sur une page explorable, un code 404 ou 410, ou une protection par mot de passe.

Cet état nuit-il au reste de mon site ?

La documentation de Google ne décrit aucun effet sur les autres pages. Le coût est local : une URL indexée avec peu ou pas de description, ou une page que vous vouliez masquer et qui reste listée. Pour les URL de contrôle de l'exploration sans présence dans la recherche, l'avertissement est en grande partie cosmétique.

En quoi est-ce différent de « URL bloquée par le fichier robots.txt » ?

Les deux proviennent du même type de règle. « URL bloquée par le fichier robots.txt » figure dans le groupe « Non indexées » : Google a respecté le blocage et n'a pas indexé l'URL. « Indexée malgré le blocage par le fichier robots.txt » est un avertissement : Google a quand même indexé l'URL parce que quelque chose pointe vers elle. Notre guide robots.txt et accès à l'exploration traite les règles elles-mêmes.

Peut-on utiliser noindex dans robots.txt ?

Non. La spécification de robots.txt de Google ne prend en charge que quatre champs : user-agent, allow, disallow et sitemap ; une ligne noindex y est donc ignorée. Placez le noindex dans la balise meta robots de la page ou dans un en-tête de réponse X-Robots-Tag, sur une URL que Google a le droit d'explorer.

Pourquoi l'état s'affiche-t-il encore après la suppression de la règle ?

Google doit récupérer à nouveau robots.txt, réexplorer chaque URL, puis actualiser le rapport. Si un test en ligne dans l'outil d'inspection d'URL indique oui pour « Exploration autorisée ? », le rapport finira par suivre. Le guide de l'indexabilité des pages et notre analyse des conflits d'indexabilité entre noindex, robots.txt et balises canoniques traitent les signaux associés.