Robots.txt bloque-t-il vraiment l'indexation dans Google ?

Quelle est la différence entre blocage crawl et blocage indexation ?

Le robots.txt contrôle ce que Googlebot peut explorer, pas ce qu'il peut indexer. Cette nuance technique échappe encore à beaucoup de praticiens. Quand tu bloques une URL via robots.txt, tu empêches le bot d'accéder au contenu de la page, mais tu ne lui interdis pas de la référencer dans l'index.

Google peut donc indexer l'URL elle-même si elle est mentionnée ailleurs sur le web — typiquement via des backlinks externes. L'entrée dans la SERP affichera alors l'URL et un snippet générique du type "Une description de cette page n'est pas disponible en raison du fichier robots.txt". Peu séduisant pour l'utilisateur, mais techniquement indexé.

Pourquoi Google indexe-t-il des pages bloquées par robots.txt ?

La logique de Google repose sur la pertinence pour l'utilisateur. Si une page génère beaucoup de signaux externes — backlinks, mentions, recherches directes — Google considère qu'elle mérite d'apparaître dans les résultats, même si le contenu n'est pas accessible au bot.

L'exemple de la page de login AdWords illustre parfaitement ce cas de figure. Cette page était bloquée par robots.txt, mais tellement recherchée et liée que Google la maintenait dans l'index. Pour les utilisateurs, trouver le lien de connexion était plus important que d'accéder à une description de la page.

Comment Google décide-t-il quelles pages bloquées méritent d'être indexées ?

La documentation officielle reste floue sur les critères de sélection. Google mentionne "l'importance pour les utilisateurs" sans détailler de seuil précis. On sait que les backlinks jouent un rôle majeur — une URL sans liens externes a peu de chances d'être indexée si elle est bloquée par robots.txt.

