Website Status Checker

Échantillonne le status final d'un site plusieurs fois de suite, compare-le aux headers de première réponse et au chemin de redirection, et lis un rapport de disponibilité.

Ce website status checker te dit si un site est up, et plus utilement, ce que l'URL renvoie vraiment, depuis notre serveur plutôt que depuis ton navigateur peut-être en cache. Il échantillonne le status final plusieurs fois pour qu'une lecture isolée ne te trompe pas, puis il le compare à l'URL exacte que tu as tapée : son status de première réponse, ses headers, et le chemin de redirection qu'elle parcourt avant d'atterrir. Le rapport garde les indices séparés, le downtime ici, un bazar de redirections là, un serveur lent ailleurs, pour que tu arrêtes de deviner en plein incident. Il note le run, nomme les longues chaînes de redirection et les fins en erreur, et te file un résumé copiable. Pensé pour le déploiement, la migration, le changement de permaliens, et le ticket de support qui dit juste que le site est down.

Les requêtes passent par le service de lookup PeopleAreGeek. Nous ne journalisons rien.

Audit de disponibilité en direct et du chemin de réponse

Teste une URL comme tu le ferais en plein incident, quand quelqu'un te harcèle et que le chrono tourne. L'outil échantillonne le status final plusieurs fois de suite, puis il le compare à ce que fait l'URL brute que tu as saisie, en premier. Le chemin de redirection, le contexte des headers, tout y passe. Tu repars avec un rapport qui sépare bien le downtime d'un bazar de redirections d'un serveur lent. Franchement, cette séparation, c'est tout l'intérêt du truc.

URL à vérifier

Samples de status final

Le check répété suit jusqu'à cinq redirections. Les panneaux headers et redirections, eux, regardent l'URL exacte que tu as tapée, avant que qui que ce soit suppose que la page finale va bien.

Ce qu'un website status checker devrait répondre en premier

Quand une page semble cassée, la question qui aide vraiment, ce n'est pas « est-ce qu'elle a l'air correcte ? ». C'est « qu'est-ce que l'URL a renvoyé ? ». Un status check te donne ce premier bout de vérité. Est-ce que la requête a même atteint un serveur. Quel code HTTP est revenu. Est-ce qu'il est resté stable sur plusieurs samples ou est-ce qu'il a vacillé. Et celle qu'on oublie toujours : est-ce que l'URL que tu as tapée est bien la page où atterrissent les visiteurs, ou juste le premier saut avant qu'une redirection les emmène ailleurs.

Ça mord après un déploiement. Après une mise à jour de plugin aussi, ou une migration qui a déplacé une URL produit, ou ce ticket de support qui dit juste « le site est down » et rien d'autre. Un onglet de navigateur tout vert ment en permanence. Il cache une redirection, une réponse en cache, un chemin qui se charge pour toi et renvoie un 404 à la personne au téléphone. Un petit status report te garde honnête avant d'aller te perdre dans le contenu, le JavaScript ou je ne sais quoi que font les métadonnées.

Le status final et la première réponse ne sont pas le même indice

Le status final répond à la question de l'utilisateur : une fois les redirections décantées, est-ce que la cible répond ? La première réponse répond à autre chose, à la question de la plomberie, c'est-à-dire ce que fait l'URL exacte que tu as tapée avant que quoi que ce soit suive une redirection. Lis-les côte à côte. Une vieille URL en HTTP peut très bien atterrir sur une page HTTPS en parfaite santé, et quand même y arriver en trois sauts de trop. Une faute de frappe te donne un beau 404. Et un serveur peut te renvoyer un 302 vers un écran de login, qui techniquement se charge, oui, mais ce n'est pas la page publique qu'espérait un crawler.

2xx veut dire en général que ce que tu as échantillonné a répondu, et qu'il a bien répondu.
3xx veut dire que ça te pointe ailleurs, donc va voir le chemin de redirection.
4xx veut dire que la ressource ou la règle d'accès a dit non pour cette requête.
5xx, c'est le serveur qui s'écroule. Là, le boulot de fiabilité passe devant tout le reste.
Timeout ou échec de fetch t'envoie creuser du côté réseau, DNS, firewall ou TLS, bien avant de toucher à la page elle-même.

Comment utiliser le rapport pendant le dépannage

