307 Redirection temporaire

TL;DR — Une 307 est une redirection temporaire, comme une 302 : elle envoie utilisateurs et moteurs de recherche vers une nouvelle URL pour le moment, sans dire à Google de transférer le classement de l’ancienne URL à la nouvelle. La chose qui la distingue d’une 302 est la suivante : une 307 promet de ne pas modifier le type de requête. Si quelqu’un envoie un formulaire (un POST), il reste un POST. Pour les simples liens de page à page, la différence est invisible ; elle ne compte que pour les formulaires et les applications. Et la « 307 » que vous voyez parfois dans votre navigateur lors d’une mise à niveau vers https n’est pas une vraie redirection.

Qu’est-ce qu’une redirection 307 ?

Lorsqu’une URL a été déplacée ailleurs pour le moment — et non définitivement — le serveur peut répondre avec une 307 Temporary Redirect et indiquer au navigateur le nouvel emplacement. C’est la même idée de base qu’une 302 : elle est temporaire, donc Google ne la traite pas comme un signal chargé de transférer le classement de l’URL d’origine à la nouvelle, contrairement à une redirection permanente. C’est un signal faible, qui ne rend pas la nouvelle URL canonique ; cela ne garantit pas non plus que l’URL d’origine conservera son classement ou restera indexée pour toujours. On utilise une redirection temporaire pour une page indisponible pendant une maintenance, une campagne saisonnière ou toute situation où l’on prévoit de revenir en arrière.

Qu’est-ce qui différencie une 307 d’une 302 ?

Il n’y a véritablement qu’une différence, et la plupart des gens ne la rencontrent jamais. Une requête Web possède une méthode — généralement GET (récupérer une page), mais parfois POST (envoyer des données, par exemple avec un formulaire). Une 307 garantit que le navigateur conserve la même méthode lorsqu’il suit la redirection. Les anciens navigateurs transformaient parfois un POST en GET avec une 302, ce qui pouvait interrompre l’envoi d’un formulaire. Une 307 supprime ce risque dans la spécification. Evidence for this claim RFC 9110 defines 307 Temporary Redirect as a temporary move and requires clients not to change the request method when following it automatically. Scope: HTTP semantics for real server 307 responses, not browser-internal HSTS displays. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.8 — 307 Temporary Redirect

Pour l’immense majorité des redirections — quelqu’un clique sur un lien vers une page — cela ne change absolument rien, car il s’agit dans les deux cas de requêtes GET.

Une 307 nuit-elle au SEO ?

Non. La documentation de Google dit qu’une 307 est « equivalent to » une 302 (traduction) : « équivalente à une 302 ». Les deux sont temporaires ; aucune ne transfère le classement de l’ancienne page à la nouvelle comme le ferait une redirection permanente (une 301). Il n’y a ni pénalité secrète ni bonus secret : une 307 est traitée exactement comme une 302.

La « 307 » qui n’est pas une redirection

C’est la partie qui déroute le plus. Si votre site impose https (une fonctionnalité de sécurité appelée HSTS), votre navigateur affichera parfois une « 307 » dans ses outils de développement lorsque vous consultez la version http d’une page. Votre serveur ne l’a jamais envoyée : le navigateur l’a fabriquée pour expliquer qu’il est passé directement à la version sécurisée. Il affiche même une réponse de 0 octet, ce qui permet de la reconnaître.

Si un outil d’audit ou votre navigateur signale une 307 inattendue, ne concluez pas que votre serveur est mal configuré. Une nouvelle fenêtre privée efface généralement la mémoire HSTS apprise par le navigateur et affiche le véritable code d’état — mais pas toujours : certains domaines figurent dans la liste HSTS préchargée des navigateurs, que le mode privé n’efface pas. Un vérificateur de redirections ou une requête curl est plus fiable pour voir ce que votre serveur renvoie réellement.

Vous voulez le langage de la spécification, les déclarations de John Mueller, les mécanismes HSTS en détail et la manière de renvoyer réellement une 307 ? Ouvrez l’onglet Advanced.

TL;DR — Une 307 est une redirection temporaire qui, selon la RFC 9110, « MUST NOT change the request method » (traduction) : « NE DOIT PAS modifier la méthode de la requête » — c’est la seule garantie ferme qu’une 302 ne donne pas. Pour le SEO, c’est un non-événement : la documentation de Google la décrit comme « Equivalent to 302 » (traduction) : « équivalente à 302 » (un signal faible et temporaire), et Mueller a dit que le choix entre 307 et 302 « doesn’t really matter » (traduction) : « ne fait pas vraiment de différence » pour la recherche. La question est de savoir si la redirection doit fonctionner pour du trafic POST ou API. La 307 qui déroute réellement est l’artefact HSTS : une « redirection » de 0 octet, visible seulement dans le navigateur, que le serveur n’a jamais envoyée, lorsque le navigateur transforme lui-même http en https. Il existe deux cas sans rapport fonctionnel, et les distinguer est le cœur du sujet.

Une 307 recouvre deux cas complètement différents

