X-Robots-Tag : indexer ou désindexer par en-tête HTTP

Le X-Robots-Tag est une directive d'indexation envoyée par le serveur dans l'en-tête de la réponse HTTP, avant même que le navigateur ou le robot d'exploration ne reçoive le moindre octet de contenu. Contrairement à la balise meta robots, qui vit obligatoirement dans le <head> d'un document HTML, le X-Robots-Tag accompagne n'importe quelle réponse que le serveur renvoie : une page web, mais aussi un PDF, une image, une vidéo ou un fichier tableur. C'est cette portée qui en fait un outil à part dans la boîte à outils du SEO technique, et non un simple doublon de la meta robots.

Cet article se concentre sur ce mécanisme précis : ce qu'il permet de faire que la meta robots ne permet pas, comment le poser correctement, comment vérifier qu'il fonctionne, et surtout l'erreur la plus fréquente qui l'annule complètement sans que personne ne s'en aperçoive avant des semaines.

Qu'est-ce que le X-Robots-Tag, concrètement ?

Un en-tête HTTP est une ligne d'information transmise par le serveur en même temps que le contenu, mais séparément de lui. Content-Type, Cache-Control ou Content-Length en sont des exemples familiers. Le X-Robots-Tag fonctionne sur exactement le même principe : le serveur ajoute une ligne du type X-Robots-Tag: noindex à sa réponse, et cette ligne est lue par les robots d'exploration avant même qu'ils n'analysent le contenu qui suit.

Le point essentiel à retenir est que cette directive se pose côté serveur, dans la configuration ou dans le code applicatif qui construit la réponse, jamais dans le contenu lui-même. Pour une page HTML, cela produit le même résultat qu'une balise meta robots bien placée. Pour tout le reste, c'est la seule option qui existe.

La limite que la balise meta robots ne peut pas franchir

La balise meta robots a une contrainte structurelle qu'on oublie souvent : elle doit se trouver dans le <head> d'un document HTML pour être prise en compte. Or un document HTML est loin d'être le seul type de fichier qu'un moteur de recherche explore et indexe. Un PDF n'a pas de <head>. Une image n'a pas de <head>. Une vidéo hébergée directement, un fichier CSV téléchargeable, un flux XML : aucun de ces formats ne peut recevoir de balise meta, tout simplement parce qu'aucun n'a de structure HTML dans laquelle la placer.

C'est précisément le vide que le X-Robots-Tag comble. Puisqu'il voyage dans l'en-tête de la réponse HTTP et non dans le corps du document, il s'applique à n'importe quel type de fichier que le serveur renvoie, quel que soit son format. C'est la seule méthode native pour donner une instruction d'indexation à un moteur de recherche sur un fichier qui n'est pas du HTML.

• Un PDF de fiche produit ou de rapport ne peut recevoir aucune instruction d'indexation autrement que par cet en-tête
• Une image ou une galerie de visuels haute résolution relève du même cas
• Un fichier vidéo servi directement, hors lecteur intégré à une page HTML, également
• Un export CSV, XLS ou un flux de données brut n'a strictement aucun autre mécanisme disponible

Les directives disponibles : le même vocabulaire que la meta robots

Bonne nouvelle pour qui connaît déjà la balise meta robots : le X-Robots-Tag utilise exactement les mêmes directives. Il n'y a pas un second langage à apprendre, seulement un second endroit où l'écrire.

Ces directives peuvent se combiner sur une même ligne, séparées par des virgules, et peuvent aussi cibler un moteur de recherche précis en préfixant la valeur, par exemple pour ne s'adresser qu'à un robot en particulier plutôt qu'à tous les robots à la fois.

• noindex : ne pas inclure cette ressource dans les résultats de recherche
• nofollow : ne pas suivre les liens contenus dans cette ressource
• none : équivalent combiné de noindex et nofollow
• noarchive : ne pas conserver de version en cache de la ressource
• nosnippet : ne pas afficher d'extrait de texte ni d'aperçu dans les résultats
• max-snippet : limiter la longueur de l'extrait de texte affiché
• max-image-preview : limiter la taille de l'aperçu d'image affiché
• unavailable_after : cesser d'indexer la ressource après une date donnée

Cas d'usage concrets où l'en-tête est la seule solution

Trois familles de situations reviennent régulièrement en audit technique.

La première concerne les documents téléchargeables. Un catalogue PDF, une brochure, un livre blanc ou une fiche de données finissent souvent indexés sans que personne ne l'ait décidé, simplement parce qu'ils sont accessibles publiquement et liés depuis une page. Si ce contenu duplique une page HTML existante, ou n'a pas vocation à apparaître dans les résultats de recherche, le X-Robots-Tag posé sur la réponse du fichier est le seul levier direct pour agir.

