Redirection 302

TL;DR — Une redirection 302 envoie les visiteurs d’une URL vers une autre temporairement. Elle indique aux moteurs de recherche : « ce déplacement n’est pas permanent — gardez l’URL d’origine dans vos résultats ». Utilisez-la lorsque vous voulez réellement dire temporaire (test A/B, page de vente, avis de maintenance). Utilisez plutôt une 301 lorsque vous déplacez une page définitivement.

Qu’est-ce qu’une redirection 302 ?

Une redirection est une instruction qui envoie vers une autre URL toute personne qui en demande une. Lorsqu’un serveur répond à une requête, il inclut un code d’état HTTP — un nombre à trois chiffres qui indique ce qui s’est passé. Une 302 est l’un des codes de redirection. Son nom officiel est « 302 Found » et toute sa personnalité tient en un mot : temporaire. Evidence for this claim RFC 9110 defines 302 Found as a temporary move to another URI and notes that user agents may change POST to GET when following it. Scope: HTTP semantics for 302 responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.3 — 302 Found

Cette dimension temporaire est le point essentiel. Une 302 dit : cette page a été déplacée pour l’instant, mais l’URL d’origine reviendra. Les moteurs de recherche sont donc censés conserver l’URL d’origine dans leurs résultats et traiter la destination comme un relais, pas comme un remplacement.

Comparez-la à sa sœur permanente, la redirection 301, qui dit : « ce déplacement est définitif — indexez plutôt la nouvelle URL ». L’expérience du visiteur est la même (les deux l’envoient vers la nouvelle page), mais le message adressé aux moteurs de recherche est opposé.

Quand l’utiliser réellement

Une 302 est le bon outil lorsque le déplacement est véritablement de courte durée :

• Vous réalisez un test A/B et envoyez certains visiteurs vers une variante de la page.
• Vous avez une page de vente ou de promotion temporaire et vous reviendrez ensuite à la page précédente.
• Une page est momentanément indisponible pour maintenance et vous voulez afficher un message « retour prochainement » sans abandonner la place de l’URL réelle dans les résultats.
• Vous orientez les visiteurs selon leur emplacement ou leur appareil (par exemple vers une version destinée à un pays ou à une langue), et la destination « correcte » change selon le visiteur.

Dans tous ces cas, vous voulez que l’URL d’origine reste dans les résultats de Google — c’est exactement ce que demande une 302.

L’erreur que la plupart des gens commettent

Pendant des années, les référenceurs ont traité les 302 comme radioactives — « elles ne transmettent aucune valeur de lien, ne les utilisez jamais ». C’est un mythe. Une 302 transmet des signaux de liens ; ce qui la distingue d’une 301, c’est uniquement l’URL que les moteurs de recherche préfèrent afficher. John Mueller, chez Google, a écrit que les 302 “have a bad reputation among SEOs, which I think is incorrect.” (traduction) « ont mauvaise réputation auprès des référenceurs, ce que je considère comme incorrect. »

La véritable erreur n’est pas d’utiliser une 302 : c’est de l’utiliser pour un déplacement permanent. Si vous retirez définitivement une page mais la redirigez avec une 302, vous dites à Google « gardez l’ancienne URL indexée » ; la nouvelle page que vous voulez réellement voir se classer risque de ne pas prendre le relais pendant une période longue et imprévisible. Pour un déplacement définitif, utilisez une 301.

Vous voulez comprendre les mécanismes précis — le vocabulaire de Google sur le signal « faible » et le signal « fort », pourquoi une 302 maintenue longtemps peut basculer et se comporter comme une 301, et comment Bing la traite ? Passez à l’onglet Advanced.

TL;DR — Une 302 (« Found ») est une redirection temporaire. Le cadrage précis de Google comporte deux étapes, et non une seule : l’infrastructure d’exploration la qualifie de signal faible indiquant que la cible de la redirection doit être traitée, contre le signal fort d’une 301 — et, séparément, le pipeline d’indexation de Search dit qu’il ne considère pas une redirection temporaire comme un signal indiquant que la cible doit être canonique (la cible peut tout de même être indexée grâce à d’autres signaux). Deux mécanismes sont constamment confondus : le transfert des signaux de liens/PageRank (Mueller et Illyes ont déclaré qu’il n’est pas nul sur une 302, même s’il s’agit de leurs déclarations publiques et non d’une règle universelle publiée formellement) et la préférence de canonisation/indexation (c’est elle qui diffère réellement — une 302 dit à Google de conserver l’URL source indexée). Maintenue assez longtemps, une 302 peut basculer — phénomène observé par des praticiens, pas mécanisme documenté, sans calendrier publié. Google recommande la 302 plutôt que la 301 pour les tests A/B. La seule véritable erreur est d’utiliser une 302 pour un déplacement permanent ; ne construisez jamais non plus la destination d’une redirection à partir d’une entrée utilisateur non contrôlée.

De « Moved Temporarily » à « Found » — bref historique

