Redirection 301 ou 302 : laquelle choisir et jusqu’où Google suit

Réponse courte : Une redirection 301 (ou sa jumelle 308) convient quand l’ancienne adresse a disparu pour de bon ; une 302 (ou 307) seulement quand le changement est provisoire et que l’ancienne adresse doit rester dans la recherche. Google voit dans une redirection permanente un signal fort de traiter la cible, et dans une redirection temporaire un signal faible. Il suit par défaut jusqu’à 10 sauts, mais envoyez malgré tout chaque ancienne adresse vers sa destination finale en un seul saut.

Redirection 301 ou 302 : quelle différence ?

Une redirection est une réponse de votre serveur qui dit « pas ici, allez là-bas » et indique la nouvelle adresse dans l’en-tête Location. Le code de statut en donne la raison. Dans la norme HTTP (RFC 9110), 301 signifie que la page a une nouvelle adresse permanente, et 302 qu’elle se trouve seulement provisoirement ailleurs, le client devant donc continuer à utiliser l’adresse d’origine. Google lit la différence de la même façon et agit en conséquence :

Le tableau vient de la page de Google sur les codes de statut HTTP (dernière mise à jour : 2026-02-04). Ce que cela signifie dans la recherche figure sur la page de Google sur les redirections (dernière mise à jour : 2026-04-14) : avec une redirection permanente, la nouvelle cible apparaît dans les résultats ; avec une redirection temporaire, c’est la page de départ. Nous avons lu les pages de Google citées ici le 4 novembre 2026.

Pourquoi existe-t-il un 307 et un 308 ? Google les traite comme 302 et 301, mais note qu’ils sont sémantiquement différents : choisissez donc le code qui correspond à la situation. La différence tient à la méthode de la requête : après un 301 ou un 302, un client peut transformer un POST en GET ; après un 307 ou un 308, il doit conserver la méthode (RFC 9110, section 15.4). Pour l’affichage d’une page ordinaire, vous ne verrez rien. Pour les formulaires et les API qui reçoivent des requêtes POST, utilisez 308 ou 307.

Quelle redirection utiliser, et quand ?

Une seule question règle la plupart des cas. La page de Google sur les redirections dit : « Use permanent redirects when you’re sure that the redirect won’t be reverted. » Si l’ancienne adresse ne revient jamais, utilisez un 301. Si elle doit revenir, utilisez un 302.

La dernière ligne vient du guide de migration de Google (dernière mise à jour : 2026-08-20), et notre article sur les erreurs soft 404 montre comment les repérer. Ce guide traite du déménagement d’un site entier vers un nouveau domaine, une tâche plus vaste que celle de cet article.

Que coûte un mauvais choix ? Un 302 sur une page déplacée pour de bon dit à Google une chose fausse. Une redirection temporaire garde la page de départ dans les résultats, et « the target page might still be indexed if other canonicalization signals are present », c’est-à-dire que la page cible peut malgré tout être indexée si d’autres signaux de canonicalisation existent. C’est un peut-être, et nous n’avons trouvé aucune page de Google qui promette qu’un 302 durable se transforme plus tard en 301. N’attendez donc pas.

Combien de redirections Google suit-il ?

La page de Google sur les codes de statut dit : « By default, Google’s crawlers follow up to 10 redirect hops. » Googlebot suit en général 10 sauts pour le contenu web, d’autres produits Google peuvent avoir d’autres limites, et ce que renvoie l’adresse qui redirige est ignoré : c’est le contenu de la cible finale qui est traité.

Dix est un plafond, pas un objectif. Le guide de migration conseille de rediriger directement vers la destination finale et, si ce n’est pas possible, de garder une chaîne courte, idéalement pas plus de 3 sauts et moins de 5. Sa raison : « Chaining redirects adds latency for users, and not all user agents and browsers support long redirect chains. » La page de Google sur les erreurs d’exploration (dernière mise à jour : 2025-12-18) ajoute que les longues chaînes nuisent à l’exploration.

