Redirections 301 vs 302 : impact SEO et cas d'usage réels

Un site e-commerce de 22 000 pages migre son catalogue vers une nouvelle arborescence. L'équipe technique configure des redirections 302 "en attendant de valider la structure finale". Trois mois plus tard, les anciennes URLs sont toujours indexées, le trafic organique a chuté de 34%, et les nouvelles pages stagnent en page 3. Le problème n'est pas un filtre algorithmique, ni une pénalité : c'est juste le mauvais code HTTP.

Comment Google traite les 301 et 302 : la mécanique réelle

La distinction entre 301 (Moved Permanently) et 302 (Found / Moved Temporarily) semble triviale. Un code HTTP, une en-tête Location, le navigateur suit. Mais côté moteur de recherche, les implications divergent sur trois axes fondamentaux.

Transfert des signaux de ranking

Historiquement, la communauté SEO affirmait qu'une 302 ne transférait pas le "link juice". Google a nuancé cette position à plusieurs reprises. John Mueller a confirmé que Google peut transférer les signaux de ranking à travers une 302 — mais avec un délai et une incertitude que vous ne contrôlez pas.

La différence opérationnelle : avec une 301, Google comprend immédiatement que l'URL de destination est la version canonique. Il déindexe l'ancienne URL et consolide les signaux sur la nouvelle. Avec une 302, Google maintient l'ancienne URL dans l'index et considère la redirection comme temporaire. Il peut choisir de canonicaliser vers l'une ou l'autre URL, selon ses propres heuristiques.

Ce comportement est documenté dans la documentation Google sur les redirections : une 301 est un signal fort de canonicalisation, une 302 ne l'est pas.

Choix de l'URL canonique

C'est le point le plus sous-estimé. Quand Googlebot rencontre une chaîne de redirections ou une redirection isolée, il doit décider quelle URL afficher dans les résultats. Ce choix dépend du type de redirection :

301 : Google sélectionne l'URL de destination comme canonique. L'ancienne URL disparaît progressivement de l'index.
302 : Google tend à conserver l'URL source comme canonique. L'URL de destination peut ne jamais apparaître dans les SERPs.

Ce comportement interagit directement avec la balise <link rel="canonical">. Si vous redirigez en 302 vers une page qui déclare un canonical vers elle-même, vous envoyez des signaux contradictoires. Google doit arbitrer, et son choix ne sera pas toujours celui que vous attendez. Pour approfondir cette interaction, consultez le guide sur les URLs canoniques.

Impact sur le crawl budget

Sur un site de quelques centaines de pages, le crawl budget n'est pas un facteur limitant. Sur un catalogue de 15 000+ URLs, chaque requête de Googlebot compte. Une redirection consomme un "slot" de crawl : Googlebot requête l'URL source, reçoit le 301/302, puis doit requêter l'URL de destination. C'est deux requêtes au lieu d'une.

La différence : avec une 301 consolidée depuis plusieurs semaines, Googlebot finit par crawler directement l'URL de destination et abandonne l'ancienne. Avec une 302, il continue à revisiter l'URL source régulièrement pour vérifier si la redirection est toujours en place — puisqu'elle est supposée temporaire. Sur un site à fort volume, cela représente des milliers de crawls gaspillés. Ce mécanisme est détaillé dans l'analyse du crawl budget.

Quand utiliser une 301 : les cas définitifs

La règle est simple : si le changement d'URL est permanent, c'est une 301. Voici les scénarios concrets.

Migration de domaine ou de structure d'URLs

Vous passez de shop.exemple.fr à www.exemple.fr/boutique/, ou vous restructurez vos catégories produit. C'est permanent. 301 systématique.

Configuration Nginx pour une migration de structure de catalogue :

# Migration catégories : /category/nom → /c/nom
location ~ ^/category/(.+)$ {
    return 301 /c/$1;
}

# Migration fiches produit : /product/id/slug → /p/slug-id
location ~ ^/product/(\d+)/(.+)$ {
    return 301 /p/$2-$1;
}