La 302 est née dans l’ambiguïté. En HTTP/1.0, elle s’appelait « Moved Temporarily », et la spécification indiquait que les clients devaient réutiliser la méthode de requête d’origine lorsqu’ils la suivaient. En pratique, les navigateurs ne le faisaient pas : beaucoup transformaient silencieusement une requête POST en GET lors d’une redirection, contrairement à la spécification. HTTP/1.1 a reconnu cette réalité en renommant la 302 « Found » et en ajoutant deux alternatives non ambiguës : 303 (See Other), qui passe toujours à GET, et 307 (Temporary Redirect), qui ne change jamais la méthode. La spécification actuelle, la RFC 9110 (2022), précise encore que les clients peuvent transformer POST en GET avec une 302 — c’est exactement pourquoi la 307 existe dans les cas où ils ne doivent pas le faire. Pour les redirections de pages ordinaires fondées sur GET (le cas d’usage SEO), les 302 et 307 se comportent de la même manière pour les moteurs de recherche ; la distinction concernant la conservation de la méthode ne compte que pour les envois de formulaires et les appels d’API. Evidence for this claim RFC 9110 defines 302 Found as a temporary move to another URI and notes that user agents may change POST to GET when following it. Scope: HTTP semantics for 302 responses. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.4.3 — 302 Found

Pour la recherche, Google regroupe 302 (found), 303 (see other) et 307 (temporary redirect) sous la catégorie « Temporary », par opposition à 301 et 308, classées « Permanent ».

La décision en bref, si vous choisissez entre ces codes :

• 302 — le client qui la suit peut transformer POST en GET (RFC 9110). Elle convient à une redirection de page simple fondée sur GET ; évitez-la si vous ne pouvez pas accepter le changement de méthode.
• 307 — elle ne change jamais la méthode et ne renvoie pas une requête différente. Utilisez-la lorsqu’un envoi de formulaire ou un appel d’API doit être rejoué exactement tel qu’il a été envoyé.
• 303 — elle pointe délibérément vers une ressource différente et non équivalente, normalement récupérée avec GET/HEAD — le cas classique d’une « redirection après un POST vers une page de confirmation », et non un substitut équivalent à la requête d’origine.
• Mise en cache — une 302 n’est pas considérée comme pouvant être mise en cache heuristiquement simplement à cause de son code d’état (RFC 9111) ; elle n’est stockée et réutilisée que si vous définissez explicitement sa fraîcheur ou des directives de cache. Ne supposez pas qu’un CDN ou un navigateur considérera par défaut une 302 dépourvue de directives comme pouvant être mise en cache.

Signal faible ou signal fort — les mots précis de Google

Oubliez le folklore et lisez les termes employés par Google. Dans sa documentation sur l’infrastructure d’exploration, Google indique qu’une 302 est un signal faible :

“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 de Google utilisent celle-ci comme un signal faible indiquant que la cible de la redirection doit être traitée. »

La ligne consacrée à la 301 dans le même tableau est identique, à un mot près — strong :

“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 celle-ci comme un signal fort indiquant que la cible de la redirection doit être traitée. »

« Faible » ne signifie pas « nul » — mais il faut aussi être précis sur ce qui est faible. Deux systèmes Google différents parlent de deux étapes différentes ; il ne s’agit pas d’un continuum unique :

• L’infrastructure d’exploration (la citation sur le « signal faible » ci-dessus) concerne le fait que la cible de la redirection soit traitée — autrement dit, le robot d’exploration de Google prend-il la peine de récupérer et d’examiner la destination ?
• Le pipeline d’indexation de Search est une étape distincte et ultérieure, qui énonce directement sa propre règle : “Googlebot follows the redirect, but the indexing pipeline doesn’t use the redirect as a signal that the redirect target should be canonical. The target page might still be indexed if other canonicalization signals are present.” (traduction) « Googlebot suit bien la redirection, mais celle-ci ne suffit pas au système d’indexation pour choisir la destination comme URL canonique. D’autres signaux de canonisation peuvent néanmoins conduire à indexer cette page cible. » Evidence for this claim Google follows a 302 temporary redirect but does not use it as a signal that the destination should become canonical; Google recommends 302 rather than 301 for temporary site tests. Scope: Google Search handling of temporary redirects and A/B tests. Confidence: high · Verified: 2026-07-14 Google: Redirects and Google Search Google: Website testing

À les lire ensemble, une 302 donne à Google une faible incitation à aller examiner la cible (exploration), mais le pipeline d’indexation de Search ne traite pas cette même redirection comme un vote pour rendre la cible canonique (indexation). La cible peut tout de même finir indexée et canonique — grâce à d’autres signaux, et non à la 302 elle-même. Ne réduisez pas ces deux notions à « une 302 est un vote faible pour rendre la cible canonique » : ce n’est pas ce que dit l’un ou l’autre document ; ils décrivent des périmètres différents.

Deux mécanismes, pas un seul

C’est ici que la plupart des contenus concurrents mélangent les choses ; gardez donc ces notions séparées :

1. Le transfert des signaux de liens/PageRank n’est pas nul sur une 302. Gary Illyes a déclaré en 2016 que Google n’appliquait plus de dilution du PageRank à travers les redirections 301, 302 ou d’autres redirections 30x (abandonnant le vieux folklore de la « perte d’environ 15 % par saut »), et Mueller a fait le même point spécifiquement à propos des 302 : “do work the same as normal redirects… It’s not that they don’t pass any PageRank or anything like that.” (traduction) « fonctionnent comme les redirections normales… ce n’est pas qu’elles ne transmettent aucun PageRank ou quoi que ce soit de ce genre. » Considérez cela comme la déclaration publique de Google sur le sujet, et non comme une garantie universelle formellement publiée : la documentation primaire actuelle ne définit pas une règle exacte de transfert des signaux de liens pour chaque type de redirection dans chaque situation.
2. La préférence de canonisation/indexation est le mécanisme qui diffère réellement. Une 301 est un signal fort pour indexer la destination ; une 302 est un signal faible, et Google conserve donc par défaut l’indexation de la source.

