Chaînes de redirection : comment elles se produisent, ce qu’elles coûtent, comment les aplatir

Une chaîne de redirection est le défaut technique rare qui se cache derrière un feu vert. Tapez le URL, obtenez la page, statut 200 — chaque test ordinaire passe, car chaque client HTTP ordinaire suit toute la chaîne silencieusement et ne signale que l’endroit où il s’est arrêté. Les sauts intermédiaires existent, ils sont facturés à chaque récupération, et rien dans un navigateur ne vous indique combien il y en avait.

Une recherche utile de redirection montre l’entrée URL, les destinations intermédiaires et la page finale. Ce registre permet à l’équipe responsable de décider quelle règle doit envoyer la requête originale directement à la destination prévue. L’observation est également facile à vérifier après une réparation : inspectez à nouveau la séquence et comparez-la avec le chemin enregistré.

Une chaîne à 4 sauts se compose de 4 décisions correctes distinctes

Les chaînes s’accumulent couche par couche, et chaque couche gagne sa place lorsqu’elle atterrit :

1. TLS atterrit. Quelqu’un ajoute une règle de bord envoyant http:// à https://. La destination prévue utilise maintenant HTTPS.
2. Un hôte canonique est choisi. L’équipe standardise sur www, donc l’apex redirige vers celui‑ci. Le nom d’hôte frère devrait mener à la même destination prévue.
3. Les slashes finaux sont normalisés. Un cadre ou le défaut CDN ajoute une règle ajoutant ou supprimant le slash final. Les liens publiés et les entrées de sitemap devraient utiliser le style prévu de façon cohérente.
4. L’internationalisation est livrée. Les chemins racine commencent à router vers un préfixe de locale, /blog/ vers /en/blog/. Les pages localisées ont besoin d’URL stables distinctes, bien qu’une redirection depuis la racine soit un choix de conception du site.

Il s’agit de 4 règles correctes, et maintenant http://example.com/blog atteint sa destination via 4 redirections. Une migration CMS qui réécrit /blog/* en /articles/* ajoute un 5 sans toucher aucun des 4 premiers, car il est implémenté dans l'application alors que les autres vivent dans le bord, le serveur web et le routeur. Les règles se déclenchent dans l’ordre où la requête traverse la pile, pas dans l’ordre qui résoudrait le URL le plus rapidement. Personne ne possède la composition.

C’est aussi pour cela que le résultat http‑to‑https dans nos propres données doit être lu avec prudence. Entre le 23 mai et le 31 août 2026, la normalisation de HTTP à HTTPS a été signalée sur 44 % de 171 évaluations mais seulement 8 % de 48 sites distincts. Le niveau site 8% est le chiffre de prévalence ; le chiffre d’évaluation décrit nos observations, pas le web. Une vérification est évaluée à chaque exécution d’audit, donc un petit nombre de sites audités à plusieurs reprises alors que le défaut persistait contribuent à de nombreuses évaluations échouées chacune, et ils tirent le taux d’évaluation bien au-dessus de la part de sites affectés. Citer le 44% comme « 44% de sites » exagérerait la prévalence de plus d’un facteur de 5.

Google suit jusqu’à 10 sauts et vous conseille de rester sous 5

Le budget de saut est documenté, pas un folklore. La documentation de l’exploration de Google indique que par défaut ses explorateurs suivent jusqu’à 10 sauts de redirection, et note que les produits individuels diffèrent — les Outils d’inspection de Google ne suivent pas du tout les redirections. Les directives de migration de site sont plus précises : Googlebot peut suivre jusqu’à 10 sauts, mais « nous conseillons de rediriger directement vers la destination finale. Si cela n’est pas possible, gardez le nombre de redirections dans la chaîne faible, idéalement pas plus de 3 et moins de 5 ». La documentation du budget d’exploration le réduit à une ligne : éviter les longues chaînes de redirection, qui ont un effet négatif sur l’exploration.

Le coût se divise en 3 parties, et elles ont un poids inégal :

Efficacité d’exploration. Chaque saut est une requête que le crawler de Google consomme sans recevoir de contenu — la documentation précise que le contenu retourné par un URL redirigeant est ignoré et que seul le contenu de la cible finale est traité. Sur un site de quelques centaines d'URL, c'est du bruit. Sur un site où la chaîne se trouve dans le motif URL, chaque lien interne l'utilise, elle se multiplie sur l'ensemble du crawl et concurrence la limite de capacité de crawl que le même hôte subit déjà.

Latence, à chaque requête non mise en cache. Un saut est un aller-retour complet : DNS peut déjà être chaud, mais la réutilisation de connexion se termine dès qu'un saut change d'hôte, ce que l'étape example.com à www.example.com fait par définition. Les utilisateurs ressentent cela une fois puis ne le ressentent plus, car les navigateurs mettent en cache les redirections permanentes. Les machines qui récupèrent des ressources froides, sans cache chaud, le ressentent à chaque fois.

