Quatre codes de redirection HTTP, quatre comportements significativement différents, et une erreur SEO récurrente sur chaque migration : utiliser 302 par défaut parce que c'est ce que le framework émet. Voici la véritable matrice de décision pour 301 vs 302 vs 307 vs 308, plus le coût réel d'une mauvaise décision.
Les quatre codes en une phrase chacun
301 Moved Permanently : la redirection permanente canonique. Cacheable. La méthode peut changer de POST à GET. Le standard pour les déplacements d'URL permanents.
302 Found : redirection temporaire. Cacheable mais avec revalidation. La méthode peut changer de POST à GET. Utilisé par les frameworks par défaut ; presque jamais le bon choix pour les mouvements permanents en SEO.
307 Temporary Redirect : comme 302 mais la méthode est préservée. POST reste POST. Utilisé pour les mouvements temporaires où la méthode compte (rare en SEO de site marketing ; courant dans les API).
308 Permanent Redirect : comme 301 mais la méthode est préservée. POST reste POST. Le remplaçant HTTP/2 du 301 quand la préservation de la méthode compte. Les frameworks modernes (Next.js, Vercel) émettent 308 par défaut pour les appels redirect().
Pourquoi cela importe pour le SEO
Google a déclaré publiquement que les redirections 301 et 308 transfèrent tous deux le signal PageRank complet. Les redirections 302 et 307 transfèrent moins fiablement — l'hypothèse intégrée dans l'interprétation de Google est qu'une redirection temporaire pointe vers une destination temporaire, donc le signal canonique devrait rester sur l'URL d'origine. Lors d'une migration, c'est exactement l'inverse de ce que vous voulez : vous voulez que le signal canonique se déplace.
Impact réel : un site qui implémente des redirections de migration en 302 au lieu de 301 perd généralement 20-40% de son trafic organique dans les 60 premiers jours suivant la migration. La correction n'est pas subtile, mais elle n'est pas toujours détectée parce que les 302 fonctionnent pour les utilisateurs (le navigateur les suit, la page se charge). Search Console signale le problème dans le rapport Coverage sous « Page avec redirection » mais la plupart des équipes ignorent ce rapport pendant la panique post-migration.
La matrice de décision
Trois questions. Répondez-y dans l'ordre ; le résultat détermine le code.
Question 1 : Le déplacement est-il permanent ?
Si oui (l'URL se déplace définitivement, l'ancienne URL ne reviendra pas) : utilisez 301 ou 308. Si non (l'URL reviendra, c'est temporaire) : utilisez 302 ou 307.
Question 2 : L'URL reçoit-elle des requêtes POST ?
Si oui (soumissions de formulaires, appels API, POSTs JSON) : utilisez 307 ou 308 (méthode préservée). Si non (navigation du navigateur, clic sur un lien) : 302 ou 301 conviennent.
Question 3 : Quel est le défaut par défaut du framework ?
Stacks modernes : Next.js redirect() émet 308 par défaut, vercel.json [[redirects]] utilise 308 sauf si permanent: false est défini, Netlify _redirects utilise 301 sauf indication explicite contraire. Apache mod_rewrite utilise 302 par défaut, ce qui surprend tout le monde la première fois. Vérifiez toujours le défaut de votre framework avant de vous y fier.
Les quatre erreurs les plus courantes
- Utiliser 302 par défaut parce qu'Apache/Express/Flask l'émettent comme défaut pour le helper redirect(). Correction : définissez explicitement 301 dans chaque règle de redirection lors d'un déplacement permanent.
- Utiliser 307 en pensant que c'est le 301 moderne. Ce n'est pas le cas — 307 est le 302 moderne (temporaire, préservant la méthode). Pour les déplacements permanents, utilisez 308 ou 301.
- Mélanger 301 et 302 dans la même carte de redirections. Choisissez-en un (301 pour les migrations) et utilisez-le partout ; les codes mélangés confondent la génération de rapports de Search Console.
- Oublier que 308 préserve la méthode POST. Si votre ancienne URL était un endpoint de soumission de formulaire et que vous la redirigez en 308 vers la nouvelle URL, les données POST passent à travers. Si vous la redirigez en 301, le navigateur convertit POST en GET et la soumission du formulaire est perdue. Connaître la différence permet de détecter une vraie classe de bug.
Quand utiliser quoi, en pratique
Redirections de migration (ancien domaine → nouveau domaine, ancien slug → nouveau slug) : utilisez 301. Le plus simple, le plus largement supporté, et explicitement indiqué par Google comme un transfert complet de PageRank.
Déplacements permanents où la préservation de la méthode compte (endpoints POST, soumissions de formulaires) : utilisez 308. Le transfert de PageRank est identique à 301 ; la seule différence est que POST reste POST.
Déplacements temporaires (tests A/B, redirections géographiques, maintenance) : utilisez 302. Un transfert de PageRank réduit est le bon comportement parce que l'URL source devrait conserver son signal de classement.
Les déplacements temporaires avec préservation de méthode (points de terminaison API en basculement temporaire) : utilisez 307.
Comment configurer chaque code sur les plateformes courantes
Vercel (vercel.json)
Bloc [[redirects]]. Définissez permanent: true pour 308 (par défaut), permanent: false pour 307. Pour forcer 301, utilisez statusCode: 301 explicitement. La plupart des déploiements Vercel modernes utilisent par défaut 308, ce qui convient pour les migrations ; le choix conservateur en SEO est 301 pour une compatibilité maximale avec les anciens crawlers et indexeurs.
Netlify (netlify.toml ou _redirects)
Syntaxe _redirects : /old-url /new-url 301 pour permanent, /old-url /new-url 302 pour temporaire. Ajoutez ! pour forcer le statut : /old-url /new-url 301!.
Apache (.htaccess)
Redirect 301 /old-url /new-url pour permanent. RewriteRule avec le drapeau [R=301,L] pour les redirections de style réécriture.
Nginx
return 301 https://example.com/new-url; à l'intérieur d'un bloc location. Pour les correspondances de motif : rewrite ^/old/(.*)$ /new/$1 permanent; (le drapeau permanent génère 301 ; le drapeau redirect génère 302).
Vérifier les codes en production
Trois commandes que tout ingénieur devrait maîtriser. curl -I https://example.com/old-url retourne le code de statut dans les en-têtes de réponse. curl -ILk suit les redirections et enregistre chaque code de statut au passage (détecte les chaînes).
Pour vérifier en masse des centaines d'URLs, c'est scriptable : une boucle fetch Node.js qui lit un CSV d'anciennes URLs et enregistre le statut + la destination finale. Ou utilisez le endpoint Instant Pages on-page de DataForSEO, qui retourne la trace complète des redirections.
Le résumé
301 pour les déplacements permanents (par défaut pour les migrations SEO). 308 quand la préservation de la méthode importe et que le déplacement est permanent. 302 pour les déplacements temporaires. 307 pour les déplacements temporaires avec préservation de la méthode. Les valeurs par défaut du framework ne sont pas toujours correctes ; vérifiez-les au moment du déploiement.
Lectures connexes : 410 vs 404 couvre le cas du retrait (URLs disparaissant pour toujours, pas déplacées). Une migration classique nécessite généralement les deux décisions.