Combien de redirections Google suit-il réellement avant de fractionner le crawl ?

Que signifie concrètement « traiter comme une seule requête » ?

Quand Googlebot rencontre une URL qui redirige vers une autre, il suit automatiquement la chaîne de redirections pour atteindre l'URL finale. Mueller précise ici que Google suit jusqu'à cinq redirections consécutives sans interrompre ce processus. Ces cinq sauts sont traités comme une seule opération de crawl, comptabilisée une seule fois dans votre budget d'exploration.

Au-delà de cette limite, le processus se fragmente. Chaque redirection supplémentaire devient une requête distincte, ce qui mobilise davantage de ressources serveur et consomme votre crawl budget de manière disproportionnée. Pour un site avec plusieurs milliers de pages, cette différence n'est pas anecdotique — elle peut retarder l'indexation de contenus prioritaires.

Pourquoi Google impose-t-il cette limite de cinq redirections ?

La raison principale est la performance. Suivre des chaînes de redirections infinies exposerait Googlebot à des boucles de redirection, des erreurs de configuration ou des tentatives malveillantes de cloaking. En fixant un seuil à cinq, Google balance entre flexibilité technique et protection contre les abus.

Cette limite correspond aussi à la réalité terrain. Dans 99% des configurations saines, vous ne dépassez jamais trois redirections — et si vous en avez cinq, c'est généralement le signe d'un problème d'architecture ou de migrations successives mal nettoyées. Google vous laisse une marge, mais ne cautionne pas l'anarchie.

Cette règle s'applique-t-elle à tous les types de redirections ?

Mueller ne détaille pas si la distinction 301/302/307/308 influence ce traitement. En pratique, le type de redirection n'a pas d'impact sur le comptage des sauts — c'est le nombre de requêtes HTTP consécutives qui compte. Que vous enchaîniez cinq 301 ou un mix de 302 et 307, Google arrête le chrono au cinquième saut.

En revanche, les redirections JavaScript ou meta-refresh sont un autre sujet. Elles nécessitent un rendu côté client, donc un traitement différent. Mueller parle ici uniquement de redirections HTTP classiques, côté serveur. Si votre chaîne mêle redirections serveur et JS, c'est encore plus coûteux en ressources — et potentiellement non compté de la même façon.

• Google suit jusqu'à 5 redirections HTTP consécutives comme une seule requête
• Au-delà, chaque saut supplémentaire devient une requête distincte, gaspillant du crawl budget
• Cette limite vaut pour toutes les redirections serveur (301, 302, 307, 308)
• Les redirections JS ou meta-refresh ne suivent pas cette logique — elles nécessitent un rendu et sont plus lourdes
• Dans une architecture propre, vous ne devriez jamais dépasser 2-3 redirections

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, et c'est même l'une des rares fois où Google donne un chiffre précis. Les tests empiriques montrent que Googlebot suit effectivement jusqu'à cinq sauts avant de traiter les redirections suivantes comme des requêtes fractionnées. On observe ce comportement dans les logs serveur : une chaîne de quatre redirections génère une seule entrée de crawl, tandis qu'une chaîne de six en génère plusieurs.

Cela dit, Mueller ne dit rien sur la vitesse de crawl ni sur le PageRank perdu. Même si Google « suit » les cinq redirections, chaque saut dilue un peu plus l'équité de lien transmise. Les tests montrent qu'au-delà de deux redirections, vous commencez à perdre du jus — même si techniquement, l'URL finale est bien indexée.

Quelles nuances faut-il apporter à cette règle ?

Premier point : Mueller parle de redirections « consécutives ». Si votre architecture mêle redirections serveur et redirections client (JS, meta-refresh), le compteur ne fonctionne pas de la même façon. Google doit d'abord rendre la page JS, ce qui ajoute une latence et consomme plus de budget. Une chaîne de trois redirections serveur + une JS peut coûter autant qu'une chaîne de six redirections classiques.

