En-tête X-Robots-Tag ajouté deux fois par un middleware, contre le robots.txt

X-Robots-Tag: noindex. Puis, trois lignes plus bas dans le même flux de réponse : X-Robots-Tag: index, follow. Cette double présence, révélée par un simple curl -I, correspond à un cas rencontré sur un site institutionnel dont l’équipe technique jurait n’avoir jamais configuré de blocage d’indexation. Le robots.txt, lui, n’y était pour rien : le conflit se jouait entièrement dans les en-têtes HTTP.

Symptôme : deux directives contradictoires

La commande curl -sI https://exemple.fr/actualites/ renvoyait bien deux occurrences de l’en-tête, une conséquence rare mais documentée du protocole HTTP, qui autorise techniquement la répétition d’un même champ. La spécification précise que des en-têtes multiples avec le même nom doivent être interprétés comme une liste combinée, séparée par des virgules. Pour X-Robots-Tag, cela signifie que les moteurs de recherche reçoivent l’équivalent de noindex, index, follow, une combinaison que Google traite en retenant la directive la plus restrictive, ici noindex.

Le symptôme visible en premier lieu n’était donc pas une erreur serveur, mais une désindexation progressive de pages que personne n’avait volontairement exclues du référencement, malgré une configuration apparemment correcte dans les réglages de visibilité de WordPress.

Diagnostic : remonter la chaîne de traitement

La première hypothèse, la plus fréquente, concerne une extension SEO qui ajoute cet en-tête via send_headers pour certains types de contenus. Elle a été écartée rapidement : le site n’utilisait aucune extension de ce type, uniquement des fonctions maison dans le thème.

La deuxième piste a mené vers un module de sécurité applicative installé en amont de WordPress, un middleware au niveau du serveur, chargé d’ajouter des en-têtes de sécurité standard (X-Frame-Options, X-Content-Type-Options) mais aussi, par une règle de configuration héritée d’un autre projet, un X-Robots-Tag: noindex systématique sur les chemins contenant /actualites/, pensé à l’origine pour un environnement de préproduction jamais nettoyé lors de la mise en production.

Pendant ce temps, WordPress lui-même ajoutait son propre en-tête, correct celui-là, via la fonction wp_robots(), hookée sur wp_head pour la balise meta, mais aussi via le filtre wp_robots côté en-têtes HTTP quand une extension l’utilisait pour renforcer la cohérence entre balise meta et en-tête HTTP. Les deux mécanismes, l’un dans la configuration serveur, l’autre dans l’application, ignoraient totalement l’existence l’un de l’autre.

Correctif : centraliser la décision

La correction a consisté à retirer complètement la règle du middleware pour ce chemin, et à laisser WordPress seul responsable de la décision d’indexation, pilotée par le filtre wp_robots :

add_filter( 'wp_robots', function ( $robots ) {
    if ( is_singular( 'post' ) && ! is_admin() ) {
        unset( $robots['noindex'] );
        $robots['index']  = true;
        $robots['follow'] = true;
    }
    return $robots;
} );

Cette approche centralise la logique d’indexation dans un seul endroit, testable et versionné avec le reste du code du thème, plutôt que dispersée entre une configuration serveur opaque et le comportement natif de WordPress.

Vérifier qu’un seul en-tête subsiste

curl -sI https://exemple.fr/actualites/mon-article/ | grep -i x-robots-tag

Une seule ligne doit apparaître en sortie. Si deux lignes persistent après la correction du middleware, il reste probablement une règle de cache en amont (CDN, proxy inverse) qui sert encore une version mise en cache de l’ancienne configuration.

Prévention : un test qui aurait tout évité

• Ajouter un contrôle automatisé, dans le pipeline de déploiement, qui vérifie l’absence de doublon d’en-tête X-Robots-Tag sur un échantillon d’URL représentatives.
• Documenter, dans le dépôt du projet, la liste exhaustive des points qui peuvent injecter des en-têtes liés à l’indexation : middleware serveur, CDN, thème, extensions.
• Faire relire toute règle de sécurité applicative héritée d’un autre projet avant sa mise en production, en particulier celles touchant aux en-têtes HTTP.

Un en-tête HTTP lié à l’indexation ne devrait avoir qu’un seul point d’origine possible dans toute l’infrastructure. Dès qu’un deuxième candidat existe, même désactivé la plupart du temps, le risque de conflit silencieux reste ouvert.

En résumé

Ce cas illustre une catégorie d’incidents SEO particulièrement difficile à repérer parce qu’aucun outil de l’interface d’administration WordPress ne signale la présence d’un en-tête HTTP ajouté en amont par le serveur. Seule une inspection directe de la réponse HTTP, avec un outil en ligne de commande, permet de révéler ce genre de doublon. Sur un projet avec plusieurs couches d’infrastructure entre le visiteur et l’application, il vaut mieux vérifier régulièrement, plutôt que de faire confiance uniquement à ce que WordPress affiche dans ses réglages.