301, 302, 303, 307 et 308 : ce qui change vraiment
Une redirection est une réponse 3xx accompagnée d’un en-tête Location. Les codes diffèrent sur deux points : le déplacement est-il permanent, et le client peut-il changer la méthode de la requête? Les définitions se trouvent dans la RFC 9110.
- 301 Moved Permanently : permanente. Pour des raisons historiques, les clients peuvent transformer un POST en GET en la suivant, et les navigateurs le font.
- 302 Found : temporaire, avec la même exception historique du POST transformé en GET.
- 303 See Other : demande au client de récupérer la cible avec GET (ou HEAD). On l’utilise généralement après l’envoi d’un formulaire pour afficher une page de résultat.
- 307 Temporary Redirect : temporaire, et la méthode comme le corps de la requête ne doivent pas changer.
- 308 Permanent Redirect : permanente, et la méthode comme le corps de la requête ne doivent pas changer.
Les réponses 301 et 308 peuvent être mises en cache par défaut : un navigateur peut donc les réutiliser sans interroger de nouveau le serveur. Les réponses 302 et 307 ne sont mises en cache que si elles contiennent des en-têtes de mise en cache explicites.
Retracer la chaîne avec curl
curl -sIL suit chaque redirection et affiche les en-têtes de chaque réponse :
curl -sIL http://example.com/ | grep -iE '^(HTTP|location)'Résultat typique pour une chaîne de deux sauts :
HTTP/1.1 301 Moved Permanently
Location: https://example.com/
HTTP/2 301
location: https://www.example.com/
HTTP/2 200-I envoie des requêtes HEAD, et certains serveurs ne répondent pas de la même façon à HEAD et à GET. La première commande ci-dessous retrace la chaîne avec GET et n’affiche que les en-têtes; la seconde donne un résumé sur une ligne avec le nombre de sauts et l’URL finale :
curl -sL -o /dev/null -D - https://example.com/
curl -sL -o /dev/null -w '%{num_redirects} hops, final: %{http_code} %{url_effective}\n' http://example.com/Testez chaque point d’entrée, car chacun peut emprunter un chemin différent :
for u in http://example.com/ http://www.example.com/ https://example.com/ https://www.example.com/; do
echo "== $u"; curl -sIL --max-redirs 10 "$u" | grep -iE '^(HTTP|location)'
donecurl ne suit que les en-têtes Location. Il n’exécute ni JavaScript ni meta refresh et, par défaut, il ne conserve aucun cache HSTS ni de redirections d’une exécution à l’autre : c’est donc une bonne référence à comparer avec ce qu’affiche un navigateur.
Retracer la chaîne dans les outils de développement
Dans le panneau Network (Réseau), activez Preserve log (Chrome, Edge) ou Persist Logs (Firefox) pour que la liste ne soit pas effacée à chaque navigation, cochez Disable cache, puis chargez l’URL de départ. Filtrez les requêtes de type document : chaque saut apparaît sur une ligne, avec son code d’état et son en-tête de réponse Location.
Repérez les lignes qui n’ont jamais atteint le serveur. Chrome indique « from disk cache » pour une redirection réutilisée depuis son cache, et affiche une mise à niveau HSTS sous la forme 307 Internal Redirect avec l’en-tête Non-Authoritative-Reason: HSTS. Ces deux réponses sont produites par le navigateur lui-même, et non par votre serveur.
Problèmes courants
- Boucles de redirection : A redirige vers B et B revient vers A, jusqu’à ce que le navigateur échoue avec une erreur comme
ERR_TOO_MANY_REDIRECTS. Une cause fréquente : un CDN ou un répartiteur de charge termine HTTPS et joint le serveur d’origine en HTTP, tandis que l’origine, qui ignore le protocole initial (par exemple parce qu’elle ne tient pas compte deX-Forwarded-Proto), redirige sans cesse vers HTTPS. - Trop de sauts : des règles ajoutées au fil des ans s’empilent, par exemple
http://example.com/page→https://example.com/page→https://www.example.com/page→https://www.example.com/page/. Chaque saut ajoute un aller-retour. Faites pointer chaque règle directement vers l’URL finale. - La chaîne http → https → www : il vaut généralement la peine de la ramener à un seul saut, à une exception près. Si vous voulez HSTS sur le domaine nu ou prévoyez de le soumettre à la liste de préchargement HSTS,
http://example.comdoit d’abord rediriger vershttps://example.comsur le même hôte, pour que le navigateur y reçoive l’en-tête HSTS. - Signaux canoniques incohérents : les redirections envoient les utilisateurs vers
www, alors querel="canonical", les liens internes ou le plan du site utilisent encore le domaine nu, HTTP ou une autre forme de barre oblique finale. - Changement de méthode avec 301, 302 ou 303 : un POST vers un ancien point de terminaison devient un GET après la redirection, le corps est perdu et le formulaire ou l’appel d’API échoue. Utilisez 307 ou 308 quand la méthode doit être conservée.
- Redirections en cache et HSTS : dès qu’un navigateur a reçu un en-tête
Strict-Transport-Security, il réécrit lui-mêmehttp://enhttps://, sans aucune requête réseau, jusqu’à l’expiration demax-age. Une 301 en cache est réutilisée de façon semblable. Corriger le serveur ne changera pas ce qu’affiche ce navigateur : testez donc avec curl ou un nouveau profil de navigateur. Dans Chrome, les entrées HSTS apprises dynamiquement peuvent être supprimées àchrome://net-internals/#hsts; les entrées préchargées, non. - Redirections par meta refresh et JavaScript : le serveur renvoie 200, puis la page change d’adresse avec
<meta http-equiv="refresh" content="0; url=/new">ouwindow.location. Les outils qui lisent les en-têtes ne les voient pas. Repérez-les aveccurl -s https://example.com/ | grep -iE 'http-equiv|location\.(href|replace)'et remplacez-les par des redirections côté serveur lorsque c’est possible.
Répercussions sur le référencement
- Limitez les chaînes à un seul saut. Chaque saut supplémentaire ajoute de la latence pour les utilisateurs et les robots d’exploration, et les robots cessent de suivre la chaîne après un nombre limité de sauts.
- Utilisez une redirection permanente (301 ou 308) pour un déplacement permanent. Un code temporaire indique aux moteurs de recherche que l’URL d’origine pourrait revenir.
- Faites de la cible de la redirection l’URL canonique : elle doit renvoyer 200, porter un
rel="canonical"qui pointe vers elle-même et être l’URL utilisée dans les liens internes, les plans de site et les annotations hreflang. - Redirigez les anciennes URL vers leur équivalent le plus proche plutôt que de tout envoyer vers la page d’accueil, et conservez les redirections longtemps après une migration.
- Privilégiez les redirections côté serveur. Les redirections par meta refresh et JavaScript ne prennent effet qu’une fois la page récupérée (et, pour JavaScript, rendue), et tous les robots ne les traitent pas.
Liste de vérification rapide
- Retracez les quatre variantes :
httpethttps, domaine nu etwww. - Chacune atteint l’URL finale en un seul saut (deux si vous conservez volontairement l’étape HSTS).
- Les déplacements permanents utilisent 301 ou 308; les points de terminaison qui reçoivent des POST utilisent 307 ou 308.
- L’URL finale renvoie 200 et est sa propre URL canonique.
- Les liens internes, le plan du site et les balises canoniques utilisent l’URL finale.
- Aucune boucle derrière votre CDN ou votre mandataire : testez avec curl, pas seulement avec un navigateur.
- Le corps de la page ne contient ni meta refresh ni redirection JavaScript.
- Refaites le test dans un nouveau profil de navigateur pour écarter les redirections en cache et HSTS.
Vérifiez-le avec WebTraceCheck
Pour vérifier une chaîne sans rien installer, lancez une vérification de site Web sur WebTraceCheck; aucun compte n’est nécessaire. L’audit examine les réponses HTTP, les redirections, le DNS et le référencement technique, et présente chaque observation avec sa source et les limites de la mesure. Pour voir ce que fait un vrai navigateur, connectez-vous avec GitHub et ouvrez un navigateur infonuagique temporaire avec le moteur de navigateur, la région et le mode d’appareil de votre choix, distinct du navigateur de tous les jours où se sont accumulées vos redirections en cache et vos entrées HSTS.