302 ou 307 : quelle redirection ?

TL;DR — Une 302 et une 307 sont toutes deux des redirections temporaires : elles envoient les visiteurs ailleurs pour le moment tout en laissant l’URL d’origine comme référence. Google les traite de la même façon, donc il n’y a pas de différence SEO significative. La seule vraie différence est technique : une 307 doit conserver le même type de requête (un envoi de formulaire reste un envoi de formulaire au lieu de devenir une simple récupération de page), alors qu’une 302 a historiquement permis cette conversion. Utilisez une 302 classique pour les redirections ordinaires ; choisissez une 307 quand vous redirigez un formulaire ou une API qui envoie des données — et ne supposez pas que choisir 307 partout est sans coût.

Que signifient réellement une 302 et une 307 ?

Une 302 et une 307 sont toutes deux des redirections : vous demandez une URL et arrivez sur une autre. Le nombre correspond au code d’état HTTP renvoyé par le serveur ; il transmet un message aux navigateurs et aux moteurs de recherche.

• 302 — “Found” (temporaire). La redirection temporaire d’origine. Elle signifie : « allez ici pour le moment, mais l’ancienne adresse reste la véritable — je reviendrai. »
• 307 — “Temporary Redirect” (redirection temporaire). Même message — temporaire, l’ancienne URL reste la référence — mais avec une promesse supplémentaire : le navigateur doit répéter exactement votre requête, notamment s’il s’agissait d’un GET (simple récupération d’une page) ou d’un POST (envoi de données, par exemple un formulaire).

Ce sont donc des codes frères. On peut le résumer ainsi : une 307 est une 302 qui garantit en plus que le navigateur ne transformera pas discrètement l’envoi de votre formulaire en simple requête de page.

Est-ce important pour le SEO ?

Pas de la manière qui inquiète la plupart des propriétaires de sites. La documentation de Google indique que la 307 est “equivalent to 302” (traduction : « équivalente à 302 ») pour la façon dont ses robots traitent et suivent la redirection. Les deux sont des signaux « temporaires » : par défaut, Google ne considère donc pas la destination comme la page canonique simplement parce que vous y redirigez. La documentation de Google ne précise pas si une 302 et une 307 transmettent exactement la même valeur de liens ; elle dit clairement qu’aucun de ces codes ne transmet à la destination les signaux de la source comme le ferait une redirection permanente. Si quelqu’un vous affirme qu’une 307 « transmet moins de valeur » qu’une 302, demandez-lui sa source : Google n’en a publié aucune qui le dise.

Quand utiliser chacune ?

• Utilisez une 302 classique pour les redirections temporaires courantes : page de soldes saisonnières, test A/B, page de maintenance ou envoi vers une page d’accueil propre à un pays.
• Utilisez une 307 quand l’élément redirigé envoie des données : soumission de formulaire, appel d’API, connexion ou paiement en POST. La promesse de la 307 (conserver exactement la méthode et les données) compte réellement ici, car une 302 classique peut permettre à un ancien navigateur de transformer un POST en GET et de supprimer les données.

Un point qui piège souvent

Il arrive que vous ouvriez les outils de développement de votre navigateur et voyiez une 307 que vous n’avez jamais configurée. Il ne s’agit généralement pas d’une véritable redirection du serveur : votre navigateur transforme de lui-même un lien http:// en https:// (une fonctionnalité de sécurité appelée HSTS) et vous l’affiche comme une 307. Votre serveur ne l’a jamais envoyée. Nous verrons cela plus en détail dans l’onglet Advanced.

Vous voulez l’ensemble du tableau — l’histoire de la spécification, les déclarations exactes de Google et de Mueller, le « phantom 307 » HSTS et les valeurs par défaut des frameworks qui surprennent les développeurs ? Passez à l’onglet Advanced.

TL;DR — Les 302 et 307 sont toutes deux des redirections temporaires, et Google les traite de la même façon : sa documentation indique que la 307 est “equivalent to 302,” (traduction : « équivalente à 302 ») et Mueller a déclaré que “for SEO, it doesn’t really matter” (traduction : « pour le SEO, cela n’a pas vraiment d’importance ») entre les paires temporaire et permanente. Aucun de ces codes n’indique que la destination doit devenir canonique, et Google n’a publié aucune répartition annoncée du PageRank ou de la valeur des liens entre eux. La vraie différence est la préservation de la méthode : un suivi automatique de 307 doit conserver la même méthode (un POST reste un POST), tandis qu’une 302 permet au client de convertir POST en GET ; les octets exacts du corps, les identifiants et le comportement interorigines dépendent toujours du client, alors vérifiez plutôt que de supposer. Choisissez une 307 quand la perte de méthode casserait quelque chose — API, formulaire, flux POST/webhook/checkout/auth — mais surveillez le rejeu non idempotent (un paiement ou une commande redirigée peut être soumis de nouveau). Une 302 classique convient aux redirections GET ordinaires, notamment aux tests A/B que Google recommande explicitement. Méfiez-vous du « phantom 307 » HSTS (une étiquette d’interface Chrome, pas une garantie du protocole), des spécificités des frameworks (Next.js documente 303 pour les Server Actions et 307 ailleurs : vérifiez votre version plutôt que de généraliser aux autres plateformes) et du fait que Bing n’a publié aucune indication distincte sur 302 et 307. Mon ordre préféré pour les redirections temporaires est 307 / 302 / 303 avant les rafraîchissements meta/HTTP ; toutefois, choisir 307 par défaut n’est pas sans compromis : vérifiez les en-têtes de cache, la compatibilité des anciens clients et les protections d’idempotence.

