Utilisez robots.txt pour encadrer l'exploration par les robots concernés, et noindex pour demander qu'un contenu ne soit pas indexé. Ne bloquez pas l'accès à une page avant de vérifier comment le moteur pourra lire sa directive. Une règle technique doit correspondre à une intention précise.
Définir le résultat attendu
Écrivez l'objectif avant de modifier un fichier : garder une page accessible mais hors des résultats, limiter l'exploration d'un ensemble d'URL ou protéger une information confidentielle. Ces trois besoins ne se règlent pas de la même façon.
Google explique qu'une restriction robots.txt ne garantit pas l'absence d'une URL dans les résultats. La directive noindex doit pouvoir être lue par le moteur pour être prise en compte. Aucune de ces deux méthodes ne remplace un contrôle d'accès pour des données privées.
Préparer un inventaire limité
Choisissez quelques URL représentatives et notez leur statut HTTP, leur directive actuelle et leur rôle. Séparez une page de confirmation, une rubrique éditoriale et une variante technique. Une règle appliquée à un préfixe trop large peut toucher des pages que vous souhaitez conserver visibles.
Conservez une copie des réglages précédents et préparez une liste de contrôles avant publication. Si le besoin concerne des versions proches d'un même contenu, examinez plutôt la cohérence des URL canoniques : la duplication n'est pas automatiquement une raison d'exclure toute une famille de pages.
Exemple fictif : une confirmation d'inscription
Imaginons une page de confirmation accessible sans compte, qui contient seulement un message générique. L'objectif est de permettre son affichage après l'inscription sans la proposer comme résultat de recherche. Documentez cet objectif, puis vérifiez les directives renvoyées par cette URL.
Si vous choisissez noindex, contrôlez la réponse réellement servie et l'absence d'une restriction d'exploration qui empêcherait sa lecture. Vérifiez aussi qu'aucune donnée personnelle n'apparaît dans la page ou dans son adresse. Un identifiant sensible dans l'URL reste un problème même si la page n'est pas indexée.
La fiche conserve la décision, la réponse avant modification, la réponse après modification et la date du contrôle. Ce cas fictif n'est pas un modèle universel : une confirmation contenant des données privées demande d'abord une protection adaptée.
Vérifier sans confondre intention et résultat
Après publication, contrôlez le fichier robots.txt, les en-têtes et le HTML de la page concernée. Cherchez les règles contradictoires et les différences entre hôtes. Reprenez l'audit du sitemap pour vérifier qu'il représente les URL que vous voulez réellement proposer à l'indexation.
Lorsque vous disposez d'un accès aux outils du moteur, examinez ce qu'ils ont effectivement observé. Une modification publiée n'est pas forcément déjà relue. Notez séparément votre contrôle HTTP immédiat et l'état d'indexation connu, sans promettre un délai de prise en compte.
Questions fréquentes
Robots.txt protège-t-il un espace confidentiel ?
Non. Il publie des instructions d'exploration, pas une barrière d'accès. Les données privées nécessitent une protection appropriée à l'application et aux personnes autorisées.
Pourquoi une URL bloquée peut-elle encore être connue du moteur ?
Le moteur peut découvrir son adresse par d'autres liens sans lire son contenu. Ne présentez pas une restriction d'exploration comme une preuve de suppression des résultats.
Faut-il mettre toutes les pages secondaires en noindex ?
Non. Le choix dépend de leur utilité et de leur rôle. Une page moins importante dans la navigation peut tout de même répondre à une recherche précise et mériter d'être accessible aux moteurs.
Sources
Documentation consultée lors de la relecture du 10 septembre 2026.