301 ou 308 : quelle redirection choisir ?

Les 301 et 308 sont toutes deux des redirections permanentes : la différence essentielle est que la 308 garantit la conservation de la méthode HTTP (et du corps qui l’accompagne) pendant le saut. Pourquoi la 308 existe, pourquoi Google et Bing la traitent comme une 301, et quand l’utiliser réellement.

Première publication : 2 juil. 2026 · Dernière mise à jour : 9 août 2026 · Advanced
Langues
1 indice probant sur cette page

Les 301 et 308 sont toutes deux des redirections permanentes, et Google comme Bing traitent une 308 de la même façon qu’une 301 pour l’exploration, l’indexation et la consolidation des signaux. La documentation de Google qualifie la 308 d’*"equivalent to 301"* _(traduction)_ : « équivalente à 301 », Gary Illyes dit *"we just merge that with 301"* _(traduction)_ : « nous la fusionnons simplement avec 301 », et Fabrice Canel confirme que Bing traite les deux de la même façon. Au niveau du protocole, la différence essentielle est mécanique : une 308 garantit que le client répète la même méthode de requête (un POST reste un POST et le corps suit) vers la nouvelle URL, tandis qu’une 301 — un code de l’ère HTTP/1.0 — est ambiguë spécifiquement sur la conversion de POST en GET (la RFC ne tranche pas pour PUT/DELETE). Pour un déplacement de page ou de site ordinaire, la 301 reste le choix pragmatique (plus ancienne, mieux reconnue, mieux prise en charge par les outils, les CDN et les plugins). Choisissez une 308 uniquement lorsque vous devez préserver une méthode autre que GET : points de terminaison d’API, URL de webhook, cibles de formulaires ou flux POST d’authentification ; même dans ce cas, le code d’état ne garantit pas à lui seul la conservation des identifiants, des cookies ou de l’idempotence : testez le véritable client. Aucun des deux codes n’offre d’avantage SEO ; quiconque vous conseille de convertir massivement vos 301 en 308 pour gagner des positions vend un mythe explicitement démenti par les moteurs de recherche.

TL;DR — Les 301 et 308 sont toutes deux des redirections permanentes, et Google comme Bing traitent une 308 de la même façon qu’une 301 — la documentation de Google dit qu’elle est “equivalent to 301,” (traduction) : « équivalente à 301 », Illyes dit “we just merge that with 301,” (traduction) : « nous la fusionnons simplement avec 301 », et Canel confirme que Bing les traite de la même façon. Au niveau du protocole, la différence essentielle est la préservation de la méthode : une 308 (RFC 7538, 2015) garantit mécaniquement que le client répète la même méthode vers la nouvelle URL (le corps suit), tandis qu’une 301 date de l’ère HTTP/1.0 et reste ambiguë spécifiquement sur POST converti en GET — la RFC ne traite pas PUT ou DELETE, dans un sens ou dans l’autre ; ne généralisez donc pas la réserve sur POST. La 308 existe comme sœur permanente de la 307 — la RFC 7231 définissait un code temporaire qui préserve la méthode (307), mais aucun code permanent, et la 308 a comblé ce manque. Par défaut, utilisez 301 pour les migrations ordinaires de pages, de sites ou vers HTTPS (code plus ancien, mieux reconnu, mieux pris en charge par les CDN, CMS et plugins). Choisissez 308 seulement lorsque vous devez préserver une requête autre que GET — API, webhooks, cibles de formulaires, flux POST d’authentification — et vérifiez alors les identifiants, cookies et l’idempotence avec le client réel au lieu de supposer que le code d’état couvre tout. Aucune n’est « meilleure pour le SEO » : les moteurs ont explicitement démenti ce mythe.

La différence sémantique d’abord

