Liste des en-têtes HTTP à vérifier pour booster votre SEO

« Ton site passe en noindex. » Cette phrase, je l'ai reçue un mardi matin d'un client paniqué. Son trafic avait chuté de 62 % en dix jours. On a tout vérifié : balises meta, contenu, maillage. Rien. Le coupable était une ligne dans un fichier de config nginx, un X-Robots-Tag: noindex ajouté par un prestataire pour "protéger" un environnement de préprod. Sauf que la config avait migré en prod. Trois semaines de galère pour une seule ligne invisible dans le navigateur.

Le problème avec les en-têtes HTTP, c'est qu'ils ne se voient pas. Vous ouvrez votre page, tout s'affiche, vous êtes content. Mais Googlebot, lui, lit ces lignes que personne ne regarde. Et parfois, il lit exactement le contraire de ce que vous croyez avoir dit.

La liste des en-têtes HTTP à vérifier pour le SEO, classée par urgence

Il y a une trentaine d'en-têtes qui passent dans une réponse HTTP classique. Sur ceux-là, une dizaine mérite votre attention. Le reste, franchement, vous pouvez l'ignorer sans risque.

Les en-têtes qui décident de l'indexation

Le premier, c'est X-Robots-Tag. Il fonctionne comme la balise meta robots, mais au niveau du transport. Vous pouvez le poser sur un fichier PDF, une image, un flux JSON — tout ce qui n'accepte pas de balise dans le corps.

Les valeurs à connaître :

• noindex — retire la ressource des résultats de recherche.
• nosnippet — empêche l'affichage d'un extrait.
• noarchive — supprime le lien vers la version en cache (de moins en moins utile, le cache ayant largement perdu de son intérêt).
• max-snippet: 160 — limite la taille de l'extrait affiché, en caractères.
• unavailable_after — date après laquelle la page disparaît des résultats. Pratique pour un événement daté.

Le piège que j'ai vu le plus souvent : un hébergeur pose X-Robots-Tag: noindex sur tous les environnements de test. Puis vous faites pointer un domaine secondaire vers cette préprod pour une démo client. Google découvre le domaine, le crawle, lit le noindex. Quand vous basculez enfin vers la prod sans retirer l'en-tête, vous perdez tout. Vérifiez systématiquement curl -I https://votresite.fr après chaque mise en production.

Canonical, hreflang : ce que beaucoup oublient

Deuxième famille : les en-têtes Link. Ils transportent les indications de canonicalisation et les alternances linguistiques.

Un exemple concret, celui que j'utilise pour les PDF :

Link: <https://exemple.fr/page-principale>; rel="canonical"

Ça marche aussi pour l'hreflang, ce qui dépanne quand vous ne pouvez pas toucher au <head> :

Link: <https://exemple.fr/en/>; rel="alternate"; hreflang="en"

Attention à un détail que j'ai mis du temps à comprendre : si votre en-tête Link: canonical et votre balise <link rel="canonical"> pointent vers deux URL différentes, Google peut partir en vrille. Il choisit généralement l'en-tête HTTP, mais il peut aussi ignorer les deux si la contradiction est trop flagrante. J'ai perdu deux semaines sur ce cas l'an dernier — une régie publicitaire injectait un canonical dynamique côté serveur, incomplet, qui doublait celui du HTML.

Cache-Control, ETag, Last-Modified : l'impact caché sur le crawl budget

Vous vous demandez peut-être pourquoi votre site de 800 pages se fait crawler à 40 pages par jour. Ne cherchez pas du côté de votre sitemap. Regardez vos en-têtes de cache.

Les valeurs qui changent tout

Cache-Control indique combien de temps un intermédiaire (navigateur, CDN, Googlebot) peut réutiliser une réponse. Trois directives comptent :

• max-age — durée de validité en secondes. En dessous de 3600 sur des ressources statiques, vous dilapidez votre bande passante. Au-dessus de 86400 (24 h), vous risquez de servir du contenu périmé pendant une journée entière.
• public ou private — autorise ou interdit la mise en cache par les CDN et proxys.
• no-store — interdit toute mise en cache. À réserver aux pages sensibles, jamais à vos articles.

Ce que beaucoup ignorent : Googlebot respecte Cache-Control. Si vos pages renvoient systématiquement Cache-Control: no-store, Googlebot revient les voir très souvent, ce qui consomme du crawl budget pour rien. À l'inverse, un max-age élevé sur du contenu qui change peu permet à Googlebot de se concentrer ailleurs. Mon réglage actuel sur un blog de 1 200 URL : max-age=86400, public, stale-while-revalidate=3600. Le crawl est passé de 3 à 4 jours en moyenne entre deux passages à quasiment quotidien sur les pages fraîches.

ETag et Last-Modified, les tièdes de service

ETag fournit une empreinte unique de la ressource. Last-Modified donne sa date de modification. Une requête conditionnelle (If-None-Match ou If-Modified-Since) permet au client de ne récupérer le corps que si quelque chose a changé. Résultat : moins de bande passante, et un signal de fraîcheur honnête pour les crawlers qui en tiennent compte.

Un piège classique : deux serveurs en cluster qui calculent chacun leur propre ETag pour la même ressource. Vous obtenez deux empreintes différentes, et Googlebot croit que le contenu change à chaque appel. Il revient. Encore. Et encore.

