Pourquoi bloquer une page par robots.txt empêche-t-il Google de voir votre balise noindex ?

Quelle différence entre bloquer par robots.txt et désindexer avec noindex ?

Le robots.txt agit comme un barrage en amont : il interdit purement et simplement l'accès du crawler à une URL. Googlebot s'arrête avant même de télécharger le contenu HTML. Résultat : aucune analyse de la page, aucune lecture des balises meta, aucune détection des directives noindex ou canonical.

La balise noindex, elle, exige que le bot accède à la page, télécharge le HTML et parse l'en-tête ou le corps du document. C'est une instruction post-crawl : « OK, tu peux lire cette page, mais ne l'indexe pas ». Si vous bloquez l'URL en amont, Google ne verra jamais cette instruction. La page peut rester dans l'index — orpheline, figée, avec un snippet « Une description de ce résultat n'est pas accessible en raison du fichier robots.txt de ce site ».

Pourquoi l'outil de suppression d'URL ne change rien à l'indexation ?

L'outil de suppression d'URL dans la Search Console est un cache temporaire de 90 jours. Il masque une URL des résultats de recherche sans toucher au processus de crawl ni à l'index structurel. C'est un pansement d'urgence, pas une solution pérenne.

Google continuera à crawler l'URL selon son planning habituel, à moins qu'un robots.txt ou un noindex ne lui donne une consigne claire. L'outil ne modifie ni la fréquence de crawl ni le statut d'indexation réel. Une fois les 90 jours écoulés, si rien n'a changé côté serveur, la page réapparaît dans les SERP.

Que se passe-t-il si j'utilise robots.txt ET noindex simultanément ?

Vous créez un conflit technique. Le robots.txt bloque l'accès, donc Google ne lit jamais le noindex. La page reste potentiellement indexée avec un snippet dégradé. C'est un scénario fréquent sur des sites mal configurés : anciennes URL de staging bloquées par robots.txt mais avec un noindex dans le HTML invisible.

Google privilégie toujours le robots.txt en première ligne. Si le fichier dit « Disallow », le crawler ne va pas plus loin. Le noindex devient caduc. Pour désindexer proprement, il faut autoriser le crawl (retirer la ligne Disallow) et laisser le bot découvrir la directive noindex pendant quelques cycles de crawl.

• Le robots.txt bloque l'accès au crawl, empêchant toute lecture du HTML
• Le noindex nécessite un crawl pour être détecté et appliqué
• L'outil de suppression est temporaire (90 jours) et ne touche ni crawl ni indexation structurelle
• Combiner robots.txt + noindex crée un conflit technique où le noindex reste invisible
• Pour désindexer proprement : autoriser le crawl, laisser Google lire le noindex, puis bloquer si nécessaire

Cette déclaration reflète-t-elle les observations terrain ?

Oui, et c'est même un classique des audits SEO. On retrouve régulièrement des sites avec des milliers d'URL bloquées par robots.txt mais toujours indexées, affichant le fameux snippet « Description non disponible ». Google ne peut pas lire le noindex, donc il garde l'URL en index par défaut — surtout si des backlinks pointent vers elle.

Le problème se complique avec les migrations ou refontes. Une URL bloquée par robots.txt pendant des mois, puis débloquée, peut mettre plusieurs semaines à être recrawlée si le crawl budget est serré. Entre-temps, elle reste indexée avec un contenu obsolète ou vide. Résultat : pollution d'index, cannibalisation potentielle, dilution du crawl.

Quand le robots.txt est-il vraiment justifié pour bloquer l'indexation ?

Rarement. Le robots.txt sert avant tout à économiser du crawl budget : facettes infinies, paramètres d'URL dynamiques, zones admin, ressources inutiles. Mais pour désindexer une page indexable (contenu légitime que vous ne voulez simplement pas dans les SERP), le noindex est plus propre.

Le seul cas où robots.txt + indexation est tolérable : les PDF ou fichiers téléchargeables que vous voulez garder dans l'index pour la visibilité, mais sans que Google en crawle le contenu interne. Encore faut-il que des liens externes alimentent la notoriété de l'URL. [A vérifier] selon la typologie du site : certains secteurs (légal, médical) préfèrent bloquer totalement le crawl de documents sensibles, quitte à sacrifier le SEO.

