- →La documentation de migration de Google est explicite : une redirection permanente ne fait pas perdre de PageRank. Le mythe des « 15 % perdus par saut » n’a aucun support documentaire en 2026, arrêtez de le vendre en réunion.
- →Googlebot suit jusqu’à 10 redirections, mais le seuil défendable en QA reste celui de la doc Google : redirection directe si possible, sinon trois sauts, moins de cinq dans tous les cas.
- →Le vrai coût d’une chaîne est opérationnel : latence utilisateur, requêtes de crawl supplémentaires, compatibilité incertaine selon les user-agents, et un point de rupture de plus à chaque hop.
- →Google recommande de conserver les redirections de migration au moins un an tout en mettant à jour les liens internes et les backlinks à forte valeur vers les URL finales. Conserver n’est pas laisser pourrir.
- →Une chaîne se hiérarchise par valeur, pas par volume : le hop qui compte est celui traversé par vos vingt meilleurs domaines référents, pas les 4 000 URL de pagination.
- →Boucle infinie et cible morte ne sont pas des chaînes aggravées, ce sont des pannes. Google lui-même s’est fait piéger en septembre 2025 sur sa propre documentation.
Ce qu’une chaîne coûte vraiment, et ce qu’elle ne coûte pas
Une chaîne de redirection, c’est une URL A qui renvoie vers B, qui renvoie vers C, qui renvoie enfin vers la page servie en 200. Le crawler ne voit pas une redirection, il voit une séquence de requêtes HTTP à dérouler avant d’obtenir du contenu. Cette distinction est toute la question opérationnelle : le problème n’est pas sémantique, il est mécanique.
Il faut commencer par tuer le mythe qui traîne encore dans les audits vendus en 2026. La documentation Google sur les migrations d’URL indique que les redirections permanentes, 301 et 308, n’entraînent pas de perte de PageRank. Pas « une perte réduite », pas « une perte négligeable » : pas de perte. Le chiffre des 15 % évaporés à chaque saut vient d’une lecture ancienne du fonctionnement du PageRank appliqué aux liens sortants, et il n’a jamais été confirmé pour les redirections dans la documentation actuelle. Un consultant qui facture un chantier de dé-chaînage en promettant de « récupérer le jus perdu » vend une justification qui ne tient pas.
Ce que Google écrit en revanche, dans la même documentation, c’est qu’il déconseille les chaînes pour d’autres raisons : elles ajoutent de la latence et tous les user-agents ne les gèrent pas de façon fiable. Autrement dit, l’argument n’est pas le transfert de valeur entre pages mais la robustesse du chemin. C’est un argument plus faible sur le papier, et beaucoup plus solide dans la vraie vie, parce qu’il se vérifie avec un curl plutôt qu’avec une croyance.
La bonne façon de hiérarchiser, en 2026, tient en quatre cas. Une redirection permanente directe : rien à signaler, Google dit qu’il n’y a pas de perte. Une chaîne : pas de pénalité automatique, mais de la latence, des requêtes en plus, des risques d’implémentation et une compatibilité variable. Une boucle ou une cible cassée : la résolution devient impossible, utilisateurs et robots sont bloqués, c’est une panne. Une redirection trompeuse, qui envoie ailleurs que ce que la SERP annonçait : là on entre dans les politiques anti-spam, et l’update spam d’août 2025, lancé le 26 août 2025, visait explicitement les sneaky redirects d’après la couverture métier de l’époque. Ces quatre cas n’ont ni la même gravité ni le même correctif, et les mélanger dans un même bloc rouge d’audit est la première erreur de méthode.
La mécanique en 2026 : seuils, latence, budget de crawl
Le seuil technique est connu : Googlebot suit jusqu’à dix redirections dans une chaîne. Le seuil recommandé est bien plus bas. La documentation de migration conseille de rediriger directement vers l’URL finale quand c’est possible, et sinon de rester idéalement à trois sauts, en tout cas sous les cinq. C’est ce seuil de trois qu’il faut poser en QA, pas les dix. La différence entre les deux nombres n’est pas une marge de sécurité offerte au SEO, c’est l’écart entre ce que le crawler tolère et ce qui reste maintenable.
Le mécanisme de canonicalisation mérite d’être posé proprement, parce qu’il est souvent confondu avec la question de la chaîne. Google traite une redirection permanente comme un signal fort indiquant que la cible doit devenir l’URL canonique. Les redirections temporaires, 302, 303, 307, sont un signal temporaire et ne rendent pas la cible canonique à elles seules. Une chaîne qui mélange les deux, typiquement un 301 legacy suivi d’un 302 posé par un développeur pressé, envoie donc deux instructions contradictoires sur le même chemin. C’est là que la déclaration de canonique côté balise et la réalité HTTP divergent, et c’est ce désaccord, pas le nombre de hops, qui produit les indexations bizarres qu’on retrouve en console.
Le coût en crawl est réel mais rarement dimensionnant sur un site de quelques milliers d’URL. Il le devient sur un site à forte pagination, sur un e-commerce à facettes ou sur un parc de médias où la même règle mal écrite se réplique. Chaque hop est une requête que le crawler dépense sans obtenir de contenu. Sur un site où le volume de pages exploré chaque jour est déjà le facteur limitant, transformer trois requêtes en une seule sur 40 000 URL n’est pas de l’hygiène cosmétique.
Côté durée de vie, la doc Google est nette et souvent mal lue : conserver les redirections de migration au moins un an, tout en mettant à jour les liens internes et les liens externes importants vers les URL finales. Les deux moitiés de la phrase comptent. Garder la redirection un an, c’est laisser à Google le temps de recrawler les anciennes URL et de réattribuer les signaux. Mettre à jour les liens dans le même temps, c’est éviter que l’infrastructure de redirection devienne une dépendance permanente que plus personne n’ose toucher trois ans plus tard.
Où ça fait mal dans une opération de netlinking
C’est en netlinking que la chaîne cesse d’être un point technique pour devenir un problème d’actif. Un backlink acheté ou obtenu il y a trois ans pointe vers une URL qui a survécu à une refonte, à un changement de slug et à un passage en HTTPS. Il fonctionne encore, il passe encore ses signaux via les redirections permanentes, et pourtant il est fragile : sa valeur dépend désormais de règles de redirection maintenues par une équipe qui n’a jamais su qu’un lien payé en dépendait.
La documentation de Google recommande d’ailleurs explicitement, après un déménagement d’URL, de contacter les sites référents à forte valeur pour qu’ils mettent à jour leurs liens. Peu d’équipes le font, parce que c’est du travail manuel et peu gratifiant. C’est pourtant le seul geste qui transforme un actif en dépendance nulle. Sur les médias éditoriaux que nous opérons en propre, la règle interne est simple : un lien posé pointe vers l’URL finale du client au moment de la publication, et une migration côté client déclenche une mise à jour à la source plutôt qu’un empilement de redirections. C’est plus lent à opérer, et ça évite qu’un profil de liens repose sur des règles serveur que personne n’audite. Quand vous achetez ailleurs, exigez au minimum de savoir si l’éditeur accepte de corriger l’URL cible plus tard, et regardez ce que le catalogue de médias consultable avant toute commande dit de ses conditions d’édition.
Un cas particulier mérite un avertissement franc : le rachat de domaines redirigés vers un site principal. Une compilation de statistiques de link building publiée en 2025 par Spiralytics rapporte que 19,9 % des link builders interrogés déclarent acheter et rediriger des domaines pour acquérir des liens. Ce n’est pas une mesure de performance validée par Google, c’est un indicateur d’usage. Il dit surtout que cette pratique reste une source active de chaînes, de redirections hors sujet et d’exposition aux politiques sur l’abus de domaines expirés. Rediriger un domaine d’un secteur vers un autre sans continuité thématique ne crée pas un raccourci, ça crée un motif que les systèmes anti-spam savent lire.
Ce qu’on voit casser en audit
La première erreur récurrente, c’est de compter les chaînes au lieu de les valoriser. Un rapport qui annonce « 1 240 chaînes de redirection » sans dire combien de domaines référents, combien de trafic organique et combien de conversions transitent par chacune ne permet aucune décision. La bonne unité de reporting est la ligne : nombre de hops, valeur des domaines référents concernés, trafic organique, conversions, pertinence de la page finale. Vingt lignes triées comme ça valent mieux qu’un export de 1 240.
La deuxième, c’est d’auditer uniquement les URL du fichier de sitemap. Le sitemap ne contient que les URL vivantes que vous déclarez. Les chaînes vivent ailleurs : dans les anciennes URL qui portent des backlinks, dans les liens internes en dur qui traînent dans des articles de 2018, dans les paramètres de campagne, dans les redirections d’ancienne version linguistique. Un audit de chaînes qui part du sitemap trouve un site propre et rate la totalité du sujet.
La troisième, c’est la redirection en masse vers la page d’accueil. Elle supprime le 404 et la ligne rouge dans l’outil, elle ne conserve rien : la page d’arrivée n’a aucun rapport avec la ressource demandée, et la pertinence de la page finale est précisément l’un des critères sur lesquels une redirection se juge. Rediriger 300 fiches produit mortes vers l’accueil, c’est troquer un signal honnête contre un signal faux.
La quatrième, c’est la boucle. Elle n’arrive pas qu’aux amateurs : en septembre 2025, Search Engine Journal a rapporté que des URL de documentation obsolète de Google redirigeaient en 301 vers un changelog qui renvoyait lui-même vers ces mêmes URL, créant une boucle infinie. Les pages concernées incluaient Course Info, Estimated Salary, Learning Video, Special Announcement et Vehicle Listing. Si l’équipe qui écrit la documentation sur les redirections se piège elle-même, personne n’est à l’abri d’une règle catch-all mal ordonnée.
La cinquième, plus insidieuse : l’ordre des règles. Dans la plupart des serveurs et des fichiers de redirection, la première règle qui matche gagne. Une règle générique posée en haut du fichier annule silencieusement les vingt corrections précises ajoutées en dessous six mois plus tard. Rien ne casse, rien n’alerte, et les URL corrigées continuent de partir au mauvais endroit.
Le protocole qu’on applique sur un parc
Le point de départ n’est pas un crawl, c’est un export de backlinks. Sortez la liste des URL cibles de vos liens entrants, dédupliquez, et passez cette liste en mode liste dans un crawler plutôt que de laisser le crawler découvrir le site tout seul. Screaming Frog fait ce travail, sa version gratuite reste limitée à 500 URL par crawl d’après la page produit officielle, la licence payante étant affichée à 199 £ par an, soit 279 $ annoncés, pour lever cette limite et débloquer la comparaison de crawls et la planification. Pour un parc de plusieurs sites, la licence se rentabilise au premier chantier de migration.
Ensuite, tranchez par valeur. Les chaînes traversées par vos meilleurs domaines référents se corrigent à la source quand c’est possible, en demandant la mise à jour du lien, et se raccourcissent à un saut unique côté serveur dans tous les cas. Les chaînes internes se corrigent en réécrivant les liens dans le contenu, pas en empilant des règles : un lien interne qui pointe vers une URL redirigée est un bug d’édition, pas un sujet d’infrastructure. Le reste, pagination morte, paramètres exotiques, URL jamais liées, se documente et se laisse vivre.
Une remarque sur le calendrier. Les mises à jour larges de 2026 ne portent pas sur les redirections : le core update de mars 2026 a démarré le 27 mars et s’est achevé le 8 avril 2026, soit 12 jours et 4 heures selon Search Engine Land, et rien dans sa communication ne concerne les chemins de redirection. Attribuer une baisse à une chaîne parce qu’elle coïncide avec un core update est une erreur de causalité classique. Si vous voulez mesurer l’effet d’un dé-chaînage, comparez des fenêtres symétriques hors période de déploiement, sur les URL corrigées uniquement.
Dernier point, budgétaire. Nettoyer des chaînes ne fait pas monter un site qui n’a pas d’autorité, ça évite de perdre celle qu’il a déjà. C’est un chantier de conservation, à budgétiser comme tel : quelques jours d’audit et de correction, puis une surveillance. L’argent qui fait bouger les positions va ailleurs, dans l’acquisition de liens éditoriaux et dans le contenu, et il se compare sur des grilles tarifaires publiques plutôt que sur devis. Un audit technique qui promet des gains de trafic sur du dé-chaînage seul confond hygiène et levier.
Nautilinks opère un réseau de médias éditoriaux. Articles écrits en interne, mentions de transparence respectées, mix d'ancres calibré.
Questions fréquentes
Est-ce qu’une chaîne de deux sauts justifie un chantier de correction ?
Pas en soi. Deux sauts restent sous le seuil recommandé par Google, qui parle de trois sauts idéalement et de moins de cinq en pratique. La question à poser est différente : qui traverse cette chaîne. Si ce sont vos dix meilleurs domaines référents ou une page à conversion, corrigez, parce que vous supprimez une dépendance et de la latence. Si c’est de la pagination sans lien entrant, documentez et passez à autre chose.
Un 302 en milieu de chaîne annule-t-il le signal du 301 initial ?
Il le brouille. Google traite les redirections permanentes comme un signal fort de canonicalisation vers la cible, alors que les 302, 303 et 307 sont des signaux temporaires qui ne rendent pas la cible canonique à eux seuls. Une chaîne 301 puis 302 envoie donc deux instructions incompatibles sur le même chemin. Le symptôme typique est une URL canonique choisie par Google différente de celle que vous déclarez. Homogénéisez en permanent sur toute la chaîne.
Combien de temps garder les redirections après une migration ?
Google recommande de les conserver au moins un an, le temps de recrawler les anciennes URL et de réattribuer les signaux. La seconde moitié de la recommandation est plus souvent oubliée : pendant cette année, mettez à jour vos liens internes et faites corriger les liens externes à forte valeur vers les URL finales. Au bout d’un an, une redirection encore massivement empruntée signale que ce travail n’a pas été fait.
Rediriger un domaine expiré vers mon site, c’est une chaîne acceptable ?
C’est le cas le plus exposé. Une compilation de statistiques de link building de 2025 rapporte que 19,9 % des link builders déclarent acheter et rediriger des domaines pour obtenir des liens, donc la pratique est courante, mais elle cumule trois risques : chaînes multiples, perte de pertinence thématique et exposition aux règles sur l’abus de domaines expirés. Si le domaine n’a aucune continuité de sujet avec la cible, la redirection est un motif, pas un raccourci.
Comment détecter les chaînes qui portent vraiment de la valeur ?
Partez de l’export de backlinks, pas du sitemap. Extrayez les URL cibles de vos liens entrants, dédupliquez, et passez cette liste en mode liste dans un crawler comme Screaming Frog, dont la version gratuite plafonne à 500 URL par crawl. Croisez ensuite le nombre de sauts avec la valeur des domaines référents, le trafic organique et les conversions. Vingt lignes triées par valeur sont exploitables, un export brut de milliers de chaînes ne l’est pas.
Peut-on encore dire qu’une redirection perd 15 % de la valeur du lien ?
Non, et le répéter décrédibilise un audit. La documentation Google sur les migrations d’URL indique que les redirections permanentes n’entraînent pas de perte de PageRank. Les vraies raisons de raccourcir une chaîne sont la latence, les requêtes de crawl consommées sans contenu, la gestion inégale selon les user-agents et le nombre de points de rupture. Ce sont des arguments vérifiables avec un simple appel HTTP, contrairement au pourcentage.
Testez vos connaissances
Quiz : Chaîne de redirection
1/3Quel seuil de sauts la documentation Google recommande-t-elle en pratique, indépendamment de ce que Googlebot peut techniquement suivre ?