Les deux sont temporaires : le point de départ

Avant toute chose, les 302 et 307 appartiennent à la même catégorie. Google regroupe 302 (Found), 303 (See Other) et 307 (Temporary Redirect) sous l’appellation “temporary redirects,” (traduction) : « redirections temporaires », et son comportement est le même pour tous — “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (traduction) : « Googlebot suit la redirection, mais le processus d’indexation n’utilise pas la redirection comme signal indiquant que la cible doit être canonique. » En clair, une redirection temporaire conserve par défaut l’URL source comme canonique ; elle ne transmet pas à la destination les signaux de la source comme le ferait une redirection permanente (301/308).

C’est exactement la comparaison entre les deux niveaux : 301/308 forment la paire permanente, 302/307 la paire temporaire, et la logique selon laquelle le code au numéro le plus élevé préserve la méthode est identique dans les deux paires.

La seule vraie différence : préserver la méthode et le corps

Voici la distinction qui compte réellement, en une phrase : lorsqu’un client suit automatiquement une 307, la spécification HTTP actuelle (RFC 9110) l’oblige à conserver la même méthode de requête ; une 302 laisse au client la possibilité de convertir un POST en GET. Il s’agit d’une garantie au niveau de la spécification concernant la méthode — pas d’une garantie générale sur chaque octet du corps, les identifiants ou le comportement interorigines, qui dépendent toujours du client qui implémente la redirection. Vérifiez ces points avec une véritable requête au lieu de supposer qu’une 307 rejoue tout à l’identique dans tous les cas.

Pourquoi cette ambiguïté est apparue mérite une explication historique, car la plupart des articles énoncent le fait sans expliquer le pourquoi. À l’époque de HTTP/1.0, le texte de la spécification de la 302 indiquait techniquement que les clients ne devaient pas modifier la méthode en suivant la redirection — mais les premiers navigateurs (Netscape, puis tous les autres) l’ont ignoré et ont silencieusement converti les méthodes autres que GET, surtout POST, en GET avec une 302. Ce comportement incohérent mais universel est devenu la norme de fait. HTTP/1.1 (RFC 2616, 1999, ensuite intégré aux RFC 7231 puis à la RFC 9110 actuelle) a officialisé la séparation en deux codes explicites pour mettre fin à la confusion:

• 303 (See Other) — récupère la cible de la redirection avec GET ou HEAD (pas simplement « toujours GET » : la RFC 9110 autorise l’une ou l’autre méthode sûre), ce qui convient à « POST, puis redirection vers une page de résultat que l’on peut recharger sans risque ».
• 307 (Temporary Redirect) — la méthode est strictement conservée lors d’un suivi automatique, selon la spécification ; la RFC 9110 ne force pas pour autant tous les clients à suivre la redirection.

MDN résume clairement la conséquence pratique : une 307 garantit que le client conserve la méthode et le corps lors de la redirection, alors qu’avec une 302, les anciens clients convertissaient incorrectement la méthode en GET. Ainsi, la 307 n’a pas tant ajouté une capacité qu’elle n’a supprimé une ambiguïté : c’est la version garantie par la spécification de ce qu’une 302 bien implémentée était censée faire depuis le début. Les navigateurs modernes sont bien plus cohérents que ceux de l’époque de Netscape, mais la 307 supprime l’ambiguïté par la spécification et non par convention.

Comparaison directe :

Deux précisions sont importantes. La possibilité de conversion d’une 302 prévue par la RFC concerne POST, et non toutes les méthodes : ne la généralisez pas en “302 always breaks PUT/DELETE” (traduction) : « Une 302 casse toujours PUT/DELETE. » sans vérifier votre client. Par ailleurs, aucun de ces codes n’est mis en cache par défaut du seul fait de son statut : la RFC 9111 ne classe ni 302 ni 307 parmi les codes susceptibles d’être mis en cache heuristiquement sur cette seule base. La mise en cache dépend toujours des en-têtes explicites Cache-Control/Expires, et non du code de redirection choisi.

Ma propre définition d’Ahrefs rejoint ce point sur la préservation de la méthode : “A 307 redirect is the same as a 302 redirect, except it retains the HTTP method (POST, GET) of the original request when performing the redirect.” (traduction) : « Une 307 est identique à une 302, à ceci près qu’elle conserve la méthode HTTP (POST, GET) de la requête d’origine lors de la redirection. »

Google traite-t-il différemment les 302 et 307 pour le SEO ?

Non — et Google est inhabituellement explicite à ce sujet. C’est un point établi, peu controversé, comme pour la comparaison 301-308.

Dans la documentation de Google sur les codes d’état HTTP, la ligne consacrée à la 302 indique que les robots suivent la redirection et s’en servent comme d’un signal faible pour traiter la cible, tandis que la ligne consacrée à la 307 la déclare équivalente à une 302. Google rappelle toutefois que ces codes restent sémantiquement différents et recommande de choisir celui qui convient afin que les autres clients, notamment les liseuses et les autres moteurs de recherche, puissent interpréter correctement la réponse : “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, gardez à l’esprit qu’ils sont sémantiquement différents. Utilisez le code approprié à la redirection afin que d’autres clients, comme les liseuses et les autres moteurs de recherche, puissent en bénéficier. »

C’est la réponse concernant le traitement par les robots. Google traite les deux codes de la même façon lorsqu’il fait récupérer et suivre la redirection par Googlebot ; il demande seulement de choisir le code sémantiquement correct pour que les clients autres que Google se comportent correctement. Evidence for this claim Google treats 307 as equivalent to 302 for Search while noting that the two status codes are semantically different. Scope: Google Search redirect handling; HTTP clients still need the appropriate status code. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search

