301 vs 302 : redirections, SEO et les erreurs qui collent

Ce qui se passe réellement lors d’une redirection

Quand un navigateur demande une URL et que le serveur répond avec un statut 3xx et un en-tête Location, le navigateur émet silencieusement une seconde requête vers cette nouvelle adresse. Le visiteur ne voit que la destination ; le coût — un aller-retour supplémentaire — et la sémantique reposent sur le code de statut.

301 dit que la ressource a déménagé définitivement : les clients doivent aller à la nouvelle URL maintenant et se souvenir d’ignorer l’ancienne la prochaine fois. 302 dit qu’elle est temporairement ailleurs : allez-y maintenant, mais redemandez l’originale à l’avenir. Tout ce qui compte à propos des redirections — SEO, cache, réversibilité — découle de laquelle de ces deux promesses vous avez faite.

Ce qu’en font les moteurs de recherche

Pour un 301, les moteurs de recherche traitent le déplacement comme un fait éditorial : les signaux accumulés de l’ancienne URL — liens, historique, classement — sont transférés à la nouvelle, et dans les semaines qui suivent, la nouvelle URL remplace l’ancienne dans les résultats. C’est pourquoi les migrations de site, les passages en HTTPS et les renommages de slug se font avec des 301 : la réputation suit le contenu.

Pour un 302, les moteurs font la chose littérale : ils gardent l’ancienne URL indexée, puisque vous leur avez dit que le contenu allait revenir. Un 302 laissé en place pour un déplacement permanent est l’une des erreurs SEO silencieuses classiques — tout fonctionne pour les visiteurs, mais la nouvelle URL ne construit aucun historique pendant que l’ancienne se périme lentement. Si vous en découvrez un, le changer simplement en 301 démarre le transfert ; les moteurs gèrent la correction avec souplesse.

L’erreur miroir existe aussi : un 301 utilisé pour quelque chose de vraiment temporaire (une page de campagne, un test A/B) dit aux moteurs de désindexer l’originale — exactement ce que vous ne vouliez pas.

Ce qu’on apprend à ses dépens : les 301 collent

Les navigateurs sont autorisés à mettre un 301 en cache sans expiration — et plusieurs le font exactement. La première fois que le navigateur d’un visiteur voit la redirection, il peut la mémoriser indéfiniment et ne plus jamais interroger l’ancienne URL. Corrigez le serveur demain : ce visiteur atterrit toujours sur la mauvaise page, parce que la redirection vit désormais dans son navigateur, hors de votre portée. Il n’existe pas de bouton de purge pour les navigateurs des autres.

Deux conséquences pratiques. D’abord, testez un déplacement avec un 302, et ne le promouvez en 301 que lorsque vous êtes sûr — le code temporaire est le code réversible. Ensuite, mettez un Cache-Control explicite sur les redirections, car une durée de vie bornée transforme « bloqué pour toujours » en « bloqué au pire une journée ». Nous suivons cette règle sur ce site : nos redirections canoniques portent Cache-Control: public, max-age=86400, si bien que même une redirection que nous changeons plus tard se corrige d’elle-même en une journée pour chaque visiteur et chaque cache intermédiaire.

Une redirection avec une durée de vie bornée et cachable

$ curl -sI https://cdn.com.tr/en/features/almacenamiento-objetos-s3 | grep -iE 'http|location|cache-control'
HTTP/2 301
location: https://cdn.com.tr/en/features/object-storage
cache-control: max-age=86400, public

Chaînes de redirections : la taxe payée à chaque clic

Les redirections s’accumulent. La règle http→https ajoute un saut, la règle www un autre, le slug renommé un troisième — et voilà chaque visiteur qui paie trois allers-retours avant qu’aucun contenu ne bouge, pendant que les moteurs de recherche diluent un peu de signal à chaque étape intermédiaire et cessent tout à fait de suivre les chaînes très longues.

La solution n’est pas d’éviter les redirections ; c’est de faire pointer chaque ancienne URL directement vers la destination finale. Quand vous renommez une page vers laquelle pointait déjà une redirection, mettez aussi à jour l’ANCIENNE règle, pour que les deux générations d’URL aillent droit à la nouvelle adresse en un seul saut. Un audit occasionnel, c’est une commande par URL, et la forme que vous voulez voir est un unique 301 suivi d’un 200.

Suivez toute la chaîne et comptez les sauts

# -L follows redirects; print each hop's code and target
curl -sIL -o /dev/null -w '%{http_code} %{url_effective}\n' http://example.com/old-page

# see every hop explicitly (one line per response)
curl -sIL http://example.com/old-page | grep -iE '^HTTP|^location'

# healthy: HTTP/1.1 301 -> HTTP/2 200. unhealthy: 301 -> 301 -> 302 -> 200

Les redirections sur un CDN : où elles doivent vivre, et leur mise en cache

Une redirection servie par votre application fonctionne, mais elle coûte un aller complet jusqu’à l’origine pour produire un en-tête qui ne change jamais. Déplacer les redirections bien connues vers la périphérie — ou laisser la périphérie mettre en cache celles que votre application émet — permet d’y répondre près du visiteur.

Les deux moitiés sont disponibles ici. Les règles de diffusion peuvent rediriger directement en périphérie (la redirection vers le site mobile est un réglage à un champ dans le panneau), et depuis une amélioration récente, la périphérie met aussi en cache les 301 et 302 de votre origine avec des durées de vie bornées, si bien que les crawls répétés d’une URL déplacée cessent complètement d’atteindre votre application. Le conseil pratique : donnez à vos redirections un Cache-Control explicite comme à toute autre réponse — court pour les 302, jusqu’à une journée pour les 301 — assez long pour absorber le trafic, assez court pour survivre à vos propres erreurs.

Choisir en cinq secondes

Page renommée, changement de domaine, passage en HTTPS, doublons consolidés : 301, et mettez à jour les anciennes chaînes pour pointer directement vers l’URL finale. Page de campagne, détour de maintenance, test A/B, répartition géographique, tout ce que vous comptez annuler : 302. Pas encore sûr : 302 d’abord — c’est le code réversible — et promotion en 301 une fois le déplacement acté.

Et la méta-règle qui attrape le reste : une redirection est une promesse sur l’avenir d’une URL. Choisissez le code qui correspond à la promesse que vous pouvez réellement tenir.