Deux outils techniques sont souvent mélangés : robots.txt et la directive noindex. Pourtant, ils n'agissent pas au même niveau.

robots.txt : gérer l'accès des robots
Google présente robots.txt comme un moyen d'indiquer aux robots quelles URL ils peuvent explorer. L'un de ses usages principaux est de gérer le crawl et d'éviter des explorations inutiles ou trop coûteuses.

Ce fichier ne doit pas être considéré comme un mécanisme fiable pour retirer une page de Google. C'est précisément ce que Google rappelle dans sa documentation.

noindex : demander qu'une page ne soit pas indexée
La directive noindex peut être placée dans une balise meta robots ou, selon le type de ressource, dans un en-tête HTTP X-Robots-Tag. Lorsqu'elle est vue et respectée par Google, elle demande de ne pas conserver la page dans les résultats.

Le piège : bloquer le crawl avant que Google voie noindex
Si robots.txt empêche Google d'accéder à la page, Googlebot peut ne pas être en mesure de lire la directive noindex présente dans le HTML. On obtient alors une configuration contradictoire.

Pour retirer proprement une page de l'index, il faut généralement permettre à Google d'accéder à la directive noindex afin qu'il puisse la constater, ou protéger réellement la ressource si elle ne doit pas être publique.

Cas d'usage raisonnables de robots.txt
Des espaces techniques, certains paramètres sans intérêt, des résultats de recherche interne ou des chemins générant beaucoup d'URL peuvent justifier une gestion du crawl. Mais chaque règle doit être réfléchie : bloquer un dossier entier peut aussi empêcher l'accès à des ressources nécessaires au rendu.

Quand noindex est pertinent
Pages de confirmation, espaces utilitaires publics mais sans intérêt de recherche, certaines pages temporaires ou contenus qu'on souhaite laisser accessibles par lien sans les proposer dans Google. Le choix dépend de l'objectif du site.

Ne pas utiliser noindex pour « économiser du crawl » sans réfléchir
Une directive d'indexation et une stratégie de crawl répondent à deux besoins différents. Les mélanger produit souvent des configurations fragiles.

Comment vérifier
1. Lire la règle robots.txt qui concerne l'URL.
2. Vérifier la réponse HTTP.
3. Inspecter le HTML ou les en-têtes pour la directive robots.
4. Utiliser Search Console pour voir ce que Google constate.
5. Après correction, attendre un nouveau crawl ou demander une inspection pour quelques URL importantes.

Le cas d'une page supprimée
Si une page doit disparaître définitivement, le serveur peut retourner un statut adapté comme 404 ou 410, ou rediriger si un remplaçant pertinent existe. Maintenir éternellement une page vide avec noindex n'est pas toujours la meilleure architecture.

À retenir
robots.txt parle surtout de crawl. noindex parle d'indexation. Une stratégie propre commence par décider ce que l'on veut obtenir, puis par utiliser le bon outil au bon niveau.

Sources officielles pour aller plus loin
• https://developers.google.com/search/docs/crawling-indexing/robots/intro
• https://developers.google.com/search/docs/crawling-indexing/block-indexing
• https://developers.google.com/search/docs/crawling-indexing/ask-google-to-recrawl

Google Décrypté — guide indépendant, non affilié à Google.

Un scénario fréquent lors d'une refonte
Une équipe souhaite masquer temporairement un espace de préproduction. Elle bloque alors le dossier dans robots.txt, puis découvre plus tard que certaines URL avaient déjà été connues de Google. La meilleure protection pour un environnement réellement privé reste une authentification ou un contrôle d'accès côté serveur, pas simplement une règle robots.txt. Cette distinction évite d'exposer accidentellement des ressources sensibles.

Pour un site public, documentez les règles importantes. Une ligne ajoutée en urgence dans robots.txt peut rester oubliée pendant des mois et bloquer une nouvelle section. Les changements doivent être relus après déploiement, surtout lorsqu'ils utilisent des motifs larges.

De même, lorsqu'une directive noindex est retirée, l'URL ne revient pas immédiatement dans les résultats. Google doit la revisiter, constater le changement puis retraiter la page. Il est donc normal qu'un délai existe entre la correction technique et l'état visible dans Search Console ou dans les résultats.