En-tête	Valeur attendue	Impact SEO	Criticité
X-Robots-Tag	absent ou index, follow	Contrôle l'indexation	Critique
Link (canonical)	URL absolue unique	Évite le contenu dupliqué	Critique
Cache-Control	max-age ≥ 3600 sur statique	Fréquence de crawl	Élevée
Vary	Accept-Encoding minimum	Évite les collisions de cache	Moyenne
Content-Encoding	gzip ou br	Vitesse de transfert	Moyenne
Content-Type	text/html; charset=UTF-8	Interprétation du contenu	Critique
Strict-Transport-Security	max-age=31536000 minimum	Confiance HTTPS	Faible mais recommandée
Server / X-Powered-By	masqués si possible	Aucun direct	Négligeable

Vary et Content-Encoding : les en-têtes qu'on oublie de vérifier

Il y a une catégorie d'en-têtes que je ne vois jamais dans les checklists SEO classiques, et pourtant. Vary indique aux caches que la réponse dépend de certains paramètres de la requête. Si vous servez du gzip aux clients qui le supportent et du non-compressé aux autres, vous devez renvoyer Vary: Accept-Encoding. Sinon, un cache intermédiaire peut servir du gzip à un client qui ne le décode pas, ou l'inverse.

Conséquence SEO indirecte : si le CDN sert une version cassée à Googlebot, il peut recevoir du binaire à la place du HTML. J'ai vu ce cas une fois sur un site e-commerce. Le diagnostic avait pris quatre jours parce que le bug n'apparaissait que sur 8 % des requêtes.

Faut-il activer Brotli ?

Oui, si votre serveur le supporte. Content-Encoding: br compresse environ 15 à 20 % mieux que gzip sur du HTML. Sur un site à forte volumétrie, c'est un gain gratuit sur le temps de transfert. À condition de garder gzip en secours pour les vieux clients.

Les erreurs de configuration que je rencontre le plus

Voici la liste, dans l'ordre de fréquence observée chez mes clients :

1. Chaînes de redirection. A → B → C → D. Chaque saut coûte du temps et dilue légèrement l'autorité. Au-delà de 3 sauts, vous perdez réellement. Certains outils en ligne signalent jusqu'à 8 sauts sur des sites institutionnels.
2. Redirection 302 au lieu de 301. Une 302 est temporaire par définition ; Google peut décider de garder l'ancienne URL dans l'index. Quand le déménagement est définitif, posez 301.
3. X-Robots-Tag hérité de l'environnement de test. Le cas que j'ai décrit en ouverture. Toujours vérifier après un déploiement.
4. Cache-Control: no-cache posé partout. Beaucoup de frameworks le mettent par défaut. Résultat : plus de requêtes inutiles, plus de charge serveur, crawl ralenti.
5. Content-Type sans charset. Un serveur qui renvoie text/html sans préciser l'encodage laisse le navigateur deviner. Sur des pages accentuées, vous risquez des caractères mal affichés — et un signal négatif sur l'expérience utilisateur.

Comment vérifier ces en-têtes concrètement

Trois méthodes, par ordre de fiabilité décroissante.

Le terminal. Une commande qui fait tout :

curl -sI https://exemple.fr | grep -iE 'x-robots|link|cache-control|vary|content-type|strict-transport'

C'est ce que j'utilise à chaque mise en production. Cinquante secondes, zéro ambiguïté. Si vous voulez aller plus loin, ajoutez -L pour suivre les redirections et -w "%{http_code} %{url_effective}\n" pour afficher la chaîne complète.

Les outils en ligne (header checker divers, extensions navigateur) sont pratiques pour un diagnostic ponctuel, mais ils passent souvent par leur propre cache ou leur propre user-agent. Ce qu'ils voient n'est pas toujours ce que Googlebot voit. Le terminal, au moins, vous donne la vérité brute.

Pour une vérification à l'échelle, un crawler type Screaming Frog renvoie les en-têtes de chaque URL dans l'onglet Response Headers. Sur un site de 10 000 pages, c'est la seule méthode praticable.

Comment vérifier ce que Googlebot voit réellement

Passez par l'User-Agent de Googlebot :

curl -sI -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://exemple.fr

Certains serveurs servent des en-têtes différents selon le client. Rare, mais ça existe — notamment sur des configs anti-bot mal faites qui noient Googlebot dans le lot.

En-têtes de sécurité : vraiment un sujet SEO ?

Non, pas directement. Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options n'influencent pas le classement. Mais.

Une CSP trop restrictive peut bloquer l'exécution de scripts que Google utilise pour le rendu. Si votre site repose sur du JavaScript côté client, et que votre CSP interdit les inline scripts chargés par votre framework, Googlebot verra une page vide. Le rendu échoue, l'indexation suit le même chemin. J'ai eu ce cas une fois sur un site React mal configuré : 400 pages indexées en version blanche pendant six semaines avant qu'on s'en aperçoive sur un rapport de couverture.

HSTS, de son côté, force le navigateur à utiliser HTTPS. C'est une bonne pratique, mais à activer avec précaution : une fois posé avec un max-age élevé, il est difficile de revenir en arrière. Ma règle : commencer par max-age=300 pendant une semaine, surveiller les erreurs de certificat, puis passer à 31536000. Le preload, en revanche, je le déconseille sauf cas particulier. Une fois dans la liste de préchargement des navigateurs, la sortie prend des mois.

Ce qui reste, quand on a tout vérifié, c'est souvent l'en-tête le plus bête qui pose problème. Un noindex oublié. Un canonical contradictoire. Un cache mal calibré. Le SEO technique, c'est rarement spectaculaire — c'est surtout une affaire de discipline et de vérifications répétées aux bons moments, c'est-à-dire juste après chaque déploiement.