Développement & Tech
Redirections : 301 vs 302, chaînes et migrations sans perte
Quand utiliser chaque code HTTP, l'impact des chaînes de redirections sur la vitesse et l'erreur de migration qui détruit votre trafic organique.
Les redirections semblent simples jusqu'au jour où vous réalisez une refonte ou une migration de site. À cet instant, elles deviennent le facteur déterminant qui décidera si vous conservez votre trafic organique ou si vous repartez de zéro.
Les règles techniques sont directes. Les erreurs coûtent cher mais sont presque toujours évitables.
Les différents codes d'état HTTP
301 — Déplacé de façon permanente (Moved Permanently). Les moteurs de recherche transfèrent l'autorité de classement (PageRank) vers la nouvelle URL et remplacent progressivement l'ancienne dans leur index. Les navigateurs la mettent en cache de manière agressive, parfois indéfiniment. C'est pourquoi une redirection 301 déployée par erreur est complexe à annuler : les visiteurs réguliers continuent d'utiliser leur cache local bien après la correction sur le serveur.
308 — Redirection permanente (Permanent Redirect). Identique au code 301 à une nuance essentielle près : elle conserve la méthode HTTP initiale. Une requête POST reste un POST au lieu d'être convertie en GET. À privilégier pour les points de terminaison d'API ; pour les pages web classiques, le 301 reste le standard universellement reconnu.
302 — Trouvé / Déplacement temporaire (Found). Les signaux SEO restent attachés à l'URL d'origine et la page de destination n'est pas indexée à sa place. Adapté aux tests A/B, aux pages de maintenance et aux redirections linguistiques basées sur l'en-tête Accept-Language — toutes les situations où la destination dépend du contexte de la requête et ne constitue pas un remplacement définitif.
307 — Redirection temporaire (Temporary Redirect). L'équivalent temporaire du 308, préservant la méthode de requête HTTP.
L'erreur coûteuse : utiliser un code 302 pour un changement d'URL définitif. Google finira souvent par l'assimiler à un 301, mais ce délai d'apprentissage peut durer des mois pendant lesquels votre nouvelle page ne sera pas indexée correctement.
Les chaînes de redirections
Une chaîne survient lorsqu'une redirection renvoie vers une autre redirection avant d'atteindre la destination finale. Elles s'accumulent insidieusement au fil du temps :
http://example.com/ancienne-page
→ 301 → https://example.com/ancienne-page
→ 301 → https://www.example.com/ancienne-page
→ 301 → https://www.example.com/nouvelle-page/
→ 200
Quatre requêtes réseau successives avant que le navigateur ne reçoive le moindre octet de contenu. Chacune résultait d'une règle légitime ajoutée à des moments différents : forcer le HTTPS, standardiser le sous-domaine www, migrer l'arborescence.
Quel est l'impact réel de ces chaînes ?
Ce n'est plus la perte de popularité SEO. Google a confirmé dès 2016 que les redirections 301 transmettaient l'intégralité du PageRank, rendant obsolète le mythe d'une « déperdition de 15 % par saut ».
Le coût réel concerne la vitesse de chargement. Sur une connexion mobile, chaque étape représente un aller-retour réseau complet (round trip). Même si la résolution DNS est faite, les négociations TCP et TLS peuvent s'ajouter, injectant 200 à 400 ms de latence supplémentaire par saut. Cela dégrade directement le Largest Contentful Paint (LCP), pénalisant le positionnement et augmentant le taux de rebond.
Google abandonne le suivi au-delà d'une dizaine de rebonds. Vos visiteurs, eux, auront quitté la page bien avant.
La solution consiste à aplatir vos règles : faites pointer directement l'URL d'origine vers la destination finale sans passer par des règles intermédiaires.
Le gain de performance grâce au HSTS
Si vous redirigez systématiquement le http:// vers https://, chaque nouvel utilisateur subit cette latence initiale.
L'activation du protocole HSTS supprime ce délai pour tous vos visiteurs récurrents :
Strict-Transport-Security: max-age=31536000; includeSubDomains
Le navigateur se connecte directement en HTTPS dès la visite suivante sans solliciter le serveur en HTTP. Vous économisez un aller-retour réseau sur chaque chargement de page.
Les boucles de redirection
Une boucle de redirection rend l'accès à une page impossible (erreur ERR_TOO_MANY_REDIRECTS). Causes fréquentes :
- Un conflit entre la gestion du slash final (
/) et l'URL canonique - Une règle HTTPS au niveau applicatif entrant en conflit avec celle du CDN
- Une redirection linguistique renvoyant en boucle sur la page sélectionnée
Ces anomalies restent invisibles jusqu'à ce qu'un internaute tente d'accéder à l'URL exacte qui déclenche le conflit.
Vous pouvez inspecter le parcours précis de n'importe quelle URL grâce à notre testeur de redirections gratuit. Il détaille chaque saut individuellement pour identifier les pertes de temps.
L'erreur de migration qui détruit le trafic SEO
Toute ancienne URL disposant d'un historique de trafic ou de liens entrants doit faire l'objet d'une redirection 301 vers son équivalent le plus proche et spécifique.
Pas vers la page d'accueil.
Google assimile une redirection massive d'URL disparates vers la page d'accueil à une fausse erreur 404 (Soft 404) et ne transmet aucun jus de lien. C'est la cause numéro un d'effondrement de trafic lors d'une refonte de site web, souvent choisie par facilité pour s'éviter la création d'un plan de redirection exhaustif.
La méthode rigoureuse et efficace :
- Explorer l'ancien site avant toute coupure (via Screaming Frog, Sitebulb ou vos sitemaps).
- Exporter les URL stratégiques : celles générant du trafic organique dans vos statistiques et disposant de backlinks dans la Search Console.
- Associer chaque page à son équivalent exact sur la nouvelle structure.
- Pour les pages supprimées sans équivalent, renvoyer un code HTTP 410 Gone plutôt qu'un 301 vers un contenu sans rapport. Le 410 indique aux moteurs de désindexer proprement la ressource.
- Déployer le plan de redirection dès la mise en ligne du nouveau site.
- Surveiller Search Console pendant 6 semaines pour repérer les erreurs d'exploration résiduelles.
Gestion des barres obliques finales (Trailing Slash)
/page et /page/ constituent deux URL distinctes pour un serveur. Choisissez une convention unique, redirigez l'autre variante vers celle-ci, et assurez-vous que vos liens internes respectent rigoureusement la forme canonique choisie.
L'enjeu n'est pas seulement d'éviter le contenu dupliqué (géré par la balise canonique), mais de supprimer une redirection inutile sur chaque clic interne de vos utilisateurs.
Redirection ou balise canonique ?
Utilisez une redirection 301 lorsqu'une page a définitivement changé d'emplacement et que l'utilisateur doit aboutir sur la nouvelle URL.
Utilisez une balise canonique (canonical) lorsque plusieurs URL doivent rester accessibles simultanément mais qu'une seule doit être indexée (produit présent dans deux catégories distinctes, version imprimable, paramètres de suivi publicitaire).
Emplacement technique optimal
Au niveau du serveur web — dans le .htaccess (Apache / LiteSpeed) ou dans le bloc serveur (Nginx). C'est la méthode la plus rapide car elle s'exécute avant le démarrage de l'application.
Au niveau applicatif — via le routeur de votre framework ou un plugin de CMS. Légèrement plus lent car l'application doit s'initialiser, mais plus simple à administrer si les redirections reposent sur une base de données.
À proscrire : les redirections côté client. Une redirection en JavaScript ou via la balise <meta http-equiv="refresh"> est lente, interprétée de façon aléatoire par les robots et ne transmet pas les signaux d'autorité de manière fiable.
Checklist récapitulative
- Les changements définitifs utilisent le code 301, jamais 302
- Aucune chaîne de redirection ne dépasse un seul saut
- Le HSTS est configuré pour éviter le premier saut HTTP vers HTTPS
- Chaque ancienne URL stratégique renvoie vers un équivalent précis
- Les pages définitivement supprimées sans équivalent renvoient un code 410
- Les liens internes pointent directement vers l'URL finale canonique
- Chaque URL spécifique est testée individuellement