C’est l’idée directrice de tout ce qui suit. Elle vient directement de mon propre guide des codes d’état, où la 307 possède deux entrées distinctes : « 307 Temporary Redirect – Has the same functionality as a 302 redirect, except you can’t switch between POST and GET » (traduction) : « 307 Temporary Redirect — a la même fonction qu’une redirection 302, sauf qu’on ne peut pas basculer entre POST et GET » ; et « 307 HSTS Policy – Forces the client to use HTTPS when making requests instead of HTTP. » (traduction) : « 307 HSTS Policy — force le client à utiliser HTTPS au lieu de HTTP pour ses requêtes. » Elles partagent un numéro et presque rien d’autre :

1. La 307 comme vraie redirection temporaire émise par le serveur — choisie délibérément (ou fournie par défaut par un framework) pour préserver la méthode et le corps HTTP d’une requête qui n’est pas une requête GET.
2. La 307 comme artefact du navigateur lié au HSTS — ce n’est pas du tout une réponse du serveur. Le navigateur transforme http en https en interne et étiquette cette mise à niveau comme une 307.

Confondre ces deux cas est la principale source de confusion autour des 307. Examinons-les l’un après l’autre.

Cas 1 : la vraie 307 — ce que la spécification exige réellement

La RFC 9110, la spécification actuelle sur la sémantique HTTP, est sans ambiguïté au §15.4.8 :

“The 307 (Temporary Redirect) status code indicates that the target resource resides temporarily under a different URI and the user agent MUST NOT change the request method if it performs an automatic redirection to that URI.” (traduction) : « Le code d’état 307 (Temporary Redirect) indique que la ressource cible se trouve temporairement sous une URI différente et que l’agent utilisateur NE DOIT PAS modifier la méthode de la requête s’il effectue une redirection automatique vers cette URI. »

Ce « MUST NOT » est une exigence ferme, pas une suggestion. La section 302 (§15.4.3) décrit au contraire le comportement historique que la 307 a été créée pour corriger : un agent utilisateur peut transformer un POST en GET lors de la requête suivante et doit utiliser une 307 si cette conversion n’est pas souhaitée. En d’autres termes, la 307 existe précisément pour supprimer l’ambiguïté POST→GET que les anciens clients avaient avec les 302.

MDN donne la version pratique de la même distinction :

“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. 307 and 302 responses are identical when the request method is GET.” (traduction) : « La différence entre 307 et 302 est que 307 garantit que le client ne modifiera ni la méthode ni le corps de la requête lors de la redirection. Avec 302, d’anciens clients modifiaient à tort la méthode en GET. Les réponses 307 et 302 sont identiques lorsque la méthode de la requête est GET. »

Cette dernière phrase est la plus importante pour le SEO. Presque toutes les redirections qui intéressent un spécialiste SEO — d’une ancienne page vers une nouvelle — sont des requêtes GET, et avec une requête GET, une 307 et une 302 sont littéralement identiques. La garantie de préservation de la méthode n’intervient que lorsque la méthode n’est pas GET : renvoi de formulaires, points de terminaison d’API, cibles de webhooks, passage d’une commande ou d’une authentification par POST. La spécification garantit la méthode et le corps, mais ne fixe pas à elle seule la gestion exacte des en-têtes, des identifiants ou des requêtes interorigines lors de la retransmission : vérifiez ces éléments avec votre client réel au lieu de supposer un comportement identique au niveau des octets. Si vous comparez les deux codes pour un déplacement de page ordinaire, le sujet est traité en détail dans l’article consacré à la comparaison 302/307 ; cet article suppose que vous connaissez déjà le concept de redirection temporaire et se concentre sur ce qui est propre à la 307.

302, 303 ou 307 : un tableau récapitulatif

Les trois codes appartiennent à la catégorie « temporaire » de la RFC, mais leur comportement diffère sur les deux axes qui comptent réellement : la conservation de la méthode et la mise en cache :

Aucun des trois codes n’est mis en cache de manière heuristique par défaut : une 307 (comme une 302 et une 303) a besoin d’un signal explicite de fraîcheur (Cache-Control, Expires, etc.) avant qu’un cache puisse la stocker sans nouvelle vérification.

Cas 1, suite : comment Google traite une vraie 307 en SEO

Version courte : exactement comme une 302. La documentation Google sur les codes d’état HTTP indique pour la ligne 307 « Equivalent to 302 » (traduction) : « équivalente à 302 », et la ligne 302 dont elle hérite précise ce que cela signifie :

“By default, Google’s crawlers follow the redirect, and Google systems use the redirect as a weak signal that the redirect target should be processed.” (traduction) : « Par défaut, les robots d’exploration de Google suivent la redirection et les systèmes Google utilisent la redirection comme un signal faible indiquant que la cible doit être traitée. »

« Weak » est le mot important : une redirection temporaire ne regroupe pas la canonicalisation sur la cible comme le ferait une redirection permanente. La documentation Google sur les redirections et Google Search regroupe les 302, 303 et 307 sous « temporary » et décrit directement le comportement : « 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 pipeline d’indexation n’utilise pas la redirection comme signal indiquant que la cible doit être canonique. » Même page, même intention : « If you just want to send users to a different page temporarily, use a temporary redirect. » (traduction) : « Si vous voulez seulement envoyer les utilisateurs vers une autre page temporairement, utilisez une redirection temporaire. »

