Il existe plus de types de redirections URL que le débat 301 contre 302 ne le laisse entendre, et choisir le mauvais peut vous coûter discrètement en vitesse ou en positionnement. Ils se répartissent en deux familles. Les redirections HTTP côté serveur sont des codes de statut renvoyés par le serveur avant le chargement de la page - 301, 302, 303, 307, 308. Les redirections côté client se produisent dans le navigateur après le chargement de la page - une balise meta refresh ou un saut via JavaScript. Le côté serveur est plus rapide et plus propre pour les utilisateurs et les robots d'exploration ; le côté client est plus lent et moins fiable, et on y recourt uniquement quand le serveur est hors de portée.
Je travaille sur le chemin de redirection, donc je vais rester concret : ce que chaque type fait sur le réseau, comment les moteurs de recherche le lisent, et lequel utiliser réellement. Si vous voulez approfondir les deux que vous utiliserez le plus, redirections 301 vs 302 couvre cette paire en détail ; cet article est la carte complète.
En résumé : pour un déplacement permanent, utilisez un 301 ; pour un déplacement temporaire, utilisez un 302 ; ajoutez les variantes préservant la méthode 308/307 quand un POST doit survivre ; et évitez les options côté client sauf si vous n'avez aucun serveur à configurer.
Les deux familles de redirections#
Une redirection est simplement une instruction d'aller ailleurs, mais l'endroit où se trouve cette instruction change tout dans son comportement.
Une redirection côté serveur, c'est le serveur qui répond "pas ici, allez là-bas" avant qu'aucun contenu de page ne soit envoyé. Le navigateur reçoit un code de statut et un en-tête Location et se déplace immédiatement - aucun contenu ne se charge à l'URL d'origine, donc c'est rapide et sans ambiguïté. Une redirection côté client est l'inverse : la page d'origine se charge complètement, puis seulement une balise meta ou un script envoie le visiteur ailleurs. Cela implique un chargement de page gâché, un scintillement visible, et un signal plus faible pour les moteurs de recherche, qui doivent charger et parfois exécuter la page pour même détecter la redirection. Les définitions formelles des codes côté serveur se trouvent dans la RFC 9110, et le comportement pratique des navigateurs est documenté dans le guide MDN sur les redirections HTTP.
Cette distinction unique - avant la page ou après elle - explique pourquoi le reste de cet article revient constamment à "utilisez une redirection côté serveur quand vous le pouvez."
Les redirections par code de statut HTTP#
Ce sont les vraies redirections, renvoyées par le serveur dans la plage 3xx. Cinq sont importantes.
| Code | Signification | Permanente ? | Méthode préservée ? | Utilisation typique |
|---|---|---|---|---|
| 301 | Déplacé définitivement | Oui | Non garantie | Déplacement définitif, migration de site, passage en HTTPS |
| 302 | Trouvé | Non | Non garantie | Déplacement temporaire, liens modifiables, tests A/B |
| 303 | Voir ailleurs | Non | Force un GET | Redirection après formulaire vers une page de résultat |
| 307 | Redirection temporaire | Non | Oui | Déplacement temporaire sur un point d'accès POST ou API |
| 308 | Redirection permanente | Oui | Oui | Déplacement permanent où la méthode doit être préservée |
Les deux axes qui organisent le tableau sont la permanence et la gestion de la méthode. La permanence est l'axe SEO : un 301 et un 308 sont permanents, donc les moteurs de recherche transmettent les signaux de positionnement et traitent la cible comme canonique, tandis que 302, 303 et 307 sont temporaires et conservent l'URL d'origine indexée. La gestion de la méthode est l'axe technique : 307 et 308 préservent strictement la méthode HTTP, donc un POST reste un POST, tandis que 301 et 302 permettaient historiquement qu'elle dérive vers un GET. Le 303 est le cas particulier, conçu spécifiquement pour forcer un GET après la soumission d'un formulaire, afin qu'un rechargement ne soumette pas à nouveau les données. La propre documentation sur les redirections de Google confirme qu'il traite les codes permanents comme des signaux de canonicalisation.
Pour les liens web ordinaires, qui sont des requêtes GET, l'axe de la méthode disparaît et vous choisissez vraiment entre permanent et temporaire - ce qui correspond exactement à la décision 301 vs 302.
Redirections côté client : meta refresh et JavaScript#
Quand vous ne pouvez pas configurer le serveur, deux options au niveau du navigateur restent disponibles, et toutes deux sont des compromis.
Une meta refresh est une balise HTML dans l'en-tête de la page qui demande au navigateur de charger une nouvelle URL après un délai - le schéma "vous serez redirigé dans 5 secondes". Ça fonctionne, mais la page a déjà été chargée avant que ça ne se déclenche, donc c'est lent, et les moteurs de recherche l'interprètent de façon inconsistante : une meta refresh instantanée est généralement traitée comme une redirection permanente, tandis qu'une meta refresh différée est ambiguë et peut être lue comme un soft 404. Une redirection JavaScript est encore moins fiable, car elle ne se produit que si le robot d'exploration exécute le script. Google rend le JavaScript, mais avec un délai, et de nombreux autres robots ne l'exécutent pas du tout, de sorte que la redirection peut être complètement manquée.
Le classement honnête des options est simple : un 3xx côté serveur en premier, une meta refresh uniquement si vous contrôlez le HTML mais pas le serveur, et une redirection JavaScript en dernier recours quand vous ne contrôlez rien d'autre. Rien de tout cela ne s'applique à un lien court géré, qui utilise toujours une redirection côté serveur - les techniques côté client sont pour des situations comme un hébergeur statique sans configuration de redirection.
Quelle redirection utiliser#
Ramenez-le à une décision que vous pouvez prendre en un seul passage.
- Déplacement permanent, lien ordinaire :
301. Transfert complet du positionnement, traité comme canonique. - Déplacement temporaire, lien ordinaire :
302. Conserve l'original indexé et le lien modifiable. - Le déplacement implique un POST ou un appel API : utilisez
308pour permanent ou307pour temporaire, afin que la méthode survive. - Après une soumission de formulaire :
303, pour qu'un rechargement de page ne soumette pas à nouveau le formulaire.
La méta-règle derrière ces quatre cas : faites correspondre le code de statut à la réalité du déplacement - est-il permanent, et la méthode est-elle importante. Se tromper dans cet appariement, c'est comment les redirections font fuir discrètement le positionnement ou cassent un formulaire.
Ce qu'utilisent les liens courts#
Un lien court géré est une redirection côté serveur, et pour une bonne raison - c'est la famille rapide et favorable aux robots. Le choix intéressant est le code, et la réponse pour la plupart des liens courts est un 302.
Cela semble contre-intuitif pour le SEO jusqu'à ce que vous vous souveniez à quoi sert un lien court. Un 302 garde le lien modifiable, pour que vous puissiez le faire pointer ailleurs après qu'il a été imprimé ou partagé, et il fait que chaque clic atteint le serveur, pour que vos analytiques restent précises - deux choses qu'un 301 mis en cache de façon permanente vous coûterait. Le raisonnement complet, y compris le piège du cache du navigateur, se trouve dans redirections 301 vs 302, et les mécanismes de résolution de la redirection au niveau de l'edge sont expliqués dans comment fonctionnent les raccourcisseurs d'URL. La règle qui s'applique quel que soit le code : limitez-vous à un seul saut. Une redirection qui pointe vers une autre redirection gaspille le budget d'exploration et la latence, et c'est le moyen le plus rapide d'annuler le SEO que les liens courts préservent par ailleurs.
La carte complète tient en une phrase : codes côté serveur pour les vraies redirections, permanent versus temporaire pour le SEO, variantes préservant la méthode pour les requêtes non-GET, et techniques côté client uniquement quand le serveur est inaccessible. Choisissez selon la réalité du déplacement, limitez la chaîne à un seul saut, et vos redirections font ce que vous aviez prévu.
Sur le blog#
- Redirections 301 vs 302 : laquelle les liens courts doivent-ils utiliser
- Les raccourcisseurs d'URL nuisent-ils au SEO ? La réponse honnête
- Comment fonctionnent les raccourcisseurs d'URL en coulisses
- Atteindre p95 sous 15ms pour les redirections depuis FRA, ASH et SGP
- Stratégie de cache pour les redirections URL : L1 LRU + L2 Redis
Essayer Elido
Collez une URL, obtenez un lien court
Sans inscription. Lien actif 30 jours. Inscrivez-vous pour le garder pour toujours.
Gratuit, sans inscription · 2 par jour