Une migration de 12 000 URLs produit e-commerce avec des 302 au lieu de 301. Trois semaines plus tard, Google indexe toujours les anciennes URLs, le trafic organique chute de 38 %, et les équipes passent un mois à corriger le tir. Ce scénario est plus fréquent qu'on le croit — et il repose sur une incompréhension technique qui tient en un chiffre : le code HTTP retourné par le serveur.
Ce que dit réellement la spécification HTTP
La confusion entre 301 et 302 ne vient pas d'un manque de documentation. Elle vient du fait que les deux produisent le même effet visible côté utilisateur : le navigateur suit la redirection et affiche la page cible. La différence est purement sémantique — et c'est cette sémantique que Googlebot exploite pour ses décisions d'indexation.
301 Moved Permanently
Le serveur indique que la ressource a été définitivement déplacée vers une nouvelle URL. Selon la RFC 7231 (Section 6.4.2), le client devrait mettre à jour ses références vers la nouvelle URL. En pratique, cela signifie que :
- Les moteurs de recherche transfèrent les signaux de ranking (PageRank, ancres, historique) vers la cible.
- L'URL source est progressivement désindexée au profit de la cible.
- Le navigateur peut mettre en cache la redirection de manière agressive.
302 Found (anciennement "Moved Temporarily")
Le serveur indique que la ressource est temporairement disponible à une autre URL. Le client ne doit pas mettre à jour ses références. Concrètement :
- Google conserve l'URL source dans son index comme URL canonique.
- Les signaux de ranking restent attachés à l'URL source.
- Le navigateur ne cache généralement pas la redirection (ou avec un TTL court).
Le cas 307 et 308
Pour être complet : HTTP/1.1 a introduit les codes 307 (Temporary Redirect) et 308 (Permanent Redirect). Leur différence avec 302 et 301 concerne la méthode HTTP — 307 et 308 garantissent que la méthode (POST, PUT) est préservée lors de la redirection, là où 301 et 302 permettent au client de basculer en GET. Pour le SEO, 308 est fonctionnellement identique à 301, et 307 à 302. Google les traite de la même manière selon la documentation officielle.
Impact réel sur le transfert de PageRank
Pendant des années, la communauté SEO a répété qu'une 301 engendrait une perte de PageRank (souvent chiffrée à 15 %). Cette information provient d'un tweet de Matt Cutts en 2013. Elle est obsolète.
En 2016, Gary Illyes de Google a confirmé que les redirections 301 ne provoquent aucune perte de PageRank. La page cible hérite de 100 % des signaux. Ce point a été réaffirmé dans la documentation Google Search Central sur les redirections et Google Search.
La vraie question n'est donc pas "combien de jus je perds avec une 301" mais plutôt : est-ce que Google transfère correctement les signaux quand vous utilisez une 302 là où une 301 s'imposait ?
Ce qui se passe réellement avec une 302 mal placée
Quand Google rencontre une chaîne de 302, il fait un pari : il considère que l'URL source est l'URL canonique et garde cette URL dans l'index. Si la 302 persiste pendant des semaines ou des mois, Google finit parfois par la traiter comme une 301 — mais ce comportement n'est pas garanti et dépend de multiples signaux (sitemaps, liens internes, canonical tags).
Le problème concret : pendant cette période d'ambiguïté, vous avez potentiellement deux URLs en concurrence dans l'index. L'ancienne URL (toujours indexée) et la nouvelle (que Google commence à découvrir via d'autres chemins). C'est un cas classique de cannibalisation — deux pages se disputent les mêmes requêtes, et aucune ne performe à son potentiel.
Quand utiliser une 301 : les cas légitimes
La règle est simple : si l'ancienne URL n'a aucune raison de revenir, c'est une 301.
Migration de domaine ou restructuration d'URL
Le cas le plus évident. Vous passez de shop.example.fr à www.example.fr/boutique/, ou vous restructurez vos catégories produits. Chaque ancienne URL doit pointer vers son équivalent exact via 301.
Configuration Nginx pour une migration de catégories e-commerce :
# Migration des anciennes catégories vers la nouvelle structure
# Ancien : /categorie/chaussures-homme
# Nouveau : /homme/chaussures/
location ~ ^/categorie/(.+)-homme$ {
return 301 /homme/$1/;
}
location ~ ^/categorie/(.+)-femme$ {
return 301 /femme/$1/;
}
# Redirection spécifique pour les anciennes fiches produit
# Ancien : /produit/12345
# Nouveau : /p/nom-du-produit-12345
# Cette règle nécessite une map ou un fichier de correspondance
map $uri $new_product_uri {
include /etc/nginx/redirects/product-map.conf;
}
server {
# ...
if ($new_product_uri) {
return 301 $new_product_uri;
}
}Le fichier product-map.conf contient les correspondances ligne par ligne :
/produit/12345 /p/basket-running-nike-12345;
/produit/12346 /p/derby-cuir-noir-12346;
Pour un site de 12 000 produits, cette approche par map est nettement plus performante qu'une série de blocs location — Nginx charge la map en mémoire au démarrage et la lookup est en O(1).
Passage de HTTP à HTTPS
Chaque URL HTTP doit retourner une 301 vers son équivalent HTTPS. C'est acquis pour la plupart des sites, mais on voit encore des configurations qui retournent des 302 — souvent parce que le dev a utilisé return 302 pendant la phase de test et a oublié de basculer.
Consolidation de pages similaires
Vous avez trois pages qui traitent du même sujet avec des variantes mineures (/guide-seo, /guide-seo-2024, /seo-guide-complet). Gardez la meilleure, redirigez les deux autres en 301. Vérifiez que la balise canonical de la page conservée pointe bien vers elle-même.
Suppression définitive d'une section du site
Si vous arrêtez une gamme de produits et que les pages n'ont plus de contenu pertinent, redirigez-les en 301 vers la catégorie parente ou une page de remplacement contextuelle. Ne les redirigez pas vers la homepage — Google traite ce pattern comme un soft 404 quand il est détecté à grande échelle.
Quand utiliser une 302 : les vrais cas temporaires
La 302 a des cas d'usage légitimes, mais ils sont plus rares qu'on ne le pense.
Tests A/B côté serveur
Vous testez une nouvelle page produit pendant 4 semaines. L'URL d'origine doit rester l'URL canonique — vous ne voulez pas que Google indexe la variante de test. Une 302 vers la variante préserve l'URL d'origine dans l'index.
// Middleware Express.js pour un test A/B côté serveur
// 50% des utilisateurs voient la variante B pendant 30 jours
const AB_TEST_END = new Date('2026-05-05');
const VARIANT_RATE = 0.5;
function abTestMiddleware(req, res, next) {
// Ne pas rediriger Googlebot — il doit voir la page originale
const ua = req.headers['user-agent'] || '';
if (ua.includes('Googlebot') || ua.includes('bingbot')) {
return next();
}
// Vérifier si le test est encore actif
if (new Date() > AB_TEST_END) {
return next();
}
// Vérifier le cookie existant ou assigner un groupe
let group = req.cookies?.ab_group;
if (!group) {
group = Math.random() < VARIANT_RATE ? 'B' : 'A';
res.cookie('ab_group', group, {
maxAge: 30 * 24 * 60 * 60 * 1000,
httpOnly: true
});
}
// Pages concernées par le test
const testPaths = ['/produit/nouvelle-fiche'];
if (group === 'B' && testPaths.includes(req.path)) {
return res.redirect(302, `${req.path}?variant=B`);
}
next();
}Point critique dans cet exemple : Googlebot est explicitement exclu de la redirection. Si vous redirigez Googlebot en 302 vers la variante, il risque d'indexer cette URL temporaire. Servez-lui toujours la version originale.
Maintenance temporaire ou indisponibilité planifiée
Une section du site est en maintenance pendant 48h. Vous redirigez temporairement les utilisateurs vers une page d'information. Ici, la 302 est correcte — la page originale va revenir.
Un point souvent ignoré : si la maintenance dure plus de quelques heures, un code 503 Service Unavailable avec un header Retry-After est techniquement plus approprié qu'une 302. Google comprend le 503 comme "reviens plus tard" sans impact négatif sur l'indexation, à condition que la durée reste raisonnable (quelques jours maximum).
Redirections géolocalisées
Vous redirigez les visiteurs français vers /fr/ et les visiteurs allemands vers /de/. Si la page racine / doit rester indexable (comme page par défaut ou page de sélection de langue), utilisez une 302. Google doit pouvoir continuer à crawler / sans la considérer comme définitivement déplacée. La gestion des annotations hreflang est alors indispensable pour éviter les problèmes d'indexation multilingue.
Promotions saisonnières
Vous redirigez /black-friday vers /promotions/black-friday-2026 pendant un mois. L'année prochaine, cette même URL /black-friday pointera vers /promotions/black-friday-2027. La 302 préserve l'autorité accumulée sur /black-friday au fil des ans.
Scénario concret : migration d'un e-commerce de 15 000 pages
Prenons un cas réaliste. MaisonDeco.fr, un e-commerce de mobilier avec 15 200 pages indexées, migre de Magento 1 vers Shopify. La structure d'URL change intégralement :
- Anciennes URLs produit :
/catalog/product/view/id/4523/s/table-chene-massif - Nouvelles URLs produit :
/products/table-chene-massif - Anciennes catégories :
/catalog/category/view/id/87/s/tables - Nouvelles catégories :
/collections/tables
Phase 1 : Cartographie des redirections
L'équipe exporte la liste complète des URLs indexées depuis Google Search Console (Couverture > Pages indexées) et Screaming Frog (crawl du site existant). Résultat : 15 200 URLs uniques, dont 11 400 produits, 340 catégories, et 3 460 pages filtrées (combinaisons couleur/taille).
Décision technique sur les pages filtrées : les 3 460 URLs de filtres à facettes n'étaient déjà pas souhaitées dans l'index (elles étaient taguées noindex). Plutôt que de créer 3 460 redirections 301, l'équipe les redirige vers la catégorie parente. C'est un compromis acceptable — ces pages avaient peu ou pas de backlinks.
Phase 2 : Implémentation
Sur Shopify, les redirections se gèrent soit via l'admin (limité à 20 000 entrées), soit via le fichier _redirects pour Shopify Oxygen, soit via un reverse proxy (Cloudflare Workers, Nginx en front).
Pour un volume de 15 000+ règles, un Cloudflare Worker offre la flexibilité nécessaire :
// Cloudflare Worker — gestion des redirections de migration
// Les mappings sont stockés dans un KV namespace "REDIRECTS"
addEventListener('fetch', event => {
event.respondWith(handleRequest(event.request));
});
async function handleRequest(request) {
const url = new URL(request.url);
const path = url.pathname.replace(/\/$/, ''); // Normaliser le trailing slash
// Lookup dans le KV store
const newPath = await REDIRECTS.get(path);
if (newPath) {
const destination = `${url.origin}${newPath}`;
return Response.redirect(destination, 301);
}
// Pattern matching pour les catégories non mappées individuellement
const categoryMatch = path.match(
/^\/catalog\/category\/view\/id\/(\d+)\/s\/(.+)$/
);
if (categoryMatch) {
const slug = categoryMatch[2];
return Response.redirect(
`${url.origin}/collections/${slug}`,
301
);
}
// Pas de redirection — passer la requête au origin
return fetch(request);
}Le KV namespace contient les mappings exacts, peuplés via un script batch :
# Peupler le KV Cloudflare avec les mappings de redirection
# Format CSV : ancien_chemin,nouveau_chemin
while IFS=',' read -r old_path new_path; do
wrangler kv:key put --namespace-id="REDIRECT_NS_ID" \
"$old_path" "$new_path"
done < redirects-mapping.csv
# Vérification rapide d'un échantillon
wrangler kv:key get --namespace-id="REDIRECT_NS_ID" \
"/catalog/product/view/id/4523/s/table-chene-massif"
# Attendu : /products/table-chene-massifPhase 3 : Validation et monitoring
Une fois les redirections en production, la validation est critique. Voici la checklist que l'équipe MaisonDeco.fr a suivie :
Jour 0 — Lancement :
- Crawl complet avec Screaming Frog sur les 15 200 anciennes URLs. Vérification que chaque URL retourne un 301 (pas un 302, pas un 404, pas une chaîne de redirections).
- Test d'un échantillon de 50 URLs dans Chrome DevTools (onglet Network, case "Preserve log" cochée) pour confirmer le code de réponse.
- Soumission du nouveau sitemap dans Google Search Console. L'ancien sitemap est conservé temporairement — les URLs qu'il contient doivent renvoyer 301, ce qui accélère la découverte des nouvelles URLs par Googlebot.
Semaine 1 :
- Surveillance du rapport "Couverture" dans Search Console. Les anciennes URLs passent progressivement de "Indexée" à "Page avec redirection".
- Vérification qu'aucune ancienne URL ne reste dans l'index via
site:maisondeco.fr/catalog/— le résultat doit tendre vers zéro. - Monitoring du crawl budget via les statistiques d'exploration de Search Console. Une hausse temporaire des requêtes de crawl est normale — Googlebot recrawle les anciennes URLs pour vérifier les redirections.
Semaine 2-4 :
- Le trafic organique chute initialement de 15-20 % (normal lors d'une migration). Il devrait se stabiliser puis remonter en semaine 3-4 si les redirections sont correctement implémentées.
- Surveillance des backlinks entrants via Search Console ou Ahrefs. Les domaines référents doivent progressivement pointer vers les nouvelles URLs dans le rapport.
Le piège qui a failli coûter cher : lors du crawl de validation, Screaming Frog a détecté 340 URLs produit qui retournaient une chaîne de deux redirections : 301 > 302 > page finale. Le problème venait de l'app Shopify de gestion des variantes produit qui ajoutait une 302 intermédiaire. Sans cette détection, ces 340 produits auraient eu un transfert de signaux dégradé pendant des semaines.
Un outil de monitoring continu comme Seogard aurait détecté cette régression automatiquement — une alerte se déclenche dès qu'une URL surveillée change de code de réponse HTTP, ce qui est exactement le type de problème silencieux qui passe sous le radar entre deux audits manuels.
Chaînes de redirections et redirect loops
Une chaîne de redirections, c'est quand l'URL A redirige vers B, qui redirige vers C. Googlebot suit jusqu'à 10 redirections dans une chaîne (selon la documentation officielle), mais chaque hop supplémentaire :
- Consomme du crawl budget inutilement.
- Ajoute de la latence pour l'utilisateur (chaque redirect = un aller-retour HTTP).
- Augmente le risque qu'un maillon de la chaîne casse lors d'une future modification.
Détecter les chaînes
Dans Screaming Frog : Configuration > Spider > Redirects > "Always Follow Redirects". Puis filtrez les URLs avec un "Redirect Chain" de longueur > 1.
En ligne de commande, curl avec l'option -L (follow redirects) et -v (verbose) :
# Vérifier la chaîne complète de redirections
curl -sIL -o /dev/null -w "Redirect chain:\n" \
--max-redirs 10 \
-D - \
"https://maisondeco.fr/catalog/product/view/id/4523/s/table-chene-massif" \
2>&1 | grep -E "^(HTTP/|Location:)"
# Sortie attendue pour une redirection propre :
# HTTP/2 301
# Location: https://maisondeco.fr/products/table-chene-massif
# HTTP/2 200
# Sortie problématique (chaîne) :
# HTTP/2 301
# Location: https://maisondeco.fr/produits/table-chene-massif
# HTTP/2 302
# Location: https://maisondeco.fr/products/table-chene-massif
# HTTP/2 200Redirect loops
Plus dangereux encore : A redirige vers B, B redirige vers A. Le navigateur abandonne après quelques cycles. Googlebot aussi. La page devient inaccessible et sort de l'index.
Ce problème survient typiquement quand :
- Deux règles de redirection se contredisent (une dans le .htaccess, une dans l'application).
- Un plugin WordPress ajoute une redirection qui entre en conflit avec une règle serveur.
- Une règle de trailing slash (
/page→/page/) coexiste avec une règle inverse dans un autre fichier de config.
Pour prévenir les loops, une bonne pratique est de centraliser toutes les règles de redirection dans un seul endroit — idéalement au niveau du serveur ou du CDN, pas dispersées entre .htaccess, config applicative, et plugins.
Redirections et JavaScript : le cas SPA/SSR
Les sites en Single Page Application (React, Vue, Angular) gèrent souvent le routing côté client. Quand un utilisateur tape /ancienne-url, le serveur renvoie un 200 avec le shell HTML, puis le JavaScript côté client détecte l'URL et affiche le contenu de /nouvelle-url via window.location.replace() ou router.push().
Le problème : Googlebot reçoit un 200 OK du serveur. Même si le rendu JavaScript finit par afficher le contenu de la nouvelle URL, il n'y a pas de transfert de signaux de ranking. Google voit deux pages distinctes avec un contenu identique — un cas de contenu dupliqué.
La règle absolue : les redirections SEO doivent être implémentées côté serveur, au niveau HTTP. Une redirection JavaScript ne transmet pas le PageRank.
Si vous avez un framework SSR (Next.js, Nuxt.js), vous pouvez gérer les redirections dans la couche serveur du framework :
// next.config.ts — redirections gérées côté serveur par Next.js
import type { NextConfig } from 'next';
const nextConfig: NextConfig = {
async redirects() {
return [
{
source: '/ancien-blog/:slug',
destination: '/articles/:slug',
permanent: true, // true = 308 (équivalent 301)
},
{
source: '/promo-temporaire',
destination: '/offres/promo-printemps-2026',
permanent: false, // false = 307 (équivalent 302)
},
{
// Regex pour les anciennes URLs avec paramètre numérique
source: '/product/:id(\\d+)',
destination: '/api/redirect-product/:id',
permanent: true,
},
];
},
};
export default nextConfig;Notez que Next.js utilise 308/307 plutôt que 301/302. Comme mentionné plus haut, Google traite ces codes de manière identique. Vous pouvez vérifier ce comportement en testant ce que Google voit réellement sur vos pages redirigées via l'outil d'inspection d'URL de Search Console.
Les erreurs les plus coûteuses (et comment les éviter)
Rediriger tout vers la homepage
Lors d'une refonte, certaines équipes redirigent toutes les URLs supprimées vers /. Google détecte ce pattern et le traite comme un soft 404 — la redirection est ignorée, les signaux ne sont pas transférés, et les anciennes URLs sortent de l'index sans bénéfice pour la homepage. Si une ancienne page n'a pas d'équivalent exact, redirigez vers la catégorie parente ou la page thématiquement la plus proche.
Oublier les trailing slashes
/produit/chaise et /produit/chaise/ sont deux URLs distinctes pour HTTP. Si votre serveur sert le contenu sur les deux sans redirection, vous avez du contenu dupliqué. Choisissez une convention et redirigez l'autre en 301. C'est un problème fréquent qui, à l'échelle d'un site de plusieurs milliers de pages, peut impacter significativement le budget de crawl.
Ne jamais retirer les redirections
Les redirections 301 doivent rester en place aussi longtemps que l'ancienne URL reçoit du trafic ou des liens. En pratique, conservez-les au minimum 1 an. Pour les URLs avec des backlinks de qualité, conservez-les indéfiniment. Le coût serveur d'une règle de redirection est négligeable comparé à la perte de PageRank si un backlink tombe sur un 404.
Confondre redirection côté client et côté serveur
Un <meta http-equiv="refresh" content="0;url=/nouvelle-page"> ou un window.location.href = '/nouvelle-page' ne sont pas des redirections HTTP. Google peut les interpréter comme des redirections dans certains cas, mais le comportement n'est pas garanti et le transfert de signaux est partiel au mieux. Toujours privilégier un vrai code HTTP 3xx.
Ignorer le protocole et le sous-domaine dans les règles
http://example.fr, https://example.fr, https://www.example.fr — trois origines distinctes. Vos règles de redirection doivent couvrir toutes les combinaisons. Un oubli classique : rediriger http://example.fr vers https://example.fr mais oublier http://www.example.fr vers https://www.example.fr. Le résultat : des backlinks pointant vers http://www. tombent dans le vide.
Monitoring continu des redirections
Un audit ponctuel ne suffit pas. Les redirections cassent silencieusement — un déploiement écrase une règle Nginx, un plugin WordPress se met à jour et modifie son comportement, un CDN applique une nouvelle policy de cache qui interfère avec les redirections.
Les signaux à surveiller en continu :
- Changement de code HTTP : une URL qui retournait 301 et qui passe à 200 (la règle a disparu) ou 404 (le serveur a changé).
- Apparition de chaînes : un intermédiaire s'ajoute dans une chaîne de redirections après un déploiement.
- Temps de réponse des redirections : une redirection qui prend 2 secondes au lieu de 50ms indique un problème de configuration (lookup dans une base de données au lieu d'une règle statique).
L'API d'inspection d'URL de Search Console permet d'automatiser la vérification du statut vu par Google pour un échantillon d'URLs. Pour un monitoring à l'échelle de tout le site, un outil comme Seogard surveille en permanence les codes de réponse HTTP et alerte dès qu'une régression est détectée — avant que l'impact sur le trafic ne devienne visible dans vos analytics.
Le choix entre 301 et 302 se résume à une question : l'ancienne URL a-t-elle vocation à revenir ? Si non, 301. Si oui, 302. Toute autre considération (perte de PageRank, impact sur le crawl) découle de cette décision initiale. L'erreur coûteuse n'est presque jamais d'avoir choisi le mauvais code — c'est de ne pas avoir détecté qu'une redirection a cassé trois mois après sa mise en place.