Commence par le résumé. Tous les samples online, la famille de status stable, le temps de réponse pas honteux ? Bien, passe aux headers, aux redirections et au reste qui touche à la page. Mais si les samples ne sont pas d'accord entre eux, n'arrange pas ça en conclusion. Garde la raw data et relance. Les pannes intermittentes, c'est le pire, et en général elles réclament des logs serveur, des logs de la couche cache, une trace applicative, peut-être un deuxième point de monitoring qui observe d'ailleurs, avant d'avouer ce qui cloche.

Le panneau response path reste pratique, et c'est voulu. L'URL saisie, le status de la première réponse, la chaîne de redirections qu'il a échantillonnée, l'URL finale que ce checker voit réellement. Ça suffit en général à attraper les bêtises évidentes. HTTP et HTTPS qui se contredisent en douce. Un vieux slug qui rebondit encore à travers quatre redirections historiques que personne n'a nettoyées. Un login qui squatte là où il y avait une page publique. Ou un 404 qui n'a jamais eu sa règle de redirection après que quelqu'un a changé la structure des permaliens et a oublié.

Status checks et SEO technique

Un status checker ne fera pas bouger ton classement. C'est un check de fondation, du genre ennuyeux. Les crawlers comme les gens ont besoin que tes URLs importantes répondent de façon fiable et atterrissent sur une seule page canonique claire, sans détour par des chemins d'erreur. Donc avant d'aller peaufiner des balises title ou du schema, confirme que l'URL renvoie le status que tu attends. Confirme que le chemin de redirection est bien celui que tu voulais mettre en place. Assure-toi que la page finale peut vraiment être indexée, et que tes liens internes pointent vers la destination, pas vers une vieille redirection qui aurait dû partir à la retraite depuis longtemps.

Sur WordPress, il fait gagner son temps après un changement de thème, une modif de permaliens, un nouveau plugin de cache ou de sécurité, un changement de CDN, une migration HTTPS. N'importe lequel peut réécrire tes headers ou tes redirections sans toucher un seul mot de l'article visible, et c'est exactement comme ça que ça te passe sous le nez. Fais un audit rapide avant le changement, puis encore une fois après. Comme ça, le comportement caché a un endroit pour se montrer.

Questions fréquentes

Un HTTP 200 veut-il dire que la page est parfaite ?

Non. Tout ce que ça veut dire, c'est que la requête HTTP que tu as échantillonnée est passée. La page en dessous peut très bien être pauvre, cassée visuellement, bloquée à l'indexation, pointer vers le mauvais canonical, lancer des erreurs JavaScript, ou juste mettre une éternité à s'afficher. Le 200, c'est la porte qui s'ouvre. Ça ne dit rien sur la pièce.

Pourquoi une page d'erreur peut-elle quand même avoir l'air online ?

Parce que certaines applis habillent leurs erreurs. Elles servent une jolie page brandée avec une mise en page qui a l'air de marcher, et ton œil y croit. Le status code ne ment pas comme le fait la mise en page, donc fie-toi au code. Une page vraiment absente n'a rien à faire à se faire passer pour un 200 normal, et pourtant un paquet d'entre elles font exactement ça.

Est-ce la même chose que du monitoring d'uptime ?

Non, et la différence compte. Ici, c'est un instantané que tu prends à la demande, une poignée de samples maintenant. Le monitoring d'uptime, c'est le truc qui tourne sur un planning en permanence, qui garde l'historique, qui te réveille à 3h du mat, et qui compare dans le temps et entre plusieurs endroits. Deux boulots différents. Honnêtement, tu veux les deux.

Qu'est-ce que ce checker me dit qu'un navigateur ne dit pas ?

Le brut que ton navigateur lisse pour toi. Le vrai status code, le temps de réponse, le comportement des redirections, tout lu depuis un point neutre qui n'est pas ta machine. Ce dernier point, c'est le morceau utile : il t'aide à distinguer une vraie panne de ton propre réseau ou d'un cache périmé qui te ment en local.

Mon site est-il down pour tout le monde ou juste pour moi ?

Manière rapide de le savoir. Si le checker atteint le site et que toi non, c'est toi : ton DNS, ton cache, ton réseau, ton FAI, un truc de ton côté. Si le checker revient lui aussi les mains vides, alors c'est réel, et le problème vit sur le serveur ou là où c'est hébergé.

Quel status code veut dire que le site est en bonne santé ?

Le 200 OK, c'est ta base pour « en bonne santé ». Les codes 3xx sont des redirections qui t'envoient ailleurs. Les 4xx sont des erreurs client ou de page introuvable. Et 5xx veut dire que le serveur lui-même a planté, ce qui pointe du doigt l'application ou l'hébergeur plutôt que toi.