Vérificateur de Statut de Site
Un vérificateur de statut de site envoie une requête HTTP à une URL et affiche le code de statut renvoyé par le serveur. Les codes 200–399 comptent comme en ligne ; 400–599 ou un délai de connexion dépassé comptent comme hors ligne. Vérifier https://example.com ici renvoie 200 OK en quelques dizaines de millisecondes : le site nous répond donc à nous, et pas seulement à vous.
Codes de statut HTTP et ce que ce vérificateur affiche
| Code | Phrase de motif | Verdict ici | Ce que cela signifie pour votre vérification |
|---|---|---|---|
| 200 | OK | En ligne | Le serveur a répondu normalement. Rien à corriger. |
| 301 | Moved Permanently | En ligne | Redirection permanente. Cet outil ne la suit pas : vous voyez donc le 301 et son en-tête Location. |
| 302 | Found | En ligne | Redirection temporaire, souvent vers une page de maintenance, de connexion ou de routage géographique. |
| 304 | Not Modified | En ligne | Une copie en cache est encore valide. Renvoyé uniquement lorsque la requête transporte des validateurs. |
| 403 | Forbidden | Hors ligne | Le serveur a répondu : l'hôte est donc joignable et il ne s'agit pas d'une panne. Un WAF, un filtre anti-bots ou une liste d'IP autorisées a refusé ce client ; le verdict reste Hors ligne car 403 est un code 4xx. |
| 404 | Not Found | Hors ligne | L'hôte a répondu, il est donc joignable — seul le chemin demandé est absent. Testez ensuite le domaine seul. |
| 429 | Too Many Requests | Hors ligne | Limitation du débit : trop de requêtes en peu de temps. Si la réponse comporte un en-tête Retry-After, attendez l’échéance qu’il indique — un nombre de secondes ou une date HTTP — avant de réessayer. |
| 500 | Internal Server Error | Hors ligne | L'application a planté sur l'origine. Consultez le journal d'erreurs de l'origine. |
| 502 | Bad Gateway | Hors ligne | Un proxy ou un CDN n'a pas pu joindre l'origine, souvent pendant un déploiement. |
| 503 | Service Unavailable | Hors ligne | Surcharge ou maintenance planifiée. Temporaire par définition ; regardez Retry-After. |
| 504 | Gateway Timeout | Hors ligne | L'origine a mis plus de temps à répondre que le proxy n'était prêt à attendre. |
| 0 | Aucune réponse | Hors ligne | Rien n'a répondu : échec DNS, connexion refusée, certificat TLS invalide ou délai dépassé — 8 secondes pour établir la connexion, 15 secondes au total. |
Les verdicts suivent les classes de statut du RFC 9110 : 200–399 est signalé en ligne, 400–599 hors ligne. Le verdict décrit l'URL que vous avez saisie, pas la machine derrière elle — avec un 403 ou un 404, le serveur a répondu, l'hôte est donc joignable et aucun des deux n'est une panne. Un 304 compte comme en ligne parce que la ressource existe ; un 404 compte comme hors ligne parce que l'URL demandée n'existe pas.
Le site est-il hors ligne ou est-ce seulement chez moi ?
La vérification ci-dessus s'exécute sur notre serveur et non dans votre navigateur, et c'est exactement ce qui rend la comparaison utile. Si cette page annonce 200 OK alors que votre navigateur affiche une erreur de connexion, la panne est de votre côté : un résolveur DNS qui a mis en cache un enregistrement mort, un VPN ou un proxy d'entreprise, une entrée dans votre fichier hosts, ou un problème de routage chez votre fournisseur d'accès. Si les deux échouent, l'origine ou son CDN est réellement hors ligne et il n'y a rien à réparer sur votre machine.
Pourquoi les sites web tombent-ils en panne ?
La plupart des pannes se rangent dans six familles, et le code de statut vous dit laquelle vous avez sous les yeux :
- Certificat TLS expiré ou ne correspondant pas au nom — la connexion échoue avant même le début de HTTP, d'où le statut 0.
- Enregistrements DNS modifiés ou expirés : le nom d'hôte ne se résout plus, statut 0 également.
- Le processus applicatif a planté ou manqué de mémoire — 500 depuis l'origine, 502 depuis le proxy placé devant.
- Un trafic supérieur à la capacité, ou une fenêtre de maintenance volontaire — 503, généralement avec Retry-After.
- Une base de données lente ou un démarrage à froid qui dépasse le délai du proxy — 504.
- Un incident chez un fournisseur, un CDN, une région cloud ou un registraire, capable de faire tomber d'un coup des milliers de sites sans rapport entre eux.
Que faire si mon site est hors ligne ?
Procédez de l'extérieur vers l'intérieur, dans cet ordre :
- Lancez la vérification ici pour confirmer que la panne n'est pas limitée à votre réseau.
- Lisez le code. 0 désigne le DNS ou TLS ; 5xx, l'origine ; 403, une règle de pare-feu ; 404, un mauvais hôte virtuel ou un mauvais chemin.
- Ouvrez la liste des en-têtes de réponse — Server, Location et Retry-After nomment la couche qui vous a répondu.
- Consultez les pages d'état de votre hébergeur et de votre CDN avant d'ouvrir un ticket de support.
- Relancez la vérification après chaque modification et exportez le CSV, pour que le ticket d'incident porte des horodatages plutôt que des captures d'écran.
En combien de temps un site web devrait-il répondre ?
Le temps de réponse affiché est l'aller-retour dont notre serveur a eu besoin pour une seule requête HEAD : résolution DNS, connexion TCP, poignée de main TLS et première réponse du serveur. Il exclut les images, le CSS, le JavaScript et le rendu : il est donc bien inférieur à un temps de chargement mesuré par Lighthouse. Voici les plages de couleur utilisées sur cette page :
| Temps de réponse | Couleur | Interprétation |
|---|---|---|
| < 500 ms | Vert | Sain. Typique d'un point de présence CDN ou d'un cache chaud. |
| 500–1500 ms | Jaune | Acceptable mais à surveiller : généralement un aller-retour jusqu'à l'origine, sans cache en périphérie. |
| > 1500 ms | Rouge | Lent. Vérifiez le processeur de l'origine, les requêtes de base de données, les démarrages à froid et le routage intercontinental. |
À propos de Vérificateur de Statut de Site
Un vérificateur de statut de site répond bien à une question très précise : le serveur a-t-il répondu, et qu'a-t-il dit ? Cet outil ouvre une seule requête HTTP HEAD vers l'adresse que vous saisissez, accorde 8 secondes pour établir la connexion et 15 secondes pour l'ensemble de la requête, puis rapporte quatre éléments — le code de statut numérique, le temps d'aller-retour en millisecondes, le Content-Type et l'en-tête Server — ainsi que la liste complète des en-têtes de réponse renvoyés par l'origine.
Deux choix de conception rendent la lecture sans ambiguïté. D'abord, les redirections ne sont pas suivies. Si example.com répond 301, vous voyez 301 et son en-tête Location plutôt que le statut d'une autre page trois sauts plus loin ; c'est exactement ce qu'il faut pour contrôler une règle HTTP vers HTTPS ou non-www. Ensuite, le verdict suit les classes de statut définies par le RFC 9110 : de 200 à 399 est signalé en ligne, de 400 à 599 hors ligne, et un statut 0 signifie que la requête n'a jamais abouti — le DNS n'a pas résolu, la connexion a été refusée, le certificat TLS n'a pas été validé, ou l'origine a dépassé le délai.
La vérification s'exécute depuis notre serveur et non depuis votre navigateur : c'est ce qui permet de trancher entre une panne réelle et un problème propre à votre poste. Si votre machine n'arrive pas à charger un site alors que cette page annonce 200 OK, la faute est locale : votre résolveur, votre fournisseur d'accès, un VPN, un proxy d'entreprise ou une entrée obsolète dans le fichier hosts. Si les deux échouent, le problème se situe à l'origine ou dans son CDN.
Le mode en masse accepte jusqu'à 10 adresses, une par ligne, et les vérifie l'une après l'autre avec une pause de 300 ms entre les requêtes, afin qu'une seule exécution n'épuise pas le quota de 60 vérifications par minute. Les résultats reviennent sous forme de liste compacte, téléchargeable en CSV ou copiable en tableau séparé par des tabulations, directement dans un tableur ou dans un ticket d'incident. Chaque vérification produit aussi un lien partageable qui se relance tout seul quand un collègue l'ouvre : le signalement arrive avec sa preuve, pas avec une capture d'écran.
Une réserve à garder en tête : les requêtes partent d'une IP de centre de données avec l'agent utilisateur FreeWebTools Status Checker/1.0. Les sites protégés par un filtrage anti-bots agressif peuvent nous répondre 403 tout en servant normalement les navigateurs. Lisez donc un 403 comme « ce client a été refusé », et non automatiquement comme « hors ligne ».
Cas d'utilisation
Comment vérifier si un site web est hors ligne
Laissez l'onglet URL unique sélectionné et saisissez l'adresse à tester, par exemple example.com ; si le préfixe https:// manque, il est ajouté automatiquement.
Cliquez sur Vérifier le statut. Une requête HTTP part de notre serveur et la bannière affiche Le site est EN LIGNE pour les codes 200–399, ou Le site est HORS LIGNE pour 400–599 et les délais dépassés.
Lisez les quatre encarts : Code de statut, Temps de réponse, Type de contenu et Serveur. Un temps inférieur à 500 ms s'affiche en vert, supérieur à 1500 ms en rouge.
Ouvrez la liste En-têtes de réponse pour voir tout ce que le serveur a renvoyé, y compris Location sur une 301 et Retry-After sur une 429 ou une 503.
Passez à l'onglet Vérification en masse pour coller jusqu'à 10 URL, une par ligne, puis conservez la série avec Télécharger le CSV ou Copier en tableau.
Utilisez Copier le lien de partage pour envoyer une adresse qui relance exactement la même vérification à l'ouverture.
Astuces Pro
- Testez séparément le domaine seul et la version www. example.com et www.example.com pointent souvent vers des hôtes différents, et un seul des deux peut être en panne.
- Le statut 0 n'est pas un 500. Il signifie que rien n'a répondu du tout : vérifiez la résolution DNS et l'expiration du certificat TLS avant d'accuser l'application.
- Les temps de réponse inférieurs à 500 ms s'affichent en vert, de 500 à 1500 ms en jaune et au-delà de 1500 ms en rouge. Le chiffre ne couvre que l'aller-retour serveur : ni images, ni CSS, ni JavaScript.
- Si vous obtenez 403 ici alors que le site s'affiche dans votre navigateur, un WAF filtre les IP de centres de données ou notre agent utilisateur FreeWebTools Status Checker/1.0. Ce n'est pas une panne.
- Le mode en masse est plafonné à 10 URL et l'API autorise 60 vérifications par minute et par IP. Découpez les listes plus longues en lots plutôt que de réessayer jusqu'au 429.
Dépannage
La vérification renvoie le code de statut 0 et aucun en-tête.
Rien n'a répondu. Le nom d'hôte ne se résout peut-être pas, la connexion a pu être refusée, le certificat TLS peut être expiré ou émis pour un autre nom, ou la requête a dépassé le délai : 8 secondes pour établir la connexion, 15 secondes au total. Contrôlez d'abord le DNS et le certificat, puis testez la version http:// pour isoler une panne TLS.
Nous signalons 403 Forbidden alors que le site s'affiche normalement dans le navigateur.
Une règle de WAF ou d'anti-bots bloque les IP de centres de données ou l'agent utilisateur FreeWebTools Status Checker/1.0. Le site est en ligne : il refuse simplement les clients automatisés. Ajoutez la vérification à la liste d'autorisation ou confirmez depuis une connexion résidentielle.
La vérification en masse s'arrête en cours de route avec un message de limitation.
L'API autorise 60 vérifications par minute et par adresse IP. Attendez soixante secondes puis relancez les URL restantes, ou découpez la liste en lots plus petits. L'exécution espace déjà ses requêtes de 300 ms.
Une page qui fonctionne dans le navigateur renvoie 404 ici.
Vous testez probablement un chemin qui n'existe pas sur cet hôte, ou le domaine pointe vers un hôte virtuel par défaut. Testez d'abord le domaine seul, puis ajoutez le chemin une fois que la racine répond 200.
Questions fréquemment posées
Saisissez l’adresse dans le champ ci-dessus et cliquez sur « Vérifier le statut ». L’outil envoie une seule requête HTTP depuis notre serveur et indique le code de statut, le temps de réponse et tous les en-têtes de réponse. Un code entre 200 et 399 signifie que le site est en ligne ; de 400 à 599, ou un statut à 0, signifie qu’il est hors ligne. Le temps de réponse affiché est l’aller-retour effectué par notre serveur, pas par votre navigateur — résolution DNS, connexion TCP, handshake TLS et première réponse —, souvent quelques dizaines de millisecondes pour une origine proche.
Ce vérificateur s’exécute depuis notre serveur et non depuis votre navigateur : comparer les deux résultats situe donc la panne. Si nous obtenons 200 OK et que la page ne se charge toujours pas chez vous, le problème est de votre côté : cache DNS, VPN, proxy, cache du navigateur ou fichier hosts. Si nous obtenons nous aussi un 502 ou un délai dépassé, la panne est du côté du site et non du vôtre — même si un blocage géographique ou une règle de pare-feu visant notre adresse IP produit ici le même résultat.
503 Service Unavailable signifie que le serveur est joignable mais refuse de traiter la requête pour le moment, généralement à cause d’une surcharge ou d’une maintenance planifiée. C’est temporaire par définition, et la réponse comporte souvent un en-tête Retry-After qui indique quand réessayer. Les moteurs de recherche lisent un 503 bref comme un « revenez plus tard », pas comme une panne définitive.
En pratique : certificats TLS expirés ou non concordants et enregistrements DNS cassés (les deux apparaissent en statut 0), une application qui a planté ou manqué de mémoire (500), un proxy qui n’atteint pas l’origine en plein déploiement (502), un trafic au-delà de la capacité ou une maintenance (503), une base de données plus lente que le délai du proxy (504), et les incidents CDN ou cloud à l’échelle d’un hébergeur.
Confirmez d’abord ici que la panne n’est pas limitée à votre réseau. Lisez ensuite le code : 5xx invite à regarder les journaux de l’origine et le gestionnaire de processus, 0 à vérifier le DNS et l’expiration du certificat, 403 signale une règle de pare-feu ou de WAF, et un 404 sur le domaine seul, un mauvais hôte virtuel. Consultez la page de statut de votre hébergeur avant d’ouvrir un ticket.
Oui. Passez à l’onglet « Vérification en masse » et collez jusqu’à 10 URL, une par ligne. Elles sont vérifiées l’une après l’autre avec 300 ms d’écart entre les requêtes, et les résultats s’affichent en liste avec verdict, code de statut et temps de réponse. Vous pouvez ensuite télécharger toute la série en CSV ou la copier sous forme de tableau séparé par des tabulations.
Non, et c'est délibéré. Les redirections ne sont pas suivies afin qu'un 301 ou un 302 s'affiche exactement tel que le serveur l'a envoyé, avec son en-tête Location — c'est précisément ce qu'il faut pour contrôler une règle HTTP vers HTTPS ou non-www. Pour parcourir toute une chaîne de redirections saut par saut, utilisez plutôt notre Vérificateur de redirections.
Parce que la requête part d'une IP de centre de données avec l'agent utilisateur FreeWebTools Status Checker/1.0. Les services anti-bots, les WAF et les règles de pare-feu des CDN répondent couramment aux clients automatisés par un 403 Forbidden ou une page de vérification, tout en servant normalement les vrais navigateurs. Un 403 renvoyé par cet outil signifie donc « ce client a été refusé », pas toujours « hors ligne ».
C'est le temps, en millisecondes, dont notre serveur a eu besoin pour effectuer une seule requête HEAD, résolution DNS, connexion TCP et poignée de main TLS comprises. Il exclut les images, le CSS, le JavaScript et le rendu : il est donc bien inférieur à un score de chargement Lighthouse. Comparez les mesures entre elles et comptez 100 à 300 ms de plus pour une origine lointaine.
Non. Le point d'accès refuse les noms localhost, 127.0.0.1, 0.0.0.0 et ::1, toute adresse IP d'une plage privée ou réservée comme 192.168.x.x ou 10.x.x.x, les adresses de métadonnées cloud telles que 169.254.169.254, ainsi que les ports sensibles 22, 3306 et 6379. Un nom d'hôte est résolu une fois et refusé si cette adresse IPv4 est privée ; la vérification est uniquement IPv4, considérez-la donc comme une protection contre la falsification de requête côté serveur (SSRF) plutôt que comme une garantie. Testez les hôtes internes avec curl depuis le réseau.
Sources et standards
Les cinq classes de statut et la signification de chaque code proviennent de la spécification HTTP et du registre de l'IANA ci-dessous. Les pages de MDN et de Google Search Central sont de la documentation et non des spécifications, et le 429 Too Many Requests est défini dans le RFC 6585, pas dans le RFC 9110. Le verdict en ligne / hors ligne est notre propre lecture de ces limites de classes : cette page traite 200–399 comme en ligne, et 400–599 ainsi que toute requête qui n'obtient aucun code de statut comme hors ligne.
- RFC 9110, HTTP Semantics, section 15 — la définition normative de chaque classe de statut.
- Registre des codes de statut HTTP de l'IANA — la liste faisant autorité des codes attribués.
- MDN, codes de statut des réponses HTTP — des notes pratiques sur chaque code.
- Google for Developers, « How HTTP Status Codes Affect Google's Crawlers » — ce que chaque code implique pour l'exploration et l'indexation.
- Google for Developers, « Debug Network and DNS Errors for Google's Crawlers » — ce que cela veut dire quand une requête n'obtient aucun code de statut.
- RFC 6585, Additional HTTP Status Codes, section 4 — la définition du 429 Too Many Requests et de son indication Retry-After.