Vérificateur de redirections : découvrez où mène une URL ou un lien
Un vérificateur de redirections suit une URL de saut en saut et indique le statut HTTP de chacun jusqu’à la fin de la chaîne. Saisissez http://github.com et il enregistre deux sauts : le saut 1 répond 301 Moved Permanently et pointe vers https://github.com/, qui répond 200 OK. Il n’y a donc qu’une redirection, ce qui est sain ; chaque redirection supplémentaire ajoute un aller-retour. Ce vérificateur suit les réponses 301, 302, 303, 307 et 308 ainsi que les balises HTML meta refresh, signale les boucles et les chaînes longues, et peut envoyer la requête en se présentant comme Googlebot ou comme un smartphone.
Une URL par ligne, 10 au maximum. Chaque URL est suivie séparément, puis tout le lot peut être exporté.
Résultats du lot
| URL de départ | Redirections | Statut final | URL finale | Temps (ms) | Remarque |
|---|---|---|---|---|---|
Destination finale
Chaîne de redirections
Cette URL passe par plus d’une redirection avant la page finale. Chaque saut supplémentaire coûte un aller-retour ; faites pointer la première URL directement vers la destination finale.
Boucle de redirection détectée
Cette URL redirige vers une page déjà présente dans la chaîne : elle n'atteint donc jamais de destination finale.
Chaîne de redirection trop longue
La chaîne redirigeait encore après 10 sauts : la vérification s’est arrêtée là.
Arrêt au bout de 20 secondes
La chaîne se poursuivait encore quand le temps alloué à une vérification s’est écoulé. La dernière URL atteinte est indiquée ci-dessous.
Chaîne de redirections
Outils populaires
À propos de Vérificateur de redirections
Ce vérificateur de redirections retrace ce qui se passe réellement entre l’URL que vous saisissez et la page qui finit par se charger. Depuis notre serveur, il envoie une requête GET par saut, sans cookies, enregistre le code de statut, l’en-tête Location et la durée de chaque saut, puis passe à l’URL suivante jusqu’à obtenir une réponse qui n’est pas une redirection — ou jusqu’à 10 sauts, ce qui correspond déjà à la profondeur maximale suivie par les robots d’exploration de Google et à environ la moitié des quelque 20 sauts qu’un navigateur accepte avant d’abandonner avec ERR_TOO_MANY_REDIRECTS.
Quand un saut répond 200 avec une page HTML, le vérificateur en lit au maximum les 64 premiers Ko à la recherche d’une balise meta refresh, car ce type de redirection se trouve dans la page et non dans les en-têtes. Rien n’est exécuté sur la page, ce qui explique aussi que les redirections JavaScript lui échappent : elles n’existent qu’une fois que le navigateur exécute les scripts de la page.
Le résultat est volontairement littéral. Le saut 1 est l’URL que vous avez saisie, et chaque ligne suivante est l’URL exacte vers laquelle le saut précédent vous a envoyé, y compris le changement de protocole, le www ajouté ou retiré, le slash final et la chaîne de requête ; un saut atteint via une balise meta refresh est signalé comme tel, avec son délai. C’est ce qui rend l’outil utile pour les migrations : une règle qui semble correcte dans une configuration nginx se comporte souvent autrement dès que HSTS, une règle côté CDN et une redirection canonique gérée par l’application se cumulent, et la seule façon de voir le résultat réel est de le suivre depuis l’extérieur.
Comme certains sites envoient les mobiles, les robots d’exploration et les navigateurs sur ordinateur vers des destinations différentes, la requête peut se présenter comme notre propre robot, comme Chrome sous Windows, comme Safari sur iPhone, comme Googlebot (smartphone ou ordinateur) ou comme Bingbot.
Le mode par lot accepte jusqu’à dix URL à la fois, les suit l’une après l’autre et vous fournit un tableau — nombre de redirections, statut final, URL finale et temps total — que vous pouvez exporter en CSV ou coller directement dans un tableur ou un ticket. Le bouton des variantes génère les quatre combinaisons de http et https, avec et sans www, pour l’adresse saisie et les suit d’un seul coup : c’est le moyen le plus rapide de confirmer que tous les points d’entrée convergent vers une seule URL canonique.
L’outil tranche en quelques secondes des questions typiques : l’ancienne URL d’un produit mène-t-elle toujours à la nouvelle en une seule 301, la règle HTTP vers HTTPS a-t-elle survécu au dernier déploiement, un lien d’affiliation garde-t-il sa chaîne de requête jusqu’au bout, et où aboutit exactement un lien raccourci ? Les adresses privées, localhost et les points de terminaison de métadonnées cloud sont refusés, et chaque vérification s’arrête au bout de 20 secondes : le vérificateur ne peut donc pas servir à sonder un réseau interne.
Cas d'utilisation
Comment vérifier où redirige une URL
Collez l’URL ou le lien à tester, par exemple http://github.com, ou cliquez sur l’un des exemples proposés sous le champ de saisie.
Si vous le souhaitez, choisissez qui envoie la requête : notre robot par défaut, Chrome, un iPhone, Googlebot ou Bingbot. Les sites qui traitent différemment les mobiles ou les robots afficheront une chaîne différente.
Appuyez sur Entrée ou cliquez sur « Vérifier les redirections ». Notre serveur interroge chaque saut et suit les réponses 301, 302, 303, 307 et 308 ainsi que les balises meta refresh, dans la limite de 10 sauts.
Lisez le récapitulatif : le nombre de redirections trouvées, le statut HTTP final, le temps total et l’URL finale. Un avertissement s’affiche si l’URL boucle ou passe par plus d’une redirection.
Suivez la chaîne de redirections numérotée pour voir chaque saut avec son URL, son badge de statut (par exemple 301 Moved Permanently), s’il s’agit d’une redirection meta refresh et le temps qu’il a pris.
Pour tester plusieurs adresses, passez en mode par lot (jusqu’à 10 URL) ou cliquez sur le bouton des variantes pour suivre d’un coup les versions http, https, avec et sans www, puis exportez les résultats en CSV.
Astuces Pro
- Visez une seule 301 directement vers l’URL finale. Chaque saut supplémentaire coûte un aller-retour complet, un saut qui passe en HTTPS ajoute une négociation TLS, et un saut qui change d’hôte ajoute en plus une résolution DNS — au total, généralement 100 à 300 ms sur une connexion mobile avant que quoi que ce soit ne s’affiche.
- Utilisez 308 plutôt que 301 quand la requête redirigée peut être un POST. Avec 301 et 302, les clients sont autorisés à remplacer la méthode par GET ; avec 307 et 308, ils doivent conserver la méthode et le corps de la requête.
- Testez les versions http:// et www en plus de la version https:// ; le bouton des variantes s’occupe des quatre d’un coup. Bien des sites redirigent correctement en HTTPS alors qu’une règle HTTP obsolète pointe encore vers un hôte mis hors service.
- Regardez le statut du dernier saut, pas seulement le nombre de redirections. Une chaîne qui se termine par un 404 ou un 405 est cassée, même si chaque redirection en chemin était une 301 impeccable.
- Après une migration, testez en mode par lot vos principales URL issues de la Search Console, téléchargez le CSV et comparez-le avec celui de la même liste une semaine plus tard pour repérer les règles qu’un déploiement a discrètement annulées.
Dépannage
La vérification renvoie un 403 quand je choisis Googlebot.
Beaucoup de grands sites vérifient qu’un visiteur se présentant comme Googlebot provient réellement du réseau de Google et refusent tous les autres, y compris ce vérificateur. Comparez avec le user-agent par défaut ou Chrome ; pour voir ce que Google lui-même a reçu, utilisez l’outil d’inspection d’URL de la Search Console.
La chaîne se termine par un 403, un 405 ou un 503, mais la page s’ouvre dans mon navigateur.
Le site filtre probablement les clients : une protection anti-bots ou un défi du CDN qui exige cookies et JavaScript, ou un blocage des plages d’adresses IP de serveurs. Essayez le user-agent Chrome ou iPhone ; si la réponse ne change pas, le filtre se fonde sur le réseau ou sur le comportement, et une vérification côté serveur ne peut pas le franchir.
Mon navigateur affiche ERR_TOO_MANY_REDIRECTS, mais le vérificateur montre une chaîne normale.
La boucle dépend probablement d’un élément que ce vérificateur n’envoie pas : un cookie, une session connectée ou l’entrée HSTS que conserve votre navigateur. Effacez les cookies du site ou ouvrez une fenêtre de navigation privée, puis comparez les versions http:// et https:// avec le bouton des variantes pour trouver la règle qui renvoie les visiteurs en arrière.
Un saut échoue sur une erreur de certificat SSL au lieu d’un code de statut.
Le certificat de cet hôte est expiré, autosigné ou émis pour un autre nom : la connexion est donc refusée avant qu’une redirection puisse être lue. Les navigateurs s’arrêtent au même endroit. Renouvelez ou corrigez le certificat, ou faites pointer le saut précédent vers un hôte doté d’un certificat valide.
Questions fréquemment posées
Il montre où une URL envoie réellement les visiteurs et les moteurs de recherche. Vous obtenez chaque saut entre l’adresse saisie et la page qui répond finalement, avec le code de statut et la durée de chacun. Cela répond à trois questions à la fois : la redirection se déclenche-t-elle, pointe-t-elle vers la bonne destination, et combien de sauts sont gaspillés en route ? C’est aussi un moyen sûr de savoir où mène un lien raccourci ou d’affiliation avant de cliquer dessus.
Une redirection 301 indique que le déplacement est permanent : les navigateurs la mettent en cache, et Google regroupe les signaux de classement de l’ancienne URL sur la nouvelle adresse et ne conserve l’ancienne que comme nom alternatif ; celle-ci cesse donc généralement d’apparaître dans les résultats, mais peut encore ressortir quand une requête laisse penser que les internautes lui font confiance. Une 302 indique que le déplacement est temporaire : l’URL d’origine reste donc normalement indexée, et la réponse n’est pas mise en cache, sauf si les en-têtes l’autorisent. Utilisez la 301 pour les migrations et le passage en HTTPS, et la 302 uniquement pour les tests A/B et les pages de maintenance.
Une seule, c’est l’objectif ; deux, c’est tolérable ; à partir de trois, il faut raccourcir la chaîne. Les navigateurs abandonnent après une vingtaine de sauts, et les robots d’exploration de Google suivent jusqu’à 10 sauts de redirection avant de traiter l’URL comme une erreur. Chaque saut supplémentaire coûte un aller-retour, un saut qui change de protocole ajoute une négociation TLS, et un saut qui change d’hôte ajoute en plus une résolution DNS : une chaîne de trois redirections peut ainsi ajouter plusieurs centaines de millisecondes sur mobile avant l’arrivée du premier octet de contenu réel.
Saisissez votre domaine et cliquez sur le bouton des variantes. Il suit http://, https://, http://www. et https://www. pour le même chemin, en un seul lot. Dans une configuration saine, les quatre aboutissent à la même URL finale, qui répond 200 : la version canonique n’affiche aucune redirection et chacune des trois autres une seule 301 ou 308. Deux redirections sur la version http://www. signifient généralement que le protocole et l’hôte sont corrigés par des règles distinctes, qui peuvent être fusionnées en une seule.
Oui. Choisissez le user-agent avant de lancer la vérification : Chrome sous Windows, Safari sur iPhone, Googlebot pour smartphone ou pour ordinateur, ou Bingbot. Les sites qui envoient les visiteurs mobiles vers un sous-domaine m. ou qui traitent les robots différemment afficheront une chaîne différente pour chacun. Attention toutefois : beaucoup de grands sites vérifient qu’un visiteur se présentant comme Googlebot provient réellement du réseau de Google et répondent 403 dans le cas contraire ; un 403 avec le user-agent Googlebot signifie donc souvent exactement cela. Pour voir précisément ce que Google a reçu, utilisez l’outil d’inspection d’URL de la Search Console.
Les meta refresh, oui. Quand un saut répond 200 avec une page HTML, le vérificateur lit ses 64 premiers Ko, repère une balise meta refresh qui contient une URL et la suit comme saut suivant, signalé comme meta refresh avec son délai en secondes. Les redirections JavaScript, non : elles ne se produisent qu’une fois que le navigateur exécute les scripts de la page, et ce vérificateur n’exécute jamais rien. Si le dernier saut répond 200 mais que votre navigateur aboutit ailleurs, un script en est probablement la cause ; l’onglet Réseau des DevTools l’affiche comme une navigation déclenchée par un script.
Quatre causes reviennent souvent. Votre navigateur a le site dans son cache HSTS et convertit donc http:// en https:// avant même qu’une requête ne quitte la machine. Le site adapte sa réponse selon les cookies, l’en-tête de langue ou le pays, et notre serveur n’a pas le même profil que vous. Le site envoie les mobiles et les ordinateurs vers des destinations différentes, ce que vous pouvez reproduire en changeant de user-agent. Ou bien une redirection JavaScript termine le parcours après le chargement de la page, ce qu’un suivi côté serveur ne voit jamais.
Oui. Passez en mode par lot et collez jusqu’à dix URL, une par ligne. Chacune est suivie séparément et les résultats s’affichent dans un seul tableau avec le nombre de redirections, le statut final, l’URL finale et le temps total. Téléchargez ce tableau en CSV ou copiez-le sous forme de texte séparé par des tabulations, qui se colle proprement dans Sheets, Excel ou un ticket Jira sans aucune remise en forme. Le bouton des variantes remplit le même tableau avec les quatre versions http/https et www d’une même adresse.
Ouvrez les DevTools avec F12, allez dans l’onglet Réseau, cochez « Conserver le journal », puis chargez l’URL. Chaque saut apparaît sur sa propre ligne avec un statut 301 ou 302 ; cliquez sur l’une de ces lignes et lisez l’en-tête Location sous « En-têtes de réponse ». Le hic, c’est que les DevTools montrent ce qu’a fait votre navigateur, avec vos cookies, votre cache HSTS et vos extensions : un collègue sur une autre machine peut donc voir une chaîne différente.
Une seule 301 ou 308 transmet les signaux de classement et ne pose aucun problème. Les chaînes, en revanche, en posent, pour deux raisons : les robots d’exploration de Google suivent jusqu’à 10 sauts de redirection et signalent toute chaîne plus longue comme une erreur de redirection, et chaque saut retarde le premier octet, ce qui pèse directement sur les Core Web Vitals. Les boucles sont pires, car la page n’est jamais accessible et disparaît complètement de l’index. Raccourcissez les chaînes pour que la première URL pointe vers la dernière.