« Une 302 transmet-elle du PageRank ? » et « une 302 change-t-elle l’URL qui se classe ? » sont deux questions différentes. La réponse à la première est oui ; à la seconde, « pas par défaut ». Les confondre est à l’origine du mythe « 302 = équité nulle ».

À ce sujet, lorsque vous redirigez une URL, Google suit les deux extrémités. “Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL). One of the URLs will be the canonical; which one, depends on signals such as whether the redirect was temporary or permanent. The other URL becomes an alternate name of the canonical URL.” (traduction) « Google conserve la trace de l’ancienne URL et de la destination. Il choisit l’une d’elles comme canonique selon plusieurs signaux, dont la nature temporaire ou permanente de la redirection ; l’autre devient alors un nom alternatif. » Pour une 302, la source reste canonique — pour l’instant.

Que se passe-t-il si une 302 reste en place trop longtemps — le « basculement »

Voici la partie qui surprend : une redirection temporaire qui n’est jamais supprimée peut cesser d’être traitée comme temporaire. Mueller : “if you have 302 redirects for the long run, we treat them exactly the same as 301 redirects anyway.” (traduction) « si vous avez des redirections 302 sur le long terme, nous les traitons de toute façon exactement comme des redirections 301. »

Pourquoi cela se produit-il ? Voici ma propre explication de travail, tirée de mon guide Ahrefs sur la canonisation — un modèle mental de praticien fondé sur le comportement observé, et non un mécanisme formellement publié par Google — imaginez une balance qui penche. Les redirections permanentes envoient les signaux vers l’avant, vers la nouvelle URL ; les redirections temporaires les envoient vers l’arrière, vers l’URL d’origine. Mais :

“If a temporary redirect is left in place long enough or the URL it’s redirected to already exists, it may be treated as a permanent redirect and send signals forward instead. It requires enough signals to flip the scale we saw earlier for canonicalization signals. As links build up, internal links are changed, sitemap URLs are updated, etc., more signals point to the new URL than the old URL, and the flip occurs.” (traduction) « Si une redirection temporaire reste en place assez longtemps, ou si l’URL vers laquelle elle redirige existe déjà, elle peut être traitée comme une redirection permanente et envoyer les signaux vers l’avant. Il faut suffisamment de signaux pour faire basculer la balance que nous avons vue plus tôt pour les signaux de canonisation. À mesure que les liens s’accumulent, que les liens internes sont modifiés, que les URL du sitemap sont mises à jour, etc., davantage de signaux pointent vers la nouvelle URL que vers l’ancienne, et le basculement se produit. »

Le point délicat est que personne ne sait combien de temps cela prend. Comme je l’ai écrit dans mon guide sur les redirections, “Nobody knows how long a 302 redirect has to exist before Google starts treating it as a 301 redirect. Usually, it’s a few weeks to a few months, but it can be days, weeks, or months.” (traduction) « Personne ne sait combien de temps une redirection 302 doit exister avant que Google commence à la traiter comme une redirection 301. Habituellement, cela prend de quelques semaines à quelques mois, mais cela peut être des jours, des semaines ou des mois. » Google peut agir plus tôt s’il pense que vous avez commis une erreur : “Only if Google thinks you used a 302 redirect by mistake for a permanent move does this not happen. In that case, it treats the redirect as a 301… In some circumstances, Google even appears to treat 302s as 301s from the get-go.” (traduction) « Cela ne se produit que si Google pense que vous avez utilisé par erreur une redirection 302 pour un déplacement permanent. Dans ce cas, il traite la redirection comme une 301… Dans certaines circonstances, Google semble même traiter les 302 comme des 301 dès le départ. » Ne citez pas un nombre de jours précis : il n’en existe pas de publié, et aucun chiffre que vous pourriez voir (y compris les « deux jours » qui circulent dans le folklore Bing) n’a été confirmé par Google.

Comment Bing traite une 302 — il observe le comportement, pas seulement l’en-tête

Bing arrive au même résultat par un chemin un peu différent, et l’a dit explicitement. Dans son explication ancienne des redirections, Bing décrit l’observation du schéma constaté d’une redirection au fil d’explorations répétées, plutôt que la confiance dans le seul code d’état : les redirections dont la destination change constamment sont davantage traitées comme des 302 même si elles sont étiquetées 301, tandis que celles qui pointent toujours au même endroit sont davantage traitées comme des 301 même si elles sont étiquetées 302 — le système de Bing commence à “think about them more like 301s as we continue to crawl them again and again.” (traduction) « les considérer davantage comme des 301 tandis que nous continuons à les explorer encore et encore. » C’est la même convergence que celle décrite par Google, obtenue indépendamment : avec un comportement suffisamment cohérent dans le temps, les deux moteurs font davantage confiance à ce que fait une redirection qu’à ce que son en-tête prétend.

