Langues

Chaînes de redirections

Définition d’une chaîne de redirections (A → B → C au lieu de A → C), causes liées aux migrations successives, nombre de sauts suivis par Google, méthodes de détection avec curl et des crawlers, et correction à appliquer.

Première publication : 2 juil. 2026 · Dernière mise à jour : 21 août 2026 · Advanced
Langues
AIRédigé parAI v2
1 indice probant sur cette page

Une chaîne de redirections apparaît lorsqu’une URL passe par une ou plusieurs redirections intermédiaires avant d’atteindre sa destination finale — A → B → C au lieu de A → C — et se termine à la première réponse qui n’est pas une redirection, pas nécessairement un code 200. Chaque saut ajoute de la latence et peut retarder la consolidation complète des signaux par Google. Les chiffres souvent cités ne se contredisent pas : dix sauts constituent la limite technique suivie par Googlebot, tandis que trois au maximum et moins de cinq représentent la recommandation pratique actuelle de Google. John Mueller a décrit séparément environ cinq sauts par exploration en 2014 et par tentative d’exploration en 2020 ; en 2014, il indiquait aussi qu’une exploration ultérieure pouvait reprendre le reste. Ces déclarations historiques ne garantissent pas le fonctionnement actuel. Mon observation selon laquelle Google reprend souvent les longues chaînes et mon seuil de triage d’environ cinq sauts sont des preuves pratiques indépendantes. Les chaînes proviennent presque toujours de migrations successives, pas d’incompétence. Leur coût tient à la latence d’exploration, non à une perte de PageRank à chaque saut. La correction reste la même : faire pointer chaque redirection directement vers la destination finale active, puis mettre à jour les liens internes, balises canoniques et sitemaps qui alimentent encore la chaîne.

En bref — Une chaîne de redirections suit A → B → C au lieu d’un trajet direct A → C ; chaque redirection constitue un saut et le parcours s’arrête à la première réponse qui n’est pas une redirection, pas nécessairement un code 200. Les chaînes sont le résidu presque inévitable de migrations successives, de conflits d’extensions et de règles mal ordonnées, non un signe d’incompétence. Les chiffres souvent cités décrivent des réalités différentes : 10 est la limite technique actuelle de Googlebot, tandis que 3 au maximum et moins de 5 est la recommandation pratique de Google. Mueller a évoqué séparément environ 5 sauts par exploration en 2014 et par tentative d’exploration en 2020 ; il indiquait en 2014 qu’une exploration ultérieure pouvait reprendre le reste. Ces déclarations historiques ne garantissent pas le fonctionnement actuel. Mon observation selon laquelle Google reprend souvent les longues chaînes constitue une preuve pratique distincte. Le coût documenté tient à la latence et au traitement d’exploration, pas à une perte de PageRank par saut. La correction ne varie pas : chaque redirection doit viser la destination finale active, puis les liens internes, balises canoniques et sitemaps doivent être corrigés.

Ce qui constitue une chaîne — et ce qui n’en est pas une

Chaque saut 3xx est un échange HTTP distinct. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: RFC 9110: Redirection Aucun pourcentage universel de perte de classement ni aucune limite fixe d’exploration n’est documenté ; viser un seul saut direct reste donc la solution défendable. Evidence for this claim Primary standard or official documentation supporting the adjacent article claim. Scope: Protocol semantics and Search behavior are kept separate; no indexing, ranking, or migration-timing guarantee is inferred. Confidence: high · Verified: Google: Redirects and Search

Une chaîne comprend au moins deux réponses de redirection consécutives avant la première réponse qui n’est pas une redirection : A → B → C plutôt que A → C. Chaque redirection de la séquence est un saut. La chaîne se termine à la première réponse qui n’est pas une redirection : le plus souvent un 200, mais aussi parfois un 404, un 500, une demande d’authentification ou un autre résultat terminal. Une chaîne qui aboutit à une erreur reste une chaîne défaillante, pas automatiquement une boucle.

Une boucle de redirections est un problème différent et plus précis : le parcours est cyclique. L’un des sauts renvoie vers une URL déjà visitée ; la requête n’atteint donc jamais de réponse terminale et le navigateur affiche ERR_TOO_MANY_REDIRECTS. La distinction utile oppose cycle et parcours non cyclique, non longueur et brièveté, ni erreur finale et code 200. Une boucle de deux sauts reste une boucle ; une chaîne de dix sauts qui finit en 404 reste une chaîne.

Dans mon article 11 Types Of Redirects & Their SEO Impact, je le formule simplement : “Redirect chains are when multiple redirects take place between a requested resource and its final destination.” (traduction) « Une chaîne se forme lorsque plusieurs redirections interviennent entre une ressource demandée et sa destination finale. »

Pourquoi les chaînes se forment en pratique