Les chaînes se forment par couches successives, rarement par choix. Une chaîne typique compte trois sauts avant que la page s’affiche :

http://example.com/ancien-guide       301 -> https://example.com/ancien-guide
https://example.com/ancien-guide      301 -> https://www.example.com/ancien-guide
https://www.example.com/ancien-guide  301 -> https://www.example.com/nouveau-guide
https://www.example.com/nouveau-guide  200

La solution tient en un saut par ancienne adresse : chaque variante de l’ancienne adresse répond par un seul 301 qui nomme l’adresse finale. Il en va de même pour vos propres liens : faites pointer les liens internes, les balises canonical et les entrées du sitemap vers l’adresse finale. Une redirection sert aux visiteurs venus de l’extérieur et aux anciens favoris, pas à votre propre navigation.

Comment mettre en place une redirection 301

Utilisez une redirection côté serveur. La page de Google sur les redirections la présente comme le type le plus susceptible d’être interprété correctement. Nous avons exécuté les exemples nginx et Node ci-dessous le 4 novembre 2026 (nginx 1.24.0, Node 25.9.0) et lu les réponses avec curl. Les lignes Apache sont l’exemple de Google lui-même, que nous n’avons pas exécuté.

D’abord nginx. La règle location va dans le bloc server de https://example.com. Les deux blocs server envoient toutes les autres variantes vers cette adresse en un seul saut, et $request_uri conserve le chemin et la chaîne de requête :

# une page déplacée pour de bon (pour un déplacement provisoire, utilisez 302)
location = /ancien-guide {
    return 301 https://example.com/nouveau-guide;
}

# http:// et https://www. vont tous deux vers https://example.com
server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}

server {
    listen 443 ssl;
    server_name www.example.com;
    ssl_certificate     /etc/ssl/example.com.pem;
    ssl_certificate_key /etc/ssl/example.com.key;
    return 301 https://example.com$request_uri;
}

Node sans paquet. Remplacez 301 par 308 si les requêtes POST doivent rester des POST :

import http from 'node:http';

const deplaces = new Map([['/ancien-guide', '/nouveau-guide']]); // ancien chemin -> nouveau chemin

http.createServer((req, res) => {
  const { pathname, search } = new URL(req.url, 'http://localhost');
  const cible = deplaces.get(pathname);
  if (cible) {
    res.writeHead(301, { location: `https://example.com${cible}${search}` });
    return res.end();
  }
  res.writeHead(200, { 'content-type': 'text/plain' });
  res.end('ok');
}).listen(3000);

Apache, d’après la page de Google (dans la configuration du serveur ou dans un fichier .htaccess) :

Redirect permanent "/ancien" "https://example.com/nouveau"
Redirect temp "/ancien-deux" "https://example.com/nouveau-deux"

Si vous ne pouvez pas toucher au serveur, regardez d’abord votre plateforme : Google cite Blogger et Shopify comme exemples de plateformes qui peuvent avoir des outils de redirection intégrés. Google lit aussi une balise meta refresh (0 seconde compte comme permanent, un délai comme temporaire) et les redirections JavaScript, mais seulement en dernier recours. Avec JavaScript, Google « might never see it » si le rendu échoue.

Comment vérifier vos redirections, et ce que trouve SEOgrinder

Deux commandes curl suffisent. La première affiche chaque saut avec son statut et sa cible, la seconde donne le nombre de sauts et l’adresse finale. Elles utilisent GET et non HEAD, parce que certains serveurs répondent différemment à HEAD :

curl -s -L -o /dev/null -D - http://example.com/ancien-guide | grep -i -E "^(HTTP|location)"
curl -s -L -o /dev/null -w "%{num_redirects} redirections, adresse finale : %{url_effective}\n" http://example.com/ancien-guide

Lancez-les pour chaque variante sous laquelle les visiteurs et les liens vous atteignent : http et https, avec et sans www. Le résultat attendu est un seul 301, puis un 200.

SEOgrinder est notre outil ; nous le développons. L’analyse gratuite de SEOgrinder examine les redirections à trois endroits (noms de l’interface en français) :

