Le lien sur lequel vous cliquez n’est souvent pas la page que vous obtenez. Entre les deux peuvent s’intercaler un passage en HTTPS, un changement d’hôte, un service de suivi, un raccourcisseur d’URL et une règle du CMS qui ajoute un slash final : autant de requêtes distinctes que votre navigateur envoie sans vous le dire.

Ce guide explique comment voir ces étapes avec TrueURL, curl et les outils de développement du navigateur (DevTools), ce que signifie chaque élément d’une chaîne de redirections et comment corriger les problèmes les plus courants.

Qu’est-ce qu’une chaîne de redirections ?

Une redirection a lieu lorsqu’un serveur répond avec un code de statut 3xx et un en-tête Location qui indique une autre URL. Le client, navigateur ou robot d’exploration, demande alors cette URL, et recommence jusqu’à obtenir une réponse qui n’est pas une redirection.

Chaque requête et sa réponse forment un saut (une étape de la chaîne). La séquence complète, de la première URL jusqu’à la réponse finale, constitue la chaîne de redirections :

#  URL                              Status  Location
1  http://example.com/Shoes         301     https://example.com/Shoes
2  https://example.com/Shoes        301     https://www.example.com/Shoes
3  https://www.example.com/Shoes    302     /shoes/
4  https://www.example.com/shoes/   200

Il faut donc trois redirections et quatre requêtes pour atteindre une seule page. L’en-tête Location du saut 3 est relatif : les clients le résolvent par rapport à l’URL qu’ils viennent de demander, comme le prévoit la RFC 9110 ; il désigne donc https://www.example.com/shoes/. Idéalement, chacune de ces adresses devrait mener à l’URL finale en un seul saut.

Une page peut aussi rediriger après avoir répondu 200 OK, au moyen d’une balise <meta http-equiv="refresh"> ou de JavaScript. Ces redirections côté client font elles aussi partie de la chaîne, mais les outils qui ne lisent que les en-têtes HTTP, comme curl, s’arrêtent sur cette page.

Pourquoi vérifier les redirections

SEO : signaux de canonicalisation et budget de crawl

Les moteurs de recherche interprètent une redirection comme une indication de l’URL à indexer. Google considère les redirections permanentes (301 et 308) comme un signal fort indiquant que la cible doit être l’URL canonique, et les redirections temporaires (302, 303 et 307) comme un signal faible. Une page déplacée définitivement derrière une redirection 302 peut donc conserver son ancienne URL dans les résultats de recherche.

La longueur compte aussi. Googlebot suit jusqu’à 10 sauts de redirection ; s’il n’a toujours pas obtenu de contenu à ce stade, la Search Console signale une erreur de redirection. Le guide de Google consacré au budget de crawl (« budget d’exploration » dans la terminologie de Google) recommande également d’éviter les longues chaînes de redirections, qui ont selon lui un effet négatif sur l’exploration.

Vitesse de chargement

La page finale ne peut pas commencer à se charger tant que la dernière redirection n’a pas reçu de réponse. Chaque saut coûte un aller-retour réseau, et un saut vers un nouvel hôte exige en plus une résolution DNS, une nouvelle connexion et, en HTTPS, une négociation TLS. Sur une connexion mobile, trois ou quatre redirections peuvent ajouter plusieurs centaines de millisecondes avant le premier octet de la vraie page. Le Testeur de latence des redirections montre ce que coûte chaque saut.

Sécurité des liens raccourcis et inconnus

Les liens raccourcis et de nombreux liens de suivi présents dans les e-mails masquent leur destination. Les campagnes d’hameçonnage exploitent aussi les redirections ouvertes (open redirects) de domaines connus : un lien qui part d’un site de confiance peut ainsi aboutir tout à fait ailleurs. Le Vérificateur de liens raccourcis révèle chaque domaine traversé, et indique si un saut repasse de HTTPS à HTTP non chiffré, avant même que vous ne cliquiez.

Liens d’affiliation et de suivi

Les liens marketing passent souvent par plusieurs services avant d’atteindre la page d’atterrissage, et chacun doit transmettre la chaîne de requête ; sinon, les paramètres UTM, les identifiants de clic et les tags d’affiliation disparaissent en silence. L’URL finale indique s’ils ont survécu et si le lien mène toujours à la bonne page.

