Bloquer la porte, ou interdire l'affichage
La question revient dans presque tous les audits que je fais : « j'ai mis un Disallow dans le robots.txt et la page est toujours dans Google, pourquoi ? ». La réponse tient en une phrase : ces deux outils n'agissent pas au même étage de la chaîne.
Google procède en trois temps : il découvre une URL, il l'explore (requête, téléchargement du HTML, exécution des scripts), puis il décide de l'indexer ou non, c'est-à-dire de la ranger pour pouvoir l'afficher dans les résultats. J'ai détaillé ailleurs la mécanique complète du référencement Google, du crawl au classement.
Le robots.txt intervient avant l'exploration. C'est un panneau planté à l'entrée : le robot le lit, et s'il y trouve une interdiction, il ne demande même pas la page. La balise noindex, elle, se trouve à l'intérieur de la page. Pour la voir, il faut donc que le robot soit entré. Toute la logique de choix découle de là.
Ce que fait vraiment le robots.txt
Le robots.txt est un fichier texte posé à la racine du domaine, qui liste des chemins autorisés ou interdits par robot. Sa seule fonction : réduire le nombre de requêtes que les crawlers envoient à votre serveur. Rien de plus. La documentation officielle de Google Search Central est explicite sur ce point : ce n'est pas un mécanisme pour garder une page hors des résultats de recherche.
D'où l'effet contre-intuitif. Si une page bloquée reçoit des liens depuis d'autres sites, Google peut l'indexer sans jamais l'avoir ouverte : il connaît son adresse et les textes d'ancre qui pointent vers elle, ça lui suffit. Résultat dans la SERP, un titre approximatif et, à la place de la description, une mention indiquant qu'aucune information n'est disponible. La page est plus visible que jamais, et vous n'avez plus de moyen de la corriger puisque vous vous êtes coupé de la seule voie de communication.
Là où le robots.txt est le bon outil, c'est quand le problème n'est pas la visibilité mais le volume. Un moteur de recherche interne qui génère une URL par requête tapée, un système de filtres à facettes qui multiplie les combinaisons, un calendrier qui propose l'année 2087 : il ne s'agit plus de trois pages à cacher, mais de dizaines de milliers d'URL à ne pas laisser explorer. Pour la syntaxe précise du fichier, groupes, jokers et déclaration du sitemap, j'ai écrit un guide dédié sur la façon de piloter l'exploration avec le robots.txt et le sitemap XML.
Ce que fait vraiment le noindex
Le noindex est une instruction adressée aux moteurs, qui dit : tu peux lire cette page, mais tu ne l'affiches pas dans tes résultats. Elle prend deux formes. Dans le HTML, une balise placée dans la section head :
<meta name="robots" content="noindex">
Ou, pour les fichiers qui n'ont pas de head (PDF, images, documents bureautiques), un en-tête de réponse HTTP envoyé par le serveur :
X-Robots-Tag: noindex
C'est la seule instruction qui fait réellement sortir une page des résultats, et Google le confirme dans sa page d'aide sur le blocage de l'indexation. Deux points méritent qu'on s'y arrête. D'abord, l'effet n'est pas immédiat : il faut attendre que le robot repasse, ce qui prend de quelques jours à plusieurs semaines selon la fréquence de crawl du site. Ensuite, une page en noindex continue d'être explorée et ses liens sortants restent suivis, sauf si vous ajoutez nofollow (rarement souhaitable). Une page de tri ou de pagination en noindex demeure donc un chemin utile vers vos contenus.
Et puisqu'on y est, le noindex posé par erreur figure en tête de ce que je vérifie en audit : une case cochée dans les réglages de lecture de WordPress, une préproduction copiée en production sans nettoyage, une extension SEO mal paramétrée. C'est la panne la plus brutale du référencement technique, et souvent la plus rapide à réparer.
Le piège qui annule tout
Voici la combinaison que je croise le plus souvent, et qui ne marche pas : bloquer une page dans le robots.txt et y poser un noindex. Le raisonnement paraît logique (« deux sécurités valent mieux qu'une »), le résultat est l'inverse de celui attendu. Le robot ne peut pas entrer, donc il ne lit jamais la balise, donc le noindex n'existe pas pour lui. Si la page était déjà indexée, elle le reste.
La bonne séquence est toujours la même : laisser la page accessible aux robots, poser le noindex, attendre qu'elle sorte des résultats (le rapport d'indexation de la Search Console permet de le vérifier), et seulement ensuite, si le volume le justifie, ajouter un Disallow. La plupart du temps cette dernière étape est superflue et on s'arrête au noindex.
Cas concrets : lequel choisir
La théorie est courte, l'application demande un peu de nuance. Voilà les situations que je rencontre le plus, avec le choix que je fais.
- Pages de compte, panier, tunnel de commande, page de remerciement : noindex. Ce sont quelques URL, sans intérêt en recherche, et certaines affichent des informations qu'on préfère garder hors de l'index.
- Résultats du moteur de recherche interne : noindex d'abord, parce que ces pages sont souvent déjà indexées. Disallow ensuite, une fois qu'elles en sont sorties, si leur nombre pèse sur l'exploration.
- Filtres et facettes d'un catalogue : robots.txt, en ciblant les paramètres d'URL concernés. Le problème est ici mathématique, quelques filtres combinables produisent un volume que le noindex ne réglera jamais, puisqu'il faudrait tout explorer pour le lire.
- Pages en double ou quasi identiques (variantes produit, versions imprimables, URL avec paramètres de suivi) : ni l'un ni l'autre. La bonne réponse est la consolidation, et c'est exactement le rôle que joue une balise canonical bien posée, regrouper le signal sur une seule adresse plutôt que le supprimer.
- Fichiers PDF et documents téléchargeables : X-Robots-Tag en en-tête HTTP, puisqu'il n'y a pas de HTML où poser une balise.
- Site de préproduction : ni noindex ni robots.txt, une authentification. Un mot de passe serveur ferme la porte à tout le monde, robots compris, sans dépendre du bon vouloir d'un crawler.
- Contenu supprimé définitivement : un code 410 (ou 404) fait le travail proprement. Inutile de maintenir une page vide en noindex.
Un réflexe fonctionne dans presque tous les cas : demandez-vous si le problème est « cette page ne doit pas être vue par un internaute qui cherche » ou « ces milliers d'URL ne doivent pas consommer mes ressources ». Le premier appelle le noindex, le second le robots.txt.
Et si c'était urgent ?
Reste le cas qui arrive toujours au mauvais moment : une page qui n'aurait jamais dû être publiée se retrouve dans Google, et vous ne pouvez pas attendre le prochain passage du robot. La Search Console propose un outil de suppression qui masque une URL des résultats en quelques heures, mais l'effet est temporaire, de l'ordre de quelques mois.
Il sert à gagner du temps, pas à régler le problème. Pendant ce délai, posez le vrai correctif : noindex si la page doit rester en ligne, code 410 si elle doit disparaître. Sinon elle réapparaîtra à l'expiration de la demande, généralement le jour où vous aurez oublié qu'elle existait.