robots.txt ou meta robots : quelle différence ?

Par l’équipe Limpi. Les faits externes sont distingués des méthodes Limpi et aucune visibilité, position ou citation automatique n’est garantie.

Crawl et indexation sont deux décisions différentes

Le crawl correspond à la capacité d’un robot à demander une ressource. L’indexation correspond à la décision du moteur de conserver et d’exploiter cette ressource dans son index. robots.txt intervient en amont du téléchargement tandis que meta robots se trouve dans la réponse HTML elle-même.

Cette différence explique pourquoi un Disallow n’est pas l’équivalent de noindex. Une URL peut être connue grâce aux liens ou à d’autres sources alors que son contenu n’a pas été exploré. Il faut donc choisir le mécanisme en fonction du résultat réellement recherché.

Quand utiliser robots.txt

robots.txt est adapté lorsque l’objectif consiste à contrôler l’exploration de certaines zones par les robots qui respectent ce protocole. Il peut limiter le crawl de paramètres, de combinaisons techniques ou de zones qui n’ont pas besoin d’être parcourues.

Il ne s’agit toutefois pas d’un mécanisme de sécurité. Une ressource privée ou sensible doit être protégée par authentification et autorisation côté serveur. Publier son chemin dans robots.txt ne la protège pas et peut même rendre son existence plus évidente.

Quand utiliser meta robots ou X-Robots-Tag

Lorsqu’une page accessible ne doit pas être indexée, une directive noindex peut être fournie dans le HTML avec meta robots. Pour certains types de fichiers et certains usages serveur, X-Robots-Tag permet d’envoyer des directives comparables dans les en-têtes HTTP.

Le crawler doit néanmoins pouvoir récupérer la ressource pour lire cette directive. Bloquer simultanément l’URL dans robots.txt et compter sur un noindex uniquement présent dans la page peut donc empêcher le moteur d’observer précisément le signal que l’on souhaitait lui transmettre.

Éviter les combinaisons contradictoires

Les configurations problématiques apparaissent souvent lorsque plusieurs équipes ajoutent chacune leur propre mécanisme : Disallow dans robots.txt, noindex dans le template, canonical vers une autre URL et parfois redirection côté serveur. Plus les signaux s’accumulent, plus le diagnostic devient difficile.

La bonne approche consiste à repartir de l’objectif. Si la page ne doit plus exister, le statut HTTP ou la redirection peut être le sujet principal. Si elle doit rester accessible mais pas indexée, noindex devient pertinent. Si l’objectif est uniquement de limiter l’exploration d’une zone sans intérêt, robots.txt peut être étudié séparément.

Auditer les signaux dans l’ordre où le crawler les rencontre

Commencez par robots.txt, puis récupérez l’URL et observez son statut HTTP, ses redirections, ses en-têtes, sa meta robots et sa canonical. Cet ordre permet de savoir quelles informations sont réellement accessibles au robot.

Sur un site à grande échelle, raisonnez par templates et familles d’URLs. Une règle introduite dans un layout ou un reverse proxy peut affecter des milliers de pages. La correction doit donc viser la source du signal plutôt que quelques exemples observés dans un rapport.

Ne jamais utiliser ces directives comme contrôle d’accès

Ni robots.txt ni meta robots ne remplacent une protection applicative. Une page contenant des informations confidentielles doit nécessiter une authentification adaptée, une autorisation correcte et une configuration serveur empêchant les accès non prévus.

Cette frontière est importante lors d’un audit SEO : supprimer une URL des résultats de recherche et empêcher un utilisateur non autorisé de consulter son contenu sont deux problèmes totalement différents. La stratégie technique doit traiter chacun avec le mécanisme approprié.

Raisonner avec des scénarios concrets

Une page de résultats interne que l’on ne souhaite pas explorer peut relever d’une réflexion robots.txt. Une page publique utile à la navigation mais que l’on ne souhaite pas conserver dans l’index pose plutôt une question noindex. Une facture privée accessible seulement après connexion relève quant à elle de la sécurité et ne doit pas dépendre de l’un ou l’autre de ces mécanismes.

Ces scénarios montrent pourquoi il est dangereux de chercher une règle universelle. La bonne directive dépend du cycle de vie de la ressource, de son accès utilisateur et du comportement attendu des moteurs.

Documenter les raisons derrière chaque règle

Une ligne robots.txt ou une directive noindex peut survivre longtemps après le besoin qui l’a créée. Pour éviter les règles orphelines, documentez l’objectif, la famille d’URLs concernée et le système qui génère la directive. Cette information accélère les audits et réduit le risque de supprimer un contrôle encore nécessaire.

Lors d’une migration, comparez les politiques avant et après bascule. Une configuration copiée sans contexte peut réintroduire d’anciens blocages sur une architecture qui a complètement changé.

Revalider robots.txt et meta robots pendant une migration

Une migration change souvent les chemins, les templates et les règles de reverse proxy en même temps. Une directive correcte sur l’ancien site peut devenir inadaptée sur le nouveau. Avant la bascule, comparez les familles d’URLs, les règles robots.txt et les directives générées par les nouveaux templates ; après la bascule, testez des exemples représentatifs sur l’environnement réellement public.

Cette vérification est particulièrement importante pour les directives héritées d’un ancien CMS. Un Disallow devenu inutile ou un noindex copié dans un nouveau template peut affecter une grande partie du site sans être visible dans une simple revue de contenu.

Questions fréquentes

Disallow signifie-t-il noindex ?

Non. Disallow concerne l’exploration définie par robots.txt ; noindex concerne l’indexation.

Peut-on écrire noindex directement dans robots.txt ?

Il faut utiliser un mécanisme pris en charge pour l’indexation, comme meta robots ou X-Robots-Tag selon la ressource.

Une URL bloquée peut-elle encore être connue ?

Oui. Un moteur peut découvrir son URL par d’autres sources même s’il n’en récupère pas le contenu.

robots.txt protège-t-il une page privée ?

Non. Les données privées nécessitent de vrais contrôles d’accès.

Sources de référence : Google Search Central — robots.txt · Google Search Central — meta robots