Redirections 301 et 302 : laquelle choisir et ce que voit le SEO

Ce qu'est réellement une redirection

Une redirection n'est pas une page. C'est une réponse sans corps utile : un code de statut dans la plage 3xx et un en-tête Location indiquant où aller à la place. Le client lit l'en-tête et effectue une seconde requête vers la nouvelle URL.

Cette forme compte, car elle implique que toute redirection coûte un aller-retour complet, et parce que le code de statut est la seule chose qui indique si le déplacement est définitif. L'en-tête Location dit où ; le code de statut dit ce que cela signifie. Trompez-vous sur le second et l'URL continuera de fonctionner pour les visiteurs tout en faisant discrètement le mauvais travail sur votre référencement et sur chaque navigateur qui l'a vue.

Il existe cinq codes de redirection en pratique, mais toute la décision tient à une question : ce déplacement est-il définitif ou non ?

301 et 302 : la vraie différence

Une 301 Moved Permanently dit : cette URL a disparu pour de bon, utilisez la nouvelle désormais, et mettez à jour tout ce que vous avez enregistré. Une 302 Found dit : servez cette autre URL pour le moment, mais continuez à demander l'originale, car elle va revenir.

Trois conséquences en découlent, et elles constituent toute la différence pratique :

• Les moteurs consolident sur une 301. L'ancienne URL sort de l'index, la nouvelle prend sa place, et les signaux de classement accumulés par l'ancienne passent à la nouvelle. Avec une 302, le moteur garde l'URL originale dans l'index, puisque vous lui avez dit que l'originale est la vraie.
• Les navigateurs mettent une 301 en cache, souvent agressivement. Un navigateur qui a vu une 301 peut ne même plus interroger votre serveur : il va droit à la cible. Une 302 n'est pas mise en cache par défaut, donc le navigateur redemande chaque fois.
• Une 301 est difficile à reprendre. À cause de ce cache, une 301 que vous regrettez continue de rediriger les visiteurs qui reviennent longtemps après que vous l'avez retirée de votre configuration. C'est l'erreur la plus coûteuse de tout le sujet.

La règle n'est donc pas « la 301 est meilleure pour le SEO », même si on le lit partout. La règle est : une 301 vaut mieux quand le déplacement est réellement définitif, et elle est réellement nuisible quand il ne l'est pas.

Ce que voit réellement le SEO

Les moteurs actuels sont plus indulgents que ne le laisse croire le folklore, ce qui a produit des mythes tenaces qu'il vaut la peine de dissiper.

• « Une 301 perd 15 % du jus de lien. » Cela venait d'un facteur de décroissance appliqué il y a des années. Google a indiqué ne plus appliquer de dilution du PageRank aux redirections. Une 301 correctement mise en place transmet les signaux.
• « Une 302 ne transmet rien. » Pas tout à fait. Google finit par traiter comme définitive une 302 en place depuis longtemps, car le comportement contredit la déclaration. Mais ce « finit par » pèse lourd : vous passez des semaines ou des mois avec la mauvaise URL indexée, et le calendrier ne vous appartient pas.
• « Les redirections nuisent toujours au classement. » Une seule redirection propre vers une page étroitement liée est une routine et ne coûte en général rien de mesurable. Ce qui nuit, c'est de rediriger vers quelque chose d'hors sujet : faire pointer cent fiches produit retirées vers votre page d'accueil se lit comme un 404 silencieux, et les signaux de ces pages ne vont nulle part.

Les vrais risques sont plus ternes que les mythes : chaînes, boucles, signaux contradictoires et URL redirigées encore présentes dans votre sitemap. Voir plus bas.

Laquelle utiliser, selon la situation

Presque tous les cas entrent dans l'une de ces catégories.

Utilisez une 301

Vous avez changé un slug ou restructuré vos chemins. Vous avez déménagé vers un nouveau domaine. Vous avez choisi un nom d'hôte canonique et l'autre doit le suivre : www vers l'apex ou l'inverse. Vous forcez HTTPS. Vous avez fusionné deux pages. Vous avez retiré une fiche produit au profit de la catégorie qui l'a remplacée. Dans tous ces cas l'ancienne URL ne reviendra jamais, ce qui est exactement ce que déclare une 301.