Il faut toutefois distinguer cette équivalence de traitement par les robots du résultat d’indexation, car c’est une lacune réelle de nombreux articles. La documentation de Google sur les redirections et la Recherche Google regroupe les 302, 303 et 307 comme des “temporary redirects” (traduction) : « redirections temporaires » et précise que “the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (traduction) : « le processus d’indexation n’utilise pas la redirection comme signal indiquant que la cible doit être canonique. » C’est une garantie utile, mais elle ne promet pas que votre URL source conservera son classement ni que la destination ne pourra jamais être indexée par d’autres signaux. « Les 302 et 307 sont traitées de la même façon » et « aucune n’est un signal de canonisation vers la cible » sont deux affirmations distinctes, toutes deux vraies — ce n’est pas une affirmation selon laquelle les deux codes transmettraient exactement le même PageRank ou la même valeur de liens, ce que la documentation de Google ne dit dans aucun sens.

John Mueller dit la même chose avec ses propres mots. Dans l’épisode du podcast Search Off the Record intitulé « Parlons des redirections », Martin Splitt lui a demandé pourquoi les 307 et 308 existaient en plus des 301 et 302. Mueller explique que les 301 et 302 transmettent généralement des requêtes GET, tandis que les 307 et 308 transmettent aussi les requêtes POST. Pour le SEO, il ne voit pas de différence déterminante : le choix est surtout fonctionnel et dépend de la compatibilité avec les API, qui n’ont généralement pas vocation à être indexées directement dans la recherche.

Le cadrage est important : la seule raison de préférer une 307 à une 302 est fonctionnelle (« does it work for APIs? »), pas liée au classement. Aucune source primaire crédible ne revendique d’avantage SEO dans un sens ou dans l’autre.

Bing traite-t-il différemment les 302 et 307 ?

Honnêtement : Bing ne l’a pas dit. Ses recommandations publiques sur les redirections (l’article de 2011 « Gestion des redirections – 301, 302 et URL canoniques » et celui de 2020 « Migration de site avec Bing ») traitent seulement de la distinction permanente/temporaire entre 301 et 302 et ne mentionnent jamais les 307 ou 308. Contrairement au sujet des 301 et 308 — sur lequel Fabrice Canel a fait une déclaration directe — je n’ai trouvé aucune déclaration d’un représentant de Bing qui distingue précisément 302 et 307.

Je vais donc le dire clairement plutôt que de supposer une équivalence : Bing n’a publié aucune déclaration distinguant précisément 302 et 307. Un comportement documenté de Bing mérite toutefois d’être connu dans le contexte des redirections temporaires : si Bingbot voit la même 302 suffisamment de fois de suite, il commence à la traiter comme une 301 et à consolider les signaux vers l’avant. Bing n’a pas confirmé publiquement que ce comportement s’applique aussi aux 307 répétées. Considérez cela comme une véritable lacune documentaire, pas comme un fait établi sur la 307.

Quand la 307 est le choix techniquement correct

Toute redirection où la perte de la méthode ou du corps d’origine casserait quelque chose :

• API et points de terminaison de webhooks — un POST/PUT/DELETE qui doit parvenir à la nouvelle URL avec sa méthode et son contenu intacts.
• Soumissions de formulaires (flux POST) — comme l’a dit Mueller, “if you have a— I’d almost say like a broken setup, that you have a form on one domain and the results are forwarded to a different one, then you would use the 307, 308.” (traduction) : « si vous avez — je dirais presque — une configuration défectueuse, avec un formulaire sur un domaine et ses résultats transmis à un autre, vous utiliseriez alors les 307 et 308. »
• Passage POST pour un paiement, une commande ou une connexion/authentification — partout où la suppression silencieuse du corps ferait échouer la transaction.

Une précaution mérite d’être soulignée : la garantie de préservation de méthode de la 307 peut avoir des effets dans les deux sens. Si la requête d’origine n’était pas idempotente — débit d’un paiement, envoi d’une commande ou autre opération ayant un effet de bord — un suivi automatique de 307 rejoue exactement cette requête à la nouvelle URL. C’est généralement ce que l’on veut, mais cela signifie aussi qu’une nouvelle tentative du client ou une chaîne de redirections peut soumettre plusieurs fois un appel non idempotent. Ajoutez des contrôles d’idempotence (clé d’idempotence, détection des soumissions en double) sur le point de terminaison qui reçoit la requête, au lieu de supposer que la redirection suffit à sécuriser le rejeu.

Une raison fréquente pour laquelle les développeurs rencontrent une 307 sans l’avoir choisie est que certains frameworks et plateformes edge utilisent par défaut un code qui préserve la méthode pour les requêtes autres que GET. Next.js est l’exemple le mieux documenté : sa fonction redirect() renvoie 303 lorsqu’elle est appelée depuis une Server Action et 307 dans d’autres contextes pris en charge, d’après sa référence API actuelle. Vérifiez donc la documentation de votre version de Next.js plutôt que de supposer qu’un seul code s’applique à tout le framework. Les autres frameworks, CDN et équilibreurs de charge varient selon le produit et la version : vérifiez le code d’état réellement renvoyé par votre plateforme au lieu de supposer qu’il correspond à celui d’une plateforme similaire. Une 307 ou une 303 inattendue peut être la plateforme qui applique volontairement une logique liée à la méthode, et non une mauvaise configuration — mais confirmez-le dans votre environnement précis.

Quand la 302 est le choix pragmatique par défaut