Immédiatement après les lignes consacrées aux 307 et aux 308, Google ajoute la réserve à retenir :

“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 manière, gardez à l’esprit qu’ils sont sémantiquement différents. Utilisez le code d’état adapté à la redirection afin que d’autres clients (par exemple des liseuses ou d’autres moteurs de recherche) puissent en tirer parti. »

Google regroupe donc les 307 et 302 pour le classement, tout en vous demandant de choisir le code sémantiquement correct. C’est toute la réponse SEO. Evidence for this claim Google treats 307 as equivalent to 302 for Search while noting that the HTTP semantics differ. Scope: Google Search redirect handling; clients still need the semantically appropriate status code. Confidence: high · Verified: 2026-07-14 Google: HTTP status codes and Search John Mueller l’a formulé encore plus directement dans l’épisode 51 de l’émission “Search Off the Record” (traduction) : « Hors micro » (« Parlons des redirections »), en expliquant que « with 307, 308, it also forwards POST requests » (traduction) : « avec 307 et 308, les requêtes POST sont également transmises », contrairement aux 301/302, qui transmettent des requêtes GET, avant de conclure :

Pour John Mueller, le choix entre 302 et 307 ne change pas vraiment le SEO : la question pratique est surtout de savoir si la redirection fonctionne pour les API, qui n’ont généralement pas vocation à être indexées directement dans la recherche.

Il n’y a aucun avantage de classement à remplacer vos redirections temporaires par des 307. La seule raison valable de la choisir est la conservation de la méthode et du corps — ou, comme préférence générale de pérennité, ce que j’aborderai à la fin.

Cas 1, suite : les valeurs par défaut des frameworks et des CDN

De plus en plus de questions « pourquoi est-ce une 307 ? » ne viennent pas d’un choix explicite, mais des valeurs par défaut des frameworks. La fonction redirect() de Next.js utilise une 307 par défaut, et sa documentation explique pourquoi sous un titre littéralement intitulé « Why does redirect use 307 and 308? » : « The redirect() method uses a 307 by default, instead of a 302 temporary redirect, meaning your requests will always be preserved as POST requests. » (traduction) : « La méthode redirect() utilise 307 par défaut au lieu d’une redirection temporaire 302, ce qui signifie que vos requêtes seront toujours conservées comme des requêtes POST. » (Next.js utilise précisément 303 dans les Server Actions et fournit permanentRedirect() pour le cas 308.) Si vous voyez des 307 que vous n’avez pas écrites, vérifiez si votre framework ou votre plateforme edge les utilise par défaut pour les redirections qui ne sont pas des GET : c’est généralement la réponse, et généralement le bon comportement.

Cas 2 : l’« artefact 307 » HSTS que votre serveur n’a jamais envoyé

C’est le territoire réellement peu couvert, et celui où un article consacré à la 307 est utile. Lorsqu’un site envoie un en-tête Strict-Transport-Security (HSTS), il dit au navigateur : à partir de maintenant, charge-moi toujours en https. Lors de la prochaine requête vers la version http, le navigateur passe lui-même en https sans contacter le serveur, et affiche cette mise à niveau interne comme une « 307 » dans les outils de développement et les robots d’exploration.

John Mueller a expliqué ce mécanisme sur son site personnel :

“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. 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) : « Après avoir vu l’URL HTTPS avec l’en-tête HSTS (par exemple avec n’importe quelle redirection depuis la version HTTP), Chrome se comportera comme s’il voyait une redirection 307 la prochaine fois que vous tenterez d’accéder à la page HTTP. Votre serveur ne renvoie pas une 307 : Chrome vous l’affiche ainsi pour expliquer qu’il effectue la redirection pour vous. »

Le corps de 0 octet est le signe révélateur. Mueller ajoute : « the 307 isn’t actually a redirect at all, it’s just a placeholder » (traduction) : « la 307 n’est en réalité pas une redirection, c’est seulement un espace réservé ». Mon propre guide des redirections présente la conséquence pratique pour les audits : « 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. The initial hit (without cache) will have a server response code that’s likely a 301 or a 302. But your browser will show you a 307 for subsequent requests which makes it more difficult to troubleshoot. You will need to use a fresh Incognito session to see the returned status code. » (traduction) : « Lorsque les serveurs Web exigent que les clients utilisent uniquement des connexions HTTPS (politique HSTS), Google ne verra pas la 307, car elle est mise en cache dans le navigateur. La première requête (sans cache) recevra probablement une réponse serveur 301 ou 302. Mais votre navigateur affichera une 307 lors des requêtes suivantes, ce qui complique le dépannage. Vous devrez utiliser une nouvelle session privée pour voir le code d’état renvoyé. »

Ce que Googlebot voit réellement avec HSTS (et l’évolution du récit)