Utilisez une 302

Maintenance ou page d'attente pendant que la vraie page est indisponible. Test A/B entre deux versions d'une page. Routage géographique ou linguistique où l'URL d'origine doit rester canonique. Une page promotionnelle temporaire à la place de l'habituelle. Une redirection de connexion qui renvoie ensuite l'utilisateur. Ici vous voulez que l'URL d'origine reste indexée, et une 301 la retirerait.

Quand la 307 et la 308 comptent

307 Temporary Redirect et 308 Permanent Redirect sont les versions strictes de la 302 et de la 301. La différence porte sur la méthode HTTP : avec 301 et 302, les clients transformaient historiquement un POST en GET en suivant la redirection, et ce comportement est désormais entériné. La 307 et la 308 doivent préserver la méthode et le corps.

Pour des déplacements de pages ordinaires, 301 et 302 sont ce qu'attendent les moteurs et ce qu'il faut utiliser. Pour les API et les envois de formulaires, utilisez 307 ou 308 : un POST redirigé qui devient silencieusement un GET perd le corps de la requête, et le bug qui en résulte est exaspérant à retrouver.

La 303 et la seule chose qu'elle sert

303 See Other transforme volontairement la requête suivante en GET. Son usage propre est le motif « poster puis rediriger » : accepter un POST de formulaire, puis renvoyer une 303 vers une page de résultats afin qu'un rafraîchissement ne renvoie pas le formulaire. Ce n'est pas une redirection à tout faire et elle n'a pas sa place dans les déplacements de pages.

Meta refresh et redirections JavaScript

Il existe deux façons non HTTP de déplacer un visiteur, et toutes deux sont pires qu'elles n'en ont l'air.

Un meta refresh (<meta http-equiv="refresh">) est traité par le navigateur après le téléchargement de la page. Les moteurs le suivent et traitent généralement un refresh sans délai comme une redirection permanente, mais c'est lent, invisible pour tout ce qui ne rend pas le HTML, cela casse le bouton retour, et avec un délai c'est un véritable problème d'accessibilité. À n'utiliser que si vous n'avez aucun accès à la configuration du serveur.

Une redirection JavaScript est encore pire. Elle exige que la page se charge et que le script s'exécute, rien qui n'exécute JavaScript ne la suivra, et elle gâche toute la première requête. Ce sont des contournements, pas des outils. Si vous pouvez poser un code de statut, posez un code de statut.

Chaînes et boucles : par où fuit le trafic

C'est la partie qui coûte vraiment de l'argent, et c'est presque toujours accidentel.

Une chaîne est une redirection vers une redirection. Elle s'accumule sur des années, une règle à la fois : http://example.com → https://example.com → https://www.example.com → https://www.example.com/nouvelle-page. Chaque saut est un aller-retour complet, donc une chaîne de quatre sauts sur une connexion mobile se remarque, et les robots abandonnent les longues chaînes : Google suit un nombre limité de sauts puis s'arrête tout simplement. Supprimez les chaînes en faisant pointer la première URL directement vers la destination finale.

Une boucle renvoie le client à son point de départ et la page ne se charge jamais. La cause classique, ce sont deux règles qui se contredisent : l'une force www, l'autre force l'apex, chacune défaisant l'autre. Les navigateurs affichent ERR_TOO_MANY_REDIRECTS après une vingtaine de sauts. Si vous voyez cela, vous avez deux règles qui se battent, pas une règle cassée.

Deux autres fuites à vérifier :

• Des URL redirigées laissées dans le sitemap. Un sitemap ne doit lister que des destinations finales. Y lister une URL qui redirige dit au robot de dépenser son budget sur un saut.
• Une balise canonique qui contredit la redirection. Si la page d'arrivée déclare une canonique pointant vers l'ancienne, vous avez donné deux instructions contradictoires et le moteur choisit pour vous.

