HTTP en profondeur - 14 - Les redirections : guider le client ailleurs

301, 302, 307, 308, le header Location, les chaînes de redirections et quand utiliser quel code.

14 - Les redirections : guider le client ailleurs

Ce que tu vas apprendre

  • Les quatre codes de redirection principaux et leurs différences
  • Le header Location et son fonctionnement
  • Les chaînes de redirections et leurs limites
  • L'impact SEO de chaque type de redirection
  • Les alternatives : meta refresh et redirection JavaScript
  • Quel code utiliser selon le cas

Prerequisites


Une URL change. Un site migre vers un nouveau domaine. Une page HTTP doit renvoyer vers HTTPS. Un formulaire soumis en POST doit afficher une page de confirmation. Tous ces cas utilisent des redirections HTTP, et choisir le mauvais code a des consequences reelles.

J'ai vu une migration de domaine ou l'équipe avait mis des 302 partout au lieu de 301. Six mois plus tard, Google indexait toujours l'ancien domaine. Le nouveau site avait zero autorite SEO. Six mois de trafic organique perdus a cause d'un chiffre.

Le mecanisme : Location header

Toute redirection HTTP fonctionne de la meme facon. Le serveur renvoie un code 3xx et un header Location :

HTTP/1.1 301 Moved Permanently
Location: https://new.example.com/page

Le client (navigateur, bot, outil) suit automatiquement la redirection vers la nouvelle URL. Le body de la réponse est généralement vide ou contient un message pour les clients qui ne suivent pas les redirections automatiquement.

La Location peut etre une URL absolue ou relative. La RFC recommande les URLs absolues, mais les URLs relatives fonctionnent dans tous les navigateurs modernes.

301 : Moved Permanently (méthode peut changer)

HTTP/1.1 301 Moved Permanently
Location: https://new.example.com/page

La ressource a définitivement change d'adresse. Les clients et les moteurs de recherche doivent mettre à jour leurs liens. Google transféré le "link juice" (l'autorite SEO) vers la nouvelle URL.

Le piège historique : la spec d'origine disait que le client devait conserver la méthode HTTP. En pratique, la plupart des navigateurs transforment un POST en GET apres un 301. Tu soumets un formulaire en POST, le serveur répond 301, le navigateur suit avec un GET. Les donnees du formulaire disparaissent.

Ce comportement est tellement repandu qu'il est devenu le standard de fait. Mais c'est un bug devenu feature, et ca a cause suffisamment de problèmes pour justifier la création du code 308.

302 : Found (ambigu)

HTTP/1.1 302 Found
Location: /maintenance.html

Redirection temporaire. La ressource est temporairement ailleurs, le client doit continuer a utiliser l'URL originale pour les prochaines requêtes.

Le meme problème que le 301 : les navigateurs transforment souvent POST en GET. Et en plus, le nom a change au fil du temps. Le code s'appelait "Moved Temporarily" en HTTP/1.0, puis "Found" en HTTP/1.1. L'ambiguite sur le changement de méthode n'a jamais ete clarifiee dans la spec originale.

Résultat : 302 est le code de redirection le plus utilise et le plus mal compris. Beaucoup de développeurs l'utilisent pour toutes les redirections, temporaires ou permanentes, sans se soucier des implications.

307 : Temporary Redirect (méthode preservee)

HTTP/1.1 307 Temporary Redirect
Location: /maintenance.html

Meme semantique que 302 (temporaire), mais avec une garantie : la méthode HTTP est preservee. Un POST reste un POST. Un PUT reste un PUT. Pas d'ambiguite.

C'est le bon code quand tu rediriges temporairement un endpoint API. Si ton client POST des donnees vers /api/orders et que tu veux le rediriger vers /api/v2/orders, un 307 garantit que le POST et son body arrivent intacts.

308 : Permanent Redirect (méthode preservee)

HTTP/1.1 308 Permanent Redirect
Location: https://new.example.com/api/orders

Meme semantique que 301 (permanent), mais la méthode est preservee. C'est le pendant permanent du 307.

Le 308 est le code le plus recent du lot (RFC 7538, 2015). Le support navigateur est complet aujourd'hui, mais certains vieux bots ou clients HTTP ne le connaissent pas encore.

Résumé des quatre codes

Code Duree Méthode Cas d'usage
301 Permanent Peut changer (POST -> GET) Migration de domaine, HTTP -> HTTPS
302 Temporaire Peut changer (POST -> GET) Maintenance, A/B testing
307 Temporaire Preservee Redirection temporaire d'API
308 Permanent Preservee Migration permanente d'API

Les chaînes de redirections

Une redirection peut mener a une autre redirection. Et celle-la a une autre. C'est une chaîne.

