Une chaîne de redirections fait-elle perdre du PageRank ?

Selon Google, non : une redirection 30x ne fait pas perdre de PageRank en elle-même, et ce depuis 2016. Le risque est ailleurs : un maillon qui casse, une 302 qui s'intercale, ou une chaîne qui dépasse la limite de sauts et fait sortir la page de l'index.

Une 302 au milieu de la chaîne, c'est grave ?

C'est le maillon que je corrige en premier. Une 302 annonce un déplacement temporaire, donc l'URL d'origine reste en principe la bonne aux yeux de Google. Glissée dans une chaîne de 301, elle envoie un signal contradictoire sur l'adresse à indexer. Remplacez-la par une 301 vers la destination finale.

Et une boucle de redirections ?

A renvoie vers B, qui renvoie vers A : le navigateur affiche une erreur « trop de redirections » et Google classe l'URL en erreur de redirection. Le coupable classique, ce sont deux couches qui se contredisent, par exemple un plugin WordPress et une règle serveur, ou un CDN qui contacte votre serveur en HTTP pendant que celui-ci force le HTTPS. Avec Cloudflare, le mode SSL « Flexible » est un suspect habituel.

Chaîne de redirections : combien de sauts Google suit-il, et comment la corriger

Une chaîne de redirections, concrètement

Une redirection simple, c'est un saut : l'URL A répond « 301, allez voir B », et B affiche la page. Une chaîne, c'est quand B redirige à son tour vers C, puis C vers D. Chaque maillon est une requête HTTP complète, pour le navigateur comme pour Googlebot.

Personne ne construit une chaîne exprès. Elle se forme par couches, une refonte après l'autre. Voici le cas que je retrouve le plus souvent en audit, sur des sites qui ont vécu deux ou trois refontes :