Les redirections temporaires ordinaires sur des requêtes GET simples : il n’y a aucune méthode à préserver, donc la garantie de la 307 ne vous apporte rien :

• Redirections géographiques ou linguistiques (avec la réserve habituelle : évitez de bloquer complètement le contenu selon la région).
• Tests A/B et tests fractionnés — les consignes de Google sur les tests de sites web indiquent explicitement d’utiliser une 302, et non une 301, pour rediriger vers des variantes de test, précisément parce que la redirection est temporaire.
• Redirections de maintenance ou « retour prochainement » — mais seulement lorsqu’il existe réellement une ressource vers laquelle envoyer les visiteurs. Si le site entier est indisponible, les propres consignes de Google orientent plutôt vers une 503 (service indisponible) que vers une redirection. Et si la requête redirigée n’est pas une requête GET — paiement ou appel d’API arrivant sur votre page de maintenance — une 307 rejouera cette requête à la nouvelle URL. Ce n’est pas automatiquement sûr si l’appel a des effets de bord : ne choisissez donc pas une 307 par habitude sans vérifier.
• Redirections mobile↔ordinateur (m-dot) — l’exemple de Mueller où une 302 est spécifiquement le bon code : “a 302 redirect would be the right one because next time someone goes there, you don’t really know if they want to go to the mobile version or the desktop version.” (traduction) : « une redirection 302 serait la bonne solution car, la prochaine fois que quelqu’un s’y rend, vous ne savez pas vraiment s’il veut accéder à la version mobile ou à la version pour ordinateur. » La bonne destination dépend du visiteur : ce n’est donc pas un déplacement permanent.

Le « phantom 307 » HSTS : une 307 que votre serveur n’a jamais envoyée

Cette section est nécessaire car le sujet est complètement différent du choix d’un code de redirection ; les confondre crée une vraie confusion lorsqu’on débogue des chaînes de redirections.

Si un site envoie l’en-tête HSTS (Strict-Transport-Security) sur HTTPS, le navigateur s’en souvient et, lors d’une tentative ultérieure d’accéder à la version http://, transforme lui-même la requête en https:// : l’URI est réécrite avant même que la requête touche le réseau. Les versions actuelles de Chrome affichent cette mise à niveau interne dans DevTools comme une 307, mais le serveur n’a rien envoyé. Le libellé exact, le nombre d’octets ou la présentation de l’en-tête relèvent de l’interface propre à la version de Chrome, et non d’une exigence de la spécification HTTP ou HSTS : ne considérez pas « 307 » comme un libellé garanti dans tous les navigateurs ou toutes les versions futures. John Mueller l’explique sur son site : “After seeing the HTTPS URL with the HSTS header (for example, with any redirect from the HTTP version), Chrome will act like it’s seeing a 307 redirect the next time you try to access the HTTP page.” (traduction) : « Après avoir vu l’URL HTTPS avec l’en-tête HSTS (par exemple après une redirection depuis la version HTTP), Chrome fera comme s’il voyait une redirection 307 la prochaine fois que vous tenterez d’accéder à la page HTTP. » Et voici la précision essentielle : “Your server’s not returning a 307, Chrome is just showing it to you as such to explain that it’s doing the redirect for you.” (traduction) : « Votre serveur ne renvoie pas une 307 ; Chrome vous l’affiche ainsi pour vous expliquer qu’il effectue lui-même la redirection. »

J’ai signalé le même phénomène dans mon propre article sur les codes d’état : il existe même un sens distinct de “307 HSTS Policy” (« force le client à utiliser HTTPS »), différent de “307 Temporary Redirect.” (traduction) : « 307 Redirection temporaire. » La nuance SEO est la suivante : “When web servers require clients to only use HTTPS connections (HSTS policy), Google won’t see the 307 because it’s cached in the browser.” (traduction) : « Lorsque les serveurs Web obligent les clients à n’utiliser que des connexions HTTPS (politique HSTS), Google ne voit pas la 307, car elle est mise en cache dans le navigateur. » Ainsi, si vous repérez une 307 dans l’onglet Network que vous n’avez jamais configurée, avant de chercher une règle de redirection mal configurée, vérifiez s’il ne s’agit pas simplement de HSTS qui effectue la mise à niveau HTTP→HTTPS pour vous.

Mythes courants