Consolidation du signal, c'est là que le folklore vit. L'ancienne affirmation est que chaque saut emporte un pourcentage d'équité de lien. Google l'a contredit publiquement en juillet 2016, lorsque Gary Illyes a déclaré de façon catégorique que les redirections 30x ne perdent pas PageRank, clarifiant ce que John Mueller avait déjà dit sur les migrations http‑to‑https plus tôt cette année. La version durable du souci est plus étroite et toujours réelle : un 301 est le signal de canonisation le plus fort disponible, et la valeur d'une redirection est qu'elle nomme une destination de façon univoque. Une chaîne nomme toujours une destination, donc l'argument d'équité est le plus faible des raisons 3 pour aplatir. L'efficacité de crawl et la latence portent l'affaire.

Les fetchers et agents IA traitent les chaînes moins indulgemment que les navigateurs

Les navigateurs sont les clients de redirection les plus permissifs qu'un site sera jamais testés avec. Ils suivent les longues chaînes sans commentaire, mettent en cache agressivement les redirections permanentes, et présentent la destination comme si c'était le URL demandé. Les clients programmatiques — la couche que les assistants IA, les pipelines de récupération et les agents récupèrent réellement — varient d'une manière qu'un test de navigateur ne peut révéler.

curl ne suit rien du tout sans -L; une chaîne renvoie un simple 301 et un corps vide. Les clients de la bibliothèque HTTP choisissent chacun leur propre plafond de saut et leur propre valeur par défaut pour savoir s'ils suivent ou non, et ces valeurs par défaut sont définies par celui qui a écrit le code de récupération, pas par le site. Les clients conformes aux spécifications abandonnent les informations d'identification lorsqu'une redirection traverse des origines, ce qui est précisément ce qu'un saut apex‑to‑www fait. La sémantique des méthodes change aussi : 301 et 302 ont une longue histoire de réécriture d'un POST en GET, tandis que 307 et 308 conservent la méthode d'origine — une distinction qui compte dès qu'un agent soumet plutôt que lit.

Ajoutez la contrainte budgétaire. Un résumeur ou agent travaillant une page sous une limite de temps passe une partie de son temps sur des sauts qui ne renvoient aucun contenu, et un fetch qui dépasse un plafond interne de saut ressemble à un site qui est hors service. La chaîne ne se signale pas comme une chaîne ; elle se signale comme un résultat vide. C'est la même forme d'échec que les conflits de directives dans nos données d'indexabilité — le site fonctionne pour les gens et refuse silencieusement de fonctionner pour les machines.

Aplatir en étapes 4 : inventaire, collapse, relier, garder la carte

1. Inventoriez les vrais comptes de saut. Mesurez, ne ne raisonnez pas sur la configuration. Pour un seul URL :

curl -sIL -o /dev/null -w '%{num_redirects} hops -> %{url_effective}\n' http://example.com/blog
curl -sILD - -o /dev/null http://example.com/blog | grep -iE '^(HTTP/|location)'

La première ligne donne le compte, la deuxième le chemin. Exécutez-le contre les formes http:// et https://, apex et www, avec ou sans barre oblique finale, et contre un URL représentatif de chaque modèle — la chaîne vit généralement dans un motif, pas une page. Un audit effectue la même marche sur la page d'accueil, la cible canonique, et l'hôte alternatif en une seule passe, et rapporte le chemin tracé comme preuve.

2. Réduisez chaque chaîne à un seul 301. Prenez l'entrée URL et la destination finale de l'inventaire et écrivez une règle qui mappe le premier directement au dernier, à la couche la plus externe pouvant voir les deux — généralement le bord ou CDN. Puis retirez les règles intermédiaires dont la chaîne était composée, plutôt que de les laisser en place derrière la nouvelle. Utilisez 301 pour un déplacement permanent, et 308 lorsque la méthode doit survivre. La cible doit être un 200 qui se déclare canonique ; un redirection qui atterrit sur une page dont le canonique pointe ailleurs redémarre l'ambiguïté dans un vocabulaire différent, ce qui est l'interaction que nos canonical tags guide traversent.

3. Orientez les liens internes vers les URL finales. Une règle aplatie coûte toujours un saut sur chaque lien interne qui nomme l'ancien URL. Les sitemaps, la navigation, les annotations hreflang, les tags canoniques, et les liens en corps doivent tous référencer la destination directement, de sorte que la redirection n'existe que pour les liens entrants externes et les anciens signets. Cette étape est ce qui transforme une correction de configuration en un gain d'efficacité de crawl.

4. Conservez la carte de la chaîne. Enregistrez chaque règle retirée, son entrée URL, et sa destination finale dans un fichier unique qui vit avec la configuration d'infrastructure. Les chaînes se reforment parce que la prochaine personne à ajouter un préfixe de locale ou à migrer un schéma de chemin n'a aucun moyen de voir les 4 règles déjà dans le chemin de requête. La carte est ce qui rend la composition visible à quiconque expédie la couche 5, et c'est l'entrée pour le prochain inventaire. Le traitement complet vérification par vérification se trouve dans notre redirections et URL guide de normalisation.

Une couche de redirection aplatie est l'une des rares améliorations techniques sans dépendance de contenu, sans retard de classement, et une étape de vérification qui prend une seule commande. Elle reste cassée sur tant de sites parce qu'aucun test que quelqu'un exécute à la main ne rapporte les sauts. Une fois qu'un trace fait partie de l'audit, le joint entre les décisions correctes des équipes 4 devient une constatation avec un chemin, un statut par saut, et une règle à écrire.