En-têtes HTTP d’une URL
Saisissez une URL et lisez chaque en-tête renvoyé par son serveur, tel qu'il est arrivé : type de contenu, règles de cache, cookies et identité du serveur. Comparez deux relevés pour voir ce qu'une mise en ligne a changé. Vous payez à la vérification, sans abonnement.
Exécuter en ligne
Exécutez cette tâche sur nos serveurs, avec votre compte. Les outils gratuits tournent dans votre navigateur ; celui-ci est facturé sur votre solde KIT au prix affiché ci-dessus.
Cette vérification interroge une URL et vous les rend en clair : type de contenu, règles de cache, serveur, compression, cookies posés. C’est la fiche technique de la réponse, celle que le navigateur lit mais ne montre jamais.
Ce que le serveur dit sans l’afficher
Avant d’envoyer le moindre pixel, un serveur transmet une série d’en-têtes qui pilotent le comportement du navigateur. Ils indiquent le type de contenu, s’il faut mettre la page en cache et pour combien de temps, si la réponse est compressée, quel logiciel sert la page, quels cookies sont déposés. Le navigateur les applique en silence.
Les rendre lisibles, c’est accéder à la couche technique qui explique quantité de comportements : une page qui ne se met jamais à jour, un fichier téléchargé au lieu d’être affiché, un cookie posé sans raison apparente.
À quoi cela sert au quotidien
Les en-têtes de cache sont la première piste quand une page semble figée : si le serveur demande de garder la réponse une journée, les visiteurs ne verront pas votre correction avant. Le type de contenu explique qu’un fichier s’ouvre mal ou se télécharge de travers. La compression révèle si la page est allégée avant l’envoi, ce qui pèse sur le temps de chargement.
Lire ces en-têtes remplace les suppositions par une réponse nette : on voit ce que le serveur annonce réellement, pas ce qu’on imagine qu’il fait.
Une lecture simple, un tarif clair
La vérification interroge l’URL publique et lit sa réponse comme le ferait un navigateur : aucune donnée privée n’est requise de votre côté. Le prix est affiché à l’avance, sans frais caché.
Cas d’usage
Comprendre une page qui ne se met pas à jour
Studio Lumen SAS a corrigé une page mais les visiteurs voient l’ancienne : les en-têtes révèlent une règle de cache d’une journée, qui retient l’ancienne version.
Diagnostiquer un fichier qui s’ouvre mal
Un document mis en ligne par Atelier Garnier SARL se télécharge au lieu de s’afficher : le type de contenu renvoyé par le serveur explique le comportement.
Vérifier que la compression est active
Avant d’optimiser un site lent, Thomas Rousseau contrôle si les pages sont bien compressées à l’envoi, ce que les en-têtes indiquent en une ligne.
Questions fréquentes
Comment un en-tête explique-t-il une page figée ?
Les en-têtes de cache disent au navigateur combien de temps conserver une réponse sans la redemander. Si cette durée est longue, vos visiteurs continuent de voir l’ancienne version après une correction. Repérer cette règle explique pourquoi une modification ne s’affiche pas tout de suite.
Quelle différence avec l’audit des en-têtes de sécurité ?
Cette vérification montre l’ensemble des en-têtes renvoyés, tous usages confondus. L’audit de sécurité se concentre sur les en-têtes de protection — HSTS, CSP et les autres — et signale ceux qui manquent. L’un donne la vue complète, l’autre évalue spécifiquement la sécurité.
Faut-il fournir un accès au serveur ?
Non. La vérification lit la réponse publique de l’URL, exactement comme un navigateur qui visite la page. Aucun identifiant, aucun accès d’administration, aucune donnée confidentielle ne vous est demandé.
Combien coûte une vérification ?
Vous réglez à l’usage, et une facture peut vous être adressée pour votre comptabilité si besoin.
Que faut-il surveiller dans la réponse d'un serveur avant et après une mise en ligne ?
Surveillez chaque en-tête censé rester stable, comme le type de contenu, la politique de cache et l'identité du serveur, et vérifiez qu'aucun n'a disparu. Un en-tête absent en dit souvent autant qu'une valeur erronée.
Outils associés
Pour les développeurs — accès API
Tout sur cette page est disponible par programmation. Cette section s'adresse aux équipes qui veulent l'intégrer à leurs systèmes ; les autres peuvent simplement utiliser l'outil ci-dessus.
Endpoint
Authentification par jeton Bearer : un seul POST met la tâche en file d’attente, et le résultat vous parvient par webhook ou lien signé.
Appeler depuis votre stack
curl -X POST https://api.kit.forhosting.com/web/headers \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"url":"https://example.com"}'const res = await fetch("https://api.kit.forhosting.com/web/headers", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"url": "https://example.com"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/web/headers",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"url": "https://example.com"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/web/headers", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"url":"https://example.com"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"url":"https://example.com"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/web/headers", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Exemple de requête
{
"url": "https://example.com"
}Exemple de réponse
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "web.headers",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}L’API est asynchrone : chaque appel renvoie un task_id immédiatement, puis vous interrogez l’état à raison d’une requête par seconde.
Tarifs
Le prix est publié, sans tokens ni crédits. Une tâche qui échoue n’est pas facturée.
Limites
timeout_sec | 30 |
max_crawl_pages | 25 |
Erreurs
| HTTP | Code | Signification |
|---|---|---|
401 | unauthorized | Clé API absente ou invalide : vérifiez l’en-tête Authorization. |
402 | insufficient_balance | Solde insuffisant : rechargez votre compte pour lancer cette tâche. |
404 | unknown_type | Type de tâche inconnu : vérifiez le champ type de votre requête. |
429 | rate_limited | Trop de requêtes : ralentissez la cadence, puis réessayez. |
Notes techniques
Les en-têtes HTTP sont les métadonnées qu’un serveur renvoie avec chaque page, avant même le contenu visible.
Une lecture simple, un tarif clair
Le tarif est de $0.002 par requête, en dollars US, sans abonnement. Vous obtenez le résultat sur cette page ou via l’API, selon que vous inspectez une adresse à la main ou que vous intégrez le contrôle à un outil.
Questions techniques
À quoi servent les en-têtes HTTP ?
À piloter la façon dont le navigateur traite une page : mise en cache, type de contenu, compression, cookies, sécurité. Ils ne sont pas visibles à l’écran mais déterminent une grande partie du comportement d’un site. Les lire aide à diagnostiquer ce qui échappe à l’œil.