Les chaînes de redirection après une migration

Après une migration, elles s’empilent. Vieille URL de blog vers /blog/, vers /fr/blog/, vers le nouveau slug. Le TTFB en pâtit. Les crawlers suivent quelques sauts puis s’arrêtent. Ton favori marche encore. C’est le seul plus. Search Console indexe encore l’arrêt intermédiaire comme s’il comptait.

Exporte ce qui est là maintenant. Crawl, logs, Search Console. Trace ancien → nouveau. Un 301 par chemin. Les règles d’hôte (http/https, www) en un seul passage, pas trois astuces séparées. Le slash final dans le même saut. Un 302 « temporaire » qui tient depuis deux ans, c’est un 301 que quelqu’un a oublié.

L’étape intermédiaire « pour les gens avec l’ancien favori » peut partir si le favori passe déjà par la chaîne depuis deux ans. Les gens arrivent aussi en un saut. Et retire l’URL intermédiaire du sitemap. Sinon tu promets une adresse qui redirige tout de suite.

Les semaines après le lancement, continue à regarder. Je ne laisserais pas des chaînes de plus de deux pas. La conversation avec celui qui fait le serveur est plus courte si tu as déjà la liste. Imprime les sauts. Le débat « ça a l’air assez rapide » gagne rarement contre un tableau.

Les vieux 302 d’un test A/B restent aussi. Ils vont dans la même ronde de ménage. Et si le CDN et l’app redirigent tous les deux, tu comptes deux sauts avant le HTML. Choisis un endroit qui dirige. L’autre laisse passer. Ennuyeux. Ça te sauve aussi du TTFB.