Les requêtes directes (recherches du nom exact de l'URL ou de la marque) semblent également peser dans la balance. Si des milliers de personnes cherchent "adwords login" chaque jour, Google considère légitime de proposer l'URL correspondante, même bloquée au crawl.

• Robots.txt bloque le crawl, pas l'indexation — l'URL peut apparaître dans la SERP sans que Googlebot ait accédé au contenu
• Google indexe les pages bloquées jugées importantes pour les utilisateurs, notamment via backlinks et recherches directes
• Le snippet affiché sera générique et peu informatif, faute d'accès au contenu de la page
• Pour empêcher complètement l'indexation, utilise noindex (meta tag ou header HTTP), pas robots.txt
• La combinaison robots.txt + noindex est impossible — Googlebot ne peut pas lire la directive noindex s'il ne crawle pas la page

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, et c'est documenté depuis longtemps dans les guidelines officielles. Le problème, c'est que beaucoup de SEO confondent encore les deux concepts. Je rencontre régulièrement des audits où des pages sensibles (backend, admin, paramètres) sont bloquées uniquement par robots.txt, avec la conviction que ça suffit à les retirer de l'index.

En pratique, ces pages apparaissent souvent dans la SERP si elles ont des liens entrants — même internes. Un simple lien dans un footer, une mention dans un fichier sitemap (ironiquement), et Google indexe l'URL malgré le blocage crawl. Le snippet sera vide, certes, mais l'URL traîne dans les résultats, ce qui pose des problèmes de confidentialité et dilue le crawl budget sur des requêtes parasites.

Quelles nuances faut-il apporter à cette règle ?

La notion d'"importance pour les utilisateurs" reste subjective et opaque. [A vérifier] Google ne publie aucun seuil chiffré — combien de backlinks ? quel volume de recherches directes ? On navigue à vue. Dans mes tests, j'ai vu des URL avec 3-4 backlinks de sites moyens rester indexées pendant des mois après blocage robots.txt, tandis que d'autres avec un seul lien d'un gros site disparaissaient rapidement.

Autre point : la vitesse de désindexation. Quand tu bloques une URL déjà indexée, Google ne la retire pas immédiatement. Le délai varie énormément — de quelques jours à plusieurs semaines, voire mois pour des pages historiques. Si tu veux un retrait rapide, passe par la Search Console avec une demande de suppression d'URL, en complément du blocage.

Dans quels cas cette règle pose-t-elle problème ?

Le scénario classique : tu veux désindexer proprement une section entière de ton site (anciens produits, pages de test, contenus dupliqués). Si tu te contentes de bloquer par robots.txt, Google conservera les URL dans l'index tant qu'elles reçoivent des signaux externes. Résultat : des dizaines, voire centaines de pages "fantômes" qui polluent ta présence dans la SERP.

La parade recommandée — noindex avant robots.txt — crée un autre souci timing. Il faut d'abord laisser Googlebot crawler les pages avec la directive noindex, attendre la désindexation complète (vérifiable en Search Console), puis seulement bloquer le crawl si nécessaire. Beaucoup de sites sautent cette étape et se retrouvent coincés avec des URL indexées sans moyen propre de les retirer.

Que faut-il faire concrètement pour contrôler l'indexation ?

Si ton objectif est d'empêcher l'indexation, oublie robots.txt. Utilise une balise meta robots noindex dans le <head> de la page, ou un header HTTP X-Robots-Tag: noindex pour les fichiers non-HTML (PDF, images). Ces directives indiquent explicitement à Google de ne pas indexer la ressource, même si elle est crawlable.

Pour les sections entières (répertoires complets, paramètres d'URL), un pattern dans robots.txt peut bloquer le crawl — mais uniquement après désindexation complète via noindex. La séquence correcte : (1) ajouter noindex, (2) attendre le passage de Googlebot et vérifier la désindexation en Search Console, (3) optionnellement bloquer le crawl pour économiser du budget.

Quelles erreurs éviter dans la gestion robots.txt vs indexation ?

Erreur numéro un : bloquer par robots.txt des pages déjà indexées en espérant qu'elles disparaissent de la SERP. Ça ne fonctionne pas — ou très lentement et de manière imprévisible. Tu te retrouves avec des URL fantômes qui squattent l'index pendant des semaines.

Deuxième piège : ajouter noindex sur des pages bloquées par robots.txt. Google ne peut pas lire la directive, donc elle reste sans effet. J'ai vu des sites laisser cette configuration pendant des mois, convaincus que le noindex ferait son travail. Spoiler : non.

Troisième erreur : ne pas monitorer l'index réel via Search Console. La commande site: dans Google est peu fiable. Utilise le rapport "Couverture" de la Search Console pour identifier les URL indexées malgré un blocage robots.txt — c'est un signal d'alarme.

Comment vérifier que votre stratégie d'indexation est correcte ?

Commence par un audit de l'index actuel. Dans Search Console, filtre les pages par statut "Indexée, non envoyée dans le sitemap" et croise avec ton fichier robots.txt. Toute URL bloquée qui apparaît ici mérite investigation — soit tu la désindexes proprement via noindex, soit tu acceptes sa présence et optimises son snippet.

Vérifie également les backlinks entrants vers ces pages bloquées. Si des sites externes continuent de linker des URL que tu veux retirer, ça ralentira ou empêchera la désindexation. Contacte les webmasters pour retirer les liens, ou utilise l'outil de désaveu en dernier recours si c'est du spam.

• Utiliser noindex (meta tag ou HTTP header) pour empêcher l'indexation, jamais robots.txt seul
• Appliquer noindex en premier, vérifier la désindexation complète, puis bloquer le crawl si nécessaire
• Monitorer régulièrement l'index via Search Console, pas via site: qui est approximatif
• Identifier et traiter les backlinks vers les pages que tu veux désindexer — ils retardent le processus
• Pour un retrait rapide d'URL déjà indexées, utiliser l'outil de suppression d'URL de la Search Console en complément
• Ne jamais combiner robots.txt et noindex simultanément sur les mêmes ressources