Une redirection 301 indique qu’une page a déménagé pour de bon ; une 302 indique que le déplacement est temporaire et que l’ancienne adresse reviendra. Les moteurs de recherche tiennent compte de cette différence : après une 301, ils indexent la nouvelle adresse à la place de l’ancienne ; après une 302, ils conservent généralement l’ancienne. Utilisez une 301 (ou une 308) pour tout ce qui est définitif, comme une page renommée, un nouveau domaine ou le passage en HTTPS, et une 302 (ou une 307) uniquement si l’adresse d’origine doit vraiment revenir. Limitez chaque redirection à un seul saut, et vérifiez-la avec un outil qui affiche chaque étape.
Les codes de statut de redirection
Une redirection est une réponse de la famille 3xx accompagnée d’un en-tête Location qui indique la nouvelle adresse. En pratique, cinq codes comptent :
CodeSignificationConserve la méthodeÀ utiliser pour301 Moved PermanentlyDéplacé définitivementPas garanti : les navigateurs transforment un POST en GETPages renommées, nouveaux domaines, passage de HTTP à HTTPS302 FoundTemporairement ailleursPas garanti : les navigateurs transforment un POST en GETDéplacements de courte durée, renvoi des visiteurs vers une page de connexion303 See OtherRécupérer le résultat à une autre adresseNon, toujours un GETAprès l’envoi d’un formulaire, pour qu’un rechargement ne le renvoie pas une seconde fois307 Temporary RedirectTemporairement ailleursOui, méthode et corpsDéplacements temporaires d’endpoints d’API et de formulaires308 Permanent RedirectDéplacé définitivementOui, méthode et corpsDéplacements définitifs d’endpoints d’API et de formulaires
Pour les pages ordinaires, que les navigateurs récupèrent en GET, 301 et 308 se comportent de la même façon, tout comme 302 et 307. La différence apparaît quand un client envoie un POST : après une 301 ou une 302, la plupart des clients le répètent en GET sans le corps, alors que 307 et 308 les obligent à renvoyer exactement la même requête. C’est pourquoi une API qui déplace un endpoint doit utiliser 308 ou 307. La liste complète des codes figure dans la référence des codes de statut HTTP.
L’effet des redirections sur le SEO
La documentation de Google sur les redirections considère 301 et 308 comme permanentes, et 302, 303 et 307 comme temporaires. Une redirection permanente est un signal fort indiquant que la cible doit apparaître dans les résultats de recherche à la place de l’ancienne adresse. Une redirection temporaire est un signal faible : l’ancienne adresse reste donc généralement indexée.
D’où trois erreurs courantes :
Une 302 pour un déplacement définitif. De nombreux frameworks et plugins redirigent en 302 par défaut. Après une migration de site, vérifiez que les redirections répondent bien en 301 ou en 308.
Tout rediriger vers la page d’accueil. Quand une ancienne page n’a pas d’équivalent, Google peut traiter une redirection vers la page d’accueil comme une soft 404. Envoyez chaque ancienne page vers la page la plus proche, ou laissez-la répondre 404 ou 410.
Des liens qui pointent encore vers des redirections. Une redirection est un filet de sécurité, pas une destination. Mettez à jour les liens internes, les balises canonical et le sitemap avec l’adresse finale, pour que ni les visiteurs ni les robots d’exploration ne paient le saut supplémentaire.
Les redirections côté serveur sont le signal le plus clair. Les balises meta refresh et les redirections JavaScript fonctionnent pour les visiteurs, mais les moteurs de recherche ne les voient qu’après avoir chargé la page, et d’autres clients ne les voient pas du tout.
Laquelle choisir
Une page a été renommée ou fusionnée avec une autre : 301.
Le site a changé de domaine, est passé en HTTPS, ou passe du www au domaine nu (ou l’inverse) : 301 depuis chaque ancienne variante, directement vers l’adresse finale.
Une page se trouve temporairement ailleurs, le temps d’une campagne ou d’une refonte : 302.
Un visiteur doit d’abord se connecter : 302 vers la page de connexion, puis retour.
Un formulaire a été envoyé : 303 vers la page de résultat.
Un endpoint d’API a été déplacé : 308 si c’est définitif, 307 si c’est provisoire, pour que les clients conservent leur méthode et leur corps.
Le site est en maintenance : aucune redirection. Répondez 503 Service Unavailable sur l’adresse d’origine, pour que les moteurs de recherche reviennent plus tard au lieu d’indexer une page de maintenance.
Les navigateurs mémorisent les redirections permanentes
Les navigateurs mettent en cache les réponses 301 et 308, souvent longtemps, et les suivent sans redemander au serveur. Une mauvaise redirection permanente continue donc d’envoyer les visiteurs réguliers au mauvais endroit, même après la correction côté serveur. Quand vous créez une nouvelle règle, testez-la d’abord en 302, puis passez-la en 301 une fois qu’elle est correcte. Si une mauvaise 301 est déjà partie, un en-tête Cache-Control: no-store sur les redirections suivantes aide les nouveaux visiteurs, mais les copies que les navigateurs ont déjà en cache expirent à leur propre rythme.
Chaînes et boucles de redirection
Une chaîne est une redirection vers une adresse qui redirige à son tour : http://example.com vers https://example.com vers https://www.example.com vers https://www.example.com/en/. Chaque saut ajoute un aller-retour avant que la page ne commence à se charger, et Google suit au maximum 10 sauts. Les chaînes s’allongent au fil des migrations, chacune ajoutant sa règle par-dessus la précédente. Pour les corriger, envoyez chaque ancienne variante directement vers l’adresse finale, en un seul saut.
Une boucle est une chaîne sans fin : deux règles renvoient les visiteurs de l’une à l’autre jusqu’à ce que le navigateur abandonne avec « trop de redirections ». Les causes habituelles :
HTTP et HTTPS. Un CDN communique avec votre serveur en HTTP, tandis que le serveur redirige chaque requête HTTP vers HTTPS. Derrière Cloudflare, c’est le réglage SSL Flexible ; le mode Full (strict) règle le problème.
www et le domaine nu. Le serveur web ajoute le www et l’application le retire, ou l’inverse. Dans WordPress, vérifiez que l’adresse web de WordPress et l’adresse web du site correspondent à la règle du serveur.
Barres obliques finales et règles de langue. Une règle ajoute une barre oblique ou un préfixe de langue, une autre le retire.
Comment vérifier une redirection
Depuis un terminal, curl affiche chaque saut avec son code de statut et son en-tête Location :
curl -sIL http://example.com/old-page | grep -iE « ^(HTTP|location) »
HTTP/1.1 301 Moved Permanently
Location: https://example.com/old-page
HTTP/2 301
location: https://example.com/new-page
HTTP/2 200
Deux sauts : la deuxième règle aurait dû passer en premier. Dans un navigateur, ouvrez les outils de développement, cochez Preserve log dans l’onglet Network et chargez l’ancienne adresse ; chaque redirection apparaît sur sa propre ligne. N’oubliez pas que le navigateur peut répondre à une 301 depuis son cache : une fenêtre de navigation privée donne une image plus fiable.
Vous pouvez aussi utiliser notre vérificateur de redirections gratuit : saisissez une URL pour voir chaque saut avec son code de statut, l’endroit où la chaîne aboutit, et si elle boucle, s’allonge trop ou utilise une redirection temporaire là où vous vouliez sans doute une redirection permanente. Il suit jusqu’à 5 sauts, vérifiés en direct depuis Stockholm.
Mettre en place une 301
La plupart des hébergeurs et des CDN proposent un réglage de redirection dans leur tableau de bord. Dans la configuration du serveur :
# nginx: one page
location = /old-page { return 301 /new-page; }
# nginx: a whole domain, keeping the path
server {
server_name old-example.com www.old-example.com;
return 301 https://example.com$request_uri;
}
# Apache (.htaccess): one page
Redirect 301 /old-page /new-page
Ensuite, vérifiez l’ancienne adresse, ses variantes HTTP et www, ainsi qu’une adresse avec des paramètres de requête, et assurez-vous que chacune atteint la page finale en un seul saut.
Surveiller les redirections avec Uptimecheck
Un moniteur HTTP(S) de la surveillance de disponibilité d’Uptimecheck suit par défaut jusqu’à 10 redirections et évalue la page d’arrivée, considérée comme disponible lorsqu’elle répond avec un statut compris entre 200 et 399. Une boucle, ou une chaîne plus longue, est signalée comme une panne avec « Too many redirects », et l’incident précise si la chaîne rebondit entre HTTP et HTTPS ou entre le www et le domaine nu. Les vérifications s’exécutent jusqu’à une fois par minute depuis Stockholm, Londres et New York, et une seconde vérification confirme la panne avant de vous alerter.
Pour surveiller la redirection elle-même, par exemple après un changement de domaine, désactivez Follow redirects afin que le moniteur évalue le code de statut propre à la redirection, réglez Expected status codes sur 301, et ajoutez une vérification d’en-tête indiquant que Location doit être égal à la nouvelle adresse. Si quelqu’un transforme plus tard la redirection en 302 ou la fait pointer ailleurs, vous êtes prévenu. Consultez comment ajouter votre premier moniteur et le guide des codes de statut HTTP en surveillance.
Sachez quand une migration casse quelque chose. Essayez Uptimecheck gratuitement pendant 14 jours, sans carte bancaire.