Redirections 301 vs 302 : l'impact reel sur le ranking

Nous avons change la plateforme d'un e-commerce en janvier et perdu 38% du trafic organique en deux semaines. Le coupable n'etait ni le contenu, ni la nouvelle architecture, ni le Core Update du mois: c'etait une regle de redirection 302 que l'equipe infra avait poussee dans Cloudflare Workers, pensant pouvoir revenir en arriere plus tard. Googlebot a lu cela comme temporaire, a conserve les anciennes URL dans l'index, et le signal d'autorite a fait du ping-pong entre deux versions de la meme page. Ce cas resume le probleme: une redirection n'est pas un detail technique, c'est un signal semantique, et utiliser le mauvais code coute du ranking.

La difference formelle est simple. La 301 indique au crawler que l'URL a change definitivement, transfere le PageRank accumule (avec une perte minimale, selon Gary Illyes en 2023) et demande une mise a jour de l'index. La 302 dit que le changement est temporaire, garde l'ancienne URL comme canonique de fait et ne consolide rien. Au quotidien, la plupart des CMS et frameworks utilisent 302 par defaut quand on oublie de specifier, ce qui suffit a saigner l'equity lors de migrations, changements de slug et consolidations. Faites un Comment auditer le SEO on-page sans tomber dans les conjectures periodique qui inclut les codes de statut et vous trouverez des 302 dans des endroits que personne ne se rappelait avoir touches.

Il existe des cas legitimes pour la 302, et il faut les reconnaitre avant de tout changer. Tests A/B server-side avec duree limitee, geolocalisation quand le hreflang n'est pas encore en place, parcours de checkout qui renvoient au panier, maintenances planifiees de 24-48h. Le critere est binaire: l'ancienne URL va-t-elle reservir le contenu original? Si oui, 302. Si non, 301. Quand l'equipe produit demande un test de longue duree, poussez la discussion vers une 301 avec rollback documente, ou vous decouvrirez dans Search Console que les deux versions se battent pour la meme requete (voir Search Console : 7 rapports sous-exploites et ce qu il faut en tirer pour extraire ces donnees).

L'impact sur le ranking ne se limite pas a la perte d'equity. Les chaines de redirection, le melange 301-302 et les boucles sont le vrai fleau. Dans un audit recent chez un client SaaS, nous avons trouve 14 000 URL avec des chaines de 3+ sauts, dont le dernier en 302. Selon le log file analysis que nous avons fait tourner (l'article Log file analysis : ce que Googlebot fait vraiment detaille la technique), Googlebot abandonnait la moitie de ces chaines avant la destination finale. Resultat: pages strategiques indexees avec le mauvais contenu et crawl budget brule en redirections. Chaque saut ajoute de la latence, degrade le LCP et empile des signaux de canonicalisation contradictoires, qui s'entendent mal avec ce que vous avez defini dans Canonical tags : les erreurs frequentes qui saignent le trafic organique.

La methodologie que j'utilise pour auditer tient en quatre etapes. D'abord, Screaming Frog ou Sitebulb en mode liste, alimente par le top 5000 d'URL de GSC et GA4. Ensuite, croiser le code de reponse avec le statut d'indexation via l'API Search Console. Troisiemement, isoler trois groupes: 302 qui devraient etre 301 (la majorite), 301 en chaine (consolider en un seul saut) et 4xx servis derriere des redirections (pire cas). Quatriemement, prioriser par trafic et backlinks pointant vers l'URL source, avec Ahrefs ou Majestic. En e-commerce la courbe est brutale: 5% des URL concentrent 80% de l'equity, et c'est la qu'une 301 correcte recupere du trafic en 4-8 semaines, comme nous l'avons vu dans la migration discutee dans On-page e-commerce: PLP vs PDP sans cannibalisation.

Un detail que peu d'equipes considerent: 307 et 308, equivalents HTTP/1.1 modernes de 302 et 301, preservent la methode de la requete (important pour les POST d'API, sans interet pour le SEO de pages servies en GET). Google traite 308 comme 301 et 307 comme 302 pour l'indexation, selon la documentation officielle mise a jour en 2025. Utilisez ce que votre stack sert correctement, mais ne les melangez jamais dans la meme chaine. Et si vous travaillez sur des sites multilingues, rappelez-vous qu'une redirection par IP ou Accept-Language sans hreflang correct donne le pire des mondes: le Googlebot americain n'atteint jamais le contenu FR, comme detaille dans hreflang sans douleur: implementation pour sites multilingues.

Takeaway pratique: lancez aujourd'hui un crawl depuis la home sur 3 niveaux de profondeur, filtrez par code de reponse 302 et 307 et demandez pour chacun si l'ancienne URL va vraiment revenir. Si la reponse est non ou peut-etre, passez en 301. En parallele, cartographiez les chaines de plus d'un saut et consolidez vers la destination directe. Documentez les regles dans un fichier versionne dans le repo infra, pas dans le panneau du CDN, pour que le prochain changement de plateforme n'efface pas le travail. L'equity de lien ne se recupere pas par demande polie, elle se recupere avec le bon code de statut au bon endroit.