Elles résultent rarement d’une seule décision négligente. Elles s’accumulent :

  • Migrations successives. C’est la cause principale. Une URL redirigée pendant un changement de domaine l’est encore lors du passage à HTTPS, puis lors d’un changement de plateforme. Chaque migration ajoute une couche au lieu de remplacer la précédente. http://old → https://old → https://new emploie trois règles là où une seule suffirait.
  • Règles distinctes pour www/non-www et HTTP/HTTPS. http://www → https://www → https://non-www est une chaîne classique de trois sauts qui devrait être réunie en une seule règle.
  • Conflits entre CMS et extensions. Deux extensions, ou une règle d’extension et une règle serveur, agissent sur la même URL.
  • Règles génériques placées avant les règles précises. Une règle globale (ancien domaine → nouvelle page d’accueil) située avant une règle précise empêche cette dernière de s’appliquer. Bing recommande expressément de placer les règles précises avant la règle générique pour cette raison.

Exemple de migration : trois règles raisonnables, une chaîne inutile

Un site de vêtements a accumulé trois changements raisonnables pris séparément :

301  http://old-shop.example/products/trail-shoe
301  https://old-shop.example/products/trail-shoe
301  https://shop.example/products/trail-shoe
200  https://shop.example/shoes/trail-runner

La première règle impose HTTPS, la deuxième déplace le domaine et la troisième traduit un renommage du catalogue. Aucune migration n’est fautive isolément : c’est l’ancien point d’entrée qui rejoue encore les trois décisions historiques.

Remplacez ce parcours par une redirection permanente directe :

301  http://old-shop.example/products/trail-shoe
200  https://shop.example/shoes/trail-runner

Mettez ensuite à jour les liens internes, balises canoniques et entrées de sitemap qui annoncent encore une URL intermédiaire. Ce parcours .example est illustratif et ne constitue pas un rapport sur une entreprise précise.

Autre anti-modèle important : n’empilez pas une règle globale « tout vers la page d’accueil » au-dessus de redirections précises. Google avertit que rediriger de nombreuses anciennes URL vers une destination unique sans rapport “might be treated as a soft 404 error.” (traduction) « peut être traité comme une erreur soft 404 ». Redirigez chaque ancienne URL vers son véritable équivalent.

Combien de sauts Google suit-il réellement ?

C’est ici que des articles concurrents confondent trois chiffres différents. Ils sont complémentaires, pas contradictoires :

1. La limite technique — 10 sauts. La documentation Google sur les migrations de site indique : “While Googlebot can follow up to 10 hops in a ‘chain’ of multiple redirects (for example, Page 1 > Page 2 > Page 3), we advise redirecting to the final destination directly.” (traduction) « Bien que Googlebot puisse suivre jusqu’à dix sauts dans une chaîne de plusieurs redirections, nous conseillons de rediriger directement vers la destination finale. » Dix est le maximum total parcouru avant l’abandon.

2. La recommandation pratique — trois au maximum, moins de cinq. La même phrase ajoute : “If this is not possible, keep the number of redirects in the chain low, ideally no more than 3 and fewer than 5.” (traduction) « Si ce n’est pas possible, limitez le nombre de redirections de la chaîne, idéalement à trois au maximum et à moins de cinq. » C’est le conseil de Google, non une estimation tierce.

3. Les déclarations historiques représentatives — environ cinq sauts par exploration. Lors d’un hangout pour webmasters en 2014 à 46:03, John Mueller a décrit Googlebot suivant jusqu’à cinq redirections pendant une exploration puis, s’il en restait, les reprenant à la suivante. Dans un commentaire Reddit distinct de 2020 rapporté par Search Engine Journal, il a indiqué que Google suivait “up to 5 hops in the chain per crawl attempt.” (traduction) « jusqu’à cinq sauts dans la chaîne par tentative d’exploration ». La déclaration de 2014 constitue bien une preuve de reprise ultérieure, mais elle est historique : elle ne garantit ni une reprise systématique aujourd’hui ni un calendrier prévisible.

Mes propres observations sur des sites réels concordent indépendamment avec ce schéma : Google reprend souvent une chaîne plus longue, et j’utilise environ cinq sauts comme seuil de triage. Il s’agit d’une preuve pratique et d’un seuil opérationnel, non de la source de la déclaration de Mueller ni d’une limite Google.

En résumé : 10 est la limite actuelle documentée par Google ; trois à cinq (moins étant préférable) est sa cible pratique ; environ cinq par exploration est une indication historique représentative de Mueller. Une chaîne de plus de cinq sauts n’échoue pas nécessairement : elle retarde généralement l’arrivée de Google sur la destination et la consolidation des signaux. Au-delà de dix sauts, une erreur de redirection peut apparaître dans le rapport d’indexation de Search Console, mais la correspondance n’est pas systématique : le journal dépend de ce que le crawler a observé lors de cette tentative, et la chaîne peut simplement se résoudre plus lentement.