Les 301 et 308 indiquent la même chose aux moteurs de recherche au sujet de la permanence : la ressource a définitivement changé d’adresse et la destination devrait devenir canonique. Leur différence tient à une seule garantie mécanique et étroite : la façon dont le client réémet la requête.

  • 301 (Moved Permanently) (traduction) : « déplacée définitivement » est le code de redirection permanente original, qui remonte à l’ère HTTP/1.0. Surtout, il a toujours été ambigu quant à la conservation de la méthode de requête. En pratique, les navigateurs et autres clients ont historiquement converti un POST en GET lors du suivi d’une 301 — ce qui convient à une page classique, mais casse silencieusement tout ce qui dépend de la méthode ou du corps de la requête.
  • 308 (Permanent Redirect) (traduction) : « redirection permanente » est la version stricte. Elle garantit que le client répète exactement la même méthode et le même corps vers la nouvelle URL. Un POST reste un POST ; la charge utile suit.

La formulation en une phrase serait : une 308 est une 301 qui garantit en plus que le navigateur ne remplacera pas discrètement votre POST par un GET. Evidence for this claim RFC 9110 defines both 301 and 308 as permanent redirects; 308 forbids changing the request method, while 301 permits POST-to-GET rewriting for historical reasons. Scope: HTTP semantics for 301 and 308 responses. Confidence: high · Verified: IETF: RFC 9110 §§15.4.2, 15.4.9 IETF: RFC 7538 §3 — 308 Permanent Redirect

Pourquoi la 308 existe-t-elle : le « 307 permanent » manquant ?

C’est le point que presque personne n’explique, et la manière la plus claire de comprendre toute la comparaison. Il s’agit d’un trou dans la spécification.

Les codes de redirection modernes forment une grille temporaire/permanente et souple/stricte :

TemporaryPermanent
Method may change (loose)302301
Method preserved (strict)307308

La RFC 7231 définissait la 307 — une redirection temporaire qui préserve la méthode — comme la contrepartie stricte de la 302, souple et ambiguë. Mais elle ne définissait aucun équivalent permanent qui préserve la méthode. Il existait un code temporaire strict, mais pas de code permanent strict. La RFC 7538 (avril 2015) a ajouté la 308 précisément pour combler ce manque : elle est à la 301 ce que la 307 est à la 302. Si vous avez lu la comparaison 302-vs-307 de ce groupe, 301-vs-308 est exactement la même relation, une ligne plus haut : permanente-souple contre permanente-stricte.

La 301 est antérieure à toute cette grille. Elle vient de HTTP/1.0, avant que le concept de « conservation de la méthode » soit formalisé ; c’est précisément pourquoi elle est ambiguë et pourquoi il a fallu inventer la 308 plutôt que simplement clarifier la 301.

Ce que signifie « méthode et corps préservés » en pratique

Pour l’immense majorité des redirections — quelqu’un clique sur un lien, son navigateur émet un GET et le serveur l’envoie ailleurs — il n’y a pas de différence pratique. Les navigateurs modernes conservent très bien GET avec une 301. La distinction n’apparaît que lorsque la requête n’est pas un GET classique :

Type de requêteAvec une 301Avec une 308
GET (page classique)Suivie en GET (en pratique, aucun problème)Suivie en GET
POST (formulaire, API)Peut être convertie silencieusement en GET, corps perduRépétée en POST, corps conservé
PUT / DELETE (API)Non documenté par la RFC — l’autorisation historique concerne uniquement POST→GET ; comportement propre au client et non vérifiéMéthode conservée (la règle de suivi automatique de la 308 ne vise pas seulement POST)

Le risque d’une 301 concerne donc précisément POST et les corps de requête — formulaires, API, webhooks et flux d’authentification. Dire qu’une « 301 cassera toujours mon formulaire » serait exagéré : un GET classique est sûr. La dérogation historique de la spécification pour la 301 concerne précisément POST→GET ; elle ne documente pas le comportement de PUT ou DELETE. Ne supposez donc pas comment l’un ou l’autre code traitera ces méthodes sans tester le client réel. Ce que la spécification affirme clairement, c’est que la 308 interdit au client de changer la méthode qu’il répète — cette règle ne se limite pas à POST. La préservation de la méthode est la garantie fournie ; elle ne promet pas séparément que les en-têtes, cookies, identifiants ou toute la transaction resteront inchangés. Pour tout ce qui compte, testez-les avec le client et l’intégration concernés (voir la liste de contrôle ci-dessous).