Deux déclarations de Google, séparées de cinq ans, méritent d’être lues ensemble. En décembre 2015, Zineb Ait Bahajji (alors chez Google) a déclaré, selon Search Engine Roundtable, « With HSTS implemented, Googlebot sees a 301 redirect (try it with Fetch as Google). The 307 is just an ‘internal redirect’. » (traduction) : « Avec HSTS, Googlebot voit une redirection 301 (essayez avec Fetch as Google). La 307 n’est qu’une “redirection interne”. » En octobre 2020, la formulation de Mueller dans une vidéo Ask Google Webmasters (par Search Engine Journal) était légèrement différente : « In short, [Googlebot] doesn’t interact with them. 307 redirects are generally not real redirects. » (traduction) : « En bref, Googlebot n’interagit pas avec elles ; les redirections 307 ne sont généralement pas de vraies redirections. » Dans les deux cas, le robot ne voit pas la même « 307 » que l’humain dans les outils de développement : les outils et l’infrastructure d’exploration ont changé (Fetch as Google a été remplacé par l’Inspection de l’URL), mais l’idée centrale tient depuis au moins une décennie : dans le cas HSTS, Googlebot n’interagit pas avec une vraie 307 émise par le serveur. Considérez la déclaration de 2020 comme l’orientation actuelle ; celle de 2015 est utile pour l’historique.

La conséquence opérationnelle est importante : le HSTS est une commodité de navigateur, pas un mécanisme de découverte pour les robots. Les propriétaires de sites doivent toujours prévoir une vraie redirection côté serveur (une véritable 301) de http vers https s’ils veulent que ce chemin fonctionne pour les robots.

Comment Bing traite-t-il une 307 ?

Honnêtement, il existe une lacune documentaire. Je n’ai trouvé aucune déclaration publique de Bing qui traite nommément la 307 ou la 307 provoquée par le HSTS. Les recommandations de Bing sur les redirections (l’article de 2011 Gérer les redirections — 301, 302 et balises canoniques et celui de 2020 Migrer un site avec Bing) couvrent uniquement la distinction permanente/temporaire 301/302 — pas les 307, 308 ou le HSTS. Plutôt que de supposer une parité avec Google, restons précis : Bing n’a pas publié de position spécifique sur les 307. Le phénomène demeure réel et pertinent pour l’exploration quel que soit le moteur — Screaming Frog propose un réglage « Respect HSTS Policy » justement parce que le HSTS influence l’exploration — mais il s’agit d’une documentation d’outil, pas d’une déclaration de Bing.

Quand choisir volontairement une 307 ?

Choisissez une 307 plutôt qu’une 302 chaque fois que perdre la méthode ou le corps d’origine casserait quelque chose :

• Points de terminaison d’API et cibles de webhooks qui reçoivent des POST/PUT/PATCH.
• Flux d’envoi de formulaires (POST) qui redirigent après traitement.
• Passages POST de paiement ou de connexion entre deux hôtes.
• Toute requête contenant un corps que vous ne pouvez pas vous permettre de perdre.

Pour un simple déplacement de page, une 302 et une 307 sont indiscernables pour Google : les deux conviennent du point de vue SEO. Si la version de ce mécanisme est permanente, il s’agit de la relation 301/308 : la 308 est à la 301 ce que la 307 est à la 302.

Ma préférence déclarée, dans le guide des redirections, est plus tranchée que le classique « cela ne fait pas de différence » : « my preferred order would be: 307 / 302 / 303 > Meta refresh 0 / HTTP refresh 0. » (traduction) : « Mon ordre de préférence serait : 307 / 302 / 303 > Meta refresh 0 / HTTP refresh 0. » Je place la 307 en tête des options temporaires : l’utiliser systématiquement garantit la sécurité du côté de la préservation de la méthode, ce qui rejoint à peu près l’argument de « complétude » de Mueller. Quel que soit votre choix, veillez à ce qu’une vraie 307 (ou l’artefact HSTS) ne devienne pas un saut dans une chaîne plus longue : chaque saut supplémentaire ajoute de la latence et réduit l’efficacité.

Résumé par IA

Voici la version condensée de l’onglet Advanced :