Migrations, HTTPS et hôte canonique

Après une refonte, un changement de domaine ou un passage en HTTPS, chaque ancienne URL doit mener à son nouvel équivalent en une seule redirection permanente. Les quatre variantes de base d’un site (http:// et https://, avec et sans www) doivent toutes aboutir à une même adresse canonique. Ces règles se dérèglent sans prévenir : une nouvelle règle de CDN, la mise à jour d’un plugin ou un changement de serveur peut ajouter un saut ou une boucle sans que personne ne s’en aperçoive.

Vérifier une redirection avec TrueURL

TrueURL exécute chaque vérification sur le réseau edge de Cloudflare : vous pouvez donc inspecter des liens dont vous vous méfiez sans les ouvrir dans votre navigateur. Le Vérificateur de redirections d’URL de la page d’accueil traite une URL à la fois ; le Vérificateur de chaîne de redirections et les autres outils spécialisés reposent sur le même moteur.

Étape 1 : saisir l’URL

Collez l’URL et lancez la vérification. Si vous n’indiquez pas de protocole, https:// est utilisé ; saisissez http:// pour tester en HTTP non chiffré.

Étape 2 : ajuster les Paramètres avancés si besoin

Par défaut, le vérificateur envoie une requête GET avec le User-Agent d’un Chrome récent pour ordinateur, sans cookies et avec une limite de 20 redirections. Les Paramètres avancés permettent de modifier ce comportement :

  • Méthode HTTP : GET, HEAD ou POST. HEAD est plus léger, mais certains serveurs y répondent différemment, et sans corps de réponse, les redirections côté client ne peuvent pas être détectées. POST envoie le corps de requête que vous saisissez, pour tester des formulaires et des API. Les sauts suivants respectent les règles des navigateurs : après un POST, une redirection 301 ou 302 se poursuit en GET (une 303 le fait dans tous les cas), tandis que 307 et 308 conservent la méthode et le corps.
  • Nombre max. de sauts : le nombre de redirections à suivre, de 1 à 50. La valeur par défaut, 20, correspond à la limite fixée par le standard Fetch ainsi que par Chrome et Firefox. Réglez-la sur 10 pour savoir si une chaîne respecte la limite de Googlebot.
  • User-Agent personnalisé : laissé vide, c’est celui de Chrome pour ordinateur. Les préréglages comprennent Safari sur iPhone, Chrome sur Android, Googlebot (smartphone et ordinateur), Bingbot, les robots d’aperçu de liens de Facebook et de X, ainsi que curl.
  • En-têtes de requête personnalisés : des en-têtes supplémentaires envoyés à chaque saut, par exemple Accept-Language: fr-FR pour déclencher une redirection selon la langue.
  • Cookies : saisissez name=value; other=value pour reproduire un état connecté, un consentement ou une région. Les cookies définis au fil de la chaîne sont conservés pour les sauts suivants, comme dans un navigateur.
  • Redirections côté client : suivre les balises meta refresh et les redirections JavaScript simples, ou seulement les signaler.
  • Ignorer les erreurs SSL : le réseau edge de Cloudflare valide toujours les certificats ; cette option ne permet donc pas de passer outre un certificat défectueux. Une erreur TLS est signalée sur le saut où elle s’est produite.

Étape 3 : lire le résultat

Le résultat commence par l’URL finale et son code de statut. En dessous, la chaîne compte une ligne par saut, avec :

  • l’URL demandée et la méthode HTTP utilisée ;
  • le code de statut et son message de statut (la référence des codes de statut les explique un par un) ;
  • le temps de réponse, de l’envoi de la requête à la réception des en-têtes, résolution DNS et établissement de la connexion compris ;
  • l’adresse indiquée dans Location ;
  • les en-têtes de réponse et le nom des cookies éventuellement définis par le saut.

Chaque redirection est étiquetée selon son mécanisme : code de statut HTTP, meta refresh (avec son délai en secondes) ou JavaScript. Les redirections côté client détectées mais non suivies sont également signalées. La façon dont la vérification s’est terminée est tout aussi importante :

Bilan Signification
Réponse finale La chaîne a abouti à une réponse qui n’est pas une redirection, par exemple 200 OK ou 404 Not Found.
Boucle de redirection La requête suivante répéterait une requête précédente : même URL, même méthode et mêmes cookies. Le résultat indique quel saut referme la boucle.
Limite de sauts atteinte La chaîne redirigeait encore lorsque la limite a été atteinte. La cible suivante est affichée, mais pas demandée.
Erreur Un saut a échoué (DNS, connexion, TLS ou délai dépassé), ou la cible de la redirection n’était pas une URL valide ou autorisée.

Des avertissements signalent une redirection temporaire dans la chaîne, un passage de HTTPS à HTTP, plus de trois redirections, une URL finale sur un autre domaine, des redirections côté client et les requêtes HEAD qui n’ont pas pu lire le corps d’une page.

Un avertissement appelle à la prudence. Certains sites présentent au trafic automatisé ou issu de centres de données une vérification anti-bot, comme la page « Just a moment... » de Cloudflare. TrueURL signale les réponses qui y ressemblent, car la vérification a alors atteint la couche de protection du site, et non la destination. Un vrai visiteur peut très bien aboutir ailleurs.

Vérifier les redirections en ligne de commande

curl est préinstallé sur macOS, Windows 10 et 11 et la plupart des distributions Linux, et il montre exactement ce que le serveur envoie, sans aucun cache de navigateur. Les exemples utilisent un shell Unix ; dans Windows PowerShell 5.1, tapez curl.exe, car curl y est un alias de Invoke-WebRequest, et écrivez NUL au lieu de /dev/null.

Examiner un seul saut

Bash
curl -I https://example.com/old-page

-I envoie une requête HEAD et affiche les en-têtes de réponse, dont la ligne de statut et l’éventuel Location. curl ne suit pas les redirections, sauf si on le lui demande. Comme certains serveurs traitent HEAD différemment, refaites la vérification en GET si le résultat vous semble étrange ; -o /dev/null ignore le corps et -D - affiche les en-têtes :

Bash
curl -sS -o /dev/null -D - https://example.com/old-page

Suivre toute la chaîne

-L suit les redirections et, avec -I ou -D -, curl affiche les en-têtes de chaque saut. Un filtre grep permet d’obtenir une vue compacte :

Bash
curl -sIL http://example.com/Shoes | grep -iE '^(HTTP/|location:)'
HTTP/1.1 301 Moved Permanently
Location: https://example.com/Shoes
HTTP/2 301
location: https://www.example.com/Shoes
HTTP/2 302
location: /shoes/
HTTP/2 200

Par défaut, curl suit jusqu’à 50 redirections ; --max-redirs 10 applique la limite de Googlebot.

N’afficher que l’URL finale

L’option -w (write-out) affiche des informations à la fin du transfert, ce qui fait de curl un vérificateur de liens raccourcis en une seule ligne :

Bash
curl -sSL -o /dev/null -w '%{http_code} %{num_redirects} %{url_effective}\n' https://example.com/go

%{url_effective} correspond à la dernière URL récupérée, %{num_redirects} au nombre de redirections suivies et %{http_code} au statut final. %{time_redirect} indique le temps, en secondes, passé dans les redirections avant la requête finale. Sans -L, %{redirect_url} montre où mènerait la première redirection.

Tester des requêtes POST

-d envoie un corps et transforme la requête en POST. Lorsqu’il suit les redirections, curl se comporte alors comme un navigateur : il passe en GET après une 301, une 302 ou une 303, et renvoie le POST avec son corps après une 307 ou une 308.

Bash
curl -sSL -o /dev/null -D - -d 'email=test%40example.com' https://example.com/subscribe

Évitez de combiner -X POST et -L. -X impose la méthode à chaque requête : curl continue donc d’envoyer un POST après une 301, une 302 ou une 303, là où un navigateur passerait en GET, et vous testez une chaîne qu’aucun vrai client ne produit.

Modifier le User-Agent, les en-têtes et les cookies

Bash
# User-Agent de smartphone
curl -sIL -A 'Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.0 Mobile/15E148 Safari/604.1' https://example.com/

# En-tête de requête supplémentaire
curl -sIL -H 'Accept-Language: de-DE,de;q=0.9' https://example.com/

# Envoyer un cookie et conserver les cookies définis au fil de la chaîne
curl -sSL -o /dev/null -D - -b 'consent=yes' -c cookies.txt https://example.com/

-A définit le User-Agent, -H ajoute un en-tête et -b envoie des cookies. -c enregistre les cookies reçus dans un fichier et active le moteur de cookies de curl : un cookie défini par un saut est ainsi renvoyé au saut suivant.

curl n’exécute pas le JavaScript et ne tient pas compte des balises meta refresh. Si sa dernière réponse est une page HTML en 200 OK alors que votre navigateur aboutit ailleurs, la redirection se produit côté client.

Vérifier les redirections dans les DevTools du navigateur

Les DevTools montrent la chaîne telle que la voit votre propre navigateur, avec vos cookies, vos extensions et votre localisation :

  1. Ouvrez les DevTools (F12, ou Cmd+Option+I sur Mac) et sélectionnez l’onglet Réseau (Network).
  2. Activez Conserver le journal (Preserve log) dans Chrome et Edge, ou Journaux persistants (Persist Logs) dans le menu des paramètres réseau de Firefox. Sinon, la liste est effacée à chaque chargement de page et les redirections côté client disparaissent de l’affichage.
  3. Activez Désactiver le cache (Disable cache), pour qu’une redirection mise en cache ne masque pas ce que le serveur envoie aujourd’hui.
  4. Saisissez l’URL dans la barre d’adresse.

Chaque saut apparaît sur sa propre ligne avec son statut 3xx ; sélectionnez-le et ouvrez En-têtes (Headers) pour voir l’en-tête de réponse location. Dans Chrome, la mention « (disk cache) » ou « (memory cache) » dans la colonne Taille (Size) signifie que la redirection provient du cache, et non du serveur.

Chrome affiche parfois une 307 Internal Redirect de http:// vers https://. Le serveur ne l’a jamais envoyée : le navigateur a lui-même converti la requête en HTTPS, généralement parce qu’il a enregistré une politique HSTS pour le site. Pour voir ce que le serveur fait d’une requête en HTTP non chiffré, utilisez curl ou TrueURL.

Problèmes de redirection courants et solutions

Chaînes de plus d’un saut

Les chaînes se forment par couches successives : une règle issue d’une ancienne migration pointe vers une URL qu’une migration ultérieure a de nouveau redirigée. Faites pointer chaque règle directement vers la destination finale, et mettez à jour les liens internes, les balises canonical, les annotations hreflang et les sitemaps pour que votre propre site ne déclenche jamais de redirection. Le Vérificateur de redirections en masse montre quelles anciennes URL nécessitent encore plus d’un saut.

Boucles de redirection

Chrome signale une boucle par le message « … vous a redirigé à de trop nombreuses reprises » (ERR_TOO_MANY_REDIRECTS) ; Firefox indique « La page n’est pas redirigée correctement ». Causes fréquentes :

  • HTTPS derrière un proxy ou un CDN. Le serveur d’origine redirige le HTTP vers le HTTPS, mais le proxy le contacte en HTTP non chiffré : le serveur d’origine ne voit donc jamais passer de HTTPS et redirige à l’infini. Chez Cloudflare, c’est la conséquence classique du mode SSL/TLS Flexible ; utilisez Full (strict), ou faites vérifier X-Forwarded-Proto par le serveur d’origine.
  • Deux couches en désaccord, par exemple une règle de CDN qui retire le www alors que le serveur l’ajoute, ou un framework qui ajoute un slash final que le CDN supprime.
  • Redirections qui dépendent d’un cookie. Une page de connexion ou de consentement renvoie le visiteur vers l’URL d’origine, qui le redirige de nouveau vers la page de connexion parce que le cookie n’a pas été enregistré.

Le Détecteur de boucles de redirection montre quel saut referme la boucle. Confiez ensuite chaque règle à une seule couche.

Redirections 301 et 302 mélangées dans une même chaîne

Une chaîne 301, puis 302, puis 200 correspond à un déplacement permanent avec une étape temporaire au milieu. Elle provient souvent d’une valeur par défaut : res.redirect() d’Express et header('Location: ...') de PHP envoient tous deux une 302, sauf indication contraire. Utilisez un code permanent à chaque saut et vérifiez-le avec le Vérificateur de redirection 301. Notre guide des codes de redirection HTTP explique dans quels cas utiliser chaque code.

Double saut HTTP, puis HTTPS, puis www

Une chaîne très courante est http://example.com → https://example.com → https://www.example.com : deux sauts là où un seul suffirait. Redirigez chaque variante non canonique directement vers l’URL HTTPS finale, puis testez les quatre avec le Vérificateur de redirection HTTPS.

Une exception est voulue. Si votre hôte canonique est www et que vous ajoutez le domaine à la liste de préchargement HSTS, hstspreload.org exige que http://example.com redirige d’abord vers https://example.com, pour que les navigateurs enregistrent la politique HSTS du domaine sans www.

Incohérences de slash final

/pricing et /pricing/ sont deux URL différentes. Si les deux renvoient 200 OK, vous avez du contenu dupliqué ; si deux couches redirigent chacune une forme vers l’autre, vous avez une boucle. Choisissez une forme, redirigez l’autre vers elle avec une seule redirection 301 et utilisez toujours la même forme dans vos liens. Le Vérificateur de slash final teste les deux formes à la fois.

Redirections réservées aux mobiles

Les sites mobiles séparés, les invitations à installer une application et la détection d’appareil envoient parfois les téléphones ailleurs, souvent vers la page d’accueil mobile au lieu de la page équivalente. Avec l’indexation mobile-first, Google explore principalement avec son robot d’exploration pour smartphone : c’est donc la chaîne mobile qui compte le plus pour l’indexation. Comparez les deux avec l’outil Redirections mobile vs ordinateur.

Redirections dans les sitemaps

Un sitemap doit lister les URL canoniques que vous voulez voir dans les résultats de recherche, et celles-ci renvoient 200 OK. Les entrées qui redirigent gaspillent des requêtes d’exploration et envoient des signaux de canonicalisation contradictoires. Lancez le Vérificateur de redirections de sitemap après chaque migration et remplacez chaque entrée qui redirige par son URL finale.

Redirections JavaScript et meta refresh

Google traite une balise meta refresh instantanée comme une redirection permanente, et une balise différée comme une redirection temporaire. Il ne voit les redirections JavaScript qu’après avoir effectué le rendu de la page, une étape qui intervient après l’exploration et qui peut échouer. De nombreux autres robots d’exploration, robots d’aperçu de liens et outils en ligne de commande n’exécutent pas du tout le JavaScript, et certains ignorent aussi les meta refresh. Utilisez des redirections côté serveur partout où vous contrôlez le serveur, et repérez les redirections côté client avec le Vérificateur de meta refresh.

Liste de contrôle des redirections

Parcourez cette liste après une migration, après un changement de CDN ou avant le lancement d’une campagne :

  1. Chaque ancienne URL atteint sa destination finale en un seul saut.
  2. Les déplacements permanents utilisent une 301 ou une 308 à chaque saut.
  3. Les quatre variantes de protocole et d’hôte aboutissent à l’URL HTTPS canonique.
  4. Aucun saut ne passe de HTTPS à HTTP.
  5. La chaîne de requête, paramètres UTM et identifiants d’affiliation compris, est conservée jusqu’à l’URL finale.
  6. Chaque URL n’existe que sous une forme, avec ou sans slash final, et l’autre forme redirige vers elle.
  7. Les requêtes envoyées depuis un ordinateur, depuis un smartphone et par Googlebot aboutissent à des pages équivalentes.
  8. Des redirections côté serveur remplacent les meta refresh et le JavaScript partout où c’est possible.
  9. Les liens internes, les balises canonical, les annotations hreflang et les sitemaps pointent vers les URL finales.
  10. Les pages supprimées sans remplacement renvoient un code 404 ou 410 au lieu de rediriger vers la page d’accueil.
  11. Les redirections mises en place lors d’un déplacement de site restent actives ; Google recommande de les conserver au moins un an.