# Antipatterns de redirection : chaîner les 301 ralentit le crawl de Google

> Trois refontes successives, trois couches de redirections empilées : voici pourquoi chaîner les 301 finit par coûter cher en budget de crawl et en vitesse.

- Auteur : Clément Hadrot
- Publié le : 2020-07-16
- Mis à jour le : 2020-07-16
- Catégorie : SEO & GEO
- URL : https://wpmoderne.dev.wordpress-developpement.fr/seo/antipatterns-redirections-301-en-chaine/

## L’essentiel

- Une chaîne de trois redirections ou plus ralentit sensiblement l'exploration
- Googlebot suit les chaînes mais ne transmet plus tout le crédit d'origine
- Chaque redirection doit pointer vers la destination finale, jamais vers une étape intermédiaire

En auditant les redirections d'un site passé par trois refontes successives en cinq ans, un motif revient sans arrêt : une URL de 2016 redirige vers une URL de 2018, qui elle-même redirige vers l'URL actuelle de 2020. Trois sauts pour arriver à destination, sur des centaines d'URL héritées. Rien ne semble cassé du point de vue de l'utilisateur, qui atterrit bien sur la bonne page après un léger délai.

Le problème est ailleurs : chaque redirection supplémentaire dans la chaîne ajoute une requête HTTP, un délai, et une dilution progressive du signal transmis à la page finale. Voici ce qu'on voit sur ce type d'audit, pourquoi c'est un problème concret, et comment le corriger sans tout reconstruire.

## Ce qu'on voit typiquement dans ce genre d'historique

Chaque refonte a son propre plan de redirection, généralement bien intentionné : au moment de la refonte de 2018, les redirections de 2016 fonctionnaient encore, donc personne n'a jugé utile de les réécrire vers les nouvelles URL de 2018. Résultat, en 2020, une nouvelle couche de redirections vient s'ajouter par-dessus les deux précédentes, sans jamais les fusionner. Un audit avec un outil de suivi de redirections révèle alors des chaînes de trois, parfois quatre sauts, sur des URL parfois encore actives dans des liens externes anciens.

## Pourquoi ce n'est pas un simple détail cosmétique

Trois effets concrets et mesurables découlent de ce chaînage :

- **Vitesse** : chaque saut ajoute une requête réseau complète, avec son propre temps de résolution DNS potentiel et son propre round-trip TCP, ce qui pénalise directement le temps de chargement perçu.
- **Budget de crawl** : Googlebot doit suivre chaque maillon de la chaîne pour atteindre la destination, ce qui consomme plusieurs requêtes d'exploration pour une seule URL utile au final.
- **Dilution du signal** : Google a confirmé suivre plusieurs redirections dans une chaîne, mais au-delà d'un certain nombre de sauts, l'exploration peut s'arrêter avant d'atteindre la destination, surtout si le budget de crawl du site est déjà contraint.

> L'essentiel à retenir : Une chaîne de trois redirections ou plus ralentit sensiblement l'exploration ; Googlebot suit les chaînes mais ne transmet plus tout le crédit d'origine ; Chaque redirection doit pointer vers la destination finale, jamais vers une étape intermédiaire

## Comment tracer une chaîne existante

La commande `curl` avec l'option qui suit les redirections en mode verbeux permet de visualiser chaque saut individuellement :

```
curl -IL https://exemple.fr/ancienne-url-2016/
```

Chaque bloc de réponse affiché correspond à un maillon de la chaîne, avec son code de statut et l'en-tête `Location` pointant vers l'étape suivante. Sur un site entier, cette vérification manuelle URL par URL n'est pas réaliste : il faut croiser l'export du fichier `.htaccess` ou des règles de redirection avec un tableur, en suivant chaque destination jusqu'à trouver un code 200 final, pour repérer les chaînes automatiquement.

## La correction : aplatir, pas empiler

La règle est simple à énoncer et facile à appliquer une fois les chaînes identifiées : chaque redirection doit pointer directement vers la destination finale actuelle, jamais vers une étape intermédiaire devenue elle-même une redirection. Sur l'exemple cité, la redirection de 2016 doit être réécrite pour pointer directement vers l'URL de 2020, en supprimant le maillon de 2018 devenu inutile.

```
# Avant : trois sauts
RewriteRule ^produit-ancien/?$ /produit-2018/ [R=301,L]
RewriteRule ^produit-2018/?$ /produit-final/ [R=301,L]

# Après : un seul saut
RewriteRule ^produit-ancien/?$ /produit-final/ [R=301,L]
```

## Le cas particulier des redirections croisées avec le canonical

Un piège supplémentaire apparaît quand la destination finale d'une chaîne pointe vers une URL qui possède elle-même une balise canonique vers une troisième URL différente. Dans ce cas, Google reçoit deux signaux distincts, la redirection et le canonical, qui peuvent se contredire si la maintenance n'a pas été rigoureuse. Il faut systématiquement vérifier que la destination finale d'une redirection est aussi celle indiquée par sa propre balise canonique, sans quoi la confusion s'installe.

## Notre verdict

Une redirection isolée ne pose jamais de problème. C'est l'accumulation, refonte après refonte, sans nettoyage des couches précédentes, qui transforme un mécanisme sain en gaspillage progressif. Un audit de redirections devrait faire partie de tout chantier de refonte, avec un objectif simple : zéro chaîne de plus d'un saut à la fin du projet, quitte à réécrire des dizaines de règles héritées.