301 vs 302 : redirections permanentes et temporaires

Ce que les deux codes disent à un client

Les deux codes envoient le client vers l'adresse indiquée dans l'en-tête Location, et pour un visiteur, ils paraissent identiques. La différence se situe dans ce que tout le reste fait de cette information. Un 301 invite les clients et les crawlers à mettre à jour leurs enregistrements : remplacer le signet, réécrire le lien, indexer la cible plutôt que la source. Un 302 leur demande de continuer à utiliser l'URL d'origine et de simplement prendre un détour cette fois-ci. Les navigateurs peuvent mettre un 301 en cache et cesser complètement d'interroger le serveur ; un 302 n'est pas mis en cache par défaut sauf si la réponse indique le contraire.

Quand utiliser lequel

• Utilisez 301 pour un changement de domaine, une migration HTTP vers HTTPS, une canonicalisation non-www vers www, une restructuration d'URL permanente, une page fusionnée ou renommée, ou une page produit retirée pointant vers son remplacement le plus proche.
• Utilisez 302 pour une page de maintenance, un test A/B, un choix de page d'atterrissage géographique ou linguistique que vous pouvez changer, une URL de campagne éphémère, ou une destination temporaire « revenez plus tard ».

N'utilisez jamais un 301 pour quelque chose que vous prévoyez d'inverser. Comme les clients le mettent en cache, les visiteurs qui reviennent peuvent continuer à atterrir sur la destination temporaire bien après que vous ayez supprimé la règle, et il n'existe aucun moyen d'accéder à leurs caches. L'erreur inverse : laisser un 302 sur un déménagement permanent, et l'ancienne URL reste indexée, la nouvelle lui fait concurrence, et les signaux restent divisés.

Conséquences SEO

La documentation de Google indique qu'une redirection permanente est un signal que la cible de la redirection devrait être traitée comme l'URL canonique, tandis qu'une redirection temporaire ne l'est pas, donc l'URL d'origine garde sa place dans l'index. En pratique :

• Un 301 consolide le capital de lien sur la cible et, avec le temps, remplace l'ancienne URL par la nouvelle dans l'index.
• Un 302 laisse généralement l'URL source indexée. Les moteurs de recherche essaient d'interpréter l'intention, donc un 302 qui perdure longtemps peut finir par être traité comme permanent, mais vous ne devriez pas compter sur le fait d'être correctement deviné.
• Les chaînes de redirections diluent le bénéfice et ralentissent le crawl. Faites pointer les anciennes URL directement vers la destination finale.
• Rediriger de nombreuses pages retirées vers la page d'accueil a tendance à être traité comme un faux 404 plutôt que comme un déménagement. Redirigez vers la page équivalente la plus proche, ou renvoyez un 410 si rien n'est équivalent.
• Quel que soit votre choix, gardez-le cohérent avec vos balises canoniques et votre sitemap. Des signaux contradictoires sont pires qu'un choix légèrement sous-optimal.

307 et 308 : les versions qui préservent la méthode

Les définitions originales de 301 et 302 étaient ambiguës sur la méthode HTTP, et les clients se sont installés sur un comportement que le standard décrit désormais comme historique : en suivant un 301 ou un 302 après un POST, de nombreux clients changent la méthode en GET et abandonnent le corps. Pour une page, c'est inoffensif. Pour un point de terminaison de formulaire ou une API, cela détruit la requête et ne rapporte rien.

307 Temporary Redirect a la même signification que 302, et 308 Permanent Redirect a la même signification que 301, avec une exigence ajoutée aux deux : la méthode et le corps doivent être préservés. Donc pour les URL qui ne reçoivent que des requêtes GET, 301 et 302 conviennent et sont ce que la plupart des outils attendent. Pour tout ce qui accepte POST, PUT, PATCH ou DELETE, utilisez 308 pour un déménagement permanent et 307 pour un déménagement temporaire. Si vous voulez spécifiquement qu'un POST soit suivi d'un GET sur une autre URL, c'est à cela que sert 303 See Other.

Comment vérifier quel code une URL renvoie

1. Lisez la ligne de statut et la cible sans suivre la redirection :

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

   La ligne de statut montre 301, 302, 307 ou 308, et Location montre vers où elle pointe.
2. Suivez toute la chaîne et comptez les sauts, pour voir si une redirection en est devenue trois :

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

3. Testez avec un POST si le point de terminaison en accepte un. Si la requête arrive à la cible comme un GET sans corps, basculez la règle vers 307 ou 308.
4. Changez le code là où il est généré. Cela peut être l'application, la config du serveur web, une règle .htaccess, ou le CDN. Si deux couches redirigent toutes les deux, la plus extérieure gagne et la règle intérieure est invisible.
5. Vérifiez avec un cache froid. Un navigateur qui a déjà mis en cache un 301 continue de lui obéir, donc confirmez avec curl ou une fenêtre privée avant de conclure que le changement n'a pas pris effet.
6. Après un déménagement permanent, gardez la redirection en place. La supprimer plus tard laisse en rade chaque lien et signet qui pointe encore vers l'ancienne URL.

Surveiller une redirection après l'avoir configurée

Une redirection qui change de code, se met à boucler ou perd son certificat TLS laisse l'URL source continuer à répondre, donc rien ne paraît cassé jusqu'à ce que le trafic chute. Les vérifications externes qui enregistrent le code de statut exact et suivent la chaîne font remonter cela dès l'exécution suivante, et les exécuter depuis de nombreux réseaux distingue un changement de règle global d'un problème CDN régional. HostTracker surveille des sites web depuis 2004 et exécute des vérifications depuis plus de 300 points de contrôle dans 158 villes. Voyez ce qu'une URL renvoie en ce moment avec l'outil de vérification HTTP, et lisez le guide complet de la famille de redirection 3xx pour les codes de part et d'autre de ces deux-là.