Pour vérifier une redirection, il faut suivre toute la chaîne entre l'URL demandée et la page finale, et noter le code HTTP de chaque étape. Une bonne redirection est un seul saut en 301 (ou 308) vers l'URL définitive, en HTTPS. Les problèmes les plus fréquents sont les chaînes de plusieurs sauts, les boucles, les 302 utilisées pour un déménagement définitif, et les redirections qui repassent par HTTP.
Voici comment tester une redirection en ligne ou en ligne de commande, et comment corriger ce que vous trouvez.
Les codes de redirection à connaître
| Code | Signification | Quand l'utiliser |
|---|
301 | Déplacé définitivement | Changement d'URL, passage en HTTPS, migration de domaine |
308 | Déplacé définitivement, méthode conservée | Comme 301, quand un formulaire POST doit rester en POST |
302 | Trouvé ailleurs, temporairement | Page de maintenance, test A/B, redirection selon la langue |
307 | Temporaire, méthode conservée | Comme 302, pour les requêtes POST |
Deux autres mécanismes existent : la balise <meta http-equiv="refresh"> et la redirection en JavaScript. Google les suit, mais plus lentement et moins sûrement. Réservez-les aux cas où vous n'avez pas accès à la configuration du serveur.
Ce que Google fait vraiment des redirections
- 301 et 302 ne font pas perdre de « jus SEO » : Google a confirmé que les redirections 30x ne diluent pas le PageRank. La différence est ailleurs : une 301 ou 308 est un signal fort que la nouvelle URL doit remplacer l'ancienne dans les résultats. Une 302 ou 307 est un signal faible, et Google peut garder l'ancienne URL.
- Googlebot suit au maximum 10 sauts dans une chaîne. Au-delà, la page n'est pas explorée. Bien avant cette limite, chaque saut ajoute une requête et ralentit le chargement pour les visiteurs.
- Une 302 laissée des mois finit en général par être traitée comme une 301. Mieux vaut ne pas compter dessus et utiliser le bon code dès le départ.
Tester une redirection en ligne
Le Redirect Checker suit la chaîne complète d'une URL et affiche chaque étape : code HTTP, URL de destination, passage HTTP ou HTTPS. Il signale les boucles, les chaînes trop longues et les retours en HTTP au milieu d'une chaîne HTTPS.
Testez au minimum les quatre variantes de votre domaine. Toutes doivent arriver sur la même URL, en un seul saut :
http://exemple.frhttp://www.exemple.frhttps://exemple.frhttps://www.exemple.fr
Tester en ligne de commande avec curl
Pour voir chaque étape avec ses en-têtes :
curl -sIL http://exemple.fr | grep -iE "^(HTTP|location)"
Résultat typique d'une chaîne à corriger :
HTTP/1.1 301 Moved Permanently
Location: https://exemple.fr/
HTTP/2 301
location: https://www.exemple.fr/
HTTP/2 200
Ici, deux sauts au lieu d'un : http://exemple.fr passe d'abord en HTTPS, puis ajoute le www. La version corrigée redirige directement vers https://www.exemple.fr/.
Pour ne compter que les sauts et l'URL finale :
curl -sL -o /dev/null -w "%{num_redirects} saut(s) vers %{url_effective}\n" http://exemple.fr
Les problèmes les plus fréquents
La chaîne de redirections
Elle apparaît après plusieurs migrations successives : HTTP vers HTTPS, puis ajout du www, puis changement de structure des URL. Chaque règle ajoute un saut. La correction consiste à faire pointer chaque ancienne URL directement vers sa destination finale.
La boucle de redirection
Le navigateur affiche « ERR_TOO_MANY_REDIRECTS ». Cause classique : le CDN (Cloudflare en mode SSL « Flexible ») contacte le serveur en HTTP, le serveur redirige vers HTTPS, le CDN recontacte en HTTP, et ainsi de suite. Passez Cloudflare en mode « Full (strict) » avec un certificat valide sur le serveur.
La redirection vers la page d'accueil
Lors d'une refonte, toutes les anciennes pages sont redirigées vers l'accueil. Google traite souvent ces redirections comme des erreurs 404 « soft » : le lien vers l'ancienne page ne compte plus. Redirigez chaque ancienne page vers son équivalent, ou laissez une vraie 404 s'il n'y en a pas.
Le retour en HTTP
Une chaîne HTTPS qui repasse par HTTP expose la requête en clair et casse la protection HSTS. C'est souvent une règle de réécriture qui construit l'URL avec http:// en dur.
Corriger dans .htaccess (Apache)
Une seule règle pour tout envoyer vers https://www. en un saut :
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^ https://www.exemple.fr%{REQUEST_URI} [L,R=301]
Placez cette règle en premier, avant celles de votre CMS. Sur Nginx, l'équivalent est un bloc server dédié avec return 301 https://www.exemple.fr$request_uri;.
Après une migration : surveiller dans la durée
Une redirection qui marche le jour de la mise en ligne peut casser plus tard : mise à jour d'un plugin, changement d'hébergeur, nouveau CDN. Le jour où la redirection de votre ancien domaine disparaît, les liens qui pointent vers lui ne mènent plus nulle part. Domains Defender surveille la disponibilité de vos sites et vos DNS, et vous alerte si une page ne répond plus correctement. Pour un changement de DNS sans coupure, voir aussi migrer ses DNS d'OVH vers Cloudflare sans interruption.
Questions fréquentes
301 ou 302 pour le SEO ?
301 pour un changement définitif, 302 pour un changement temporaire. Les deux transmettent la popularité de la page, mais seule la 301 indique clairement à Google de remplacer l'ancienne URL dans ses résultats.
Combien de redirections successives sont acceptables ?
Une seule, idéalement. Deux restent sans conséquence grave. Au-delà de trois, corrigez : chaque saut ralentit la page, et Googlebot abandonne après 10.
Comment vérifier une redirection 301 ?
Avec le Redirect Checker, ou avec curl -sIL en ligne de commande. Le code affiché à chaque étape doit être 301 ou 308, et la dernière réponse 200.
Pourquoi mon navigateur ne voit pas ma nouvelle redirection ?
Les navigateurs gardent les redirections 301 en cache, parfois longtemps. Testez en navigation privée ou avec curl, qui n'a pas de cache.