• Une 307 recouvre deux cas sans rapport. (1) Une vraie redirection temporaire émise par le serveur qui conserve la méthode et le corps HTTP ; (2) un artefact de navigateur HSTS, une « 307 » de 0 octet que le serveur n’a jamais envoyée lorsque le navigateur transforme lui-même http→https. Les distinguer est le cœur du sujet.
• Cas 1 — la garantie de la spécification : la RFC 9110 dit qu’une 307 “MUST NOT change the request method.” (traduction) : « NE DOIT PAS modifier la méthode de la requête ». MDN ajoute que “307 and 302 responses are identical when the request method is GET” (traduction) : « les réponses 307 et 302 sont identiques lorsque la méthode est GET » ; cela ne compte donc que pour les requêtes POST/PUT/PATCH (formulaires, API). La garantie couvre la méthode et le corps ; la gestion des en-têtes, identifiants et requêtes interorigines dépend encore du client.
• 302, 303 ou 307 : une 302 peut historiquement transformer POST en GET, une 303 récupère volontairement la cible avec GET/HEAD, et une 307 ne doit pas modifier la méthode. Par défaut, aucune des trois n’est mise en cache heuristiquement.
• Réponse SEO : la documentation Google indique « Equivalent to 302 » (traduction) : « équivalente à 302 » — un signal faible et temporaire qui ne consolide pas la cible. Mueller dit que, pour le SEO, « it doesn’t really matter » (traduction) : « cela ne fait pas vraiment de différence » ; la vraie question est : « does it work for APIs » (traduction) : « est-ce que cela fonctionne pour les API ? »
• Valeurs par défaut des frameworks : redirect() de Next.js utilise 307 par défaut (303 dans les Server Actions et permanentRedirect() pour 308) afin de préserver les POST ; c’est une source fréquente de 307 « accidentelles », généralement correcte.
• Cas 2 — HSTS : le navigateur affiche une 307 avec un corps de 0 octet ; le vrai code serveur est généralement 301 ou 302. Googlebot ne voit pas cette 307 (Mueller en 2020 : « doesn’t interact with them » (traduction) : « n’interagit pas avec elles » ; Zineb en 2015 : « sees a 301 » (traduction) : « voit une 301 »). Il faut tout de même une véritable 301 côté serveur pour http→https. Auditez avec un vérificateur de redirections ou curl simple ; une nouvelle session privée fonctionne souvent, sauf pour les domaines de la liste HSTS préchargée du navigateur.
• Bing : aucune déclaration publique spécifique à la 307 — une lacune documentaire, pas une preuve de parité.
• Préférence : aucune raison de classement ne justifie de passer à 307 ; mon ordre personnel place la 307 en tête des options temporaires pour préparer l’avenir.

Documentation officielle

Documentation de première main et spécifications.

Google

• Codes d’état HTTP, erreurs réseau et DNS, et Google Search — ligne « 307 (redirection temporaire) — équivalente à 302 », formulation du signal « faible » pour 302 et réserve sur la différence sémantique.
• Redirections et Google Search — regroupe 302/303/307 sous « temporaire » et précise que le pipeline d’indexation n’utilise pas la redirection pour faire de la cible la canonique.

Bing / Microsoft

• Gérer les redirections — 301, 302 et balises canoniques — recommandations de Bing sur les redirections (uniquement 301/302 ; aucune mention de 307 ou HSTS).
• Migrer un site avec Bing — recommandations de migration, là encore limitées aux 301/302.

Spécification HTTP

• RFC 9110 §15.4.8 — 307 Temporary Redirect — “MUST NOT change the request method.” (traduction) : « NE DOIT PAS modifier la méthode de la requête ».
• RFC 9110 §15.4.3 — 302 Found — remarque historique sur POST→GET qui renvoie à la 307.

Référence technique

• MDN — 307 Temporary Redirect — conservation de la méthode et du corps ; les réponses sont identiques lorsque la méthode est GET.

Framework

• Next.js — redirect() function reference — FAQ « Why does redirect use 307 and 308? » et valeur par défaut 307 (303 dans les Server Actions).

Outils d’exploration

• Screaming Frog — An SEO’s Guide To Crawling HSTS & 307 Redirects — réglage « Respect HSTS Policy » et mécanismes HSTS.

Citations de la source

Déclarations attribuées. Chaque lien mène au passage cité ou le documente.

Documentation Google — traitement SEO

• “307 (temporary redirect) — Equivalent to 302.” (traduction) : « 307 (redirection temporaire) — équivalente à 302. » — Google Search Central, Codes d’état HTTP, erreurs réseau et DNS, et Google Search. Voir la citation
• “By default, Google’s crawlers follow the redirect, and Google systems use the redirect as a weak signal that the redirect target should be processed.” (traduction) : « Par défaut, les robots d’exploration de Google suivent la redirection et les systèmes Google utilisent la redirection comme un signal faible indiquant que la cible doit être traitée. » (formulation héritée de la ligne 302) Voir la citation
• “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 de la même manière, ils sont sémantiquement différents. Utilisez le code adapté à la redirection afin que d’autres clients (par exemple des liseuses ou d’autres moteurs de recherche) puissent en tirer parti. » Voir 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 pipeline d’indexation n’utilise pas la redirection comme signal indiquant que la cible doit être canonique. » — Google Search Central, Redirections et Google Search. Voir la citation

Spécification HTTP / MDN — garantie technique

• “The 307 (Temporary Redirect) status code indicates that the target resource resides temporarily under a different URI and the user agent MUST NOT change the request method if it performs an automatic redirection to that URI.” (traduction) : « Le code d’état 307 (Temporary Redirect) indique que la ressource cible se trouve temporairement sous une URI différente et que l’agent utilisateur NE DOIT PAS modifier la méthode de la requête s’il effectue une redirection automatique vers cette URI. » — RFC 9110, §15.4.8. Lire la section
• “For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the 307 (Temporary Redirect) status code can be used instead.” (traduction) : « Pour des raisons historiques, un agent utilisateur PEUT modifier la méthode de POST en GET pour la requête suivante. Si ce comportement n’est pas souhaité, le code d’état 307 (Temporary Redirect) peut être utilisé à la place. » — RFC 9110, §15.4.3 (section 302). Lire la section
• “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… 307 and 302 responses are identical when the request method is GET.” (traduction) : « La différence entre 307 et 302 est que 307 garantit que le client ne modifiera ni la méthode ni le corps de la requête lors de la redirection… Les réponses 307 et 302 sont identiques lorsque la méthode est GET. » — MDN, 307 Temporary Redirect. Voir la citation