Les anciennes recommandations de Bing insistaient aussi davantage que Google aujourd’hui sur l’usage parcimonieux des 302, en avertissant qu’une 302 mal utilisée peut laisser de la valeur bloquée sur les URL d’origine. La conclusion pratique est identique à celle de Google : faites correspondre le type de redirection à votre intention réelle.

Quand une 302 est le bon choix

Google ne se contente pas de tolérer les 302 — il les recommande pour un cas d’usage. Extrait de ses recommandations sur les tests A/B :

“If you’re running a test that redirects users from the original URL to a variation URL, use a 302 (temporary) redirect, not a 301 (permanent) redirect. This tells search engines that this redirect is temporary—it will only be in place as long as you’re running the experiment—and that they should keep the original URL in their index rather than replacing it with the target of the redirect (the test page). JavaScript-based redirects are also fine.” (traduction) « Si vous réalisez un test qui redirige les utilisateurs de l’URL d’origine vers une URL variante, utilisez une redirection 302 (temporaire), et non une redirection 301 (permanente). Cela indique aux moteurs de recherche que la redirection est temporaire — elle ne sera en place que pendant la durée de l’expérience — et qu’ils doivent conserver l’URL d’origine dans leur index au lieu de la remplacer par la cible de la redirection (la page de test). Les redirections fondées sur JavaScript conviennent également. »

Les cas d’usage légitimes (tous réellement temporaires) :

• Test A/B — c’est la recommandation explicite de Google ci-dessus. Mais ne le prolongez pas inutilement : Google avertit que “if we discover a site running an experiment for an unnecessarily long time, we may interpret this as an attempt to deceive search engines and take action accordingly.” (traduction) « si nous découvrons qu’un site mène une expérience pendant une durée inutilement longue, nous pouvons l’interpréter comme une tentative de tromper les moteurs de recherche et agir en conséquence ». Faites-le durer le temps nécessaire pour atteindre la significativité, puis retirez-le.
• Routage géographique, par appareil et par langue — lorsque la « bonne » destination dépend du visiteur et qu’aucune URL ne doit remplacer définitivement la source. Il ne suffit toutefois pas de choisir un code d’état : confirmez la destination reçue par Googlebot (il ne transmet généralement pas les signaux de lieu ou d’appareil d’un visiteur réel ; vérifiez donc ce que votre règle lui sert), si le routage s’appuie sur des cookies ou des en-têtes que le robot n’enverra pas, si les clés de cache et l’en-tête Vary séparent correctement les variantes (pour qu’un cache ne serve pas la page d’un pays à un autre), si un visiteur avec lecteur d’écran ou sans JavaScript peut tout de même atteindre le contenu et s’il peut contourner le routage automatique au lieu de rester bloqué dans une boucle de redirection. Associez-le à un hreflang correct sur les versions localisées — la redirection et hreflang doivent être cohérents, et non se contredire.
• Pages temporaires de maintenance ou d’indisponibilité de service — l’exemple donné par Google : “if a service your site offers is temporarily unavailable, you can set up a temporary redirect to send users to a page that explains what’s happening, without compromising the original URL in search results.” (traduction) « si un service proposé par votre site est temporairement indisponible, vous pouvez mettre en place une redirection temporaire vers une page qui explique ce qui se passe, sans compromettre l’URL d’origine dans les résultats de recherche ». Déterminez laquelle de ces deux situations vous concerne réellement. Si l’URL elle-même ne peut tout simplement pas être servie pour le moment (serveur dorsal hors service ou déploiement en cours), une réponse 503 Service Unavailable avec un en-tête Retry-After sur la même URL est souvent plus précise : elle dit « je ne peux pas satisfaire cette requête temporairement, réessayez plus tard », sans rediriger ailleurs. Utilisez une 302 lorsque vous orientez délibérément les visiteurs vers une URL différente et réellement utile, comme une page d’état ou une page « retour prochainement » plus détaillée, plutôt que de vous contenter de marquer l’originale comme indisponible.
• Promotions à durée limitée — envoyez les visiteurs vers une page de campagne pendant toute sa durée, puis revenez en arrière.
• Équilibrage de charge ou basculement — acheminez le trafic ailleurs lorsqu’une origine ou un centre de données est temporairement indisponible.

Consultez l’onglet Examples pour voir ces cas annotés côte à côte, et l’onglet Checklists pour une vérification préalable.

La seule véritable erreur

Utiliser une 302 lorsque vous voulez un déplacement permanent. Vous dites à Google de conserver l’ancienne URL indexée ; la nouvelle page que vous voulez voir se classer risque donc de ne pas prendre le relais pendant une durée indéfinie et imprévisible — un coût réel en visibilité perdue, pas un risque théorique. Si une page disparaît définitivement, utilisez une 301 (ou une 308). Parmi les erreurs connexes : mélanger de façon incohérente des 301 et des 302 dans une chaîne de redirections et — le problème qui concerne toute redirection — faire pointer accidentellement deux URL l’une vers l’autre, créant ainsi une boucle.

Mettre en œuvre une 302

C’est l’en-tête qui compte — la ligne d’état 302 Found accompagnée d’un champ Location. Voici l’exemple PHP de Google :

header('HTTP/1.1 302 Found');
header('Location: https://www.example.com/newurl');
exit();

