Comment configurer les redirections 301 sans perdre de trafic

Un changement d'URL qui tourne mal, ça ressemble à ça : le lundi, votre page "tarifs" est en troisième position sur sa requête. Le mardi, vous déployez la nouvelle arborescence. Le mercredi, elle a disparu. Pas en 404 franche — pire. Une petite page blanche qui dit "not found" à Google, qui l'enregistre consciencieusement, et qui vous regarde ensuite perdre trois semaines de positions.

Configurer une redirection 301 correctement n'a rien de sorcier. Mais l'erreur est si banale, et ses conséquences si disproportionnées, qu'elle mérite qu'on s'y attarde vraiment. J'ai cassé un site entier comme ça en 2023. J'avais oublié une règle. Une seule. Le site a mis cinq semaines à s'en remettre, et j'ai appris ma leçon à la dure.

Qu'est-ce qu'une redirection 301, et pourquoi elle protège votre trafic

Le code HTTP 301 veut dire "Moved Permanently" : déplacé de façon définitive. Quand un navigateur ou un robot d'indexation tombe sur cette réponse, il comprend que l'ancienne URL n'existe plus et que la nouvelle est sa remplaçante légitime. Google transfère alors l'essentiel de la popularité (les liens, l'historique, la pertinence) vers la destination.

L'essentiel, pas la totalité. Et c'est là que la nuance commence.

Les trois codes à ne pas confondre

Il existe plusieurs redirections, et chaque erreur de casting se paye.

• 301 — déplacement définitif. C'est celle que vous voulez pour une migration, un changement de nom de domaine, ou un renommage de slug.
• 302 — déplacement temporaire. Utile pour un test ou une page en maintenance. Google garde l'ancienne URL dans son index et ne transfère pas la valeur.
• Meta refresh / JavaScript — une redirection côté client. Facile à mettre en place, mais l'indexation peut ne jamais la suivre. À éviter pour un déplacement de contenu.

Beaucoup de blogueurs sortent la 302 par défaut, persuadés que "c'est juste une redirection, quelle importance". Ça compte énormément. Une 302 sur une migration complète, c'est un signal envoyé à Google : "reste là, je reviens". Sauf que vous ne revenez pas. Résultat : les deux URLs traînent dans l'index, la valeur se divise, et vous vous demandez pendant des semaines pourquoi rien ne remonte.

Préparer la cartographie avant de toucher au serveur

La partie que tout le monde saute. Moi le premier, pendant longtemps. J'ai configuré des redirections à l'aveugle en me disant que je verrais bien ce qui casse. Mauvaise approche.

La liste des URLs à migrer

Avant de toucher à quoi que ce soit, exportez la liste complète de vos URLs actuelles. Pas seulement celles du menu. Celles qui reçoivent du trafic, celles qui ont des backlinks, celles qui traînent dans les archives et qui, parfois, génèrent 40 visites par mois sans qu'on s'en rende compte.

Vous pouvez croiser deux sources : votre plan de site XML (pour la liste exhaustive) et votre outil de statistiques (pour celles qui comptent vraiment). Les secondes sont prioritaires.

L'état des lieux des liens internes

Une redirection 301 n'a de sens que si elle pointe vers une URL qui existe. Si vous redirigez l'ancienne page "blog/conseils" vers "ressources/conseils" mais que la seconde est un article totalement différent, vous trompez Google. Le transfert de pertinence se fait sur le sujet. Un article recyclé vers un autre sujet, c'est une redirection techniquement valide mais sémantiquement absurde.

Le test que j'utilise : est-ce qu'un lecteur qui arrive là s'attend à trouver à peu près ce qu'il cherchait ? Si la réponse est non, la redirection pointe vers la mauvaise cible.

Comment configurer les redirections 301 sans perdre de trafic, en pratique

Voyons la syntaxe réelle. Trois environnements couvrent 90 % des cas : serveur Apache, serveur Nginx, et WordPress.

Sur Apache (fichier .htaccess)

La règle de base, écrite à la main :

Redirect 301 /ancienne-page/ https://votresite.com/nouvelle-page/

Pour un domaine entier :

RewriteEngine On
RewriteRule ^(.*)$ https://nouveau-domaine.com/$1 [R=301,L]

Et pour une redirection conditionnelle (par exemple HTTP vers HTTPS) :

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Un piège : chaque règle `Redirect` doit être unique. Deux règles pointant vers la même cible créent un conflit silencieux.

Sur Nginx

La syntaxe est différente, mais la logique identique :

location = /ancienne-page/ {
    return 301 https://votresite.com/nouvelle-page/;
}

Pour un domaine complet :

server {
    listen 80;
    server_name ancien-domaine.com;
    return 301 https://nouveau-domaine.com$request_uri;
}

Le `return 301` est plus propre que `rewrite ... permanent` dans la plupart des cas. Nginx l'exécute plus vite, et le code est plus lisible.

Sur WordPress

Deux options. Un plugin (Redirection, Yoast, Rank Math) gère bien les cas simples : une URL ancienne, une URL nouvelle, et c'est réglé. La deuxième option, plus fiable sur les gros volumes, c'est de passer par votre `.htaccess` même sur WordPress — les règles serveur s'exécutent avant que WordPress ne charge quoi que ce soit.

Si vous migrez plus de 50 URLs, utilisez un fichier de règles plutôt qu'un plugin. Le plugin ajoute une requête base de données à chaque visite. Sur un site qui reçoit 20 000 visites mensuelles, ça commence à se sentir.

Les erreurs qui coûtent cher

Voici les quatre que je vois le plus souvent — et celle que j'ai commise.

Les chaînes de redirections

Une chaîne, c'est A → B → C. Chaque saut affaiblit le signal. Google finit bien par trouver la destination, mais la valeur transmise s'en trouve réduite. La règle : toujours une seule étape, de A directement vers C. Si vous découvrez une chaîne existante, corrigez la source, pas la destination.

Mon erreur de 2023. J'avais redirigé mon ancien blog vers un sous-domaine, qui lui-même redirigeait vers une nouvelle URL. Trois sauts. J'ai perdu 40 % du trafic organique pendant cinq semaines. Corrigé en une après-midi une fois la chaîne identifiée.

Les boucles

Une boucle, c'est A → B → A. Le navigateur affiche une erreur, Google abandonne l'indexation. C'est rare mais ça arrive quand vous mélangez des règles www/non-www avec des règles de trailing slash. Le test rapide : visitez chaque URL redirigée manuellement. Chaque. Une. Douze URLs, c'est 12 tests. Vingt minutes pour éviter des semaines de problème.

Les 404 qui traînent

Un 404 n'injecte pas de pénalité. Mais un 404 sur une ancienne URL qui recevait du trafic, c'est une perte sèche. Et parfois, la 404 n'est visible que dans la Search Console, jamais côté utilisateur — parce que Google continue à crawler l'ancienne adresse pendant des mois. Vérifiez la Search Console deux semaines et six semaines après la migration.

La 301 vers une URL non indexable

Rediriger vers une page en noindex, c'est garantir que Google abandonne la valeur. Ou vers une page en 404. Ou vers une page qui redirige ailleurs. Toute destination doit être une URL 200, indexable, sur le même sujet.

Vérifier et surveiller après la mise en ligne

Une redirection configurée n'est pas une redirection vérifiée. Il y a un monde entre les deux.

Le test technique

Ouvrez la console développeur, cochez "Preserve log", et visitez l'ancienne URL. Vous devez voir une réponse 301, puis une réponse 200 sur la nouvelle adresse. S'il y a un 200 sur l'ancienne, la redirection ne fonctionne pas. S'il y a plusieurs 301 à la suite, c'est une chaîne.

Le test de trafic

Une semaine après la migration, comparez votre trafic organique à la même période l'année précédente. Une perte de 5 à 10 % est normale, surtout si vous avez modifié l'arborescence. Une perte de 30 % ou plus signale un problème. Six semaines après, le trafic devrait être revenu au niveau précédent, voire au-dessus.

Le test des liens internes

Vos liens internes doivent pointer vers les nouvelles URLs, pas vers les anciennes. Sinon, chaque visite interne déclenche une redirection — ce qui fonctionne, mais qui ralentit le crawl et brouille le signal. Corrigez les liens internes, pas les redirections.

Une astuce que j'utilise systématiquement : après une migration, je cherche dans le code source du site toute mention de l'ancien slug. Là où il reste, je remplace. La redirection ne sert qu'aux visiteurs externes et à Google. Pas à moi.

Faut-il conserver les redirections pour toujours ?

Oui. Aussi longtemps que l'ancienne URL peut être cliquée quelque part, la redirection doit exister. Les backlinks externes pointent vers l'ancienne URL. Les partages sur les réseaux sociaux aussi. Les mails newsletter envoyés il y a trois ans, toujours dans la boîte de réception de quelqu'un.

J'ai déjà vu quelqu'un supprimer ses redirections un an après une migration "parce que ce n'était plus utile". Six mois plus tard, il ne comprenait pas pourquoi certains de ses meilleurs backlinks n'était plus comptabilisés.

Une redirection 301 ne coûte rien à conserver. Elle coûte cher à recréer.

Ce qui compte vraiment

La différence entre une migration réussie et une migration catastrophique tient rarement à la syntaxe. Elle tient à la préparation — à savoir quelles URLs existent, où elles pointent, et ce que Google en pense.

La syntaxe, vous la trouverez dans n'importe quelle documentation. La cartographie, c'est vous qui la construisez. Et c'est elle qui décidera si, dans six semaines, votre trafic ressemble à ce qu'il était avant — ou à un cimetière de pages blanches.

Une dernière chose. Si vous devez migrer un site, prévoyez une fenêtre où rien d'autre ne bouge. Pas de refonte graphique. Pas de changement de CMS. Pas de nouvelle campagne d'acquisition. Une seule variable à la fois. C'est chiant, c'est lent, et c'est la seule façon de savoir ce qui a vraiment cassé quand quelque chose casse.