John Mueller, Google — SEO et conservation de la méthode

• “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) : « Je pense que, pour le SEO, cela ne fait pas vraiment de différence. C’est plutôt : je ne sais pas… 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 Search. » — émission Search Off the Record, épisode 51, « Parlons des redirections » (17 novembre 2022). Transcript PDF
• “And with 307, 308, it also forwards POST requests” (traduction) : « Et avec 307 et 308, les requêtes POST sont également transmises » (par opposition aux 301/302, qui transmettent des requêtes GET). — Même épisode.

John Mueller, Google — l’« artefact 307 » HSTS

• “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… the 307 isn’t actually a redirect at all, it’s just a placeholder.” (traduction) : « Votre serveur ne renvoie pas une 307 ; Chrome vous l’affiche ainsi pour expliquer qu’il effectue la redirection pour vous… la 307 n’est en réalité pas une redirection, c’est seulement un espace réservé. » — John Mueller, HTTPS & HSTS: 301, 302, or 307? (johnmu.com, à l’origine Google+, juin 2016). Voir la citation
• « En bref, Googlebot n’interagit pas avec elles ; les redirections 307 ne sont généralement pas de vraies redirections. » — John Mueller, Ask Google Webmasters (octobre 2020), via Search Engine Journal. Voir la citation

Zineb Ait Bahajji, Google — HSTS, 2015 (citation relayée)

• “With HSTS implemented, Googlebot sees a 301 redirect (try it with Fetch as Google). The 307 is just an ‘internal redirect’.” (traduction) : « Avec HSTS, Googlebot voit une redirection 301 (essayez avec Fetch as Google). La 307 n’est qu’une “redirection interne”. » — Zineb Ait Bahajji (Google), via Twitter, rapporté par Search Engine Roundtable (décembre 2015). Voir la citation

Quelle 307 êtes-vous réellement en train d’observer ?

Presque toutes les questions sur les 307 se résument à deux situations totalement différentes. Suivez le chemin.

Mythes et erreurs à éviter

« Une 307 ne transmet pas les signaux de liens comme une 302. » Faux si l’on veut dire qu’une 307 serait « pire qu’une 302 » — et cette idée circule sur de nombreux blogs SEO. La documentation Google traite les 307 et 302 de la même manière : les deux sont des redirections temporaires, des « weak signal » (traduction) : « signaux faibles », qui ne rendent pas la cible canonique, et la documentation Google sur les codes d’état HTTP dit explicitement que la 307 est « Equivalent to 302 ». Rien ne justifie de prétendre qu’une 307 transmettrait moins qu’une 302. Le point de Google est plutôt que les redirections temporaires, en général, ne sont pas destinées à consolider les signaux de classement sur la cible comme le fait une redirection permanente. Ne laissez donc pas une affirmation sur une « rétention de popularité propre aux 307 » vous pousser à changer vos règles sans raison.

« Une 307 dans mon onglet Network signifie que mon serveur est mal configuré. » Souvent faux. Si le HSTS est activé et que le navigateur a déjà reçu l’en-tête Strict-Transport-Security, il affiche une mise à niveau http→https comme une 307 pour expliquer son propre comportement ; le serveur ne l’a jamais renvoyée (le corps de 0 octet le révèle). Une nouvelle session privée affiche généralement le véritable code, sauf pour les domaines présents dans la liste HSTS préchargée du navigateur. Pour ces domaines, utilisez un vérificateur de redirections ou curl (sans HSTS configuré) avant de chercher une mauvaise configuration qui n’existe peut-être pas.

« Googlebot voit la même 307 que mon navigateur pour un site HSTS. » Pas exactement. Des représentants de Google ont dit que Googlebot voit soit une 301 (Zineb, 2015), soit qu’il n’interagit pas du tout avec le mécanisme 307/HSTS (Mueller, 2020). Dans les deux cas, il ne voit pas la « 307 » affichée à l’humain. Une vraie 301 côté serveur reste nécessaire pour http→https si la découverte de ce chemin par les robots compte.

« 303 et 307 sont pratiquement interchangeables. » Elles sont opposées sur l’axe essentiel. Une 303 bascule toujours la méthode vers GET (le schéma Post/Redirect/Get) ; une 307 garantit que la méthode ne change pas. Elles sont faciles à confondre uniquement parce qu’elles appartiennent toutes deux à la catégorie « temporaire » avec la 302.

« Remplacez toutes vos redirections temporaires par des 307 pour gagner des positions. » Il n’y a aucun bonus. La seule raison valable de préférer 307 à 302 est la conservation effective de la méthode et du corps (ou une volonté générale de pérenniser ce comportement). Transformer toutes les 302 ne vous apporte rien et peut créer des erreurs.

« Les 302 transforment toujours POST en GET, donc une 302 est fondamentalement inutilisable pour les formulaires. » C’est exagéré. La conversion POST→GET posait un vrai problème avec certains anciens clients incohérents — c’est précisément pourquoi la 307 existe comme option garantie — mais les navigateurs modernes sont beaucoup plus cohérents. La 307 supprime l’ambiguïté par la spécification au lieu de dépendre du comportement actuel du client ; cela ne signifie pas que la 302 est « cassée ».

