Comment fonctionne un vérificateur de statut de site web ?

Lorsque vous demandez à UpOrNot de vérifier un site, il fait à peu près ce que fait votre navigateur en ouvrant une page — mais il s'arrête dès qu'il sait si le serveur a répondu, et il explique la réponse simplement. Voici ce qui se passe derrière le bouton.

Étape 1 — La résolution DNS : trouver le serveur

Les ordinateurs communiquent avec des adresses numériques (comme 93.184.215.14), pas avec des noms. Le DNS (Domain Name System) est l'annuaire d'Internet : il transforme example.com en adresse du serveur qui l'héberge.

• Si le nom n'a aucun enregistrement, le site n'existe pas (ou son domaine a expiré).
• Si les serveurs DNS ne répondent pas, on ne peut pas encore conclure : c'est un problème temporaire ou de configuration.
• Si le nom pointe vers une adresse privée ou interne, nous refusons d'aller plus loin. Plus de détails ci-dessous.

Étape 2 — Les tentatives de connexion

Ensuite, le vérificateur ouvre une connexion vers le serveur, en général une connexion sécurisée HTTPS sur le port 443. Plusieurs choses peuvent échouer : le serveur peut refuser la connexion, ne pas répondre en quelques secondes, ou présenter un certificat de sécurité invalide. Si HTTPS échoue et que vous n'avez pas précisé le protocole, nous essayons aussi HTTP sur le port 80.

Étape 3 — Lire le code de statut HTTP

Une fois connecté, le vérificateur demande la page et lit le code de statut HTTP à trois chiffres en tête de la réponse. C'est le résumé le plus rapide de ce qui s'est passé :

• 200OKLa page a été servie normalement. Le site est en ligne.
• 301 / 302RedirectionLa page se trouve à une autre adresse. Nous suivons jusqu'à 5 redirections et indiquons la destination finale.
• 401 / 403RestreintLe serveur a répondu mais refuse l'accès — souvent une connexion requise ou une protection anti-robots. Le site est joignable.
• 404IntrouvableLe serveur est en ligne, mais cette page précise n'existe pas.
• 429Trop de requêtesLe serveur limite les visiteurs automatisés. Il est en ligne, simplement prudent.
• 500Erreur serveurLe serveur a planté ou rencontré un bug en construisant la page.
• 502 / 503 / 504Passerelle ou surchargeUn proxy ou le serveur est surchargé, en maintenance, ou ne joint pas son backend.

Étape 4 — Transformer les codes en verdict clair

Pourquoi des vérifications transparentes et limitées

Un vérificateur de statut envoie des requêtes aux serveurs d'autres personnes en votre nom. Le faire de manière responsable implique quelques règles strictes :

• Nous identifier. Nos requêtes utilisent un user agent proche d'un navigateur qui nomme aussi UpOrNot et renvoie vers cette page.
• Rester léger. Une seule requête par sonde, un délai court, une lecture limitée et aucune exploration du site. C'est pourquoi nos vérifications ne ralentissent pas les sites et n'affectent pas leur référencement.
• Ne jamais contourner les protections. Si un site affiche un CAPTCHA ou bloque les robots, nous l'indiquons comme protégé. Nous ne cherchons pas à déjouer Cloudflare, les connexions ou d'autres contrôles d'accès.
• Protéger les réseaux privés. Nous ne contactons que des adresses publiques sur les ports 80 et 443, revérifions chaque redirection et refusons localhost, les plages privées et les points de métadonnées cloud. Cela empêche d'utiliser l'outil pour scanner des réseaux internes (une attaque appelée SSRF).
• Limiter l'usage. Chaque visiteur peut lancer un nombre limité de vérifications par minute, ce qui garde le service équitable et prévient les abus.
• Ne publier que ce qui est sûr. La liste publique « Sites vérifiés récemment » n'affiche que les noms de domaine — jamais de chemin, de paramètres ni d'identifiants.