• « La 307 ne transmet pas la même valeur SEO que la 302. » Rien ne l’étaye : la documentation de Google indique que la 307 est “Equivalent to 302” (traduction : « équivalente à 302 ») pour le traitement de la redirection, et aucun des deux codes n’est traité comme un signal indiquant que la destination doit devenir canonique. Google n’a toutefois publié aucune formule exacte de PageRank ou de valeur de liens pour l’un ou l’autre ; n’affirmez donc pas un transfert précisément égal (ou inégal) dans un sens ou dans l’autre. L’affirmation correcte est que Google les traite de la même façon, et non qu’il a quantifié la valeur transmise.
• “302 is the safer/recommended choice because it’s clearer how search engines treat it.” (traduction) : « La 302 est le choix le plus sûr ou recommandé parce que les moteurs de recherche la comprennent mieux. » C’est exagéré. Le traitement de la 307 par Google est tout aussi documenté (“Equivalent to 302” (traduction : « équivalente à 302 »)) : ce n’est pas un cas où un code serait mieux compris des moteurs. Au contraire, la 307 offre une garantie fonctionnelle (préservation de la méthode et du corps) que la 302 n’offre pas. Certains guides tiers disent le contraire ; voyez la remarque dans l’onglet des ressources.
• « Une 307 dans l’onglet Network de mon navigateur signifie que mon serveur a mal configuré une redirection. » Souvent faux : si HSTS est activé et que vous avez déjà chargé la version HTTPS, cette 307 est la mise à niveau HTTP→HTTPS effectuée par Chrome, pas une réponse du serveur.
• « Les 302 convertissent toujours POST en GET : n’utilisez donc jamais une 302 pour un formulaire. » C’est exagéré pour les navigateurs modernes. La conversion POST→GET était un problème réel et bien documenté chez les clients anciens ; c’est la raison pour laquelle la 307 existe comme option garantie, pas la preuve que toutes les 302 actuelles suppriment les données POST. La 302 est ambiguë, pas universellement défaillante.
• « Remplacez toutes vos redirections temporaires par des 307 pour améliorer le classement. » Faux et inutile : il n’y a aucun avantage de classement. La seule raison valable de préférer une 307 est un besoin réel de préserver la méthode et le corps (ou une volonté générale de préparer l’avenir).
• « 303 et 307 sont pratiquement identiques. » Non : la 303 force explicitement la méthode à devenir GET (elle est conçue pour les scénarios POST-puis-redirection-vers-une- page-de-résultat), ce qui est l’opposé fonctionnel de la garantie de conservation de la 307. La confusion est facile parce qu’elles sont listées ensemble.

Ma recommandation

Pour les redirections temporaires, mon ordre d’implémentation préféré est 307 / 302 / 303, avant le rafraîchissement meta (0) et le rafraîchissement HTTP (0). Notez que je classe effectivement la 307 au-dessus de la 302 — non parce qu’elle aide le SEO (ce n’est pas le cas), mais parce que si vous utilisez toujours le code qui préserve la méthode, vous aurez rarement à penser à changer de code plus tard : une redirection GET simple fonctionne très bien en 307 et, le jour où vous redirigez un formulaire ou une API, vous êtes déjà couvert. C’est un argument de complétude, pas une politique sans coût : une politique authentique de 307 par défaut doit conserver la même discipline de mise en cache que toute redirection, fonctionner avec les anciens clients que vous prenez réellement en charge et appliquer des protections d’idempotence à toute cible de redirection qui n’est pas une simple récupération GET. Mueller formule le même argument de complétude : “if you always use them, then you’re always safe.” (traduction) : « si vous les utilisez toujours, vous êtes toujours en sécurité. » Cela dit, une 302 classique convient parfaitement et, pour le cas précis mobile-ordinateur, la 302 est techniquement le choix le plus correct.

Où se situe cet article ?

Les 302 et 307 sont deux codes de redirection temporaires de la famille 3xx. Chacun possède son propre article détaillé dans ce cluster, aux côtés de la paire permanente (301, 308), de la 303, sa sœur qui utilise toujours GET, et des comparaisons associées : 301-vs-308 au niveau permanent (même logique de préservation de méthode, un niveau au-dessus) et 301-vs-302, qui oppose permanent et temporaire. S’y ajoutent les risques opérationnels, les chaînes de redirections et les boucles de redirection. Pour l’ensemble de la famille des réponses du serveur, consultez le hub des codes d’état HTTP ; le type de redirection est également l’un des signaux de canonisation abordés dans la canonisation.

Résumé par IA

Une synthèse de la version avancée :

• Les deux sont des redirections temporaires. Les 302 et 307 conservent par défaut l’URL source comme canonique ; aucune ne transmet à la destination les signaux de la source comme le ferait une 301/308 permanente.
• Google les traite de la même façon. Sa documentation indique que la 307 est “equivalent to 302,” (traduction) : « équivalente à 302 », et Mueller a dit : “for SEO, it doesn’t really matter.” (traduction) : « pour le SEO, cela n’a vraiment pas d’importance. » Mais il s’agit d’une affirmation sur le traitement par les robots, pas d’une formule publiée sur le PageRank ou la valeur des liens. Google n’en a publié aucune pour l’un ou l’autre code : n’affirmez donc pas un transfert exactement égal (ou inégal) et ne supposez pas que « traité de la même façon » garantit que la source conservera son classement ou que la destination ne pourra jamais être indexée par d’autres signaux.
• La vraie différence est la préservation de la méthode. Un suivi automatique de 307 doit conserver la même méthode (un POST reste un POST) ; une 302 permet au client de convertir POST en GET. La 307 a été ajoutée dans HTTP/1.1 (RFC 2616 → 7231 → 9110) précisément pour lever cette ambiguïté ; toutefois, les octets exacts du corps, les identifiants et le comportement interorigines dépendent encore du client, et la possibilité de conversion de la RFC concerne spécifiquement POST, pas toute méthode autre que GET.
• Utilisez une 307 pour les API, formulaires et flux POST/webhook/checkout/auth — mais surveillez le rejeu non idempotent (un paiement ou une commande peut être soumis de nouveau lors de la redirection ; ajoutez des protections d’idempotence). Utilisez une 302 pour les redirections GET simples — géographiques ou linguistiques, tests A/B conformément à la recommandation explicite de Google et, dans l’exemple de Mueller, mobile↔ordinateur. Les redirections de maintenance dépendent de l’existence d’une véritable ressource cible ; en cas d’indisponibilité totale, une 503 est souvent préférable.
• Les valeurs par défaut des frameworks dépendent de la version et du contexte, elles ne sont pas universelles. Next.js documente 303 pour les Server Actions et 307 dans d’autres contextes : vérifiez votre version plutôt que de supposer que les autres frameworks ou CDN se comportent de la même façon.
• « Phantom 307 » HSTS : une 307 dans l’onglet Network de votre navigateur est souvent la mise à niveau HTTP→HTTPS effectuée par Chrome (HSTS), pas une réponse du serveur ; le libellé exact « 307 » est un choix d’interface propre à la version de Chrome, et non une exigence de la spécification HTTP/HSTS. Mueller écrit : “Your server’s not returning a 307, Chrome is just showing it to you as such.” (traduction) : « Votre serveur ne renvoie pas une 307 ; Chrome vous l’affiche ainsi. »
• Bing : aucune recommandation distincte sur 302 et 307 n’existe ; ne supposez pas une équivalence et ne supposez pas non plus que son comportement « 302 répétée → traitée comme une 301 » s’applique aux 307.
• Aucun de ces codes n’est mis en cache par défaut du seul fait de son statut (RFC 9111) : la mise en cache dépend toujours des en-têtes explicites Cache-Control/Expires.
• L’ordre préféré de Patrick pour les redirections temporaires est 307 / 302 / 303 avant les rafraîchissements meta/HTTP ; choisir 307 partout n’est toutefois pas sans coût : vérifiez les en-têtes de cache, la prise en charge par les anciens clients et les protections d’idempotence.