# Catch-all ancien domaine vers nouveau
server {
    listen 80;
    server_name shop.exemple.fr;
    return 301 https://www.exemple.fr/boutique$request_uri;
}

Passage HTTP vers HTTPS

C'est l'un des cas les plus fréquents et les plus mal gérés. Certains serveurs envoient une 302 par défaut sur la redirection HTTP → HTTPS. Vérifiez systématiquement.

Configuration Apache pour forcer la 301 sur HTTPS :

# .htaccess - Forcer 301 HTTP → HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Variante avec redirection www en même temps
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.exemple.fr/$1 [L,R=301]

Le piège classique : utiliser une redirection au niveau applicatif (middleware Express, Django, etc.) qui envoie une 302 par défaut. Vérifiez avec curl -I :

# Vérifier le code de redirection réel
curl -I http://www.exemple.fr/page-produit

# Réponse attendue :
# HTTP/1.1 301 Moved Permanently
# Location: https://www.exemple.fr/page-produit

# Si vous voyez "302 Found", corrigez immédiatement

Suppression définitive d'une page avec équivalent

Vous supprimez une page produit obsolète mais une page de remplacement existe (produit successeur, catégorie parente). Redirigez en 301 vers la page la plus pertinente. Si aucun équivalent n'existe, un 410 (Gone) est souvent plus approprié qu'une 301 vers la homepage — Google traite les 301 vers la homepage comme des soft 404 quand le contenu n'a aucun rapport.

Consolidation de pages dupliquées

Deux URLs servent le même contenu (/produit et /produit/), ou des paramètres UTM créent des duplicatas. La 301 vers la version canonique est la solution la plus propre, en complément de la balise canonical.

Quand utiliser une 302 : les cas légitimement temporaires

La 302 existe pour une raison. L'erreur n'est pas de l'utiliser, c'est de l'utiliser pour des situations permanentes.

Tests A/B et expérimentations

Vous testez une nouvelle version de page de catégorie pendant 4 semaines. L'URL originale doit rester indexée car vous pourriez revenir à la version précédente. La 302 est le bon choix.

Exemple avec un middleware Next.js pour un test A/B :

// middleware.ts - Test A/B avec redirection 302
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  const { pathname } = request.nextUrl;

  // Test A/B sur les pages catégorie
  if (pathname.startsWith('/categorie/chaussures')) {
    const cookie = request.cookies.get('ab_variant');
    let variant = cookie?.value;

    if (!variant) {
      // Attribution aléatoire 50/50
      variant = Math.random() > 0.5 ? 'control' : 'variant_b';
    }

    if (variant === 'variant_b') {
      const url = request.nextUrl.clone();
      url.pathname = '/categorie/chaussures-v2';

      const response = NextResponse.redirect(url, 302); // 302 explicite
      response.cookies.set('ab_variant', variant, {
        maxAge: 60 * 60 * 24 * 30, // 30 jours
      });
      return response;
    }
  }

  return NextResponse.next();
}

export const config = {
  matcher: '/categorie/:path*',
};

Point critique : Google recommande d'utiliser des 302 pour les tests A/B et non des 301, précisément pour éviter que l'URL de test ne remplace l'URL originale dans l'index. Si le test dure plus de 6 mois, vous avez un problème de process, pas de redirection.

Maintenance temporaire et indisponibilité planifiée

Votre système de paiement est en maintenance pendant 2 heures. Vous redirigez /checkout vers /maintenance en 302. Une 301 ici serait catastrophique : Google déindexerait votre page de checkout.

Redirections géolocalisées

Vous redirigez les utilisateurs français vers /fr/ et les allemands vers /de/ en fonction du header Accept-Language ou de l'IP. C'est une 302 : chaque version linguistique est légitime, et l'URL source (/) doit rester indexable. Google documente explicitement ce cas dans ses recommandations sur les sites multilingues.

Promotions saisonnières

/offres-noel redirige vers /offres en janvier, puis /offres redirige vers /offres-noel en décembre. C'est cyclique, donc temporaire. 302.

Le scénario qui ruine votre SEO : la 302 oubliée