Que faire si une page bloquée par robots.txt reste indexée ?

Première étape : retirer la directive Disallow du robots.txt pour cette URL ou ce répertoire. Ensuite, ajouter un noindex propre (balise meta ou en-tête HTTP X-Robots-Tag). Attendre que Googlebot recrawle — cela peut prendre de quelques jours à plusieurs semaines selon le crawl budget.

En parallèle, utiliser l'outil de suppression d'URL pour accélérer le retrait visuel des SERP, mais ne jamais s'en contenter. Vérifier ensuite dans la Search Console que le statut passe bien à « Exclue par la balise noindex ». Si après 4-6 semaines rien ne bouge, forcer un recrawl via « Inspection d'URL » ou soumettre un sitemap XML contenant l'URL (contre-intuitif mais ça marche pour déclencher un crawl rapide).

Comment auditer les conflits robots.txt / noindex sur un site ?

Exportez la liste des URL bloquées par robots.txt depuis votre fichier (ou via Screaming Frog en mode « List »). Croisez cette liste avec les URL indexées dans Google : requête site:example.com puis filtrez manuellement, ou utilisez un export Search Console « Couverture > Exclues » + un crawl Screaming Frog avec « Respect robots.txt » désactivé.

Recherchez les URL qui apparaissent à la fois dans « Bloqué par robots.txt » ET « Indexé ». Ce sont vos conflits critiques. Vérifiez si un noindex est présent dans le HTML ou les en-têtes HTTP : si oui, il est invisible pour Google. Décidez pour chaque URL : désindexation propre (retirer robots.txt, garder noindex) ou blocage définitif (garder robots.txt, accepter l'indexation résiduelle).

Quelle méthode choisir selon le type de contenu ?

Pour du contenu sensible ou privé : mot de passe, paywall, ou blocage serveur (401/403). Ne comptez jamais sur robots.txt ou noindex seuls — un leak de lien peut indexer la page. Pour du contenu dupliqué ou de faible valeur : noindex + canonical si pertinent, jamais de robots.txt (Google doit lire vos directives).

Pour des ressources techniques (CSS, JS, images) : ne bloquez RIEN par robots.txt depuis 2015 — Google a besoin de ces ressources pour le rendu et les Core Web Vitals. Pour des facettes ou paramètres d'URL : robots.txt si crawl budget serré + canonical sur la version principale. Pour des pages obsolètes ou archivées : 301 ou 410 selon le cas, jamais de robots.txt seul.

Quelles erreurs critiques faut-il éviter absolument ?

Ne jamais bloquer par robots.txt une URL que vous voulez désindexer proprement. C'est la garantie d'une indexation zombie. Ne jamais utiliser l'outil de suppression d'URL comme solution pérenne : c'est un cache de 90 jours, pas une directive d'indexation.

Évitez de bloquer /wp-admin/ ou /wp-includes/ si vous utilisez WordPress : certains plugins injectent du CSS/JS critique depuis ces répertoires, et un blocage peut dégrader le rendu mobile. Enfin, ne supprimez jamais une ligne robots.txt sans vérifier l'impact crawl : débloquer 50 000 URL de facettes d'un coup peut saturer votre serveur et diluer le budget sur les pages stratégiques.

• Exporter les URL bloquées par robots.txt et croiser avec les URL indexées (Search Console + crawl)
• Pour désindexer : retirer robots.txt, ajouter noindex, attendre le recrawl, vérifier le statut « Exclue par noindex »
• Pour bloquer le crawl sans désindexer : accepter l'indexation résiduelle ou utiliser une vraie restriction serveur (401/403)
• Ne jamais bloquer CSS/JS/images critiques — Google en a besoin pour le rendu et les Core Web Vitals
• Utiliser l'outil de suppression d'URL uniquement en urgence temporaire, jamais comme stratégie long terme
• Tester tout changement robots.txt sur un échantillon avant déploiement global (risque crawl budget)