Documentation officielle

Documentation et spécifications de sources primaires.

Google

• Codes d’état HTTP, erreurs réseau et DNS, et Google Search — la ligne de la 302 sur le « signal faible », la ligne de la 307 “Equivalent to 302” (traduction : « équivalente à 302 ») et la réserve « sémantiquement différents — utilisez le code approprié ».
• Redirections et Google Search — regroupe les 302, 303 et 307 comme “temporary redirects” (traduction) : « redirections temporaires » et explique l’effet de chacun sur la canonisation.
• Podcast Search Off the Record — « Parlons des redirections », épisode 51 (John Mueller et Martin Splitt) — la discussion enregistrée sur les raisons d’être des 307/308 et les cas où elles comptent.
• John Mueller — A search-engine guide to 301, 302, 307, & other redirects — le comportement d’indexation de la 302 (l’URL source « R » tend à être indexée ; la redirection n’est pas mise en cache).
• John Mueller — les 307 — l’explication du « phantom 307 » HSTS.

Bing / Microsoft

• Gestion des redirections — 301, 302 et URL canoniques (octobre 2011) — la distinction de Bing entre 301 permanente et 302 temporaire (aucune mention de 307).
• Migration de site avec Bing (décembre 2020) — recommandations générales pour un déplacement de site (là encore, aucune déclaration spécifique à la 307).

Spécifications

• MDN — redirection temporaire 307 — la définition de la préservation de la méthode et du corps, ainsi que la remarque historique sur les anciens clients qui modifiaient la méthode en GET.
• RFC 9110 — HTTP Semantics — §15.4.8 « 307 Temporary Redirect » et §15.4.3 « 302 Found », le texte actuel de la spécification pour les deux codes.

Citations de la source

Déclarations enregistrées de Google, ainsi que la spécification. Lorsque la page source le permet, chaque lien est un lien profond qui mène directement au passage cité.

Documentation Google — la 307 est équivalente à la 302

• “Equivalent to 302.” (traduction) : « Équivalente à 302. » (ligne consacrée à la 307) — Google Search Central. Accéder à la citation
• « Même si Google traite ces codes d’état de la même façon, ils restent sémantiquement différents. Utilisez le code approprié afin que les autres clients, notamment les liseuses et les autres moteurs de recherche, puissent en bénéficier. » Accéder à la citation
• “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical.” (traduction) : « Googlebot suit la redirection, mais le processus d’indexation n’utilise pas la redirection comme signal indiquant que la cible doit être canonique. » (redirections temporaires, notamment 302/303/307) Accéder à la citation