Voici un cas vécu qui illustre l'impact concret. Un média en ligne avec 18 000 articles migre de articles.media.fr vers www.media.fr/articles/. L'équipe dev déploie des 302 "le temps de valider que tout fonctionne côté contenu".

Chronologie de la catastrophe

Semaine 1-2 : Tout semble normal. Les anciennes URLs sont toujours indexées, le trafic se maintient. L'équipe interprète ça comme un signe positif.

Semaine 3-6 : Google Search Console montre que les nouvelles URLs commencent à apparaître dans le rapport de couverture, mais avec le statut "Duplicate, Google chose different canonical". Google voit les deux versions mais choisit de garder les anciennes URLs comme canoniques — exactement le comportement attendu avec une 302.

Semaine 7-12 : Les anciennes URLs commencent à perdre du positionnement. Pas parce que Google les pénalise, mais parce que le contenu sur l'ancien sous-domaine n'est plus mis à jour (les rédacteurs publient sur la nouvelle structure). Google détecte du contenu stale et déclasse progressivement. Pendant ce temps, les nouvelles URLs ne rankent pas car elles ne sont pas canonicalisées.

Résultat à 3 mois : -34% de trafic organique. 8 200 URLs anciennes encore dans l'index. 14 000 nouvelles URLs en statut "Discovered - currently not indexed" ou "Crawled - currently not indexed". Pour comprendre pourquoi ces nouvelles pages n'étaient pas indexées, les mécanismes de non-indexation par Google éclairent le phénomène.

La correction

Le passage de toutes les redirections en 301 a été effectué en un déploiement. Voici le script utilisé pour vérifier l'état avant et après :

#!/bin/bash
# verify_redirects.sh - Vérifie le type de redirection sur un échantillon d'URLs

INPUT_FILE="urls_to_check.txt"  # Une URL par ligne
OUTPUT_FILE="redirect_audit_$(date +%Y%m%d).csv"

echo "url_source,http_code,location_header" > "$OUTPUT_FILE"

while IFS= read -r url; do
  # Suivre la première redirection seulement
  result=$(curl -s -o /dev/null -w "%{http_code}|%{redirect_url}" \
    --max-time 10 \
    -H "User-Agent: Mozilla/5.0 (compatible; redirect-audit/1.0)" \
    "$url")

  http_code=$(echo "$result" | cut -d'|' -f1)
  redirect_url=$(echo "$result" | cut -d'|' -f2)

  echo "$url,$http_code,$redirect_url" >> "$OUTPUT_FILE"

  # Rate limiting
  sleep 0.2
done < "$INPUT_FILE"

# Résumé
echo ""
echo "=== RÉSUMÉ ==="
echo "Total URLs vérifiées : $(wc -l < "$INPUT_FILE")"
echo "Redirections 301 : $(grep -c ',301,' "$OUTPUT_FILE")"
echo "Redirections 302 : $(grep -c ',302,' "$OUTPUT_FILE")"
echo "Autres codes : $(grep -cvE ',(301|302),' "$OUTPUT_FILE")"

Après le passage en 301, la récupération a pris 6 semaines supplémentaires. Le trafic n'est revenu qu'à 91% du niveau initial — les 9% perdus correspondaient à des URLs dont les backlinks externes pointaient vers l'ancien domaine et dont le jus avait été partiellement dissipé pendant les 3 mois de 302.

Codes HTTP au-delà du 301/302 : 307, 308 et les cas edge

Le débat 301 vs 302 est incomplet sans mentionner leurs équivalents modernes.

307 Temporary Redirect et 308 Permanent Redirect

Les codes 307 et 308 ont été introduits pour corriger une ambiguïté du protocole HTTP/1.1. Avec une 301 ou 302, les navigateurs peuvent (et certains le font) changer la méthode HTTP lors de la redirection : un POST devient un GET. Les codes 307 et 308 garantissent que la méthode HTTP est préservée.

Pour le SEO, la distinction est marginale : Googlebot utilise quasi exclusivement des requêtes GET. Mais pour les formulaires, les APIs, ou les webhooks, c'est critique. Si votre page de checkout reçoit des soumissions POST et que vous redirigez en 301, le navigateur transforme le POST en GET — les données du formulaire sont perdues.