Comment vérifier ce qu'une URL renvoie vraiment

On ne distingue pas une 301 d'une 302 en regardant la barre d'adresse : les deux aboutissent au même endroit. Il faut lire la réponse.

Vérifiez ces trois points :

• Le code de statut de la première réponse, pas de la dernière. Le panneau réseau du navigateur montre toute la séquence ; la première ligne est celle qui déclare le caractère définitif.
• La séquence complète des sauts. Comptez les redirections entre l'URL saisie et la page qui s'affiche. Au-delà d'un, cela mérite un coup d'œil ; au-delà de deux, c'est une chaîne à supprimer.
• Si la chaîne mélange les codes. Une 301 suivie d'une 302 est un motif courant et déroutant qui dit « déplacé définitivement vers un endroit temporaire ».

Un vérificateur de codes de statut HTTP affiche le statut de chaque saut et l'en-tête Location à chaque étape, soit exactement la vue qu'il vous faut. Pour les règles HTTPS et de nom d'hôte, confirmez que le certificat couvre l'hôte vers lequel vous redirigez avec le vérificateur de certificat SSL : une redirection vers un hôte que le certificat ne couvre pas donne une page d'avertissement au lieu d'un site qui fonctionne.

Erreurs fréquentes

• Utiliser une 301 pour quelque chose de temporaire. Les navigateurs la mettent en cache, donc les visiteurs qui reviennent continuent d'être redirigés après le retrait de la règle. Vider cela n'est pas en votre pouvoir.
• Utiliser une 302 pour un déplacement définitif et se demander pourquoi l'ancienne URL est toujours celle qui se classe. Vous avez dit au moteur que l'ancienne est la canonique.
• Rediriger tout ce qui est retiré vers la page d'accueil. Google traite une destination hors sujet comme un 404 silencieux. Redirigez vers la page équivalente la plus proche, ou renvoyez un 410 propre s'il n'y a pas d'équivalent.
• Laisser les chaînes s'accumuler. Chaque nouvelle règle s'empile sur la précédente au lieu de la remplacer.
• Deux règles de nom d'hôte qui se battent, d'où une boucle. Choisissez un seul hôte canonique et écrivez exactement une règle pour lui.
• Rediriger un POST avec une 301 ou une 302. La méthode devient un GET et le corps est perdu. Utilisez 307 ou 308 pour tout ce qui n'est pas une simple consultation de page.
• Laisser des URL redirigées dans le sitemap, ou garder des liens internes vers l'ancienne URL. Mettez à jour vos propres liens ; une redirection est faite pour les liens des autres.

En bref

Une 301 signifie définitif : les moteurs déplacent les signaux de classement vers la nouvelle URL et les navigateurs la mettent fortement en cache. Utilisez-la pour les changements de slug, les déménagements de domaine, HTTPS et la canonicalisation du nom d'hôte — et jamais pour quelque chose que vous pourriez annuler. Une 302 signifie temporaire : l'URL d'origine reste indexée, ce qui convient exactement aux pages de maintenance, aux tests A/B et aux redirections de connexion. Utilisez 307 ou 308 quand un POST doit survivre à la redirection, limitez les chaînes à un seul saut, et assurez-vous qu'aucune règle ne renvoie à son propre point de départ. Vérifiez ce qu'une URL renvoie vraiment, saut par saut, avec le vérificateur gratuit de codes de statut HTTP, et si vous redirigez vers un nouvel hôte, confirmez d'abord son certificat avec le vérificateur de certificat SSL. Pour un tour d'horizon de ce que signifie chaque classe de réponse, le guide complet des codes de statut HTTP couvre le reste.

Outils et guides associés :

• Recherche de codes de statut HTTP : Une référence rapide pour chaque code de statut HTTP et sa signification.
• Vérificateur d'en-têtes de sécurité : Vérifiez HSTS, CSP, X-Frame-Options et d'autres en-têtes de sécurité essentiels.
• 404 ou 410 : ce que chacun dit à Google d’une page supprimée : Ce qu’un 404 et un 410 disent à un robot

Questions fréquentes