Faut-il vraiment se soucier de la différence entre redirections 301 et 302 ?

Pourquoi Google fait-il encore cette distinction en 2025 ?

La théorie veut qu'une redirection 301 signale à Google que l'ancienne URL est définitivement remplacée : le moteur transfère alors les signaux de classement (PageRank, ancienneté, backlinks) vers la nouvelle page. Une 302, censée être temporaire, devrait maintenir les signaux sur l'URL d'origine — puisque celle-ci est supposée revenir.

Sauf que dans la pratique, beaucoup de sites utilisent des 302 par défaut ou par erreur, sans jamais revenir à l'URL initiale. Google a donc dû s'adapter : si la 302 reste en place plusieurs semaines ou mois, l'algorithme la traite de facto comme une 301. Mueller le confirme ici sans préciser de délai exact — typique de Google qui refuse de donner des seuils chiffrés.

Quelle est la différence technique entre une 301 et une 302 ?

Une 301 Moved Permanently indique au navigateur et aux moteurs de recherche que la ressource a définitivement changé d'adresse. Le statut HTTP 301 est mis en cache par les navigateurs, ce qui accélère les visites ultérieures mais complique les corrections d'erreur.

Une 302 Found (ou 307 Temporary Redirect en HTTP/2) signale un déplacement temporaire. Les crawlers sont supposés revenir vérifier l'URL d'origine régulièrement. En théorie, cela préserve l'indexation de l'ancienne page — mais si la 302 persiste, Google finit par indexer la cible, pas la source.

Dans quels cas utilise-t-on réellement une 302 ?

Les cas légitimes de 302 sont rares : tests A/B temporaires, maintenance planifiée avec retour prévu de l'URL d'origine, redirections géolocalisées dynamiques (qui changent selon l'IP de l'utilisateur), ou pages saisonnières qui reviennent chaque année.

Le problème ? Beaucoup de CMS et de frameworks génèrent des 302 par défaut lors de migrations ou de changements de slug. Résultat : des redirections « temporaires » qui durent des années, provoquant une dilution lente des signaux jusqu'à ce que Google bascule en mode 301.

• 301 : transfert immédiat et complet des signaux de classement vers la nouvelle URL
• 302 : signaux conservés sur l'ancienne URL tant que la redirection reste « fraîche »
• 302 persistante : Google finit par traiter comme une 301, mais avec un délai non documenté
• Choix par défaut dans la plupart des CMS : souvent 302, ce qui impose une vigilance accrue lors des migrations
• Cache navigateur : une 301 est mise en cache agressivement, une 302 beaucoup moins

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, mais avec un bémol majeur : Mueller ne précise pas le seuil temporel à partir duquel Google bascule une 302 en 301. Les tests terrain montrent que cela peut survenir entre 3 semaines et 3 mois selon la fréquence de crawl du site. Sur un site à fort crawl budget, la bascule est plus rapide — Google détecte vite qu'une « temporaire » ne l'est pas.

Deuxième observation : la transmission de PageRank via une 302 persistante est moins nette qu'avec une 301 directe. Certains signaux semblent se perdre dans le flou tant que Google hésite entre les deux URLs. C'est invisible dans la Search Console, mais se ressent dans les rankings pendant la période de transition. [À vérifier] : aucune donnée officielle sur le taux de déperdition exact durant cette phase.

Quelles sont les failles de cette directive ?

Mueller ne dit rien sur les chaînes de redirections : que se passe-t-il si une 302 pointe vers une 301, puis une autre 301 ? Google suit-il toute la chaîne ou coupe-t-il à un certain niveau ? Les tests montrent qu'au-delà de 3 redirections successives, le transfert de PageRank devient aléatoire.

Autre angle mort : les redirections JavaScript et les meta refresh. Officiellement, Google les gère « comme des redirections normales », mais leur traitement est bien plus lent qu'un vrai statut HTTP. Si vous utilisez une redirection JS « temporaire », attendez-vous à ce qu'elle soit ignorée pendant des semaines avant que Googlebot ne la détecte réellement.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Les redirections géolocalisées sont un cas limite : une 302 qui change de cible selon le pays de l'utilisateur ne sera jamais traitée comme une 301, car Google crawle depuis plusieurs IP. Idem pour les redirections basées sur le user-agent (mobile vs desktop) — obsolètes depuis le mobile-first indexing, mais encore présentes sur certains vieux sites.

Enfin, les redirections sur des domaines expirés : acheter un vieux domaine et rediriger toutes ses URLs en 301 vers votre site ne transfère plus grand-chose depuis plusieurs années. Google détecte ces patterns et annule la transmission de PageRank. Une 302 serait encore plus suspecte.

Que faut-il faire concrètement lors d'une migration ?

Utilise exclusivement des 301 pour toute URL qui ne reviendra jamais. Pas de 302 « au cas où » : si tu hésites, c'est que la redirection est permanente. Les migrations de site, changements de slug, fusions de catégories — tout ça mérite une 301.

Teste tes redirections avec un outil HTTP (curl, Screaming Frog, ou simplement l'inspecteur réseau du navigateur) pour vérifier le code retourné. Beaucoup de plugins WordPress génèrent des 302 par défaut — modifie la config ou change de plugin. Sur Shopify, les redirections manuelles sont toujours des 301, mais les automatiques (produit supprimé) peuvent être des 302.

Quelles erreurs critiques éviter ?

Ne laisse jamais une 302 « traîner » plus de quelques jours si l'URL d'origine ne doit plus revenir. Chaque semaine de flottement, c'est du PageRank qui se dilue et des classements qui fluctuent. Google ne bascule pas instantanément — pendant ce temps, tu perds des positions sur des requêtes concurrentielles.

Évite les chaînes de redirections : URL A → 302 → URL B → 301 → URL C. Google suit, mais lentement, et le transfert de signaux est partiel. Redirige toujours directement de A vers C. Audit régulier avec Screaming Frog pour détecter ces chaînes cachées, surtout après plusieurs migrations successives.

Comment auditer les redirections existantes sur un site mature ?

Lance un crawl complet avec Screaming Frog en mode « List » : importe toutes tes URLs indexées (via sitemap ou Search Console), et vérifie les codes de réponse. Filtre sur « 302 » — chaque ligne doit avoir une justification. Si une 302 date de plus de 2 mois, bascule-la en 301 immédiatement.

Utilise aussi les logs serveur pour repérer les redirections fréquemment crawlées par Googlebot : si une 302 est visitée 50 fois par jour depuis 6 mois, c'est qu'elle devrait être une 301. Les logs révèlent aussi les chaînes cachées que Screaming Frog peut rater (redirections JS, meta refresh).

• Vérifie que toutes les redirections post-migration sont bien des 301, pas des 302 par défaut
• Audite les chaînes de redirections et élimine les intermédiaires inutiles
• Contrôle les redirections via curl ou l'inspecteur réseau : le CMS peut mentir dans son interface
• Surveille les logs Googlebot pour repérer les 302 qui persistent anormalement
• Documente chaque 302 légitime (A/B test, saisonnier) pour éviter qu'elle ne soit « corrigée » par erreur
• Teste le comportement après mise en cache navigateur : une 301 peut bloquer une correction rapide si mal configurée