Redirections 301 : quand les utiliser, comment les configurer et comment les vérifier

En bref : une redirection 301 indique aux navigateurs et aux moteurs de recherche qu'une URL a été déplacée de façon permanente. Google considère les codes 301 et 308 comme un signal fort que la cible doit être l'URL canonique ; les codes 302 et 307 sont temporaires et laissent l'ancienne URL en place. Chaque site doit répondre à une seule adresse : http://, https://, www et non-www doivent tous rediriger vers la même URL finale, en une seule étape. Conservez les redirections au moins un an, mettez à jour les liens internes vers l'adresse finale et vérifiez toute la chaîne, pas seulement sa destination.

Quand elles fonctionnent, les redirections sont invisibles. Quand elles dysfonctionnent, les symptômes sont flous : un classement réparti entre www et non-www, une migration qui fait perdre du trafic pendant des mois, une page d'accueil qui met une seconde de plus à s'afficher parce qu'elle rebondit sur trois adresses. La plupart de ces problèmes se repèrent en une minute, en suivant chaque version de votre adresse jusqu'au bout.

Ce guide présente les types de redirections et la façon dont Google les traite, les versions d'hôte que tout site doit fusionner, les chaînes et les boucles, la configuration sur les serveurs courants, le fonctionnement de notre testeur de redirections gratuit et la manière de corriger chaque problème qu'il signale.

Qu'est-ce qu'une redirection ?

Une redirection est une réponse du serveur qui indique « cette ressource se trouve ailleurs » et donne la nouvelle adresse dans un en-tête Location. Le navigateur demande alors automatiquement la nouvelle adresse. Côté serveur, une redirection ressemble à ceci :

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/new-page

Le code de statut indique aux clients comment traiter le déplacement. MDN distingue les redirections permanentes, après lesquelles les robots d'exploration « mettent à jour l'URL d'origine », et les redirections temporaires, que les robots « ne mémorisent pas ».

La documentation de Google sur les redirections classe aussi une balise meta refresh instantanée (0 seconde) et un changement de location en JavaScript parmi les redirections permanentes, et une balise meta refresh différée parmi les redirections temporaires. Google recommande, dans la mesure du possible, des redirections permanentes côté serveur et précise de n'utiliser les redirections JavaScript que si l'on ne peut pas recourir à une redirection côté serveur ou à une meta refresh, car le rendu peut échouer.

Pourquoi les redirections comptent pour le SEO

Elles consolident les doublons. Le guide de canonicalisation de Google présente les redirections comme « un signal fort que la cible de la redirection doit devenir canonique ». Sans elles, des signaux comme les liens peuvent se disperser sur plusieurs URL pour un même contenu.

Elles font suivre les pages déplacées lors d'une migration. Lorsque les URL changent, une 301 de chaque ancienne URL vers son équivalent indique à Google de les remplacer dans l'index et envoie les visiteurs des anciens liens vers la bonne page.

Elles protègent le HTTPS. Google « préfère les pages HTTPS aux pages HTTP équivalentes comme canoniques », et le même guide cite la redirection HTTP vers HTTPS comme l'un des moyens de renforcer ce choix.

Elles coûtent du temps. Chaque étape est un aller-retour supplémentaire avant le début du chargement de la page. Sur un réseau mobile, une chaîne de trois redirections provoque un délai perceptible avant que quoi que ce soit s'affiche.

Un site, une adresse

Pour un robot d'exploration, ce sont quatre sites différents, même s'ils affichent la même page :

http://example.com/
http://www.example.com/
https://example.com/
https://www.example.com/

Choisissez-en une, en général la version HTTPS avec ou sans www, et faites répondre les trois autres par une seule 301 directement vers elle. Le choix entre www et non-www relève du goût ; l'essentiel est qu'une seule version réponde avec un code 200. Assurez-vous aussi que le certificat TLS couvre à la fois example.com et www.example.com, sinon la redirection https://www échoue avant même de s'exécuter.

La même règle s'applique à l'intérieur du site : si /pricing et /pricing/ répondent tous deux 200, choisissez une forme et redirigez l'autre.

Chaînes et boucles

Une chaîne est une redirection qui mène vers une autre redirection. Le cas le plus courant est celui où le protocole et l'hôte sont traités en deux étapes distinctes :

http://www.example.com/  301 →  https://www.example.com/  301 →  https://example.com/

