Un client m'envoie un mail affolé : « Google a désindexé 400 pages d'un coup, on a perdu 60 % du trafic en une semaine. » Je regarde Search Console, je regarde le serveur. Le site était sur un hébergement mutualisé qui avait activé une petite règle dans le .htaccess, une règle que personne chez mon client n'avait écrite. Une seule ligne, un en-tête X-Robots-Tag: noindex ajouté par défaut sur tout ce qui sortait de l'application. Quatre cents pages, deux ans de travail, effacées par une header HTTP que personne ne lisait.
Voilà pourquoi je pense qu'on sous-estime massivement les en-têtes HTTP quand on parle d'indexation. Tout le monde connaît les balises meta, les robots.txt, les sitemaps. Mais les en-têtes, c'est le niveau le plus profond de la chaîne : ce que votre serveur dit au robot avant même de lui envoyer la première ligne de HTML. Et dans mon expérience, c'est là que se cachent à la fois les pires catastrophes et les gains les plus rapides.
Points clés à retenir
- Les en-têtes HTTP s'appliquent à tous les types de fichiers, y compris PDF et images, là où les balises meta ne touchent que le HTML.
X-Robots-Tagest l'en-tête le plus puissant pour piloter l'indexation à l'échelle d'un domaine ou d'un répertoire.- Un code de statut mal géré (404 renvoyant 200, redirections en 302 permanentes) gaspille du budget de crawl.
Last-ModifiedetETagbien configurés aident le robot à savoir quoi recrawler en priorité.- La plupart des accidents de désindexation massive viennent d'un en-tête hérité que personne n'a vérifié.
- Un crawl complet (Screaming Frog ou équivalent) doit inclure l'onglet « response headers », sinon vous pilotez à l'aveugle.
Pourquoi les en-têtes HTTP sont le maillon que tout le monde saute
Une requête HTTP, c'est une conversation en deux temps. Le serveur répond d'abord avec ses en-têtes — statut, type de contenu, cache, directives pour les robots — puis il envoie le corps de la page. Le robot de Google lit cette enveloppe avant de savoir de quoi parle votre page. Si l'enveloppe dit « ne m'indexe pas », il n'y a pas de débat : la page n'entrera pas dans l'index, peu importe la qualité de votre contenu.
C'est une différence de niveau, pas de degré. Une balise meta noindex posée dans le HTML exige que le robot ait déjà téléchargé et interprété le document. Un en-tête noindex agit dès la poignée de main. Et surtout, il fonctionne sur des fichiers où aucune balise meta ne peut exister : un PDF de 12 Mo, une image, une vidéo, un flux JSON.
La différence concrète avec robots.txt et la balise meta robots
Trois outils, trois rôles, et une confusion qui revient sans arrêt dans mes audits :
- Le robots.txt bloque le crawl. Le robot ne vient pas chercher la page. Conséquence vicieuse : s'il ne la voit jamais, il ne verra jamais non plus un éventuel
noindexdessus. - La balise meta robots pilote l'indexation, mais uniquement sur les pages HTML, et uniquement après téléchargement.
- L'en-tête X-Robots-Tag fait la même chose que la meta, mais au niveau HTTP, donc sur n'importe quel format, et avec la possibilité de cibler une expression régulière dans la configuration serveur.
Le cas typique où ça compte vraiment : un client publiait des fiches produits en PDF, téléchargeables librement, dont certaines contenaient des tarifs obsolètes. Ces PDF étaient indexés et remontaient en résultat de recherche avec de vieux prix. Aucune balise meta ne pouvait les arrêter. Une règle dans le serveur, en revanche, a réglé le problème en dix minutes.
Quels en-têtes influencent réellement l'indexation, et comment
Bon, soyons clairs : Google ne publie pas une liste officielle « cet en-tête fait gagner X places ». Ce que je peux vous dire, c'est ce que j'observe sur des sites que je suis, et le mécanisme logique derrière chaque en-tête. Voici le tableau que j'aurais aimé trouver il y a quelques années.
| En-tête | Effet sur le comportement du robot | Risque si mal configuré |
|---|---|---|
X-Robots-Tag | Pilote indexation, snippet, suivi des liens — sur tout type de fichier | Désindexation massive silencieuse |
Status (200, 301, 404, 410, 500) | Détermine si la page existe, a bougé, ou est morte | 404 renvoyé en 200 : pages fantômes dans l'index |
Last-Modified | Indique quand la ressource a changé ; sert de signal de fraîcheur | Absent → recrawl moins ciblé |
ETag | Signature de version ; permet de répondre 304 (non modifié) | Mal généré → 304 erronés, contenu invisible |
Cache-Control | Réduit la charge serveur, accélère les visites du robot | Trop agressif → contenu obsolète servi |
Location (avec 301/302) | Destination de la redirection | Chaînes de redirection → crawl gaspillé |
Le code de statut : l'en-tête le plus sous-estimé de tous
Le problème ? Les développeurs n'y pensent pas, parce que « la page s'affiche, donc tout va bien ». Sauf qu'une page de recherche interne qui renvoie 200 sur des millions d'URLs, c'est un aspirateur à budget de crawl. J'ai mesuré ce phénomène sur un site e-commerce de taille moyenne : les pages de résultats de recherche interne représentaient plus de 40 % des URLs explorées sur un crawl de 50 000 pages, et aucune d'elles n'avait d'intérêt à être indexée. On a corrigé en renvoyant un vrai 404 sur les recherches sans résultat et en ajoutant noindex sur les recherches avec résultat. Le crawl hebdomadaire a sensiblement accéléré sur les pages produits.
Last-Modified et ETag : aidez le robot à choisir
Un robot a un budget limité. Il ne peut pas tout recrawler tout le temps. Les en-têtes de validation lui permettent de comparer une version à celle qu'il a en mémoire : si Last-Modified n'a pas bougé, il repart avec un 304 et ne re-traite pas la page. C'est un gain de temps pour lui, donc un gain de fréquence pour vous sur les pages qui comptent.
Franchement, sur un blog ou un site institutionnel, c'est le réglage le plus rentable que je connaisse, et le moins discuté. Sur un site que j'accompagne, la mise en place correcte de Last-Modified (alimenté par la vraie date de modification en base, pas par la date de build) a fait passer le délai moyen entre publication et première visite du robot de plusieurs jours à moins de 24 heures. Rien de magique : on a simplement arrêté de dire au robot « cette page est peut-être neuve, viens vérifier toutes les cinq minutes ».
Comment configurer ces en-têtes sans casser son site
Avant de toucher à quoi que ce soit, faites un crawl complet et exportez l'onglet des en-têtes de réponse. C'est la seule façon de savoir ce que votre serveur raconte déjà. J'ai vu trop de gens ajouter une directive sans réaliser qu'une autre, héritée d'un module ou d'un CDN, la contredisait.
X-Robots-Tag : cibler finement par URL
La force de cet en-tête, c'est la granularité. Voici comment je le pose en pratique, côté serveur :
- Identifier les familles d'URLs à exclure (fichiers temporaires, versions de test, exports PDF confidentiels).
- Écrire une règle qui cible uniquement ces motifs, jamais l'ensemble du domaine.
- Tester d'abord sur un environnement de préproduction, avec un crawl avant/après.
- Vérifier dans la configuration serveur qu'aucun module (sécurité, cache, CDN) n'ajoute déjà un
noindexglobal.
Ce dernier point, c'est ma hantise. C'est exactement le scénario de mon client au début de cet article. Le module de sécurité de son hébergeur posait un X-Robots-Tag: noindex sur tout ce qui n'était pas dans un répertoire précis. Personne ne l'avait documenté. Ce genre de réglage ne se voit pas dans le navigateur — la page s'affiche normalement. Il ne se voit que dans un crawl ou dans curl -I.
Vérifier un en-tête en ligne de commande (le réflexe à prendre)
Une commande, et vous voyez l'enveloppe :
curl -I https://exemple.com/page-testLisez le statut en premier. Puis cherchez X-Robots-Tag, Last-Modified, Cache-Control. Si vous ne voyez pas de Last-Modified sur une page de contenu, c'est une anomalie à investiguer. Si vous voyez un noindex alors que la page doit être indexée, vous venez de trouver une fuite de trafic.
Les erreurs que j'ai commises avec les en-têtes (et que vous pouvez éviter)
Enfin, un peu d'honnêteté. Sur un projet, j'ai voulu désindexer proprement un lot d'anciennes pages catégories. J'ai posé un X-Robots-Tag: noindex par expression régulière. Sauf que mon regex était trop large : il attrapait aussi les nouvelles catégories, dont les URLs contenaient le même motif. Résultat, trois semaines de baisse progressive du trafic avant que Search Console ne signale la chute. Perte estimée : environ 15 % de visites organiques sur la période. J'ai corrigé en deux jours, mais il a fallu des semaines pour que l'index se reconstruise.
La leçon que j'en tire, et je la répète à chaque audit : un en-tête se teste comme une redirection. Sur un échantillon, avec un avant/après chiffré, jamais en production directement.
Les en-têtes HTTP ou les balises meta : lequel choisir ?
Il n'y a pas de réponse unique, mais une règle simple : utilisez l'en-tête quand vous devez couvrir un grand nombre d'URLs ou des fichiers non-HTML, et la balise meta quand vous voulez un contrôle au niveau de la page individuelle, géré par les rédacteurs ou le CMS. Les deux se combinent. En cas de contradiction entre une balise meta « index » et un en-tête « noindex », c'est en général le noindex qui l'emporte — donc vérifiez toujours l'en-tête d'abord.
Faut-il toucher à Cache-Control pour l'indexation ?
Indirectement, oui. Un Cache-Control trop agressif peut servir au robot une version périmée d'une page pendant des heures ou des jours. Ça ne bloque pas l'indexation, mais ça retarde la prise en compte des mises à jour. Sur les sites où je publie beaucoup, je garde des durées de cache courtes sur le HTML et longues sur les assets statiques. C'est un compromis, pas une vérité universelle.
Le vrai enjeu n'est pas là, de toute façon. Les en-têtes HTTP ne sont pas un levier d'optimisation fine : c'est une barrière de sécurité pour votre index. Tant qu'ils sont propres, personne n'y pense. Le jour où ils ne le sont plus, ils vous coûtent des mois de reconstruction. Alors avant de peaufiner votre balise title ou votre maillage interne, allez jeter un œil à ce que votre serveur chuchote au robot. Il y a peut-être une ligne qui travaille contre vous depuis des mois.
