Une ligne Disallow dans le robots.txt donne l’impression d’avoir réglé le problème. La page n’apparaît plus dans les logs d’exploration, le moteur ne la visite plus, dossier clos. Sauf que si un autre site pointe vers cette URL, Google peut l’indexer quand même — sans jamais l’avoir explorée. Le résultat est une ligne dans les résultats de recherche avec une adresse nue et la mention « aucune information n’est disponible pour cette page ». La page est invisible du moteur et visible du lecteur : le pire des deux mondes.
Deux registres qu’on confond en permanence
Le robots.txt s’adresse à l’exploration : il dit à un robot où il a le droit d’aller. L’indexation, c’est une décision distincte — celle d’ajouter une page à l’index et de la proposer dans les résultats. Deux leviers gouvernent l’indexation : la balise meta name= »robots » content= »noindex » posée dans l’en-tête de code d’une page HTML, et l’en-tête HTTP X-Robots-Tag, qui fait la même chose pour un fichier qui n’a pas de page HTML à proprement parler — un PDF, une image, un flux JSON.
La documentation de Google pour les webmasters le précise noir sur blanc : le robots.txt contrôle l’exploration, pas l’apparition dans les résultats. Une page peut être bloquée à l’exploration et indexée quand même, si des liens externes la mentionnent.
Pourquoi les deux instructions se contredisent quand on les cumule
C’est là que l’erreur devient un piège plutôt qu’une maladresse. Poser un Disallow sur une URL et une balise noindex sur la même page ne fait rien de plus fort — ça casse le mécanisme. Le robot ne peut retirer une page de l’index que s’il peut la visiter pour lire l’instruction de retrait. S’il lui est interdit d’entrer, il ne voit jamais la consigne de sortie. La page reste dans l’index, avec un extrait vide, potentiellement pendant des mois, jusqu’à ce que le moteur choisisse de son propre chef de l’écarter faute de pouvoir la vérifier.
La règle pratique tient en une phrase : pour retirer une page de l’index, il faut la laisser explorable et poser un noindex ; le Disallow ne sert qu’à économiser du budget d’exploration sur des zones qui ne présentent aucun intérêt pour l’indexation — des pages de résultats de recherche interne, des paramètres de tri, des filtres à combinaisons infinies.
Le cas des fichiers qu’on veut vraiment cacher
Pour un document confidentiel — contrat, export client, page d’administration — ni le Disallow ni le noindex ne protègent quoi que ce soit : ce sont des instructions de courtoisie, respectées par les moteurs qui jouent le jeu, ignorées par tout le reste. Un fichier qu’on ne veut voir nulle part doit être derrière une authentification, ou simplement ne pas être accessible par une URL publique. Le robots.txt lui-même est un fichier public : lister dans son Disallow un dossier qu’on veut discret revient à en publier l’adresse.
Ce qui reste du robots.txt une fois qu’on a réglé l’indexation
- Économiser le budget d’exploration sur les zones à faible valeur (filtres, tris, recherche interne).
- Éviter qu’un robot ne consomme des ressources serveur sur des scripts ou des fichiers techniques.
- Indiquer l’emplacement du sitemap XML, une ligne souvent oubliée alors qu’elle coûte une seconde à ajouter.
Rien de tout cela ne remplace une vraie décision d’indexation. La confusion tient à un raccourci de langage — « bloquer une page » — qui recouvre deux mécanismes opposés. Une fois qu’on les sépare, le diagnostic d’une page fantôme dans les résultats devient trivial : elle est presque toujours bloquée à l’exploration sans jamais avoir reçu de consigne d’indexation claire. Nous détaillons ailleurs comment organiser sa boîte à outils de suivi pour repérer ce genre d’écart avant qu’il ne dure des mois.