Pourquoi les chaînes comptent — contrairement au mythe

Le coût documenté d’une chaîne est la latence et le traitement d’exploration, non une perte de signal par saut. Selon Google, enchaîner les redirections “adds latency for users, and not all user agents and browsers support long redirect chains.” (traduction) « ajoute de la latence pour les utilisateurs, et tous les agents utilisateurs et navigateurs ne prennent pas en charge les longues chaînes de redirections ».

Il faut distinguer cela du mythe réfuté de la « perte de PageRank par redirection ». Google affirme explicitement : “301 and other permanent redirects don’t cause a loss in PageRank.” (traduction) « Les redirections 301 et les autres redirections permanentes n’entraînent pas de perte de PageRank. » Cette phrase concerne un saut unique ; elle ne rend pas une chaîne illimitée gratuite, car son coût relève de la latence d’exploration et du délai de consolidation, pas d’une fuite d’autorité. Les deux constats peuvent être vrais simultanément.

Quand corriger une chaîne — et quand ne pas s’en préoccuper

Voici où je me distingue d’une grande partie des contenus spécialisés : ne sur-optimisez pas. Beaucoup de référenceurs veulent supprimer le moindre saut supplémentaire. Je ne m’en préoccuperais pas du tout. Dans mes articles sur les migrations, j’ai expliqué qu’une chaîne sur le chemin racine ou la recherche de chaque site externe afin qu’il mette son lien à jour ne m’inquiétait pas.

Mon seuil de travail réel se situe autour de cinq sauts : en dessous, je m’inquiète rarement ; au-delà, j’ai observé des problèmes d’exploration et de prise en compte. Je conseille donc de commencer le travail à ce niveau. Pondérez aussi selon le chemin : une chaîne de cinq sauts sur une URL précieuse et souvent explorée mérite d’être corrigée ; un saut isolé sur une page peu fréquentée vaut rarement un après-midi.

Comment trouver les chaînes de redirections

La détection se fait par niveaux : ligne de commande pour les contrôles ponctuels, crawlers pour l’ensemble du site :

  • curl -IL <url> sous macOS/Linux — ou Invoke-WebRequest sous Windows — affiche la ligne d’état de chaque saut jusqu’au 200 final. C’est le moyen le plus rapide de suivre une URL. Les commandes prêtes à copier figurent dans Scripts.
  • Outils de développement du navigateur → onglet Réseau. Chargez l’URL et observez les requêtes 301/302 qui précèdent le 200 final.
  • Screaming Frog. L’onglet Response Codes et Reports → Redirects → Redirect Chains exportent toutes les chaînes du site avec leur nombre de sauts.
  • Ahrefs Site Audit. Le rapport Redirects signale automatiquement le problème “Redirect chain too long”. Site Explorer filtre aussi les backlinks ou liens sortants selon le nombre de redirections, et la barre d’outils Ahrefs affiche la séquence dans son onglet d’en-têtes HTTP.

Un rapport de chaînes n’est qu’une partie de l’examen des règles existantes. L’audit du parc de redirections vérifie aussi les destinations finales mortes, les redirections vers une page générique, les règles globales qui absorbent des URL actives et la possibilité de retirer une règle inutilisée au moyen d’un test 404 journalisé et réversible.

Comment les corriger

Une règle universelle : faites pointer chaque redirection directement vers la destination finale active, jamais vers une autre redirection. Corriger une chaîne consiste à remplacer la cible intermédiaire de chaque règle par la véritable URL finale. A → B → C devient A → C et B → C.

Terminez ensuite le travail que la plupart des gens oublient :

  • Mettez à jour les liens internes afin qu’ils visent l’URL finale et non une URL qui redirige ; sinon votre propre site continue d’alimenter la chaîne.
  • Mettez à jour les balises canoniques et les sitemaps XML qui recensent encore des URL anciennes ou intermédiaires.
  • Ordonnez correctement les règles : règles précises avant les règles globales, et regroupement de www/HTTPS dans une seule règle lorsque c’est possible.
  • Vérifiez les codes d’état, pas seulement les destinations, lorsque la chaîne ne concerne pas une simple page. Les codes 301 et 302 peuvent transformer un POST en GET au saut suivant ; 307 et 308 conservent la méthode d’origine. Une chaîne anodine pour une page peut rompre silencieusement un formulaire, un appel d’API, une URL signée ou un webhook si les mauvais codes sont mélangés.

La chaîne se réduit alors au seul saut réellement nécessaire.

À lire aussi dans ce cluster : la différence entre redirection permanente et temporaire (301 ou 302), et ce qui se produit lorsqu’une chaîne ne se termine jamais (boucles de redirections).

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.