Codes de statut de redirection 3xx

Comment fonctionne une redirection

Une redirection représente deux requêtes, pas une seule. Le client demande l'URL A, le serveur répond avec un statut 3xx et un en-tête Location nommant l'URL B, puis le client fait une nouvelle requête vers B. Les navigateurs suivent cela automatiquement, donc un visiteur ne voit que la page finale et l'URL finale dans la barre d'adresse. La réponse intermédiaire coûte quand même un aller-retour complet, ce qui explique pourquoi les longues chaînes de redirections sont lentes.

Deux propriétés distinguent les codes 3xx entre eux. La première est la permanence : une redirection permanente dit aux clients et aux crawlers que l'ancienne URL est retirée et que la nouvelle devrait la remplacer dans les signets, les liens et les index, tandis qu'une redirection temporaire dit que l'ancienne URL reste la vraie et qu'elle reviendra. La seconde est la préservation de la méthode. Les anciens codes laissent un client transformer un POST en GET quand il suit la redirection, et les plus récents l'interdisent, donc un POST reste un POST. C'est la différence entre une soumission de formulaire qui arrive intacte à la nouvelle URL et une qui arrive comme un GET vide.

Chaque code 3xx et sa signification

• 300 Multiple Choices. La ressource existe sous plusieurs représentations et le serveur laisse le client choisir. Il n'existe pas de format standard lisible par machine pour la liste, donc presque rien ne l'implémente. En pratique vous ne verrez pas de 300 dans la nature. Voir le guide 300 Multiple Choices pour comprendre pourquoi il ne survit surtout que comme terme de recherche.
• 301 Moved Permanently. La ressource a un nouveau foyer permanent. Les moteurs de recherche transfèrent les signaux de classement vers la cible, et les clients sont autorisés à mettre la redirection en cache, parfois agressivement. C'est le code pour un changement de domaine, un passage de HTTP à HTTPS ou une restructuration d'URL permanente.
• 302 Found. Une redirection temporaire. L'URL d'origine garde son identité, donc les moteurs de recherche continuent normalement d'indexer l'original plutôt que la cible. Historiquement, de nombreux clients basculaient la méthode en GET en suivant un 302, ce qui explique pourquoi le standard déconseille de compter sur la préservation de la méthode ici.
• 303 See Other. « Votre requête a été traitée ; allez maintenant chercher (GET) cette autre ressource. » Le client reçoit l'instruction explicite d'utiliser GET pour le suivi, quelle que soit la méthode d'origine. C'est la bonne réponse pour un POST de formulaire qui doit atterrir sur une page de résultat.
• 304 Not Modified. Ce n'est pas du tout une redirection. Elle répond à une requête conditionnelle et signifie « votre copie en cache est toujours à jour, réutilisez-la ». Il n'y a ni corps ni Location. Voir 304 Not Modified.
• 305 Use Proxy et 306 sont obsolètes. 305 a été déprécié pour des raisons de sécurité et 306 est inutilisé. Ignorez les deux.
• 307 Temporary Redirect. Même signification que 302, mais la méthode et le corps doivent être préservés. Un POST qui suit un 307 arrive à la nouvelle URL comme un POST.
• 308 Permanent Redirect. Même signification que 301, mais la méthode et le corps doivent être préservés.

Ce qui tourne mal avec les redirections

• Un code temporaire sur un déménagement permanent. L'erreur la plus courante et la plus coûteuse. Les moteurs de recherche gardent l'ancienne URL indexée et la nouvelle n'hérite pas de la position de l'ancienne.
• Un code permanent sur un déménagement temporaire. Plus difficile à annuler, car un 301 mis en cache peut continuer d'envoyer les visiteurs qui reviennent au mauvais endroit bien après que vous ayez supprimé la règle.
• Les chaînes de redirections. http vers https, puis non-www vers www, puis ancien chemin vers nouveau chemin représente trois allers-retours avant que le moindre contenu n'arrive. Chaque saut ajoute de la latence et chaque saut est un endroit où la chaîne peut se casser.
• Les boucles de redirection. A envoie vers B et B renvoie vers A, généralement parce qu'une règle au niveau applicatif et une règle au niveau serveur ou CDN sont en désaccord sur la forme canonique. Les navigateurs abandonnent après un nombre fixe de sauts et affichent une erreur.
• Tout pointé vers la page d'accueil. Quand toutes les pages retirées redirigent vers la racine plutôt que vers leur équivalent le plus proche, la redirection est souvent traitée comme un faux 404 et le visiteur se retrouve à chercher.
• Les corps de POST perdus. Une API ou un point de terminaison de formulaire déplacé derrière un 301 ou un 302 peut perdre sa méthode et sa charge utile avec certains clients. Utilisez 307 ou 308 pour tout ce qui n'est pas un simple GET.

Comment auditer et corriger vos redirections

1. Voyez ce qu'une URL renvoie, sans suivre :

   curl -sI https://example.com/old-page | grep -Ei "^(HTTP|location)"

   Cela affiche la ligne de statut et la cible d'un coup.
2. Suivez maintenant toute la chaîne et comptez les sauts :

   curl -sIL -o /dev/null -w "%{num_redirects} hops, final %{http_code}, %{url_effective}\n" https://example.com/old-page

3. Réduisez les chaînes à un seul saut. Faites pointer l'URL d'origine directement vers la destination finale plutôt que de la laisser traverser des règles intermédiaires.
4. Faites correspondre le code à l'intention. Déménagement permanent : 301, ou 308 si le point de terminaison accepte des requêtes non-GET. Déménagement temporaire, page de maintenance ou répartition A/B : 302, ou 307 quand la méthode doit survivre. Flux post-puis-redirection : 303.
5. Corrigez les boucles en décidant de la forme canonique une seule fois (protocole, hôte et barre oblique finale) et en l'imposant à exactement une couche. Les boucles signifient presque toujours que deux couches essaient toutes deux de faire autorité.
6. Retestez avec un cache froid. Un navigateur qui a déjà mis un 301 en cache continuera de lui obéir, donc vérifiez avec curl ou une fenêtre privée avant de conclure que la correction n'a pas fonctionné.

Détecter une redirection cassée avant que le trafic ne chute

Les redirections se cassent sans aucun symptôme visible. Une règle qui se met à boucler, ou un certificat qui échoue sur la cible de la redirection, laisse quand même l'ancienne URL répondre, donc rien ne paraît cassé jusqu'à ce que le trafic et les classements chutent. Une vérification externe qui suit la chaîne et fait une assertion sur le statut final détecte une redirection cassée dès qu'elle apparaît, et vérifier depuis de nombreux réseaux distingue un changement de règle global d'un problème CDN régional. HostTracker exécute des vérifications depuis plus de 300 points de contrôle dans 158 villes et alerte par e-mail, SMS, appel vocal, Slack, Telegram et bien plus. Testez une URL et sa chaîne de redirection avec l'outil de vérification HTTP, et lisez 301 vs 302 avant de choisir un code.