La deuxième concerne les environnements et fichiers internes. Des sous-domaines de préproduction, des exports de données, des fichiers de sauvegarde accessibles par erreur, des répertoires d'administration : quand ces ressources ne sont pas du HTML classique, ou même quand elles le sont mais qu'on veut une règle appliquée d'un coup à tout un ensemble de fichiers plutôt qu'en éditant chaque page une par une, l'en-tête est nettement plus simple à industrialiser.

La troisième concerne le contenu à durée de vie limitée. Une page d'offre promotionnelle, une annonce d'emploi qui expire, un événement déjà passé : la directive unavailable_after permet de programmer une désindexation automatique à une date connue à l'avance, sans avoir à revenir modifier ou supprimer manuellement la ressource au bon moment.

L'erreur qui annule tout : bloquer et désindexer en même temps

C'est ici que se joue la partie la plus importante de cet article, parce que c'est l'erreur la plus fréquente et la plus mal comprise autour de cette directive.

Si une URL est bloquée dans le fichier robots.txt, le robot d'exploration ne la récupère jamais. Il ne télécharge pas la réponse, il ne lit donc jamais ses en-têtes HTTP, et il ne voit jamais le X-Robots-Tag qui s'y trouve, pas plus qu'il ne verrait une balise meta robots dans le corps du document. Bloquer l'exploration et poser une instruction de désindexation sur la même ressource est une contradiction pratique : la seconde instruction ne sera jamais lue, parce que la première l'empêche justement d'être atteinte.

Concrètement, cela signifie qu'une page déjà indexée, puis bloquée dans robots.txt avec un X-Robots-Tag: noindex ajouté au même moment, ne sortira pas de l'index par ce mécanisme. Le moteur de recherche, ne pouvant plus explorer la ressource, se contente des signaux dont il dispose déjà par ailleurs, ce qui peut la maintenir indexée bien plus longtemps que prévu, parfois avec un extrait de résultat appauvri plutôt qu'une disparition propre et nette.

La règle à retenir est simple mais va à l'encontre de l'intuition de départ : pour désindexer une ressource, il faut d'abord laisser le robot l'explorer, avec l'en-tête noindex bien visible dans la réponse. C'est seulement une fois la désindexation confirmée qu'on peut, si on le souhaite, bloquer l'accès dans robots.txt. Faire les deux choses en même temps dès le départ revient à donner un ordre que personne n'entendra jamais.

Comment mettre en place le X-Robots-Tag

Deux approches génériques existent, et le choix dépend surtout de la nature du site et de la ressource concernée.

La première consiste à configurer le serveur web lui-même, en ajoutant une règle qui associe l'en-tête à un motif : une extension de fichier donnée, un chemin de répertoire, ou un sous-domaine entier. Cette approche convient parfaitement aux fichiers statiques comme les PDF ou les images, puisqu'elle s'applique sans qu'aucun code applicatif n'ait besoin d'intervenir : le serveur ajoute la ligne à chaque réponse correspondant au motif défini.

La seconde consiste à générer l'en-tête depuis le code applicatif qui construit la réponse, page par page ou selon une condition logique : un statut de contenu, un rôle utilisateur, une date d'expiration calculée. Cette approche convient mieux quand la décision d'indexer ou non dépend d'une donnée qui n'est connue qu'au moment de traiter la requête, ce qu'une règle de configuration statique ne peut pas exprimer à elle seule.

Dans les deux cas, le principe reste identique : la ligne d'en-tête doit apparaître dans chaque réponse concernée, et rien n'empêche de combiner les deux approches sur un même site, l'une pour les fichiers statiques, l'autre pour les pages générées dynamiquement.

Comment vérifier que la directive est bien appliquée

C'est le piège le plus courant après la mise en place : le X-Robots-Tag est totalement invisible dans le code source de la page. Un clic droit puis « afficher le code source » n'affiche que le corps HTML du document, jamais les en-têtes de la réponse qui l'a livré. Chercher la directive dans le code source, comme on le ferait pour une balise meta robots, ne donnera jamais de résultat, même quand l'en-tête est correctement configuré et bien présent.

La vérification passe obligatoirement par l'inspection des en-têtes de réponse eux-mêmes. Dans les outils de développement d'un navigateur, l'onglet réseau affiche, pour chaque requête, la liste complète des en-têtes reçus, X-Robots-Tag inclus s'il est présent. En ligne de commande, une requête qui ne récupère que les en-têtes sans télécharger le corps du fichier donne la même information plus rapidement, ce qui est particulièrement pratique pour vérifier un lot entier de PDF ou d'images sans les ouvrir un par un.

• Vérifier l'URL exacte et finale, après toute redirection éventuelle, car les en-têtes peuvent différer d'une étape à l'autre
• Vérifier que la ligne apparaît sur la ressource elle-même, pas seulement sur la page HTML qui y fait un lien
• Refaire le contrôle après tout changement de configuration serveur, un déploiement pouvant réinitialiser une règle ajoutée manuellement