Google traite-t-il différemment les 301 et 308 pour le SEO ? Non.

C’est l’une des rares questions sur les redirections où la documentation, les Googlers et Bing sont tous d’accord — et le sont depuis des années.

La documentation de Google sur les codes d’état HTTP place les 301 et 308 dans la même catégorie. La ligne consacrée à la 301 dit : “Google follows the redirect, and Google systems use the redirect as a strong signal that the redirect target should be processed.” (traduction) : « Google suit la redirection, et les systèmes de Google utilisent la redirection comme un signal fort indiquant que la cible doit être traitée. » La ligne consacrée à la 308 tient en une phrase : “Equivalent to 301.” (traduction) : « Équivalente à 301. » C’est la formulation la plus forte et la plus facile à citer — la propre documentation de Google assimile littéralement les deux codes. Evidence for this claim Google treats 308 as equivalent to 301 for Search while advising sites to use the semantically appropriate status code. Scope: Google Search processing; client behavior still differs when method preservation matters. Confidence: high · Verified: Google: HTTP status codes and Search

Le guide sur les redirections le confirme en commençant par “The 301 and 308 status codes mean that a page has permanently moved to a new location” (traduction) : « Les codes d’état 301 et 308 signifient qu’une page a été déplacée définitivement vers un nouvel emplacement », puis ne fait plus aucune distinction entre eux.

Les Googlers disaient déjà la même chose de manière informelle, avant que ce soit écrit dans la documentation :

  • Gary Illyes (2021) : dans un fil consacré à la question de savoir si Google traite une 308 comme une 301, il a écrit que Google “just merge[s] that with 301 so we really don’t care.” (traduction) : « fusionne simplement celle-ci avec 301, donc cela nous importe vraiment peu. » L’article de Barry Schwartz présente cette déclaration comme le moment où le point est devenu officiel : “Three years later it was added to the official Google documents that Google treats 308 redirects like 301 redirects — so now it is official.” (traduction) : « Trois ans plus tard, cela a été ajouté aux documents officiels de Google : Google traite les redirections 308 comme les 301 — c’est donc désormais officiel. »
  • John Mueller (2018) : trois ans auparavant, il disait : “If you use it [a 308 redirect] like a 301 we’ll treat it as such.” (traduction) : « Si vous l’utilisez [une redirection 308] comme une 301, nous la traiterons comme telle. » La position informelle de Google remonte donc à bien avant la documentation.

Il y a toutefois une nuance importante dans la documentation de Google, et elle constitue la thèse de cet article. Juste après avoir assimilé les codes, Google ajoute : “While Google treats these status codes the same way, keep in mind that they’re semantically different. Use the status code that’s appropriate for the redirect so other clients (for example, e-readers, other search engines) may benefit from it.” (traduction) : « Même si Google traite ces codes d’état de la même façon, leur sens reste différent. Choisissez le statut techniquement adapté afin que les autres clients — notamment les liseuses et les autres moteurs de recherche — puissent en tirer parti. » Autrement dit : choisissez le code pour la justesse technique et l’interopérabilité, pas pour le SEO, puisque le SEO s’en moque.

Bing traite-t-il différemment les 301 et 308 ? Non plus.

La plupart des articles sur le sujet ne parlent que de Google, ce qui laisse un angle mort. En septembre 2024, Fabrice Canel, de Bing, a répondu directement à la question d’une personne qui demandait si Bing traitait une 308 permanente comme une 301 : “Bing treats 308 redirects the same as 301 redirects.” (traduction) : « Bing traite les redirections 308 comme les redirections 301. » Schwartz a souligné que cela correspondait à ce que Google avait déclaré en 2021.

Les deux grands moteurs l’ont donc confirmé : pour l’exploration, l’indexation et la consolidation des signaux, la 308 est fonctionnellement identique à la 301. Aucun moteur ne traite la 308 comme supérieure pour le SEO.

Le mythe à corriger : « la 308 est meilleure pour le SEO / remplacez toutes vos 301 »