John Mueller, Google (podcast Search Off the Record, épisode 51 — « Parlons des redirections » ; PDF de la transcription officielle, cité par passage — aucune page HTML ne possède le texte d’ancrage correspondant, donc ces citations ne peuvent pas avoir de lien profond #:~:text=)

• “I had to look this up recently. And usually, with a 301 and 302, what is forwarded are GET requests.” (traduction) : « J’ai dû vérifier cela récemment. En général, avec une 301 et une 302, ce qui est transmis, ce sont des requêtes GET. » … “And with 307, 308, it also forwards POST requests.” (traduction) : « Et avec les 307 et 308, les requêtes POST sont également transmises. »
• “If you have some kind of an API that uses POST requests, or if you have a— I’d almost say like a broken setup, that you have a form on one domain and the results are forwarded to a different one, then you would use the 307, 308.” (traduction) : « Si vous avez une API qui utilise des requêtes POST, ou si vous avez — je dirais presque — une configuration défectueuse, avec un formulaire sur un domaine et ses résultats transmis à un autre, vous utiliseriez les 307 et 308. »
• “I guess from a completeness point of view, if you always use them, then you’re always safe. But that’s the difference there. I think for SEO, it doesn’t really matter. It’s more like, I don’t know… Does it work for APIs or not? And usually, APIs are not something that you need to have indexed directly in Search.” (traduction) : « Du point de vue de la complétude, je suppose que si vous les utilisez toujours, vous êtes toujours en sécurité. C’est là toute la différence. Je pense que pour le SEO, cela n’a pas vraiment d’importance. C’est plutôt : est-ce que cela fonctionne pour les API ou non ? Et généralement, les API ne sont pas des éléments que vous devez faire indexer directement dans la recherche. »
• “And for that kind of redirect [mobile/desktop], from a technical point of view, a 302 redirect would be the right one because next time someone goes there, you don’t really know if they want to go to the mobile version or the desktop version.” (traduction) : « Et pour ce type de redirection [mobile/ordinateur], d’un point de vue technique, une redirection 302 serait la bonne, car la prochaine fois que quelqu’un s’y rend, vous ne savez pas vraiment s’il veut accéder à la version mobile ou à la version pour ordinateur. » PDF de la transcription

John Mueller, Google (johnmu.com — le « phantom 307 » HSTS)

• “After seeing the HTTPS URL with the HSTS header (for example, with any redirect from the HTTP version), Chrome will act like it’s seeing a 307 redirect the next time you try to access the HTTP page.” (traduction) : « Après avoir vu l’URL HTTPS avec l’en-tête HSTS (par exemple après une redirection depuis la version HTTP), Chrome fera comme s’il voyait une redirection 307 la prochaine fois que vous tenterez d’accéder à la page HTTP. »
• “Your server’s not returning a 307, Chrome is just showing it to you as such to explain that it’s doing the redirect for you.” (traduction) : « Votre serveur ne renvoie pas une 307 ; Chrome vous l’affiche ainsi pour vous expliquer qu’il effectue lui-même la redirection. » Lire l’article

MDN — la différence de préservation de méthode

• “The difference between 307 and 302 is that 307 guarantees that the client will not change the request method and body when the redirected request is made. With 302, older clients incorrectly changed the method to GET.” (traduction) : « La différence entre 307 et 302 est que la 307 garantit que le client ne modifiera ni la méthode ni le corps de la requête lors de la redirection. Avec une 302, les anciens clients modifiaient incorrectement la méthode en GET. » Accéder à la citation

Quelle redirection temporaire : 302 ou 307 ?

Puisque les deux sont temporaires et équivalentes pour le SEO, toute la décision se résume à une question : la requête transporte-t-elle une méthode ou un corps qu’il faut préserver ?

À propos du chemin « pas certain » : Google traite la 307 de la même façon que la 302 et elle fonctionne aussi très bien pour les redirections GET simples. La choisir par défaut n’est donc pas incorrect, mais elle n’est pas non plus sans coût. Confirmez vos en-têtes de cache, vérifiez que les anciens clients que vous prenez encore en charge gèrent la 307 de manière prévisible et, si la requête redirigée a des effets de bord (appel autre que GET vers une API), ne laissez pas une 307 la rejouer sans protections d’idempotence.

Erreurs à éviter avec les redirections temporaires

Choisir une 302 parce que la 307 transmettrait prétendument moins de valeur

Google documente la 307 comme équivalente à la 302 pour la recherche. Choisissez entre les deux en fonction du comportement de la requête, pas du classement.

Supposer que la 302 est toujours plus sûre parce qu’elle est plus ancienne

Les anciens clients rendaient le traitement de la méthode par la 302 ambigu. Si un POST, PUT, DELETE, webhook ou corps d’API doit être conservé, utilisez 307 pour bénéficier de la garantie explicite de préservation.

Traiter chaque 307 de DevTools comme une règle du serveur

Chrome peut afficher une mise à niveau HSTS interne sous la forme 307 alors que le serveur n’en a jamais renvoyé. Reproduisez la requête avec un vérificateur côté serveur ou curl avant de modifier la configuration des redirections.

Affirmer que toute 302 convertit POST en GET

Le comportement historique est autorisé et ambigu, pas garanti par tous les clients modernes. Utilisez 307 quand vous avez besoin de certitude ; ne décrivez pas toutes les implémentations de 302 comme défaillantes.

Remplacer chaque 302 par une 307 pour gagner en SEO

Il n’y a aucun avantage de classement. Ne modifiez le code que lorsque la préservation de la méthode et du corps améliore la correction du flux, ou lorsqu’une valeur par défaut plus sûre du framework est appropriée.

Confondre 303 et 307

Ce sont des opposés fonctionnels concernant la méthode : 303 transforme volontairement le suivi en GET, tandis que 307 conserve la méthode et le corps d’origine.

Diagnostiquer une 307 inattendue ou un flux 302 défaillant

DevTools affiche une Internal Redirect / 307 inexpliquée

Symptôme : Une navigation http:// apparaît comme une 307 dans Chrome, mais aucune règle de redirection n’existe.

Cause probable : HSTS a mis la requête à niveau à l’intérieur du navigateur avant qu’elle n’atteigne le serveur.

Correctif : Vérifiez l’initiateur et les en-têtes de l’entrée, puis envoyez une requête qui ne suit pas automatiquement les redirections directement vers l’URL HTTP avec un outil côté serveur — pas avec votre navigateur, car même une nouvelle fenêtre de navigation privée peut encore appliquer l’état HSTS préchargé. Ne considérez pas curl comme une référence automatiquement neutre : il peut avoir son propre magasin HSTS configuré, alors notez comment vous l’avez invoqué. Si la réponse brute du serveur diffère de ce qu’affichait DevTools, ne « corrigez » pas le phantom 307 ; auditez séparément la véritable redirection HTTP→HTTPS du serveur et rejouez toute requête autre que GET comme un test contrôlé distinct. Une requête HEAD qui suit automatiquement les redirections ne peut pas prouver le comportement du corps ou de POST.

Un POST perd son corps après une redirection temporaire

Symptôme : Un formulaire, un webhook, une connexion ou un appel d’API atteint la cible en GET ou sans sa charge utile.

Cause probable : La source utilisait 302, ce qui permettait au client de modifier la méthode, ou un intermédiaire a réécrit la réponse.

Correctif : Utilisez 307 pour le déplacement temporaire, puis rejouez une requête de test inoffensive et confirmez dans les journaux de la cible que la méthode, le type de contenu et le corps sont arrivés intacts.

La plateforme émet 307 alors que vous avez choisi une redirection générique

Symptôme : Un framework ou une plateforme edge renvoie 307 au lieu de la 302 attendue.

Cause probable : La plateforme a choisi le code temporaire qui préserve la méthode, souvent pour une requête autre que GET.

Correctif : Vérifiez que le déplacement est réellement temporaire et que la préservation de la requête est correcte. Si c’est le cas, conservez-la : Google traite les codes de la même façon. Ne changez le code que lorsque la sémantique de l’application ou la compatibilité des clients exige une autre réponse.

302 et 307 en un coup d’œil

Règle générale : une page temporaire ordinaire en GET → les deux conviennent ; une requête temporaire autre que GET qui doit arriver intacte → 307.

Outils pour identifier la redirection réellement reçue

L’outil gratuit de Patrick

• Vérificateur groupé des codes d’état HTTP — envoyez des requêtes côté serveur pour jusqu’à 500 URL et examinez les codes et les chaînes réellement renvoyés. Il est particulièrement utile pour distinguer les réponses du serveur de l’affichage interne 307 dû uniquement au HSTS de Chrome.

Inspecter le comportement de la requête

• Vérificateur de redirection — suivez une source unique à chaque étape et confirmez si le serveur commence par une 302 ou une 307.
• Panneau Network de DevTools du navigateur — inspectez l’initiateur et vérifiez si Chrome étiquette une entrée comme redirection interne ; ne prenez pas cela seul comme preuve d’une réponse du serveur.
• curl et journaux de l’application — envoyez un POST inoffensif vers la préproduction et confirmez que la cible reçoit la même méthode et le même corps. Si vous avez configuré le magasin HSTS de curl (--hsts), tenez-en compte lors de l’interprétation du résultat. Les outils qui ne donnent que le statut ne peuvent pas prouver que la charge utile est arrivée.

Testez vos connaissances : 302 et 307

Cinq questions sur les deux redirections temporaires et ce qui les distingue réellement. Choisissez une réponse à chaque fois, puis vérifiez-la.

Ressources utiles

Mes textes associés

• 11 types de redirections et leur impact SEO (Ahrefs, avec Joshua Hardwick) — mon tour d’horizon complet des types de redirection. C’est là que je présente mon ordre d’implémentation préféré pour les redirections temporaires — 307 / 302 / 303 > meta refresh 0 / HTTP refresh 0 — et que je formule clairement le verdict SEO : “For SEO, it’s the same, but if you have data being sent through forms that redirect, then you don’t want to be swapping between GET and POST.” (traduction) : « Pour le SEO, c’est pareil, mais si des données passent par des formulaires qui redirigent, il ne faut pas alterner entre GET et POST. »
• Codes d’état HTTP et leur impact SEO (Ahrefs) — ma référence pour chaque code d’état, notamment les deux sens distincts de la 307 (Temporary Redirect et HSTS Policy 307) et la remarque selon laquelle, avec HSTS, “Google won’t see the 307 because it’s cached in the browser.” (traduction) : « Google ne verra pas la 307, car elle est mise en cache dans le navigateur. »
• Guide du débutant sur le SEO technique — pour replacer les redirections dans une vue d’ensemble.

Mes interventions

• Patrick Stox sur SlideShare et Speaker Deck — mes présentations de SEO technique, dont plusieurs abordent les redirections et la canonisation. (Ma réserve habituelle s’applique : “This is my understanding of systems… not going to be 100% complete or accurate.” (traduction) : « C’est ma compréhension des systèmes… elle ne sera pas complète ou exacte à 100 %. »)

Sources officielles

• Google — codes d’état HTTP, erreurs réseau et DNS — la ligne « “Equivalent to 302” » (traduction : « équivalente à 302 ») et la réserve « sémantiquement différents, utilisez le code approprié ».
• Google — Redirections et Google Search — regroupe 302/303/307 comme redirections temporaires.
• Podcast Search Off the Record — « Parlons des redirections » (Google Search Relations, épisode 51) — la discussion de Mueller et Splitt dont sont tirées les citations ci-dessus.

Dans le reste du secteur

• John Mueller — les 307 — l’explication la plus claire du « phantom 307 » HSTS : la 307 affichée par votre navigateur mais jamais envoyée par votre serveur.
• MDN — redirection temporaire 307 — une définition claire de la préservation de la méthode et du corps, ainsi que la remarque historique sur les anciens clients.
• Guide SEO des redirections (Search Engine Land, Helen Pollitt) — une bonne vue d’ensemble de la famille des redirections.
• Redirections d’URL pour le SEO : guide technique (Search Engine Journal) — un autre tour d’horizon technique utile.
• Mythe à corriger : la page « 302 vs 307 » de Conductor recommande la 302 plutôt que la 307 parce que “it’s clear how search engines treat the 302 redirect.” (traduction) : « il est clair de voir comment les moteurs de recherche traitent la redirection 302. » Ce conseil contredit la documentation de Google, qui qualifie explicitement la 307 de “Equivalent to 302” (traduction : « équivalente à 302 ») : son traitement est tout aussi documenté. Ne prenez pas “302 is the safer SEO choice” (traduction) : « la 302 est le choix SEO le plus sûr » pour une autorité ; le seul vrai critère est de savoir si vous devez préserver la méthode et le corps.
• r/TechSEO — la communauté qui aide à déboguer les redirections et la canonisation.

Journal des modifications