• Onglet « Technique & sécurité », carte « Redirections ». Elle liste les sauts de l’adresse que vous avez analysée. Si cette adresse redirige plus d’une fois, la tâche « N redirections à la suite » montre les sauts et conseille de faire pointer la première URL directement vers la destination finale.
• Même onglet, carte « Unification du domaine ». Elle attend que http et https, avec et sans www, aboutissent à une seule adresse. La tâche « N versions du site en concurrence » apparaît si ce n’est pas le cas. « Redirection du domaine seulement temporaire » apparaît si une variante redirige avec 302, 303 ou 307.
• Onglet « Page sur Google ». La tâche « N liens internes passent par un détour » liste les liens internes dont la cible redirige ou désigne une autre page comme canonical (jusqu’à 60 liens internes de la page analysée).

Deux limites. Le contrôle des chaînes porte sur l’adresse analysée et sur les variantes de votre domaine, pas sur chaque ancienne adresse de votre site : testez donc vos anciennes adresses avec curl. Et SEOgrinder ne peut pas juger si une cible est un successeur adapté, ni comment Google a traité une redirection. « Confier à l’IA » transforme une tâche en briefing pour un agent de codage, et « Réanalyser » lance une nouvelle analyse après votre modification.

Erreurs fréquentes

• Un 302 pour un changement permanent. L’ancienne adresse peut rester dans les résultats. Utilisez 301 ou 308.
• Un 301 pour quelque chose de provisoire. Une boutique fermée une semaine a besoin d’un 302.
• Des règles empilées qui forment des chaînes. D’abord http, puis https, puis www, puis la nouvelle page : trois sauts. Nommez l’adresse finale dans chaque règle.
• Tout envoyer vers la page d’accueil. Redirigez vers une page équivalente, ou répondez 404 ou 410.
• Des liens internes qui utilisent encore l’ancienne adresse. Mettez à jour les liens internes, les canonical et le sitemap.
• Bloquer l’ancienne adresse dans le robots.txt. Google ne peut alors pas la récupérer et ne voit jamais la redirection. Dans l’article de Google de 2011 Do 404s hurt my site?, le robot « has to be able to crawl that URL » pour voir sa réponse.
• Supprimer la redirection trop tôt. Pour les migrations de site, Google écrit : « Keep the redirects for as long as possible, generally at least 1 year. » L’appliquer à une seule page, c’est notre lecture.

Questions fréquentes

Une redirection 301 nuit-elle au SEO ?

Le guide de migration de Google dit : « 301 and other permanent redirects don’t cause a loss in PageRank. » Cette phrase figure dans le guide consacré aux migrations de site ; l’appliquer à une seule page, c’est notre lecture. Ce contre quoi Google met en garde, ce sont les longues chaînes, les redirections vers des pages sans rapport (soft 404) et, pendant une migration, les fluctuations de classement le temps qu’il réexplore.

308 vaut-il mieux que 301 ?

Pour Google, ils sont équivalents. Le 308 conserve en plus la méthode de la requête, ce qui compte pour les formulaires et les API. Pour des pages ordinaires, un 301 suffit.

Combien de temps avant que Google affiche la nouvelle adresse ?

Pour une page isolée, Google n’indique aucun délai à notre connaissance. Pour les migrations de site, il écrit que, pour les sites de taille moyenne, « it can take a few weeks or more » avant que les nouvelles URL remplacent progressivement les anciennes dans les résultats. Ne promettez aucune date.

Votre prochaine étape

Lancez la première commande curl sur vos anciennes adresses et sur chaque variante de votre domaine. Si une requête demande plus d’un saut, faites pointer la première adresse directement vers l’adresse finale. Analysez ensuite votre site avec SEOgrinder, ouvrez l’onglet « Technique & sécurité », regardez « Redirections » et « Unification du domaine », puis cliquez sur « Réanalyser » après votre modification. Pour d’autres bases techniques, consultez notre checklist audit SEO.

À lire aussi

• Désindexer une page de Google : 404, 410, 301 ou noindex ?