Apache (.htaccess) — c’est l’indicateur R=302 qui la rend temporaire (un R=301 ou un R seul serait permanent par défaut) :

Redirect 302 /old-path https://www.example.com/newurl
# or with mod_rewrite:
RewriteRule ^old-path/?$ https://www.example.com/newurl [R=302,L]

nginx — redirect émet une 302 (permanent émettrait une 301) :

location = /old-path {
    return 302 https://www.example.com/newurl;
}

Quelle que soit la pile (extensions de redirection WordPress, règle CDN/edge ou gestionnaire au niveau de l’application), la règle est la même : les redirections côté serveur sont préférables et vous devez choisir délibérément le code temporaire — la plupart des outils utilisent 301 par défaut, si bien qu’une 302 est généralement un choix explicite.

Une note de sécurité qui concerne toute redirection, pas seulement les 302 : si la destination de votre en-tête Location est un jour construite à partir d’une entrée contrôlée par l’utilisateur (un paramètre de requête ?next= ou ?returnUrl=, par exemple), vous réunissez les ingrédients d’une redirection ouverte — un attaquant fabrique un lien sur votre domaine qui renvoie réellement les visiteurs vers un site malveillant. N’envoyez pas les visiteurs vers l’URL qui apparaît dans un paramètre de requête ; établissez une liste blanche des destinations réellement autorisées (un ensemble fixe de chemins ou d’origines sûrs et connus) et testez la façon dont votre logique gère les entrées encodées ou relatives au schéma (//evil.example, %2F%2Fevil.example et autres formes comparables) avant de lui faire confiance en production. Vérifiez la syntaxe exacte de chaque extrait pour la version actuelle de la plateforme avant de le déployer — ces exemples illustrent le principe, mais ne remplacent pas des tests sur votre propre serveur ou CDN.

Pour la version correspondant à un déplacement permanent et la comparaison complète, consultez dans cette collection les articles sur la redirection 301, 301 contre 302 et 302 contre 307.

Résumé par IA

Une synthèse de la version Advanced :

• Une 302 (« Found ») est une redirection temporaire (code d’état HTTP 302). Elle envoie les utilisateurs vers une nouvelle URL tout en signalant que l’URL d’origine doit rester dans les résultats de recherche.
• Le cadrage précis de Google se divise en deux étapes, et non en un continuum. L’infrastructure d’exploration qualifie une 302 de signal faible indiquant que la cible doit être traitée (explorée et examinée), contre le signal fort d’une 301. Séparément, le pipeline d’indexation de Search dit qu’il n’utilise pas une redirection temporaire comme signal indiquant que la cible doit être canonique — même si la cible peut être indexée grâce à d’autres signaux. Faible ≠ nul, et « traité » ≠ « rendu canonique ».
• 302 contre 303 contre 307, en bref : le client peut changer la méthode d’une 302 de POST à GET ; une 307 ne change jamais la méthode ; une 303 pointe volontairement vers une ressource différente et non équivalente. Aucune de ces redirections n’est considérée comme pouvant être mise en cache heuristiquement par défaut — la mise en cache exige des directives explicites.
• Le transfert des signaux de liens n’est pas nul sur une 302 — Mueller et Illyes l’ont tous deux déclaré — mais il s’agit de leur déclaration publique, et non d’une règle universelle de transfert formellement publiée pour chaque scénario de redirection. La préférence de canonisation/indexation est le mécanisme qui diffère réellement : une 301 pousse l’indexation vers la destination ; une 302 la maintient par défaut sur la source.
• Les 302 maintenues longtemps peuvent « basculer ». Il s’agit d’un phénomène observé par des praticiens (Mueller et ma propre expérience), pas d’un mécanisme documenté avec un calendrier publié — « jours, semaines ou mois », sans nombre fixe.
• Bing observe le comportement, pas seulement l’en-tête : les redirections qui se comportent de manière cohérente au fil d’explorations répétées sont reclassées quel que soit leur code d’état — la même convergence que celle décrite par Google.
• Google recommande la 302 (et non la 301) pour les tests A/B. Autres usages légitimes : routage géographique, par appareil ou par langue (vérifiez le traitement réel de Googlebot, les cookies, le comportement de Vary et du cache, l’accessibilité, et associez-le à hreflang), pages de maintenance temporaires (comparez avec une 503 et Retry-After lorsque la même URL ne peut simplement pas être servie), promotions à durée limitée et équilibrage de charge/basculement. Ne laissez pas un test A/B durer « une durée inutilement longue » — Google pourrait l’interpréter comme une pratique trompeuse.
• Sécurité : ne construisez jamais directement la destination Location à partir de données utilisateur — utilisez une liste blanche pour éviter les abus de redirection ouverte.
• La seule véritable erreur : utiliser une 302 pour un déplacement permanent — cela peut laisser l’ancienne URL se classer à la place de la nouvelle indéfiniment. Utilisez une 301 pour les déplacements définitifs.

Documentation officielle

Documentation primaire des moteurs de recherche et de la spécification HTTP.

Google

• Redirections et Google Search — le tableau des types de redirection (permanente ou temporaire), la recommandation de conserver l’ancienne URL dans les résultats de Search, le suivi des URL alternatives et l’exemple d’implémentation PHP.
• Comment les codes d’état HTTP influencent les robots de Google — le tableau des codes 3xx avec les formulations exactes « signal faible » (302) et « signal fort » (301).
• Bonnes pratiques de test A/B pour Search — la recommandation explicite de Google d’utiliser une 302 et non une 301 pour les tests, ainsi que l’avertissement contre une expérience maintenue pendant une « durée inutilement longue ».

Bing / Microsoft

• Gérer les redirections — 301, 302 et canonisation (Bing Webmaster Blog) — l’explication de Bing sur la distinction entre 301 et 302 et sa position selon laquelle il observe le comportement, pas seulement l’en-tête. (L’article en ligne est rendu par JavaScript ; le texte verbatim est conservé dans l’archive Wayback Machine.)

Spécification HTTP / référence

• MDN — 302 Found et 307 Temporary Redirect — la nuance de conservation de la méthode et la raison d’être des 303 et 307.
• RFC 9110 §15.4.3 (302 Found) — la spécification HTTP Semantics actuelle ; elle indique que les clients peuvent encore transformer POST en GET avec une 302.

Citations de la source

Déclarations documentées de Google et de Bing. Chaque lien vers une documentation de recherche est un lien profond qui mène directement au passage cité sur la page source.

Google — la distinction entre faible et fort (le socle de la précision)

• “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 de Google l’utilisent comme un signal faible indiquant que la cible de la redirection doit être traitée. » — pour une 302. Accéder à la citation
• “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 l’utilisent comme un signal fort indiquant que la cible de la redirection doit être traitée. » — la ligne comparative de la 301 dans le même tableau. 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. The target page might still be indexed if other canonicalization signals are present.” (traduction) « Googlebot suit la redirection, mais le pipeline d’indexation n’utilise pas la redirection comme signal indiquant que la cible doit être canonique. La page cible peut tout de même être indexée si d’autres signaux de canonisation sont présents. » Accéder à la citation

Google — quand utiliser une redirection temporaire

• “If you just want to send users to a different page temporarily, use a temporary redirect. This will also ensure that Google isn’t influenced by the redirect which may help keep the old URL in its Search results.” (traduction) « Si vous voulez simplement envoyer temporairement les utilisateurs vers une autre page, utilisez une redirection temporaire. Cela garantit également que Google ne sera pas influencé par la redirection, ce qui peut aider à conserver l’ancienne URL dans ses résultats de Search. » Accéder à la citation
• “When you redirect a URL, Google keeps track of both the redirect source (the old URL) and the redirect target (the new URL). One of the URLs will be the canonical; which one, depends on signals such as whether the redirect was temporary or permanent.” (traduction) « Lorsque vous redirigez une URL, Google suit à la fois la source de la redirection (l’ancienne URL) et la cible de la redirection (la nouvelle URL). L’une des URL sera canonique ; laquelle dépend de signaux tels que le caractère temporaire ou permanent de la redirection. » Accéder à la citation

Google — test A/B (302 recommandée, mais sans la prolonger)

• “If you’re running a test that redirects users from the original URL to a variation URL, use a 302 (temporary) redirect, not a 301 (permanent) redirect.” (traduction) « Si vous réalisez un test qui redirige les utilisateurs de l’URL d’origine vers une URL variante, utilisez une redirection 302 (temporaire), et non une redirection 301 (permanente). » Accéder à la citation
• “If we discover a site running an experiment for an unnecessarily long time, we may interpret this as an attempt to deceive search engines and take action accordingly.” (traduction) « Si nous découvrons qu’un site mène une expérience pendant une durée inutilement longue, nous pouvons l’interpréter comme une tentative de tromper les moteurs de recherche et agir en conséquence. » Accéder à la citation

John Mueller, Google — dissiper le mythe « les 302 sont mauvaises »

• “302 redirects have a bad reputation among SEOs, which I think is incorrect. Because they do work the same as normal redirects as well. It’s not that they don’t pass any PageRank or anything like that. And if you have 302 redirects for the long run, we treat them exactly the same as 301 redirects anyway.” (traduction) « Les redirections 302 ont mauvaise réputation auprès des référenceurs, ce que je considère comme incorrect. Elles fonctionnent aussi comme les redirections normales. Ce n’est pas qu’elles ne transmettent aucun PageRank ou quoi que ce soit de ce genre. Et si vous avez des redirections 302 sur le long terme, nous les traitons de toute façon exactement comme des redirections 301. » Lire la transcription

Bing / Microsoft — observer le comportement, pas seulement l’en-tête

• Bing a indiqué qu’il reclassait les redirections selon le schéma observé au fil d’explorations répétées : les 301 dont la destination change sans cesse sont considérées davantage comme des 302, et les 302 qui pointent toujours au même endroit sont traitées davantage comme des 301 « tandis que nous continuons à les explorer encore et encore ». Source archivée

301 ou 302 ? — liste de vérification préalable

Effectuez cette vérification avant de publier une redirection, afin de vous assurer que le code correspond à votre intention :

• Le déplacement est-il permanent ? Si l’ancienne URL ne reviendra jamais → 301 (ou 308), et non une 302.
• Est-il réellement temporaire ? (test A/B, promotion, maintenance, routage géographique ou par appareil, basculement) → la 302 convient.
• Avez-vous défini le code explicitement ? La plupart des outils utilisent 301 par défaut — confirmez que la 302 est intentionnelle, et inversement.
• S’agit-il d’un test A/B ? Utilisez une 302 (recommandation de Google) et prévoyez de la retirer une fois le test significatif — ne le laissez pas fonctionner « pendant une durée inutilement longue ».
• Panne temporaire sur la même URL ? Envisagez plutôt une 503 ; utilisez une 302 lorsque vous acheminez les visiteurs vers une page explicative différente.
• Aucune chaîne de redirections ne mélange de façon incohérente les 301 et les 302 — redirigez directement vers la destination finale.
• Aucune boucle — vérifiez que deux URL ne se redirigent pas l’une vers l’autre.
• Si une 302 « temporaire » est devenue discrètement permanente, remplacez-la par une 301 afin que le signal corresponde à la réalité (et ne comptez pas sur le « basculement » de Google, dont le délai est indéfini).
• Vérifiez le code d’état réel renvoyé (curl -I, outils de développement du navigateur ou outil de vérification des redirections) — l’étiquette d’une extension de redirection ne prouve pas celle de l’en-tête envoyé.

Cas d’usage légitimes d’une 302, avec annotations

Cinq situations où une 302 est le bon choix — et pourquoi le signal « temporaire » compte dans chacune.

1. Test A/B

GET /pricing/           → 302 → /pricing/variant-b/

Vous envoyez une partie du trafic vers une variante pour la mesurer. Vous voulez que /pricing/ — l’originale — reste indexée et conserve son classement ; la variante est destinée à disparaître. C’est le cas pour lequel Google recommande explicitement une 302. Retirez-la dès que le test se termine ; un test laissé indéfiniment peut sembler trompeur.

2. Vente ou promotion temporaire

GET /shoes/             → 302 → /promo/summer-sale-shoes/

Pendant la campagne, les visiteurs arrivent sur la page de vente — mais /shoes/ est votre URL pérenne et doit reprendre sa place dès la fin de la promotion. Une 301 serait une erreur : vous transféreriez le classement de /shoes/ vers une page que vous êtes sur le point de supprimer.

3. Maintenance ou indisponibilité temporaire

GET /booking/           → 302 → /status/booking-back-soon/

Un service est brièvement indisponible et vous acheminez les utilisateurs vers une page explicative. C’est un cas d’usage donné par Google. L’URL d’origine conserve sa place dans les résultats pendant que vous corrigez le problème. (Si la même URL est simplement hors ligne plutôt que redirigée ailleurs, une réponse 503 Service Unavailable est souvent un signal plus propre.)

4. Routage géographique, par appareil ou par langue

GET /               → 302 → /us/     (visitor in the US)
GET /               → 302 → /de/     (visitor in Germany)

La destination dépend de la personne qui fait la demande ; aucune cible unique ne doit donc remplacer définitivement l’URL source. Une redirection temporaire convient puisque la « bonne » réponse change selon la requête. (Associez-la à un hreflang correct pour les versions localisées.)

5. Équilibrage de charge ou basculement

GET /app/               → 302 → /app-eu-west/     (primary origin down)

Lorsqu’une origine ou un centre de données est temporairement indisponible, le trafic bascule ailleurs — mais ce réacheminement doit prendre fin lorsque l’origine principale revient. Il est temporaire par définition.

L’anti-pattern, par contraste :

GET /old-product/       → 302 → /new-product/     ❌ (permanent move!)

Il s’agit d’un retrait permanent déguisé en situation temporaire. Google peut alors conserver /old-product/ indexée et classée au lieu de consolider sur /new-product/, pendant une période imprévisible. Il faut utiliser une 301.

Deux mécanismes, pas un seul

Utilisez ce cadre pour éviter que les mythes sur les redirections ne mélangent des questions distinctes.

Appliquez-le en trois étapes :

1. Énoncez l’intention. Une 302 indique que le déplacement est temporaire et que l’URL d’origine doit rester l’adresse stable.
2. Examinez les signaux de canonisation. Les liens internes, les entrées de sitemap, les balises canoniques, les liens externes et la durée de la redirection peuvent renforcer la source ou faire gagner la cible.
3. Interprétez correctement une 302 maintenue longtemps. Si Google commence à la traiter comme un déplacement permanent, la redirection ne s’est pas soudainement mise à « transmettre de la valeur ». C’est l’équilibre des signaux de canonisation qui a changé l’URL propriétaire du regroupement.

La question diagnostique n’est pas « une 302 transmet-elle du PageRank ? », mais « quelle URL doit être canonique, et la redirection ainsi que nos autres signaux disent-ils la même chose ? »

Outils pour vérifier les redirections temporaires

Les outils gratuits de Patrick

• Redirect Checker — vérifiez que le premier saut renvoie réellement 302, examinez le champ Location et repérez une chaîne qui mélange des codes temporaires et permanents.
• Bulk HTTP Status Code Checker — contrôlez jusqu’à 500 URL de test, de promotion, de routage ou de maintenance et exportez toute réponse qui ne correspond pas au comportement temporaire prévu.

Vérifier le comportement canonique et la durée

• Inspection d’URL de Google Search Console — comparez les URL source et variante et vérifiez laquelle Google a choisie comme canonique.
• Journaux du serveur/CDN — prouvez que la redirection est limitée au public et à la période voulus, et que Googlebot ne reçoit pas accidentellement un chemin différent.
• Journaux et configuration de la plateforme de test — consignez le début et la fin du test, la répartition et la règle de redirection afin qu’une réponse temporaire ne devienne pas une infrastructure oubliée.

Prouver qu’une redirection temporaire est restée temporaire

Test 1 — L’expérience émet une véritable 302

• Test à exécuter — Vérifiez l’URL d’origine avec Redirect Checker pendant que vous êtes affecté à la variante redirigée ; répétez depuis une session vierge si l’affectation repose sur un cookie. Effectuez une véritable requête GET, et pas seulement une requête HEAD — le serveur, le CDN ou l’application peuvent traiter ces deux méthodes différemment, si bien qu’un contrôle HEAD seul ne prouve pas ce que reçoit un visiteur réel (ou Googlebot). Capturez la ligne d’état brute, la valeur exacte de Location et les éventuels en-têtes de contrôle du cache, et pas seulement le fait que « la redirection a eu lieu ».
• Résultat attendu — La source renvoie 302 avec la variante voulue dans Location, et la variante se résout sans boucle ni saut supplémentaire sans rapport.
• Interprétation d’un échec — 301/308 envoie un signal permanent ; un 200 suivi d’une navigation indique une redirection côté client plutôt que la réponse serveur prévue ; si HEAD et GET renvoient des codes d’état différents pour la même URL, votre serveur ou CDN traite les deux méthodes de façon incohérente et doit être examiné.
• Fenêtre de surveillance — Immédiatement après l’activation du test, puis après chaque déploiement ou changement de routage.
• Déclencheur de retour arrière — L’originale renvoie un code permanent, la destination est incorrecte ou une cohorte entre dans une boucle.

Test 2 — L’originale reste l’URL canonique

• Test à exécuter — Inspectez les URL d’origine et de variante dans Google Search Console et vérifiez que les liens internes, les entrées de sitemap et les balises canoniques continuent de favoriser l’originale.
• Résultat attendu — L’originale reste la canonique voulue ; la variante ne la remplace pas comme page de test indexée séparément.
• Interprétation d’un échec — Des signaux de canonisation contradictoires ou une redirection maintenue trop longtemps poussent Google vers la variante.
• Fenêtre de surveillance — Vérifiez après la nouvelle exploration des URL par Google, puis à nouveau pendant un test long ; il n’existe pas de jour fixe où une 302 bascule.
• Déclencheur de retour arrière — La variante devient la canonique choisie par Google ou commence à apparaître indépendamment pour les requêtes de la page d’origine.

Test 3 — La règle temporaire est supprimée à la fin du test

• Test à exécuter — Après l’arrêt, demandez l’URL d’origine dans une session vierge et faites-la passer par Redirect Checker.
• Résultat attendu — L’originale renvoie à nouveau son contenu 200 normal et aucune affectation de test ne redirige vers la variante.
• Interprétation d’un échec — Une règle obsolète du CDN, de l’edge, de l’application ou de la plateforme de test est encore en place.
• Fenêtre de surveillance — Immédiatement après l’arrêt, puis une vérification après l’expiration du cache.
• Déclencheur de retour arrière — Une cohorte de production continue d’atteindre la variante retirée ; désactivez la règle obsolète et purgez le cache concerné.

Test 4 — La chaîne complète, le comportement de la méthode et les cas limites sont couverts

• Test à exécuter — Suivez toute la chaîne de redirections de bout en bout (et pas seulement le premier saut) et confirmez que la destination finale renvoie une réponse saine ; répétez chaque test avec un paramètre de requête et confirmez qu’il est conservé (ou supprimé volontairement) plutôt que perdu silencieusement ; essayez des requêtes avec un corps POST si la route peut en recevoir un, pour voir si la méthode est conservée ou modifiée ; et si la cible de la redirection provient un jour d’une entrée utilisateur, confirmez qu’elle est contrôlée par une liste blanche au lieu d’accepter une destination arbitraire.
• Résultat attendu — La chaîne se résout en un petit nombre prévisible de sauts vers une page fonctionnelle ; les paramètres et la méthode se comportent comme le prévoit votre application ; les destinations absentes de la liste blanche sont rejetées et non redirigées.
• Interprétation d’un échec — Une chaîne longue ou en boucle, un paramètre supprimé qui casse la page de destination, une méthode modifiée silencieusement alors qu’elle ne devait pas l’être, ou une redirection qui suit un paramètre arbitraire de type ?next= (risque de redirection ouverte) sont tous des problèmes bloquants pour la mise en production, et non des détails cosmétiques.
• Fenêtre de surveillance — Avant le lancement, puis après toute modification de la règle ou de la version du CDN, du framework ou du gestionnaire qui traite la redirection.
• Déclencheur de retour arrière — L’un des échecs précédents apparaît dans le trafic de production.
• Réserve sur les outils — L’outil d’inspection d’URL de Search Console a ses propres limites pour ce type de contrôle (il reflète l’exploration effectuée par Google et n’affiche pas nécessairement les en-têtes bruts en direct) : traitez-le comme un signal de ce que Google a vu, et non comme un substitut au contrôle de la réponse HTTP réelle.

Testez vos connaissances : les redirections 302

Cinq questions rapides sur la nature d’une 302 et les moments où l’utiliser. Choisissez une réponse pour chacune, puis vérifiez.

Journal des modifications