Les robots de Google « suivent jusqu'à 10 redirections » (HTTP status codes and Google Search) : une chaîne de deux étapes ne fera donc pas perdre la page. Mais le guide de Google sur les déménagements de site recommande d'« éviter d'enchaîner les redirections » et de rediriger « directement vers la destination finale » ; si ce n'est pas possible, gardez des chaînes courtes, « idéalement pas plus de 3 et moins de 5 ». Dans tous les cas, les visiteurs paient chaque étape.

Une boucle est une chaîne sans fin : A redirige vers B et B revient vers A, souvent parce qu'une règle HTTPS du serveur et une autre du CDN se contredisent. MDN précise que les navigateurs détectent les boucles et affichent une erreur : la page est alors tout simplement inaccessible.

Comment configurer une redirection 301

Apache (.htaccess ou virtual host), pour fusionner toutes les versions vers https://www.example.com :

RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\.example\.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

Pour une seule page, Redirect 301 /old-page https://www.example.com/new-page suffit. Attention : selon MDN, un Redirect sans code envoie par défaut une 302.

Nginx, avec un seul bloc server qui capte toutes les autres versions :

server {
    listen 80;
    listen 443 ssl;
    server_name example.com www.example.com;
    # ssl_certificate lines here for the 443 listener
    if ($host = example.com) { return 301 https://www.example.com$request_uri; }
    if ($scheme = http)      { return 301 https://www.example.com$request_uri; }
    # ... the site itself
}

Beaucoup de configurations utilisent plutôt des blocs server séparés ; les deux approches fonctionnent tant que chaque version atteint l'adresse finale en une seule étape.

Next.js, dans next.config.js :

module.exports = {
  async redirects() {
    return [
      { source: '/old-blog/:slug', destination: '/blog/:slug', permanent: true },
    ]
  },
}

La documentation Next.js indique que permanent: true envoie un 308 et permanent: false un 307, afin de préserver la méthode de la requête. Google traite le 308 comme permanent : c'est donc sans problème.

CDN et hébergeurs. La plupart des CDN et des panneaux d'hébergement proposent des règles de redirection et une option « toujours utiliser HTTPS ». Utilisez une seule couche par tâche : si le CDN passe de HTTP à HTTPS et que le serveur d'origine redirige aussi les hôtes, vous obtenez une chaîne de deux étapes, ou une boucle si les deux se contredisent.

WordPress. L'adresse du site dans Réglages › Général détermine l'hôte canonique ; WordPress redirige les autres hôtes vers celui-ci. Pour les redirections au niveau des pages, utilisez une extension de redirection ou le gestionnaire de redirections de votre extension SEO, et privilégiez les règles serveur pour la fusion des hôtes.

Comment fonctionne le testeur de redirections Searvia

Le testeur de redirections utilise le même moteur que notre outil d'audit SEO de site web : saisissez un domaine, il audite votre page d'accueil et les fichiers qui l'entourent avec 38 vérifications en environ 20 secondes, en affichant en premier les trois vérifications au cœur de cet outil. Voici ce qu'elles font.

Redirections et versions en doublon (priorité moyenne). Le testeur prend le domaine saisi, retire www. et ouvre quatre adresses : http:// et https://, avec et sans www. Il suit chacune sur six redirections au maximum et enregistre où elle aboutit ainsi que le code de statut de chaque étape. Une version est validée si elle aboutit sur le même schéma et le même hôte que l'adresse finale de votre page d'accueil, uniquement par des redirections permanentes (301 ou 308). Résultat :

• Échec si une version aboutit ailleurs, par exemple https://example.com qui répond avec sa propre page alors que https://www.example.com est votre site principal, ou si une version finit dans une boucle de redirections ou nécessite plus de six redirections.
• Avertissement si une version utilise une redirection temporaire (302, 303 ou 307), ou si l'adresse saisie nécessite plus d'une redirection avant de répondre, en comptant à partir de https:// suivi de l'hôte saisi.
• Succès si toutes les versions arrivent sur le même site par des redirections permanentes et que l'adresse principale nécessite une étape ou aucune.

Le rapport liste chacune des quatre versions avec son URL finale, les codes de redirection rencontrés (par exemple 301 › 301) et une coche ou une croix. Les versions qui ne se résolvent pas ou sont inaccessibles, par exemple un hôte www sans enregistrement DNS, sont écartées au lieu d'être comptées en échec.

HTTPS (priorité haute). Il requête http:// suivi de votre hôte sans suivre les redirections. La vérification est validée si le site fonctionne en HTTPS et que la requête HTTP reçoit une réponse 3xx dont le Location commence par https://. Elle échoue avec les messages « HTTP does not redirect to HTTPS » ou « The site does not work over HTTPS ». Si le HTTP simple ne répond pas du tout, la redirection ne peut pas être testée et la vérification affiche une note au lieu d'un succès ou d'un échec.

Statut de la page (priorité haute). La page finale doit répondre avec un statut 2xx. Un 4xx ou un 5xx est un échec.

Ce qu'il ne teste pas

• Les redirections meta refresh et JavaScript. Seules les redirections HTTP sont suivies. Une version qui redirige avec une balise meta apparaît comme aboutissant sur elle-même.
• Les pages internes. Seules les adresses de la page d'accueil sont testées. Pour les redirections au niveau des pages après une migration, explorez la liste des anciennes URL.
• Le nombre d'étapes par version. L'avertissement sur les étapes ne compte que celles de votre adresse principale ; une chaîne permanente de deux étapes sur http://www affiche ses codes dans le tableau (301 › 301) mais ne fait pas baisser le résultat. Utilisez curl pour voir l'URL de chaque étape.

Pour voir chaque étape avec son URL et son code :

curl -sIL http://www.example.com/ | grep -iE '^(HTTP|location)'

Lire le résultat

La note globale couvre les 38 vérifications, pondérées par priorité (haute 10, moyenne 5, basse 2 ; un avertissement vaut la moitié), avec une liste « Fix these first » et un lien de rapport partageable.

Comment corriger chaque problème signalé par le testeur

1. Certaines versions ne redirigent pas vers la version principale

1. Décidez de l'adresse finale : https://www.example.com ou https://example.com.
2. Dans le tableau du rapport, repérez les versions qui aboutissent sur la mauvaise URL.
3. Ajoutez une 301 de chacune d'elles directement vers l'adresse finale, en conservant le chemin ($request_uri dans Nginx, $1 dans Apache).
4. Si la version égarée aboutit sur un tout autre hôte, vérifiez le DNS : un ancien enregistrement A pour www peut pointer vers une page de parking ou un ancien hébergeur.
5. Vérifiez que vos balises canoniques, votre sitemap et vos liens internes utilisent aussi l'adresse finale ; une redirection qui contredit votre canonique envoie des signaux contradictoires.
6. Relancez le testeur de redirections.

2. L'adresse passe par plusieurs redirections

1. Lancez la commande curl -sIL sur l'adresse saisie et lisez la chaîne.
2. Fusionnez les étapes : une seule règle qui envoie toute version non finale directement vers l'URL finale, comme dans les exemples Apache et Nginx ci-dessus.
3. Si le CDN et le serveur d'origine redirigent tous les deux, laissez-en un seul s'en charger. En général, le CDN gère le passage de HTTP à HTTPS et l'origine ne fait rien, ou l'origine fait les deux et le CDN laisse passer les requêtes.
4. Mettez à jour les liens que vous maîtrisez : lien du logo, navigation, signatures d'e-mail, profils sociaux et destinations des annonces doivent pointer vers l'adresse finale.

3. HTTP ne redirige pas vers HTTPS

1. Vérifiez que le HTTPS fonctionne avec un certificat valide couvrant à la fois le domaine nu et www.
2. Ajoutez une redirection permanente de chaque URL http:// vers son équivalent https://, en conservant le chemin.
3. Une fois que tout fonctionne en HTTPS, envisagez HSTS (Strict-Transport-Security: max-age=31536000; includeSubDomains), pour que les navigateurs sautent complètement la requête HTTP. Google cite HSTS comme un autre moyen de renforcer le HTTPS comme canonique. Le testeur d'en-têtes de sécurité le vérifie.

4. Le site ne fonctionne pas en HTTPS

Installez un certificat (Let's Encrypt est gratuit et la plupart des hébergeurs l'automatisent), assurez-vous qu'il couvre tous les noms d'hôte que vous utilisez, puis ajoutez la redirection HTTP vers HTTPS de l'étape 3. Le contenu mixte, c'est-à-dire des scripts ou des images encore chargés en http://, est le chantier suivant.

5. La page d'accueil ne répond pas avec un code 200

Un 5xx indique un problème serveur ; consultez les journaux d'erreurs. Un 403 signifie souvent qu'un pare-feu ou une protection anti-bots refuse les requêtes automatisées, et peut-être aussi les robots des moteurs de recherche. Un 404 sur la page d'accueil signifie généralement qu'une redirection envoie les visiteurs vers un chemin qui n'existe plus. Corrigez la cible, puis revérifiez.

6. Redirections temporaires, boucles ou longues chaînes

1. Repérez la ligne marquée d'une croix et lisez ses codes. Un 302, 303 ou 307 entre des versions d'hôte doit devenir une 301 ou une 308 ; vérifiez le serveur, le CDN et les extensions, car la redirection temporaire est souvent un comportement par défaut (un Redirect Apache sans code envoie une 302).
2. Une boucle signifie généralement que deux couches se contredisent, par exemple un CDN qui renvoie de HTTPS vers HTTP alors que l'origine renvoie de HTTP vers HTTPS. Désactivez l'une des deux.
3. Pour une chaîne de plus de six étapes, remplacez-la par une seule règle qui va directement à l'adresse finale, comme à l'étape 2.

Les redirections lors d'une migration

Lorsque les URL changent, les règles au niveau de l'hôte vues plus haut ne sont qu'un début. Les recommandations de Google sur les déménagements de site ajoutent :

1. Associez chaque ancienne URL à son nouvel équivalent, à l'aide des sitemaps, des journaux serveur, des outils d'analyse et de votre CMS. Tout rediriger vers la page d'accueil n'est pas une correspondance.
2. Redirigez directement vers la destination finale, jamais vers une URL qui redirige à son tour.
3. Donnez à chaque nouvelle URL une canonique auto-référente, mettez à jour les liens internes et vérifiez que chaque sitemap liste les nouvelles URL.
4. Conservez les redirections aussi longtemps que possible, en général au moins un an.

Pour les sites internationaux, Google ajoute une règle : évitez de rediriger automatiquement les visiteurs d'une version linguistique à l'autre selon leur localisation ou la langue de leur navigateur, car « le robot Googlebot provient généralement des États-Unis » et peut ne jamais voir les autres versions (sites multirégionaux). Notre guide hreflang présente l'alternative.

Exemple pratique (hypothétique)

L'exemple suivant est hypothétique et ne repose sur aucune donnée réelle. Bramble & Co, une boutique de meubles fictive, a migré vers une nouvelle plateforme. Le testeur de redirections indique :

Le domaine nu en https:// répondait avec le site complet au lieu de rediriger : la nouvelle plateforme servait les deux hôtes, et seul l'ancien serveur avait la règle sur l'hôte. Les codes montraient aussi que http://bramble.example/ passait par deux étapes et que la première était une 302. L'équipe a ajouté une seule règle 301 au niveau du CDN pour toutes les versions non finales, supprimé la redirection HTTPS propre à la plateforme pour éviter une chaîne, puis relancé le test : les quatre versions aboutissent désormais sur https://www.bramble.example/ en une seule étape.

Une checklist de 15 minutes pour les redirections

1. Lancez le testeur de redirections gratuit sur votre domaine.
2. Vérifiez que les quatre versions aboutissent sur une seule adresse.
3. Contrôlez les codes de chaque version dans le rapport (ou avec curl -sIL) : une seule étape, statut 301 ou 308.
4. Vérifiez que les canoniques, le sitemap et les liens internes utilisent l'adresse finale.
5. Assurez-vous que le certificat couvre à la fois le domaine nu et www.
6. Après une migration, testez un échantillon d'anciennes URL et conservez les redirections au moins un an.

Comment Searvia vous aide

Le testeur de redirections gratuit suit chaque version de votre adresse et vérifie le HTTPS et le statut de la page d'accueil dans un seul rapport partageable. Dans un compte Searvia, l'audit de site explore tout le site chaque semaine et signale les liens internes qui pointent vers des redirections, les URL redirigées ou cassées dans le sitemap et les pages qui renvoient des erreurs, pour que vous puissiez partout pointer directement vers les adresses finales. Le suivi de disponibilité surveille votre site en continu et vous prévient lorsqu'il tombe ou que son certificat est sur le point d'expirer, moment où les redirections HTTPS se cassent le plus souvent. Pour l'ordre complet des vérifications techniques, consultez notre guide d'audit SEO technique.