Quand utiliser X-Robots-Tag plutôt qu’une meta robots ?

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

Situer X-Robots-Tag parmi les contrôles d’indexation

X-Robots-Tag est un en-tête HTTP qui peut transmettre des directives aux robots. Il est particulièrement utile pour des ressources non HTML, comme certains PDF, qui ne peuvent pas porter une meta robots classique dans un head. Il ne faut pas le confondre avec robots.txt : ce dernier contrôle l’exploration, tandis qu’une directive noindex concerne l’indexation de la ressource récupérée. Comprendre cette différence évite des configurations où le crawler est bloqué avant même de pouvoir voir l’en-tête censé lui donner une instruction.

Identifier quelle couche ajoute l’en-tête

L’application, Nginx, Apache, un CDN ou un proxy peut chacun ajouter X-Robots-Tag. Inspectez la réponse HTTP publique et comparez-la aux configurations disponibles. Une directive peut être appliquée par type MIME, répertoire, pattern d’URL ou code de réponse. Testez plusieurs ressources couvertes par la même règle pour déterminer sa portée. Un noindex sur un PDF volontairement privé peut être cohérent, alors que la même directive injectée sur toutes les pages d’un dossier public est une anomalie beaucoup plus large. Le bon correctif doit intervenir dans le composant réellement responsable.

Rechercher les directives dupliquées ou contradictoires

Une réponse peut contenir plusieurs en-têtes ou combiner X-Robots-Tag avec une meta robots HTML. Relevez toutes les valeurs et déterminez leur effet conjoint. Vérifiez également la canonical et le statut HTTP. Si une page est destinée à l’indexation mais reçoit noindex dans un en-tête ajouté par le CDN, changer le template HTML ne résoudra rien. Pour des règles ciblant un user-agent, contrôlez précisément la syntaxe et la nécessité de cette différenciation. Les configurations anciennes copiées sans documentation sont une source fréquente de contradictions difficiles à détecter dans l’interface du CMS.

Tester différents types de ressources et statuts

Ne vérifiez pas une seule page 200. Si la règle vise un dossier, testez un document HTML, un fichier, une redirection et une erreur pertinente. Certains serveurs ajoutent les en-têtes uniquement sur certaines réponses. Pour une ressource non HTML, utilisez une requête qui affiche les headers réels et suivez les redirections jusqu’à l’URL finale. Vérifiez aussi le cache : un CDN peut servir une ancienne version de l’en-tête après une correction d’origine. Cette matrice de tests permet de confirmer que la règle est cohérente dans les situations réellement rencontrées.

Corriger sans mélanger crawl et indexation

Si la ressource doit être indexable, retirez la directive restrictive à sa source. Si elle doit rester exclue, conservez une règle explicite et documentée. N’utilisez pas robots.txt comme remplacement automatique d’un noindex : bloquer l’exploration peut modifier la manière dont les directives sont découvertes. Pour une page HTML classique, la meta robots peut parfois être plus facile à gérer au niveau applicatif ; pour un PDF, l’en-tête HTTP est souvent le mécanisme adapté. Le choix doit suivre le format et l’architecture plutôt qu’une préférence abstraite.

Vérifier la production après modification

Rejouez les requêtes sans vous fier uniquement à un outil de préproduction. Inspectez l’en-tête final reçu depuis le domaine public, puis contrôlez plusieurs URLs qui partagent la règle. Confirmez que la valeur attendue est présente ou absente et qu’aucun proxy ne la réinjecte. Si le CDN a une configuration séparée, testez après purge ou expiration du cache. Comparez aussi robots.txt afin de détecter un conflit de stratégie. Une modification n’est validée que lorsque la réponse publique correspond réellement à la politique d’indexation décidée.

Documenter les responsabilités pour éviter les régressions

Définissez quel composant a le droit d’ajouter X-Robots-Tag et dans quels cas. Ajoutez quelques tests automatisés pour les ressources critiques, notamment lorsqu’un changement d’infrastructure est prévu. Une migration de CDN ou de serveur peut supprimer une règle utile ou étendre une directive à un mauvais périmètre. Conservez dans le suivi les URLs d’exemple, valeurs attendues et raison de l’exclusion. La clôture doit refléter une politique comprise et reproductible, pas seulement l’absence temporaire d’un en-tête sur une seule réponse testée.

Checklist opérationnelle de validation

Pour clôturer ce contrôle sur X-Robots-Tag, conservez au minimum une URL représentative, l’état avant modification, la règle ou le composant responsable et le résultat du test après correction. Vérifiez également la cohérence avec le parent /seo/indexation-crawl et les pages liées /seo/indexation-crawl, /seo/robots-txt-vs-meta-robots, /seo/page-noindex-dans-sitemap. La décision doit respecter cette limite : Expliquer X-Robots-Tag comme en-tête HTTP et la meta robots comme balise HTML. Ne pas confondre contrôle de crawl robots.txt et directives d’indexation. Si plusieurs occurrences partagent la même cause, testez un échantillon puis confirmez le résultat par un crawl global. Si un cas reste ambigu, laissez-le en revue plutôt que d’appliquer une correction mécanique. Cette trace permettra de reproduire le diagnostic lors d’une prochaine refonte, migration ou évolution du CMS.

Sources officielles

Les règles des moteurs et des fournisseurs de crawlers peuvent évoluer. Les affirmations techniques de cette page sont bornées par les documentations officielles ci-dessous.

• google robots meta