http://exemple.fr/blog/mon-article redirige vers la version HTTPS (règle ajoutée lors du passage au certificat) ;
qui redirige vers la version avec www (choix d'un prestataire suivant) ;
qui redirige vers /conseils/mon-article/ (dernière refonte, nouvelle arborescence et slash final).

Trois sauts pour une seule page. Et chaque règle, prise isolément, était parfaitement juste le jour où on l'a écrite. C'est tout le piège : personne ne regarde l'empilement. Si les bases vous manquent, je détaille ailleurs ce qu'est une redirection 301 et comment la poser correctement.

Combien de redirections Google suit-il ?

La réponse est documentée, pour une fois. Google indique que ses robots suivent par défaut jusqu'à 10 sauts de redirection. Au-delà, Googlebot abandonne : l'URL n'est pas indexée et elle remonte dans le rapport d'indexation des pages de la Search Console avec le motif « Erreur de redirection ». Ce motif couvre aussi les boucles et les chaînes qui contiennent une URL vide ou invalide.

Dix, c'est la limite technique, pas l'objectif. Dans sa page consacrée aux déménagements de site, Google demande d'éviter les chaînes et de rediriger directement vers la destination finale. Quand ce n'est pas possible, il conseille de rester idéalement à 3 sauts maximum, et en tout cas sous 5, parce que chaque saut ajoute de la latence et que tous les navigateurs ne suivent pas les chaînes longues aussi bien.

À partir de quand c'est pénalisant ?

Soyons précis sur le mot. Il n'existe pas de pénalité « chaîne de redirections » qui ferait chuter un site. Google affirme depuis plusieurs années qu'une redirection 30x ne fait pas perdre de PageRank en elle-même. Une chaîne de deux sauts ne vous coûte donc pas vos positions du jour au lendemain.

Ce qu'elle coûte, c'est plus diffus :

Du temps de chargement : chaque maillon est un aller-retour réseau de plus avant le premier octet de la page. Sur mobile avec une connexion moyenne, ça se sent.
Du crawl : Googlebot dépense une requête par saut. Négligeable sur un site de 80 pages, réel sur un site de plusieurs dizaines de milliers d'URL.
De la fragilité : plus la chaîne est longue, plus il y a de chances qu'un maillon casse. Un changement d'hébergement, une règle supprimée, et le troisième saut finit en 404 ou boucle sur le premier.
Des signaux brouillés : si une étape intermédiaire est en 302, ou si vos liens internes pointent encore vers une URL du milieu, Google reçoit des indications contradictoires sur l'URL à retenir.

Ma grille de lecture en audit : un saut, c'est normal. Deux ou trois, on nettoie quand on a le temps, en priorité sur les pages qui reçoivent des backlinks. Quatre et plus, on corrige maintenant. Une boucle ou une page en « Erreur de redirection », c'est une urgence, puisque la page n'existe plus aux yeux de Google.

Repérer les chaînes sur votre site

Pour une URL isolée, le terminal suffit. La commande ci-dessous affiche chaque saut avec son code de statut et sa destination :

curl -sIL http://exemple.fr/blog/mon-article | grep -iE "^HTTP|^location"

Pour le site entier, passez par un crawler. Screaming Frog (gratuit jusqu'à 500 URL) propose un rapport dédié aux chaînes de redirections, qui liste l'URL de départ, chaque étape et la destination finale. Complétez avec la Search Console, motif « Erreur de redirection », pour les cas déjà bloquants.

Attention à l'angle mort. Un crawl part de votre page d'accueil et suit vos liens internes : il ne verra jamais les vieilles URL que plus rien ne lie chez vous, mais que des sites externes continuent de pointer. Or ce sont souvent elles qui portent les chaînes les plus longues, et les liens les plus précieux. Je les récupère de trois façons : l'export des backlinks d'un outil de netlinking, les anciens sitemaps s'ils traînent quelque part, et les logs du serveur, où l'on voit Googlebot revenir obstinément sur des adresses mortes depuis des années (tout l'intérêt d'une analyse de logs serveur orientée SEO). Cette liste, je la recrawle en mode « liste d'URL ».

Schéma dessiné à la main montrant une suite de flèches entre plusieurs pages, raccourcie par une flèche directe vers la page finale

Corriger : aplatir la chaîne, puis couper ses sources

Le principe tient en une phrase : chaque URL qui redirige doit pointer directement vers l'URL finale, celle qui répond en 200. Pas vers une étape intermédiaire. Et ça vaut aussi pour les URL du milieu de la chaîne, qui ont pu être indexées ou liées entre-temps.

Côté serveur, le problème vient presque toujours de l'ordre des règles. La règle générique HTTP vers HTTPS s'exécute en premier, puis la règle www, puis celle de la refonte : trois sauts. La solution consiste à placer les redirections spécifiques en tête, avec une destination absolue et définitive, puis à fusionner les corrections de protocole et de domaine en une seule règle. Sur Apache, ça donne par exemple :

RewriteEngine On
# 1. Les anciennes URL, directement vers leur destination finale
RewriteRule ^blog/mon-article/?$ https://www.exemple.fr/conseils/mon-article/ [R=301,L]
# 2. Ensuite seulement, protocole et www corrigés en un seul saut
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.exemple.fr/$1 [R=301,L]

Testez sur une préproduction, puis repassez la commande curl sur chaque variante (http, https, avec et sans www) : vous devez voir un seul 301, puis un 200. Sous WordPress, un plugin comme Redirection permet de modifier la cible de chaque règle sans toucher au serveur ; le travail est le même, ligne par ligne.

Reste la partie qu'on oublie : couper les sources. Liens internes, menus, balises canonical, hreflang et sitemap XML doivent tous viser l'URL finale. Votre propre site ne devrait jamais déclencher une seule redirection. Pour les backlinks les plus forts, un e-mail poli au webmaster pour qu'il mette son lien à jour vaut largement les cinq minutes qu'il coûte. Et on ne supprime pas les anciennes redirections : Google conseille de les garder au moins un an après un déménagement, je les laisse pour ma part tant que des liens externes pointent dessus. C'est un des points de ma check-list pour migrer un site sans y laisser son référencement, et c'est précisément ce qui évite de recréer une chaîne à la refonte suivante.

Une chaîne ne fait pas tomber un site, mais elle s'allonge à chaque refonte : la corriger, c'est faire pointer chaque ancienne URL directement vers la page finale et ne plus jamais lier une URL qui redirige.