Combien de redirections Google suit-il réellement avant d'abandonner ?

Pourquoi Google limite-t-il le traitement des redirections à cinq sauts ?

Les redirections consomment du crawl budget. Chaque saut supplémentaire représente une requête HTTP, un téléchargement de réponse, une vérification de statut. Googlebot ne peut pas suivre indéfiniment des chaînes de redirections sans risquer de tomber dans des boucles infinies ou de gaspiller des ressources sur des sites mal configurés.

La limite de cinq redirections en une seule fois constitue un compromis. Elle permet de gérer les migrations classiques (HTTP → HTTPS, www → non-www, ancienne structure → nouvelle) tout en évitant les abus. Au-delà, le bot segmente le traitement : il note la dernière URL atteinte, attend le prochain crawl pour continuer.

Que se passe-t-il concrètement après la cinquième redirection ?

Le traitement devient asynchrone et fragmenté. Googlebot ne refuse pas d'indexer la page finale — il ralentit simplement le processus. Lors du premier crawl, il atteint la cinquième URL de la chaîne. Lors d'un crawl ultérieur (peut-être des jours ou des semaines plus tard, selon la priorité du site), il reprend là où il s'était arrêté.

Ce délai a deux conséquences directes. D'abord, la fraîcheur du contenu : votre nouvelle page mettra plus de temps à apparaître dans l'index. Ensuite, la perte de PageRank : chaque redirection 301 ou 302 dilue légèrement l'équité transmise, et une chaîne de sept redirections amplifie cette dilution.

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

Oui, toutes les redirections HTTP comptent dans cette limite : 301 (permanente), 302 (temporaire), 307, 308. Les redirections JavaScript ou meta refresh sont traitées différemment — elles ne comptent pas dans ces cinq sauts, mais elles ralentissent encore plus le crawl car elles nécessitent un rendu JavaScript.

Les redirections serveur (côté Apache, Nginx, via .htaccess ou fichiers de configuration) sont les plus fiables. Les CDN comme Cloudflare ajoutent parfois des redirections intermédiaires invisibles — surveille tes chaînes avec des outils comme Screaming Frog ou curl en ligne de commande.

• Cinq redirections maximum sont traitées en une seule passe de crawl par Googlebot
• Au-delà, le traitement devient fragmenté et asynchrone, ralentissant l'indexation
• Chaque saut supplémentaire dilue le PageRank transmis à la page finale
• Les redirections JavaScript/meta refresh ne comptent pas dans cette limite, mais elles ralentissent encore plus le crawl
• Les CDN et proxies peuvent ajouter des redirections intermédiaires invisibles — audite régulièrement tes chaînes

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

Oui, et c'est même un chiffre plus généreux que ce qu'on observait historiquement. Pendant des années, la recommandation officieuse tournait autour de trois redirections maximum. Que Mueller confirme cinq redirections en une seule passe est une bonne nouvelle pour les migrations complexes — domaines multiples, restructurations profondes, consolidations de marques.

Cependant, "vérifier lentement les redirections ultérieures" reste intentionnellement vague. Combien de temps entre chaque reprise ? Ça dépend du crawl budget alloué au site, de la fréquence de crawl historique, de l'autorité du domaine. Un site avec un faible crawl budget peut attendre des semaines avant que Googlebot ne reprenne la chaîne.

Dans quels cas cette limite pose-t-elle un vrai problème ?

Les migrations mal planifiées sont le cas typique. Imagine une entreprise qui migre HTTP → HTTPS, puis change de domaine, puis réorganise son arborescence, puis bascule vers un nouveau CMS — le tout en conservant chaque couche de redirections. Tu te retrouves avec sept, huit sauts avant d'atteindre la page finale.

Les sites multilingues ou multi-régionaux sont aussi exposés. Redirection géolocalisée (ex : .com → .fr), puis redirection www → non-www, puis redirection de langue (ex : /fr/ → /fr-FR/), puis redirection de catégorie après refonte… Chaque logique métier empile une couche supplémentaire.

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

D'abord, cette limite s'applique au crawl, pas au rendu. Si une page redirige via JavaScript après un premier chargement HTML, Googlebot doit d'abord rendre la page, puis suivre la redirection — processus encore plus lent. Les redirections serveur sont toujours préférables.

Ensuite, la dilution du PageRank reste un sujet flou. Google affirme que les redirections 301 transmettent 100 % de l'équité depuis plusieurs années, mais les tests terrain montrent une légère perte dans les chaînes longues. [A vérifier] — aucune donnée officielle précise sur le pourcentage exact après cinq sauts ou plus.

Comment détecter et mesurer les chaînes de redirections sur ton site ?

Lance un crawl complet avec Screaming Frog (mode Spider, limite à ton domaine). Active l'option "Always Follow Redirects" et consulte l'onglet "Redirect Chains". Tu verras chaque chaîne, le nombre de sauts, les codes de statut HTTP à chaque étape.

Pour les vérifications ponctuelles, utilise curl en ligne de commande avec l'option -L (follow redirects) et -v (verbose). Tu verras chaque étape, les en-têtes HTTP, les temps de réponse. Exemple : curl -L -v https://tonsite.com/ancienne-url. Si tu comptes plus de cinq sauts, tu as un problème.

Que faire si tu découvres des chaînes trop longues ?

Première priorité : raccourcir les chaînes critiques. Identifie les pages recevant des backlinks externes ou du trafic organique significatif. Pour ces URLs, redirige directement de l'ancienne vers la nouvelle, sans passer par les étapes intermédiaires. Modifie ta configuration serveur (.htaccess, nginx.conf, règles Cloudflare) pour pointer A → D au lieu de A → B → C → D.

Deuxième étape : nettoyer les redirections obsolètes. Beaucoup de sites conservent des redirections de migrations vieilles de cinq, dix ans. Si l'URL source ne reçoit plus aucun trafic ni backlink, tu peux la supprimer (retourne un 410 Gone ou un 404 si tu préfères). Concentre tes redirections sur ce qui a encore de la valeur.

Comment éviter de recréer ce problème lors de futures migrations ?

Planifie tes redirections en une seule couche dès le départ. Si tu migres HTTP → HTTPS et www → non-www simultanément, configure une redirection directe A → D, pas A → B → C → D. Les serveurs modernes (Apache 2.4+, Nginx) gèrent très bien les règles conditionnelles complexes.

Documente chaque vague de redirections dans un tableau de mapping (URL source, URL cible, code HTTP, date de mise en place, raison). Lors de la prochaine migration, tu pourras consolider en mettant à jour directement les anciennes sources. Automatise la vérification avec un script qui teste tes URLs critiques chaque semaine.

• Crawler ton site avec Screaming Frog pour détecter toutes les chaînes de redirections existantes
• Prioriser les URLs critiques (backlinks forts, trafic organique) et raccourcir leurs chaînes à 1-2 sauts maximum
• Supprimer ou retourner 410/404 sur les redirections obsolètes qui ne reçoivent plus aucun signal
• Configurer les futures redirections en une seule étape (A → D) plutôt qu'en cascade (A → B → C → D)
• Documenter chaque mapping dans un tableau centralisé avec dates et raisons
• Automatiser un monitoring hebdomadaire des URLs critiques pour détecter rapidement toute nouvelle chaîne