Code	Permanent ?	Préserve la méthode HTTP ?	Usage SEO
301	Oui	Non (POST → GET possible)	Standard pour SEO
302	Non	Non (POST → GET possible)	Temporaire, SEO minimal
307	Non	Oui	Temporaire technique
308	Oui	Oui	Permanent technique

En pratique, pour le crawl et l'indexation, Google traite 308 comme 301 et 307 comme 302. Si votre stack ne gère que des pages statiques crawlées en GET, restez sur 301/302 pour la simplicité.

Meta refresh et redirections JavaScript

Une redirection via <meta http-equiv="refresh" content="0;url=https://..."> ou via window.location.href n'envoie aucun code HTTP de redirection. Le serveur répond 200, le navigateur exécute la redirection côté client.

Google peut suivre ces redirections, mais avec deux problèmes majeurs :

Le transfert de signaux est imprévisible — Google peut traiter la page 200 comme une page indépendante.
Le délai de traitement est plus long (Google doit rendre la page pour découvrir la redirection JS).

Évitez-les systématiquement pour le SEO. La seule exception légitime : une page interstitielle de type "Vous allez être redirigé vers un site externe dans 5 secondes" où vous ne voulez justement pas transférer de signaux.

Auditer et monitorer vos redirections à grande échelle

Screaming Frog : le diagnostic initial

Pour un audit ponctuel, Screaming Frog reste l'outil de référence. Configurez-le pour suivre les chaînes de redirections et identifier les 302 suspectes :

Lancez un crawl complet de votre site.
Filtrez par "Redirection (3xx)" dans l'onglet "Response Codes".
Triez par "Status Code" pour isoler les 302.
Pour chaque 302, posez la question : "Est-ce que cette redirection est réellement temporaire ?"

Si une 302 est en place depuis plus de 3 mois et que l'URL source n'a pas vocation à revenir, c'est une 301 manquée.

Google Search Console : le signal post-crawl

Le rapport "Pages" (anciennement "Couverture") de Search Console révèle les symptômes d'une mauvaise stratégie de redirection :

"Page with redirect" : Google a trouvé une page qui redirige. Normal pour les 301 volontaires.
"Duplicate, Google chose different canonical" : signal d'alerte. Si l'URL que Google choisit comme canonique n'est pas celle que vous attendez, vérifiez vos redirections.
"Crawled - currently not indexed" : les URLs de destination de vos 302 peuvent se retrouver dans ce statut car Google ne les considère pas comme canoniques.

L'API URL Inspection permet d'automatiser ces vérifications sur un volume important d'URLs.

Chrome DevTools : le debug en temps réel

Ouvrez l'onglet Network, cochez "Preserve log", et naviguez sur une URL redirigée. Vous verrez la chaîne complète : la requête initiale avec son code 301/302, le header Location, puis la requête vers l'URL de destination. Vérifiez que :

Le code est bien celui attendu (301 vs 302).
Le header Location pointe vers l'URL exacte (pas de double slash, pas de trailing slash incohérent).
Il n'y a pas de chaîne de redirections (A → B → C → D). Au-delà de 2 sauts, vous perdez du crawl budget et ralentissez l'expérience utilisateur — ce qui impacte les Core Web Vitals.

Monitoring continu : détecter les régressions

Le vrai danger des redirections, c'est la régression silencieuse. Un déploiement vendredi soir écrase votre config Nginx et transforme 4 000 redirections 301 en 302 — ou pire, les supprime entièrement, renvoyant des 404. Personne ne s'en aperçoit avant le lundi, quand Googlebot a déjà recrawlé une partie du site.

Un outil de monitoring comme SEOGard détecte ce type de changement en quasi temps réel : si le code HTTP d'une URL surveillée passe de 301 à 302 ou à 200, une alerte est déclenchée avant que Google n'ait le temps de réinterpréter votre architecture.

Les chaînes de redirections : le piège de l'accumulation

