Pourquoi les redirections 307 et 308 sont-elles inutiles pour le SEO classique ?

Quelle est la différence entre 301/302 et 307/308 ?

Les redirections HTTP classiques 301 (permanente) et 302 (temporaire) convertissent automatiquement les requêtes POST en GET. Autrement dit, si un formulaire envoie des données via POST vers une URL redirigée en 301, le navigateur transforme la requête en GET et perd les données du formulaire.

Les codes 307 (temporaire) et 308 (permanente) corrigent ce comportement : ils préservent la méthode HTTP originale. Un POST reste un POST après redirection. Le navigateur redemande confirmation à l'utilisateur avant de renvoyer les données.

Pourquoi Mueller précise-t-il « sans impact SEO direct » ?

Les APIs web utilisent massivement les requêtes POST pour transmettre des données structurées. Ces endpoints ne sont généralement pas destinés à l'indexation — ils servent à échanger de l'information entre machines, pas à afficher du contenu crawlable.

Google ne crawle pas vos routes API comme il crawlerait vos pages HTML. Les redirections 307/308 concernent donc un périmètre technique qui échappe aux mécanismes d'indexation traditionnels.

Les praticiens doivent-ils revoir leurs redirections existantes ?

Non. Vos redirections SEO classiques (migrations de domaine, refonte d'URL, suppressions de pages) fonctionnent parfaitement avec 301 et 302. Les Googlebots utilisent principalement des requêtes GET pour crawler.

Les codes 307/308 restent pertinents dans des scénarios très spécifiques : applications web avec formulaires POST, interfaces d'API publiques, ou architectures où la méthode HTTP doit être préservée. Pas dans 99 % des cas SEO quotidiens.

• Les 301/302 convertissent POST en GET automatiquement
• Les 307/308 préservent la méthode HTTP originale (POST reste POST)
• Cette distinction concerne surtout les APIs et formulaires web, rarement indexés
• Aucune raison de modifier vos redirections SEO existantes si elles fonctionnent en 301/302
• Le crawler Google utilise majoritairement des requêtes GET pour l'indexation

Cette déclaration clarifie-t-elle vraiment le comportement de Google ?

Mueller reste dans une posture descriptive. Il explique la norme HTTP, pas le comportement réel du crawler. Soyons honnêtes : la plupart des sites n'ont jamais utilisé 307 ou 308, et ça n'a jamais posé problème.

Ce qui manque ici, c'est une confirmation explicite : Google traite-t-il différemment un 308 d'un 301 lorsqu'il rencontre exceptionnellement une ressource POST indexable ? Probablement non, mais [À vérifier] dans des cas limites comme certains endpoints GraphQL exposés publiquement.

Dans quels rares cas cette distinction pourrait-elle avoir un impact SEO ?

Imaginons une architecture hybride où certaines routes servent à la fois d'endpoints API (POST) et de pages crawlables (GET). Scénario rare mais possible avec des frameworks modernes type Next.js ou SvelteKit.

Dans ce cas, utiliser un 308 au lieu d'un 301 pourrait théoriquement mieux préserver l'intention. Mais concrètement ? Google crawle la version GET, l'indexe, et ignore le comportement POST. L'impact reste donc marginal, voire inexistant sur les SERPs.

Faut-il privilégier 307/308 dans une stratégie SEO moderne ?

Non. Sauf si vous avez un besoin technique explicite de préserver POST. Le 301 reste le standard pour les redirections permanentes SEO — il transfère le PageRank, conserve l'historique de crawl, et fonctionne parfaitement pour 99,9 % des scénarios.

Le 308 n'apporte aucun avantage SEO mesurable si votre site ne manipule que du GET. C'est une subtilité protocolaire utile aux développeurs d'APIs, pas aux praticiens qui gèrent des migrations de contenu.

Que faut-il faire concrètement avec cette information ?

Rien, si votre site fonctionne en mode classique (pages HTML, formulaires traités côté serveur, redirections 301/302 existantes). Vos redirections actuelles continuent de fonctionner exactement comme avant.

Si vous gérez une API publique ou une application web avancée avec des formulaires POST importants, envisagez 307/308 pour éviter la conversion automatique POST → GET. Mais c'est un choix d'architecture, pas une optimisation SEO.

Quelles erreurs éviter ?

Ne remplacez pas vos 301 par des 308 « au cas où ». Vous n'améliorerez rien côté indexation et risquez d'introduire des comportements inattendus si votre stack technique n'est pas préparée à gérer POST après redirection.

Autre piège : rediriger un endpoint API en 301/302 sans vérifier que les clients (apps mobiles, scripts) gèrent bien la conversion POST → GET. Résultat : erreurs 400 (Bad Request) ou perte de données. Là, un 307/308 aurait été pertinent.

• Conservez vos redirections 301 pour les migrations de pages HTML classiques
• Utilisez 308 uniquement si vous devez préserver POST (APIs, webhooks, formulaires complexes)
• Vérifiez que votre serveur supporte 307/308 avant de les implémenter (certains vieux serveurs ne gèrent pas ces codes)
• Ne mélangez pas 301 et 308 sur une même URL — choisissez en fonction de l'usage réel (GET ou POST)
• Testez vos redirections avec curl -X POST pour vérifier le comportement côté API
• Documentez vos choix de codes HTTP dans votre documentation technique pour éviter les confusions futures