Vérificateur d’en-têtes HTTP : lisez ce que votre serveur envoie vraiment

Chaque page et chaque fichier arrive avec un bloc d’en-têtes de réponse HTTP avant le moindre octet de contenu. Les visiteurs ne les voient jamais, mais les moteurs de recherche les lisent de près : un seul en-tête peut empêcher l’indexation d’une page, désigner son URL canonique, décider de sa durée de mise en cache et de sa compression.

Ce vérificateur d’en-têtes HTTP interroge l’URL et affiche les en-têtes de réponse bruts, exactement tels qu’ils sont renvoyés : ligne de statut, server, cache-control, content-type, content-encoding, X-Robots-Tag, Link et Strict-Transport-Security. Ceux qui comptent pour le SEO s’accompagnent d’une courte explication, de sorte qu’un noindex égaré ou une compression absente saute aux yeux.

Comment vérifier les en-têtes HTTP

1. Saisissez l’URL

   Collez l’adresse d’une page, d’une image ou d’un PDF. Les serveurs traitent souvent les types de fichiers différemment : testez donc l’URL exacte qui vous intéresse.

2. Lisez la réponse brute

   Vous voyez le code de statut ainsi que chaque nom et chaque valeur d’en-tête, dans l’ordre où le serveur les a envoyés.

3. Exploitez les remarques

   Les en-têtes importants pour le SEO sont expliqués, et les valeurs à corriger, comme un X-Robots-Tag inattendu, sont mises en évidence.

Lire une réponse, ligne par ligne

HTTP/2 200
content-type: text/html; charset=UTF-8
content-encoding: br
cache-control: public, max-age=300
link: <https://www.example.com/pricing>; rel="canonical"
x-robots-tag: noindex
strict-transport-security: max-age=31536000; includeSubDomains
vary: Accept-Encoding
server: nginx

• Ligne de statut : le 200 sur lequel les robots se fondent, quoi que dise le texte de la page.
• content-type : du HTML en UTF-8. Un mauvais jeu de caractères déforme les lettres accentuées dans les titres et les extraits.
• content-encoding : br (Brotli) ou gzip signifie que la réponse a été compressée. Les robots de Google prennent en charge gzip, deflate et Brotli.
• cache-control : la durée pendant laquelle les navigateurs et les CDN peuvent réutiliser la réponse.
• link et x-robots-tag : des consignes d’indexation. Ici, la page serait retirée de l’index malgré sa balise canonical.
• strict-transport-security : impose HTTPS lors des visites suivantes (HSTS).

Les noms d’en-têtes ne sont pas sensibles à la casse (RFC 9110) ; HTTP/2 et HTTP/3 les envoient en minuscules.

Les en-têtes qui l’emportent sur votre HTML

Deux en-têtes portent des consignes d’indexation, et ils fonctionnent aussi pour les fichiers dépourvus de <head>, comme les PDF et les images :

• X-Robots-Tag accepte les mêmes règles que la balise meta robots (noindex, nofollow, nosnippet, max-snippet, unavailable_after) et peut cibler un seul robot, comme dans X-Robots-Tag: googlebot: noindex. Voir la spécification de Google sur la balise meta robots et X-Robots-Tag.
• Link peut déclarer rel="canonical" et des alternates hreflang pour les fichiers non HTML.

Pour exclure les PDF de la recherche sur Apache, puis la même chose sur Nginx :

<FilesMatch "\.pdf$">
  Header set X-Robots-Tag "noindex"
</FilesMatch>

location ~* \.pdf$ {
    add_header X-Robots-Tag "noindex";
}

L’accident classique est l’inverse : une règle de préproduction du type Header set X-Robots-Tag "noindex" reportée en production, qui désindexe silencieusement toutes les pages. Elle n’apparaît jamais dans le code source de la page, seulement dans les en-têtes. Le vérificateur d’indexabilité la teste en même temps que la balise meta robots et robots.txt.

Les en-têtes de cache et de compression

Le HTML reçoit en général un max-age court, ou no-cache avec revalidation, afin que les mises à jour apparaissent vite. Les fichiers statiques versionnés, dont le nom change avec le contenu (app.3f9a1c.css), peuvent être mis en cache pendant un an avec cache-control: public, max-age=31536000, immutable.

Les validateurs aident aussi l’exploration. Avec un en-tête ETag ou Last-Modified, les robots de Google peuvent envoyer une requête conditionnelle et recevoir un court 304 Not Modified au lieu de la page complète (présentation des robots d’exploration de Google). Attendez-vous à voir vary: Accept-Encoding sur les réponses compressées, et vary: User-Agent si vous servez un HTML différent aux mobiles et aux ordinateurs sur la même URL. Si du HTML, du CSS ou du JavaScript arrive sans content-encoding, activez Brotli ou gzip ; le test de vitesse de site montre ce que cela vous coûte.

Les en-têtes qui en disent trop

server: Apache/2.4.41 (Ubuntu) ou x-powered-by: PHP/7.4.3 indiquent aux pirates précisément quelles versions rechercher. Masquez-les avec ServerTokens Prod sur Apache, server_tokens off; sur Nginx et expose_php = Off dans php.ini. Pour les en-têtes protecteurs à ajouter à la place, comme Content-Security-Policy et Referrer-Policy, lancez le vérificateur d’en-têtes de sécurité.

Conseils pour contrôler les en-têtes

• Testez une URL de chaque type (une page, une image, un PDF, une feuille de style), car les serveurs appliquent souvent des règles différentes à chacun.
• Comparez la réponse de votre CDN avec celle de votre serveur d’origine ; les règles d’un CDN peuvent ajouter, retirer ou réécrire des en-têtes.
• Cherchez les doublons, par exemple deux lignes cache-control ou deux lignes X-Robots-Tag définies à la fois par une extension et par le serveur.
• Depuis un terminal, curl -s -D - -o /dev/null https://example.com affiche les en-têtes d’une vraie requête GET ; certains serveurs répondent différemment aux requêtes HEAD (curl -I).
• Après une modification de la configuration du serveur, purgez le cache du CDN avant de retester, sans quoi vous risquez de regarder une ancienne copie.

Limites à garder en tête

Nous affichons la réponse à une requête envoyée depuis notre serveur, sans cookies ni connexion. Les en-têtes peuvent varier selon le user-agent, le pays, l’appareil, les cookies ou le nœud du CDN, et certains pare-feu répondent aux requêtes automatisées autrement qu’aux navigateurs. Seuls les en-têtes de réponse sont affichés, pas les en-têtes de requête envoyés par votre navigateur ; pour ceux-là, ouvrez les outils de développement de Chrome, choisissez l’onglet Réseau et cliquez sur la requête du document.

Dernière mise à jour le 30 oct. 2026 par l’équipe Yes SEO.