Voir le vrai code d’état (pas l’artefact HSTS)

Une fois le HSTS mis en cache, le navigateur masque une vraie 301 ou 302 derrière une 307 fantôme. curl n’applique pas le HSTS par défaut : une invocation simple parle directement au serveur et montre la réalité. Ne l’exécutez simplement pas avec un fichier de cache --hsts configuré, sinon vous réintroduisez la réécriture côté client que vous cherchez à écarter.

Suivre toute la chaîne de redirections, uniquement avec les en-têtes

# -s silent, -I headers-only, -L follow redirects, cap the hops
curl -sIL --max-redirs 10 http://example.com/old-page 2>&1 \
  | grep -Ei '^(HTTP/|location:)'
# Each "HTTP/…" line is one hop's real status code; each "location:" is where it points.
# An HSTS "307" never appears here — it's browser-only.

Vérifier le code d’état d’une URL sans suivre la redirection

curl -s -o /dev/null -w "%{http_code}\n" http://example.com/old-page

Console Chrome DevTools — repérer une 307 fantôme

Collez ce code dans l’onglet Console. Une vraie redirection serveur expose un indicateur redirected et une URL résolue ; la mise à niveau HSTS intervient avant même que la requête ne quitte le navigateur.

// Fetch and report what the network actually did.
fetch("http://example.com/old-page", { redirect: "manual" })
  .then(r => console.log("type:", r.type, "status:", r.status, "url:", r.url))
  .catch(e => console.log("blocked before request (often HSTS upgrade):", e.message));

Vous pouvez aussi lire directement l’enregistrement HSTS de Chrome à chrome://net-internals/#hsts — interrogez un domaine pour voir si static_upgrade_mode/dynamic_upgrade_mode impose https (c’est ce qui produit la 307 affichée dans l’onglet Network).

Bookmarklet — aperçu rapide des en-têtes de l’onglet courant

Faites glisser un favori contenant cette URL, puis cliquez dessus sur n’importe quelle page pour consigner dans la Console l’état de l’URL et son état de redirection :

javascript:(function(){fetch(location.href,{redirect:"manual"}).then(function(r){console.log("[status]",r.status,"[type]",r.type,"[redirected]",r.redirected,"[url]",r.url);}).catch(function(e){console.log("[error]",e.message);});})();

Remarque : fetch() dans un navigateur ne peut pas lire les corps de redirections opaques interorigines ; pour suivre plusieurs sauts de manière fiable, la commande curl -sIL ci-dessus reste la référence.

Renvoyer une vraie 307

L’intérêt de renvoyer une 307 (plutôt que de laisser un framework l’utiliser par défaut) est de garantir la conservation de la méthode et du corps. Voici quelques moyens courants de l’expliciter.

Apache (.htaccess)

# mod_rewrite with an explicit 307 (R=307). Preserves POST body.
RewriteEngine On
RewriteRule ^old-endpoint$ https://example.com/new-endpoint [R=307,L]

nginx

# 307 keeps the method; 302 would risk POST→GET on older clients.
location = /old-endpoint {
    return 307 https://example.com/new-endpoint;
}

Node / Express

app.post("/old-endpoint", (req, res) => {
  // res.redirect defaults to 302; pass 307 to preserve the POST + body.
  res.redirect(307, "https://example.com/new-endpoint");
});

Next.js (App Router) — 307 est la valeur par défaut, vous n’écrirez donc souvent aucun code :

import { redirect } from "next/navigation";
// redirect() returns a 307 by default (303 inside a Server Action),
// preserving the request as a POST. Use permanentRedirect() for a 308.
export default function Page() {
  redirect("/new-endpoint");
}

À quoi ressemble une réponse 307 brute ?

HTTP/1.1 307 Temporary Redirect
Location: https://example.com/new-endpoint
Content-Length: 0

À quoi ressemble l’« artefact 307 » HSTS (côté navigateur uniquement) ?

La même ligne d’état apparaît dans les outils de développement, mais les indices sont là : elle vient du navigateur et non du serveur, et son corps fait 0 octet :

HTTP/1.1 307 Internal Redirect
Location: https://example.com/old-page
Non-Authoritative-Reason: HSTS

Si vous voyez Non-Authoritative-Reason: HSTS (Chrome) ou une « 307 » de 0 octet qui disparaît lors d’un test avec un client qui n’applique pas le HSTS, c’est l’artefact — pas une redirection envoyée par votre serveur. Le nom exact de l’en-tête et l’étiquette affichée dans DevTools sont des détails d’implémentation propres à Chrome, pas des garanties de la spécification HTTP ou HSTS : considérez-les comme des exemples, pas comme une base d’automatisation valable pour tous les navigateurs ou toutes les versions.

La méthode, la durée et la source du framework

J’évalue une 307 sur trois axes avant de la modifier :