Deuxième nuance : cette limite concerne le crawl, pas forcément l'indexation finale. Google peut très bien indexer l'URL de destination même si la chaîne dépasse cinq sauts — mais le processus sera plus lent, moins prioritaire, et l'équité de lien amoindrie. [À vérifier] : aucune donnée officielle ne précise si une chaîne de sept redirections bloque complètement l'indexation ou la retarde simplement.

Dans quels cas cette règle ne s'applique-t-elle pas strictement ?

Google peut augmenter cette limite pour des domaines à très haute autorité — c'est une hypothèse plausible mais non confirmée par Mueller. Les sites comme Wikipedia ou Amazon ont des crawl budgets quasi illimités. Si leur architecture technique impose six redirections sur certaines pages, il est probable que Google les suive quand même. Mais pour 99% des sites, n'y comptez pas.

Autre cas limite : les redirections temporaires (302, 307) ne sont pas toujours traitées de la même façon que les permanentes. Si vous enchaînez cinq 302, Google peut décider de recrawler la chaîne plusieurs fois pour vérifier si elle a changé — ce qui double la consommation réelle de budget. Mueller ne précise pas ce point, mais c'est cohérent avec le comportement observé en logs.

Que faut-il faire concrètement pour nettoyer ses chaînes de redirections ?

Auditez d'abord votre site avec Screaming Frog ou Sitebulb en activant l'option « Redirection Chains ». Ces outils détectent automatiquement les chaînes de deux redirections ou plus et vous les listent. Exportez le rapport, triez par longueur de chaîne, et concentrez-vous sur celles qui dépassent deux sauts.

Ensuite, corrigez les chaînes en redirigeant directement vers l'URL finale. Si A → B → C → D, remplacez par A → D et B → D. Cela réduit la latence utilisateur, préserve l'équité de lien, et libère du crawl budget. Dans 80% des cas, ces chaînes sont le résultat de migrations successives mal documentées — personne n'a jamais nettoyé après coup.

Quelles erreurs éviter lors de la gestion des redirections ?

Ne jamais rediriger une redirection — c'est la règle d'or. Si vous migrez un site déjà migré, ne vous contentez pas d'ajouter une couche de redirections par-dessus l'existant. Retracez la chaîne complète, identifiez l'URL source originale, et redirigez-la directement vers la nouvelle destination finale.

Deuxième erreur fréquente : oublier les backlinks externes. Vous pouvez corriger vos redirections internes, mais si des milliers de liens entrants pointent vers une URL qui redirige deux fois, vous gaspillez de l'équité. Contactez les sites référents les plus importants pour mettre à jour leurs liens — ou utilisez du disavow si ces liens sont toxiques de toute façon.

Comment vérifier que mon site respecte cette limite ?

Inspectez vos logs serveur pour repérer les patterns de crawl. Si vous voyez Googlebot refaire plusieurs fois la même requête sur une chaîne de redirections, c'est qu'il fractionne le processus — signe que vous dépassez la limite. Comparez avec vos rapports Search Console : si certaines pages mettent des semaines à être indexées alors qu'elles sont crawlées, les chaînes de redirections sont souvent en cause.

Utilisez aussi l'outil « Inspection d'URL » de Search Console pour tester manuellement vos URLs à problème. Google vous indique l'URL finale indexée et le chemin de redirections suivi. Si vous voyez plus de deux sauts, c'est un red flag immédiat. Priorisez la correction selon le trafic organique actuel de ces pages.

• Auditer le site avec Screaming Frog pour identifier toutes les chaînes de redirections
• Corriger les chaînes de 3+ redirections en redirigeant directement vers l'URL finale
• Vérifier les backlinks externes et mettre à jour les liens des sites référents importants
• Inspecter les logs serveur pour détecter les patterns de crawl fractionnés
• Tester les URLs critiques dans Search Console pour valider qu'elles sont indexées sans friction
• Documenter chaque migration pour éviter d'empiler des couches de redirections au fil du temps