Sur un site qui existe depuis 10 ans, les redirections s'empilent. La page /produit-original a été redirigée en 301 vers /nouveau-produit en 2019, puis /nouveau-produit a été redirigée vers /produits/nouveau en 2022, et /produits/nouveau pointe maintenant vers /catalog/nouveau-produit après la migration de 2025.

Impact concret

Chaque saut dans la chaîne :

Consomme une requête de crawl supplémentaire.
Ajoute de la latence (chaque redirection = un round-trip réseau).
Augmente le risque de perte de signaux. Google affirme suivre les chaînes jusqu'à 10 sauts, mais la consolidation des signaux n'est documentée comme fiable que pour les redirections directes.

La solution : aplatir les chaînes

Remplacez A → B → C → D par A → D, B → D, et C → D. Toutes en 301. Scriptez cette opération :

# flatten_redirects.py - Résolution des chaînes de redirections
import csv
import requests

def resolve_chain(url, max_hops=10):
    """Suit la chaîne de redirections et retourne l'URL finale."""
    chain = [url]
    current = url

    for _ in range(max_hops):
        try:
            resp = requests.head(
                current,
                allow_redirects=False,
                timeout=5,
                headers={'User-Agent': 'redirect-flattener/1.0'}
            )
            if resp.status_code in (301, 302, 307, 308):
                next_url = resp.headers.get('Location', '')
                if not next_url or next_url in chain:  # Boucle détectée
                    break
                chain.append(next_url)
                current = next_url
            else:
                break
        except requests.RequestException:
            break

    return {
        'source': url,
        'final_destination': chain[-1],
        'hops': len(chain) - 1,
        'chain': ' → '.join(chain)
    }

# Lecture du fichier d'URLs exporté depuis Screaming Frog
with open('redirected_urls.csv', 'r') as infile:
    urls = [row[0] for row in csv.reader(infile)]

results = [resolve_chain(url) for url in urls]

# Export des chaînes à aplatir (plus d'un saut)
with open('chains_to_flatten.csv', 'w', newline='') as outfile:
    writer = csv.DictWriter(outfile, fieldnames=['source', 'final_destination', 'hops', 'chain'])
    writer.writeheader()
    for r in results:
        if r['hops'] > 1:
            writer.writerow(r)

print(f"Chaînes détectées : {sum(1 for r in results if r['hops'] > 1)}")
print(f"Redirections directes : {sum(1 for r in results if r['hops'] == 1)}")

Alimentez le fichier de sortie dans votre génération de config Nginx ou .htaccess pour produire des redirections directes.

Redirections et sitemap.xml : la cohérence oubliée

Un anti-pattern fréquent : le sitemap XML contient des URLs qui redirigent. C'est un signal contradictoire : vous dites à Google "cette URL est valide et doit être indexée" (via le sitemap) tout en lui disant "cette URL a déménagé" (via la 301).

Après chaque vague de redirections, nettoyez votre sitemap :

Retirez toutes les URLs qui renvoient un 301 ou 302.
Ajoutez les URLs de destination si elles n'y figurent pas.
Soumettez le sitemap mis à jour dans Search Console.

Sur un site de 20 000+ pages, ce nettoyage peut faire la différence entre 2 jours et 3 semaines pour que Google consolide les nouvelles URLs. Le sitemap est le premier signal que Googlebot consulte pour prioriser son crawl, et des URLs redirigées dans le sitemap gaspillent cette priorisation. Le risque d'index bloat augmente proportionnellement au nombre d'anciennes URLs qui restent indexées en parallèle des nouvelles.

Résumé décisionnel

La décision se prend en une question : le changement est-il définitif ?

Si oui → 301. Si vous hésitez et que le changement est en place depuis plus de 4 semaines → probablement 301. Si c'est un test, une maintenance, ou une redirection saisonnière avec une date de fin définie → 302.

Le vrai risque n'est pas de mal choisir initialement — c'est de ne pas monitorer. Une 302 posée "en attendant" qui reste 6 mois est invisible dans les dashboards habituels. Seule une surveillance continue des codes HTTP sur vos URLs critiques garantit que vos redirections restent alignées avec votre intention SEO.