http://example.com
  -> 301 -> https://example.com
    -> 301 -> https://www.example.com
      -> 301 -> https://www.example.com/fr/
        -> 302 -> https://www.example.com/fr/home

Quatre redirections avant d'atteindre le contenu. Chaque redirection ajoute un aller-retour réseau. Sur mobile avec 150ms de latence, ca fait 600ms de perdu.

Les navigateurs limitent les chaînes a environ 20 redirections. Au-dela, ils affichent une erreur "Too many redirects". Mais le vrai problème arrive bien avant : les moteurs de recherche perdent du "crawl budget" a suivre des chaînes, et le transfert de SEO se dilue a chaque maillon.

La regle : une seule redirection pour atteindre la destination finale. Si http://example.com doit arriver a https://www.example.com/fr/, fais-le en un seul 301, pas en quatre sauts.

Impact SEO

Les moteurs de recherche traitent les redirections differemment :

301 et 308 : Google considéré que l'ancienne URL est remplacee par la nouvelle. L'autorite SEO est transférée. L'ancienne URL disparaît de l'index au profit de la nouvelle.

302 et 307 : Google considéré que l'ancienne URL est toujours la bonne. Il garde l'ancienne dans l'index. L'autorite n'est pas transférée (ou tres partiellement). Si ta redirection "temporaire" dure des mois, Google peut eventuellement la traiter comme permanente, mais c'est a sa discretion.

Pour une migration de site, c'est 301. Toujours. Sans exception.

Meta refresh et redirection JavaScript

En dehors des redirections HTTP, deux autres mecanismes existent.

Meta refresh

html<meta http-equiv="refresh" content="5;url=https://new.example.com">

Le navigateur redirige apres 5 secondes. C'est lent, ca ne transféré pas le SEO proprement, et ca ne fonctionne pas pour les clients non-navigateur. A éviter, sauf pour afficher un message "Vous allez etre redirige..." dans des cas tres spécifiques.

Redirection JavaScript

javascriptwindow.location.href = "https://new.example.com";

Encore pire pour le SEO. Les bots qui n'executent pas JavaScript ne suivent pas cette redirection. Google exécuté le JavaScript, mais avec un delai et sans garantie. Pour un humain ca fonctionne, pour le reste du web c'est invisible.

Sur paltemps.fr, toutes les redirections sont des 301 ou 308 au niveau du serveur. Pas de meta refresh, pas de JavaScript. Le serveur gere, le client suit.

Quand utiliser quel code

Migration de domaine : 301. L'ancien domaine redirige vers le nouveau. Definitivement.

HTTP vers HTTPS : 301. Combine avec HSTS pour ne plus jamais revenir en HTTP.

Reorganisation d'URLs : 301 si les anciennes URLs ne reviendront jamais. 302 si c'est un test.

Apres un POST de formulaire : 303 (See Other). Ce code, que je n'ai pas détaillé plus haut, signifie "va voir cette autre ressource avec un GET". C'est le pattern Post/Redirect/Get qui évité les re-soumissions de formulaire quand l'utilisateur rafraichit la page.

Redirection temporaire d'API : 307. La méthode et le body sont preserves.

Migration permanente d'API : 308. Meme garantie que 307, mais permanent.

A/B testing : 302. Le serveur redirige aleatoirement vers la variante A ou B. C'est temporaire par nature.

Le piège de la boucle infinie

https://example.com -> 301 -> https://www.example.com
https://www.example.com -> 301 -> https://example.com

Le navigateur détecté la boucle et affiche "ERR_TOO_MANY_REDIRECTS". Ca arrive souvent avec des configurations Nginx ou Caddy mal ficelees, ou un CDN qui redirige vers le serveur et le serveur qui redirige vers le CDN.

Pour debugger, curl -v -L montre chaque étape de la chaîne. Le flag -L suit les redirections, -v affiche les headers. Tu vois exactement ou la boucle se forme.


Résumé

  • 301 et 308 sont permanents, 302 et 307 sont temporaires
  • 301 et 302 peuvent changer POST en GET, 307 et 308 preservent la méthode
  • Le header Location contient la destination
  • Les chaînes de redirections gaspillent de la latence et du SEO : vise un seul saut
  • 301 transfère l'autorite SEO, 302 ne le fait pas (ou mal)
  • Meta refresh et redirection JavaScript sont des alternatives inferieures aux codes 3xx
  • Les boucles de redirection se debuggent avec curl -v -L

Article précédent : 13 - CORS

Article suivant : 15 - Les proxies

Sources

Réservez un audit gratuit de 30 minutes. Je vous montre concrètement ce qu'on peut automatiser.