Soyons directs, car des pages de moindre qualité continuent de le laisser entendre. Choisir une 308 plutôt qu’une 301 n’apporte aucun avantage SEO pour une redirection ordinaire, et il n’y a aucune raison de convertir massivement vos 301 existantes en 308. Ce n’est pas mon opinion : c’est la position déclarée des moteurs de recherche :

  • La documentation de Google dit que la 308 est “equivalent to 301.” (traduction) : « équivalente à 301. »
  • Illyes : “we just merge that with 301.” (traduction) : « nous la fusionnons simplement avec 301. »
  • Canel : Bing “treats 308 redirects the same as 301 redirects.” (traduction) : « traite les redirections 308 comme les redirections 301. »

Remplacer en masse 301→308 ne vous apporte aucun gain de classement et ajoute un risque avec les anciens outils ou les outils périphériques qui ne reconnaissent proprement que 301/302 (nous y reviendrons). C’est du changement pour le changement.

Il faut distinguer ce mythe d’une affirmation réellement contestée : l’ancienne idée selon laquelle “301s lose/dilute PageRank” (traduction) : « les 301 font perdre ou diluent le PageRank ». Celle-ci réapparaît encore et a été démentie à plusieurs reprises par Google. Mais la différence est importante : le mythe de la dilution du PageRank est une correction d’une idée fausse par Google, tandis que l’équivalence 301-vs-308 est affirmée de façon cohérente par Google, Bing et la documentation depuis 2018. La question est réglée, elle n’est pas controversée. (Le récit complet du PageRank se trouve dans la comparaison 301-vs-302 de ce groupe.)

Quand la 308 est-elle le choix techniquement correct ?

Choisissez une 308 lorsque perdre la méthode ou le corps de la requête casserait la fonctionnalité, et non le classement :

  • Points de terminaison d’API que vous déplacez et auxquels les clients envoient POST/PUT/DELETE.
  • URL de webhook — l’émetteur envoie un POST dont vous ne pouvez pas vous permettre de perdre la charge utile.
  • Cibles d’action de formulaire — le <form> envoie des données qui doivent parvenir intactes à la nouvelle URL.
  • Flux POST d’authentification ou de connexion où des identifiants ou des jetons se trouvent dans le corps.

Pour POST précisément, une 301 risque de convertir la requête en GET et de laisser son corps sans destination ; une 308 interdit cette conversion. Pour PUT/DELETE, la RFC ne décrit pas le comportement de la 301 dans un sens ou dans l’autre : ne supposez rien — la règle de préservation de la méthode de la 308 s’applique quelle que soit la méthode.

Avant de basculer une API, un webhook ou un flux d’authentification, rappelez-vous que le code d’état seul ne garantit pas la survie de tous les éléments du saut. Vérifiez aussi :

  • Identifiants, cookies et en-têtes d’authentification. Aucun des deux codes ne promet quoi que ce soit ici ; testez le client réel (navigateur, SDK ou émetteur du webhook) au lieu de supposer que tout suivra.
  • Comportement interorigines. Une redirection qui change d’origine peut modifier ce qu’un navigateur ou un client fetch envoie ; vérifiez avec l’appelant réel, pas seulement avec un curl manuel.
  • Idempotence et effets de bord en double. Si la requête répétée n’est pas idempotente (webhook qui crée un enregistrement, POST de paiement), un client qui réessaie après une redirection peut la déclencher deux fois. Confirmez que la cible gère correctement une répétition avant de compter sur une 308 pour « fonctionner toute seule ».
  • Mise en production et retour arrière en tenant compte du cache. Les réponses 301 et 308 sont toutes deux susceptibles d’être mises en cache heuristiquement ; un client ou un intermédiaire qui a déjà mis en cache l’ancienne réponse peut continuer à l’utiliser après le changement de code. Testez avec un client vierge et un client qui a visité l’URL avant le changement, et prévoyez un retour arrière qui tienne compte de cet état mis en cache au lieu de supposer que l’inversion est instantanée.

Quand la 301 reste-t-elle le choix pragmatique par défaut ?

