Vérificateur de chaîne de statuts HTTP
Saisissez une URL et voyez chaque saut qu’elle fait pour y arriver : chaque statut de redirection, chaque cible, l’URL finale et les en-têtes de sécurité de la réponse finale — suivi depuis le serveur de sysosx, de sorte que la chaîne est ce que le reste d’internet voit, pas ce que votre navigateur a déjà mis en cache.
Vous préférez que ce soit surveillé automatiquement ? Surveillez-le gratuitement avec myeventwatch — alertes d’expiration et de panne, sans carte.
Ce qu’est une chaîne de redirections
Une chaîne de redirections est la suite d’adresses qu’un navigateur ou un robot visite réellement en route vers la page que vous avez demandée. Vous tapez une URL ; le serveur répond « plus ici, essayez celle-ci » ; le client suit, et le serveur suivant peut répondre la même chose. Chaque étape est un saut, et chaque saut porte un code de statut qui dit de quel type de déménagement il s’agit. Une chaîne d’un saut est la forme normale du web moderne : le http simple passé en https, ou un domaine apex nu envoyé vers www. Une chaîne de deux ou trois sauts signifie généralement que deux systèmes différents ont eu un avis — une règle de CDN plus une règle de CMS, ou une règle de migration empilée sur une plus ancienne. La chaîne affichée par cette page est suivie depuis le serveur de sysosx, saut par saut, chaque saut étant revérifié pour la sécurité avant d’être suivi, jusqu’à cinq sauts.
Le statut de chaque saut est la partie qui mérite d’être lue attentivement. Un 301 ou un 308 dit que le déménagement est permanent : l’ancienne adresse a disparu et les moteurs de recherche doivent transmettre son classement à la nouvelle. Un 302 ou un 307 dit temporaire : l’ancienne adresse peut revenir, donc le classement reste en place et les caches ne doivent pas se figer. Un 303 dit « la réponse est là-bas » et se voit surtout après l’envoi de formulaires. L’échec pratique est un 302 qui devait être permanent — une règle de migration écrite à la hâte — qui perd du classement en silence et laisse les caches servir l’ancienne adresse longtemps après le déménagement. Les chaînes cassent aussi de façons plus ternes : un saut de retour vers une adresse antérieure boucle à l’infini, un saut vers un autre hôte perd le chemin, et un saut de https redescendant vers http défait la sécurité que le premier saut venait d’établir.
Comment lire le résultat
Le résultat liste les sauts dans l’ordre, en commençant par l’URL que vous avez saisie. Une ligne de saut montre l’adresse demandée, le statut renvoyé et — pour une redirection — la cible vers laquelle elle pointait. La dernière ligne est l’adresse qui a réellement répondu avec du contenu, avec son statut, l’en-tête de serveur s’il y en a un, et le temps total du suivi. En dessous, les en-têtes de sécurité de la réponse finale sont résumés : quels en-têtes protecteurs sont présents et lesquels manquent. Une chaîne qui se termine par un statut 4xx ou 5xx n’est pas un problème de redirection, c’est la destination elle-même qui échoue — la chaîne vous dit quand même comment vous êtes arrivé à l’échec, et c’est généralement là que vit la correction. Un résultat « trop de redirections » signifie que le cinquième saut pointait encore plus loin ; la chaîne affichée est la preuve, et la raccourcir est la correction, pas la suivre davantage.
Outils associés : propagation DNS quand le problème est que différents endroits voient des adresses différentes, bilan de santé du site pour le tableau complet — joignabilité, certificat, expiration et enregistrements ensemble — et le vérificateur SSL quand un saut atterrit sur une erreur de certificat.
Lecture complémentaire : pourquoi un site a l’air différent selon l’endroit — chaînes de redirections, propagation DNS et caches intermédiaires, et comment savoir lequel vous mord.
Questions fréquentes
Ce contrôle est-il exécuté depuis mon navigateur ou depuis un serveur ?
Depuis un serveur. Votre navigateur envoie l’URL à sysosx, et le vérificateur de sysosx la récupère — en suivant chaque redirection, saut par saut, depuis sa propre position sur le réseau. C’est tout l’intérêt : une chaîne suivie depuis un serveur montre ce que voient les moteurs de recherche et les réseaux des visiteurs, pas ce que le cache de votre navigateur sait déjà. La requête vient du vérificateur de sysosx, et l’URL que vous saisissez est la seule chose envoyée.
Pourquoi le schéma de départ compte-t-il ?
Parce que le premier saut est souvent le plus important. Une URL saisie en http:// est suivie à partir de http, donc un passage à https apparaît comme son propre saut — exactement ce que vous voulez en auditant si le HTTP simple redirige vraiment. Une URL saisie en https:// est suivie à partir de https. Un nom d’hôte nu utilise https par défaut.
Que signifient les différents statuts de redirection ?
301 et 308 sont permanents : l’ancienne adresse a disparu pour de bon et les moteurs de recherche doivent transférer le classement à la nouvelle. 302 et 307 sont temporaires : l’ancienne adresse peut revenir. 303 signifie « allez voir là-bas » (généralement après l’envoi d’un formulaire). Pour une migration de site, vous voulez presque toujours 301 ou 308 ; un 302 qui devait être permanent perd du classement en silence et embrouille les caches.
Combien de redirections est-ce trop ?
Le vérificateur en suit jusqu’à cinq. Une chaîne d’un ou deux sauts est normale (http vers https, apex vers www). Trois ou plus signifie généralement des couches accumulées : une règle de CDN, une règle de CMS et une ancienne règle de migration qui se déclenchent en séquence. Chaque saut coûte un aller-retour et un peu de signal de classement, et les chaînes au-delà de cinq sont signalées comme excessives au lieu d’être suivies pour toujours — une chaîne aussi longue est elle-même le constat.
Pourquoi y a-t-il une limite de débit ?
Chaque suivi fait de vraies requêtes au serveur de quelqu’un d’autre, saut par saut. Pour rester poli, les suivis frais sont limités par visiteur (une vingtaine par heure, avec une petite marge de rafale) et les résultats sont mis en cache pendant une heure. Un résultat en cache est étiqueté comme tel ; ajoutez ?fresh=1 à l’appel API pour une nouvelle vérification, soumise aux mêmes limites.