1. Méthode : la destination doit-elle recevoir la méthode et le corps d’origine ? Si oui, la 307 est la redirection temporaire qui conserve les deux. Une simple page à page en GET n’a généralement pas besoin de cette propriété.
2. Durée : le déplacement est-il réellement temporaire ? Ne gardez la 307 que tant que l’URL d’origine doit revenir. Un déplacement permanent nécessite une décision de redirection permanente, pas un état temporaire laissé indéfiniment.
3. Source : la 307 a-t-elle été envoyée par le serveur, choisie par un framework ou synthétisée par le navigateur lors d’une mise à niveau HSTS interne ? Une « Internal Redirect » de DevTools n’est pas une règle d’origine à réécrire.

Outils pour distinguer les redirections réelles des redirections fantômes

• Redirect Checker : voir l’état observable côté serveur, la destination et chaque saut sans dépendre de l’état HSTS d’un navigateur.
• Redirect Chain Mapper : utiliser la vue par saut lorsqu’une 307 fait partie d’un chemin de redirections plus long.
• HTTP Header Checker : inspecter Location et Strict-Transport-Security et comparer les indices de l’edge et de l’origine.
• curl : exécuter curl -I http://example.com/path en dehors de l’affichage HSTS interne du navigateur. Ne tester la conservation d’un POST que sur un endpoint sûr que vous contrôlez.
• Outils de développement du navigateur : vérifier si l’entrée indique « Internal Redirect » et un transfert de zéro octet, ce qui pointe vers une mise à niveau HSTS générée par le navigateur.

Valider une 307 après le déploiement

Test du statut et de la destination

Test à exécuter : vérifier la source avec le Redirect Checker ou curl -I. Résultat attendu : une 307 avec la Location prévue. Interprétation d’un échec : une autre couche a modifié la règle ou la cible. Fenêtre de surveillance : immédiate. Déclencheur de retour arrière : boucle, destination cassée ou nom d’hôte inattendu.

Test de conservation de la méthode

Test à exécuter : envoyer un POST sans danger vers une route de test contrôlée et inspecter ce que reçoit la destination. Résultat attendu : la destination reçoit le POST avec le corps d’origine. Interprétation d’un échec : un intermédiaire a transformé la méthode ou renvoyé un autre code. Fenêtre de surveillance : immédiate. Déclencheur de retour arrière : un formulaire, un webhook ou un paiement perd sa méthode ou son corps.

Test de séparation HSTS

Test à exécuter : comparer DevTools (ou une nouvelle session privée) à une requête curl -I sans cache HSTS configuré. Résultat attendu : une « Internal Redirect » du navigateur est distinguable de la réponse réelle du serveur, et HTTP possède toujours une redirection côté serveur. Interprétation d’un échec : le HSTS masque une règle d’origine manquante — notez qu’une session privée seule ne suffit pas pour les domaines de la liste HSTS préchargée du navigateur, puisque cet état est indépendant de l’historique de navigation. Déclencheur de retour arrière : la modification de l’origine supprime la redirection HTTP→HTTPS fonctionnelle.

Testez-vous : redirection temporaire 307

Cinq questions rapides sur la 307, son traitement par Google et l’artefact HSTS. Choisissez une réponse à chaque fois, puis vérifiez.

Des ressources qui valent le détour

Mes articles associés

• 11 types de redirections et leur impact SEO — l’article d’où viennent la définition de la 307, la réserve HSTS et mon ordre de préférence (307 / 302 / 303 en premier).
• Codes d’état HTTP et leur impact SEO — l’article qui présente les deux entrées distinctes de la 307 : la redirection temporaire et la politique HSTS.
• Guide du débutant sur le SEO technique — la place des redirections dans une vue d’ensemble du SEO technique.

Mes présentations

• How Search Works (SlideShare) — mon explication de l’exploration, du rendu, de l’indexation et du classement, avec le traitement des redirections. (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 %. »)

Dans le secteur

• John Mueller — HTTPS et HSTS : 301, 302 ou 307 ? — l’explication de première main la plus claire de l’« artefact 307 » HSTS (« your server’s not returning a 307 » (traduction) : « votre serveur ne renvoie pas une 307 »).
• Épisode 51 — « Parlons des redirections » (PDF de la transcription) — Mueller et Splitt expliquent pourquoi existent les 307/308 et pourquoi « for SEO, it doesn’t really matter » (traduction) : « pour le SEO, cela ne fait pas de différence ».
• Google sur les redirections 307/HSTS (Search Engine Journal) — compte rendu de la vidéo de Mueller : « 307 redirects are generally not real redirects » (traduction) : « les redirections 307 ne sont généralement pas de vraies redirections ».
• Googlebot traite-t-il les redirections 307 comme des 301 ? (Search Engine Roundtable) — déclaration de 2015 de Zineb Ait Bahajji sur ce que voit Googlebot avec HSTS.
• MDN — Redirection temporaire 307 — référence technique de référence sur la conservation de la méthode et du corps.
• Guide SEO de l’exploration des redirections HSTS et 307 (Screaming Frog) — meilleur traitement de la configuration des robots face aux 307 dues au HSTS.
• Next.js — référence de redirect() — pourquoi un framework majeur utilise 307 par défaut pour les redirections qui ne sont pas des GET.

Journal des modifications