Pour tout ce qui est un GET classique — c’est-à-dire la plupart des redirections effectuées par les SEOs — la 301 reste le choix sensé :

  • changements de pages ou d’URL et déplacements de contenu ;
  • changements de domaine et fusions de sites ;
  • migrations de HTTP vers HTTPS ;
  • regroupement des variantes www/sans www ou des variantes avec/sans slash final.

Pourquoi choisir l’ancien code alors que la 308 est « plus stricte » ? Pour trois raisons pratiques :

  1. Reconnaissance plus large. La 301 précède la 308 de deux décennies et est reconnue par l’immense majorité des navigateurs, proxies, CDN, robots d’exploration et outils d’analyse actuels ou anciens. La 308 a maintenant plus d’une décennie et est largement prise en charge, mais le comportement des clients historiques et des outils périphériques reste moins certain : vérifiez que chaque outil de votre pile la reconnaît.
  2. Réalité des outils. De nombreux outils courants utilisent par défaut — ou exposent proprement uniquement — 301/302. Les plugins de redirection WordPress, les éditeurs de règles Cloudflare et certaines plateformes serverless/CDN privilégient 301/302, et quelques-uns émettront une 302/307 malgré ce que vous pensez avoir configuré. Pour un propriétaire de site non technique, « ce que ma plateforme prend réellement en charge » est souvent le vrai critère.
  3. Rien à gagner. Puisque Google et Bing traitent les deux codes de la même façon pour l’exploration et l’indexation, il n’y a aucun intérêt à choisir le code moins largement pris en charge pour un simple déplacement de page.

La règle pratique : GET classique → 301 ; requête autre que GET à préserver → 308.

Comment implémenter chacune ?

La syntaxe est presque identique : seul le numéro change.

Apache (.htaccess)

# 301 — permanent, for a normal page move
Redirect 301 /old-page /new-page

# 308 — permanent + method-preserving, for an API/form endpoint
RewriteEngine On
RewriteRule ^old-api/(.*)$ /new-api/$1 [R=308,L]

nginx

# 301
location = /old-page {
    return 301 /new-page;
}

# 308 — preserves POST body to the API
location = /old-api {
    return 308 /new-api;
}

Une réserve vaut pour les deux : certains CDN, plateformes edge et plugins CMS n’honoreront pas une 308 que vous configurez et émettront plutôt une 301/302/307. Si la préservation de la méthode compte vraiment, vérifiez la réponse effectivement envoyée (faites un curl de l’URL et lisez la ligne d’état) au lieu de faire confiance à la configuration. La syntaxe des directives varie également selon les versions des serveurs et les frameworks : consultez la documentation de votre version Apache/nginx (ou celle de votre framework s’il génère la redirection) plutôt que de supposer que les extraits ci-dessus sont à jour octet par octet pour votre installation.

Un levier plus important que le choix 301-vs-308 : la longueur de la chaîne

Quel que soit le code choisi, le levier de performance le plus important consiste à garder les redirections courtes. Google suit environ 10 sauts de redirection avant d’abandonner, et chaque saut supplémentaire ajoute de la latence ainsi qu’un risque de fuite des signaux. Un seul saut propre avec le bon code vaut mieux qu’une chaîne de redirections « techniquement correctes ». Redirigez directement vers la destination finale.

Où cet article se situe-t-il ?

Les 301 et 308 sont les deux codes de redirection permanents, et chacun a son propre article approfondi dans ce groupe, à côté de leurs équivalents temporaires (302 et sa sœur stricte 307) et de l’autre membre de la famille 3xx, la 303. Les comparaisons forment une grille : 301-vs-302 oppose le permanent au temporaire, 302-vs-307 forme la paire temporaire souple/stricte, et celui-ci — 301-vs-308 — la paire permanente souple/stricte. Attention aussi aux risques opérationnels : chaînes de redirections et boucles de redirection. Pour toute la famille des réponses serveur, consultez le hub des codes d’état HTTP ; le type de redirection fait également partie des signaux de canonisation abordés dans la canonisation.

Try it live

These are real endpoints on this site — not a simulation. Hit them from the button, open them in a new tab, or curl -i them from your terminal, and the server answers with the actual status code this article is about.

Open in new tab ↗
Open in new tab ↗

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.