Configurer une redirection 301 sans perdre le jus de liens
Vous avez refait votre site. Les pages sont plus belles, le contenu est meilleur. Et puis le lendemain, vos positions Google se sont effondrées. Pas parce que vos nouvelles pages sont mauvaises : parce que vous avez oublié de configurer les redirections 301. Ou pire, vous les avez configurées, mais mal.
Je vais vous montrer comment faire ça proprement. Et aussi, ce qui ne marche pas — parce que j'ai fait les deux.
Pourquoi une redirection 301 ne se contente pas de rediriger
Une redirection 301, c'est un statut HTTP qui dit aux navigateurs et aux moteurs de recherche : « Cette page a définitivement changé d'adresse. Voici la nouvelle. »
Le navigateur, lui, s'en fiche pas mal. Il suit la redirection en une fraction de seconde et personne ne remarque rien. Mais Google, lui, fait quelque chose de précis : il transfère les signaux de l'ancienne URL vers la nouvelle. C'est ce qu'on appelle le jus de liens.
Retenez bien ceci : le jus de liens n'est pas une substance magique qui voyage tout seul. C'est un ensemble de signaux — ancres, autorité du domaine, historique de la page — que Google associe à une URL précise. La 301 est le mécanisme qui dit à Google : ces signaux, il faut les rattacher ailleurs.
Une 302, elle, dit : « C'est temporaire, on va revenir. » Google conserve l'ancienne URL en index et ne transfère pas le jus. Je l'ai appris à mes dépens en 2023 quand j'ai mis mon blog en maintenance avec une 302 pensant faire une redirection temporaire. Trois semaines plus tard, mes positions pour « [un mot-clé que je ne vous dirai pas](https://www.example.com) » avaient chuté de 40 %. La redirection a duré quatre semaines. Le rétablissement, lui, a pris trois mois.
La différence entre 301 et 302, ce n'est pas la vitesse. C'est la permanence. Vous redirigez vers une page qui va disparaître dans un mois ? C'est une 302. Vous avez migré votre site définitivement ? C'est une 301. Point.
Points clés à retenir
- La 301 est le seul statut HTTP qui transfère le jus de liens vers la nouvelle URL
- Le .htaccess fonctionne pour Apache, mais le nginx utilise sa propre syntaxe
- Évitez les chaînes de redirection : une seule hop directe, pas cinq
- Redirigez vers la page équivalente, jamais vers l'accueil pour tout
- Testez avec un outil de crawl après déploiement, pas seulement avec votre navigateur
- Les paramètres de tracking et le www sont des pièges classiques du mapping
Configurer une redirection 301 dans le .htaccess
Le fichier `.htaccess`, c'est la méthode historique sur les serveurs Apache. Vous le trouvez à la racine de votre site. S'il n'existe pas, vous le créez.
Voici la syntaxe de base :
Redirect 301 /ancienne-page https://www.votresite.com/nouvelle-page
Cette ligne suffit pour une page unique. Elle est simple, lisible, et elle fonctionne. Vous pouvez aussi utiliser `RedirectMatch` pour un motif plus complexe :
RedirectMatch 301 ^/articles/(.*)$ https://www.votresite.com/blog/$1
Dans ce cas, `/articles/seo` redirige vers `/blog/seo`. Le `$1` reprend ce qui a été capturé par `(.*)`. Parfait pour une migration de structure.
Quand utiliser la réécriture à la place ?
La directive `Redirect` fonctionne sur des chemins complets. Pour des règles plus fines, on passe au module `mod_rewrite` avec `RewriteRule`. C'est plus puissant, mais aussi plus dangereux. Une erreur de regex et c'est tout votre site qui boucle en redirection.
RewriteEngine On
RewriteRule ^?ancienne-page/?$ /nouvelle-page [R=301,L]
La différence avec `Redirect` ? `RewriteRule` fonctionne sur l'URL après traitement du serveur, en interne. `Redirect` travaille au niveau du chemin demandé. En pratique, pour 95 % des cas de migration, `Redirect` ou `RedirectMatch` suffisent.
Mon conseil : commencez simple. Assurez-vous que vos règles marchent. Rendez-les plus complexes seulement si vous y êtes obligé.La redirection www vers non-www : un cas classique
C'est la question qu'on me pose le plus souvent. Vous avez choisi une version canonique, mais les visiteurs continuent d'arriver sur l'autre.
Pour passer de `www.votresite.com` à `votresite.com` :
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.votresite\.com$ [NC]
RewriteRule ^(.*)$ https://votresite.com/$1 [R=301,L]
Et l'inverse, de non-www vers www :
RewriteEngine On
RewriteCond %{HTTP_HOST} ^votresite\.com$ [NC]
RewriteRule ^(.*)$ https://www.votresite.com/$1 [R=301,L]
Le `NC` rend la condition insensible à la casse. Le `L` dit : c'est la dernière règle à traiter. Le `R=301` force le code de statut. Sans lui, la réécriture est interne et l'utilisateur ne voit rien, mais Google non plus.
J'ai migré un site client de non-www vers www en 2025. Nous avons perdu presque toutes les positions pendant dix jours. Pourquoi ? Parce que nous avions oublié de gérer le protocole en même temps. Le site passait de HTTP à HTTPS, et personne n'avait pensé à la double bascule. Résultat : des chaînes de redirection de trois hop.
La règle d'or : une seule redirection. De l'ancienne URL à la nouvelle. Directement. Pas de détour par une autre URL qui redirige elle-même.Le piège du HTTP vers HTTPS
Lorsque vous passez votre site en HTTPS, chaque page HTTP doit envoyer une 301 vers sa version HTTPS.
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://votresite.com/$1 [R=301,L]
Cette règle attrape tout le trafic HTTP et le bascule en HTTPS. Simple. Mais attention : si vous combinez cette règle avec celle du www, l'ordre compte.
D'abord le HTTPS
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://votresite.com/$1 [R=301,L]
Ensuite le www
RewriteCond %{HTTP_HOST} ^www\.votresite\.com$ [NC]
RewriteRule ^(.*)$ https://votresite.com/$1 [R=301,L]
Pourquoi cet ordre ? Parce que Google recommande des redirections courtes. Avec cet ordre, un visiteur sur `http://www.votresite.com/page` fait deux sauts : d'abord vers `https://www.votresite.com/page`, puis vers `https://votresite.com/page`. Ce n'est pas idéal, mais c'est acceptable.
Une seule règle peut faire les deux :
RewriteCond %{HTTP_HOST} ^www\.votresite\.com$ [NC,OR]
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://votresite.com/$1 [R=301,L]
Voilà. Un seul saut, quelle que soit la requête d'origine. J'ai mis six mois à comprendre pourquoi mes redirections www vers non-www laissaient des chaînes. C'était exactement ce problème.
La redirection 301 sous WordPress
WordPress a sa propre couche de réécriture. Si vous utilisez un plugin de redirection, il gère tout dans la base de données. C'est pratique, mais ça a un coût : chaque requête passe par PHP.
Pour les petits sites, ce n'est pas grave. Pour les gros volumes, c'est de la latence inutile.
Ma préférence personnelle : les règles dans le `.htaccess` ou dans la configuration du serveur. C'est plus rapide, plus prévisible, et ça ne dépend pas d'un plugin qui peut se mettre à jour et casser quelque chose.
Cela dit, un plugin a un avantage : il journalise les 404. Vous voyez les URLs qui génèrent des erreurs, et vous pouvez créer des redirections directement depuis l'écran d'administration. J'ai utilisé Redirection pendant un an sur un site avec 3 000 articles migrés. Ça a fonctionné, mais la table de redirections devenait lentement un capharnaüm. J'ai fini par tout exporter vers le `.htaccess` pour récupérer la performance.
Comment vérifier que le jus de liens est bien transféré ?
C'est là que la plupart des tutoriels s'arrêtent. On vous montre la ligne de code, on vous dit « voilà, c'est fait ». Mais ce n'est pas fini.
Le test du navigateur ne suffit pas. Ouvrir votre ancienne URL et voir la nouvelle page s'afficher ne prouve rien. Le navigateur suit les redirections sans broncher, même les chaînes de cinq hop, même les boucles (jusqu'à une certaine limite).Le premier réflexe : utiliser un outil de crawl. [Screaming Frog](https://www.screamingfrog.co.uk) — la version gratuite suffit pour moins de 500 URLs — va traverser votre site et lister chaque URL avec son code de statut. Vous cherchez :
- Les codes 301 : bons.
- Les codes 302 : à corriger si la redirection est permanente.
- Les chaînes de redirection : le rapport « Redirect Chains » vous les liste. Chaque chaîne doit être consolidée en une seule hop.
- Les boucles : des URLs qui se redirigent l'une vers l'autre. Le crawl vous les montrera en erreur.
Ensuite, Google Search Console. L'outil « Contrôle d'URL » vous permet de tester une URL précise et de voir le résultat du crawl. Si vous voyez « Redirection : 301 », c'est bon signe.
Mais le test ultime, c'est le temps. Google doit recrawler l'ancienne URL, suivre la redirection, puis re-traiter la nouvelle page. Ça peut prendre des semaines. La patience fait partie du travail. J'ai vu des sites mettre deux mois à récupérer leurs positions après une migration. Ce n'est pas un échec de la redirection ; c'est un délai normal de recrawling.
Que faire pour les paramètres et les URLs avec UTM ?
Les URLs avec paramètres (`?utm_source=newsletter&utm_campaign=ete`) posent un problème spécifique. Si vous redirigez chaque variante, vous allez créer des centaines de règles inutiles.
Une seule règle avec une regex bien pensée fait le travail :
RedirectMatch 301 ^/ancien-produit(/?\?.*)?$ /nouveau-produit
Le `(/?\?.*)?` capture les paramètres éventuels. Mais je préfère vous avertir : dans la plupart des cas, les URLs avec UTM ne sont pas indexées. Elles ne transportent pas de jus. Les ignorer est défendable.
L'important, c'est de ne pas laisser les anciennes URLs renvoyer un 404 si elles ont des backlinks. C'est le vrai sujet.
L'erreur n°1 : la redirection vers la page d'accueil
Vous avez supprimé une page et vous ne savez pas où la rediriger. Alors vous la pointez vers l'accueil. « Comme ça, le visiteur trouve toujours quelque chose », pensez-vous.
Erreur. Double erreur.
D'abord, l'utilisateur qui cherchait une page précise et qui arrive sur votre accueil est perdu. Il ne trouve pas ce qu'il cherchait, il s'en va, et votre taux de rebond explose.
Ensuite, le jus de liens : Google voit que l'ancienne page n'a pas d'équivalent. Il transfère les signaux, mais dilués, parce que l'accueil a déjà son propre profil.
La bonne pratique : rediriger vers la page la plus proche. Votre article sur « les meilleures chaussures de running » a été fusionné ? Redirigez vers l'article « le guide complet des chaussures de running ». Un produit a été retiré de votre catalogue ? Redirigez vers la catégorie correspondante.Si aucune page n'est réellement équivalente, le code 410 (Gone) est parfois plus honnête qu'une 301 mal ciblée. Un 410 dit à Google : cette page est partie et elle ne reviendra pas. Google finit par la retirer de l'index, sans transfert de jus. C'est moins glorieux qu'une redirection, mais c'est plus propre qu'une fausse promesse.
Les redirections par code ou par regex : quelle stratégie ?
Sur un site de 10 000 pages, vous ne pouvez pas écrire 10 000 lignes de `Redirect`. Il faut utiliser des motifs.
La méthode par regex sur les structures que vous avez conservées :
Migration : /category/post-name vers /blog/post-name
RedirectMatch 301 ^/category/(.*)$ /blog/$1
Quand c'est possible, c'est la solution la plus efficace. Une seule règle pour tout le blog.
Mais méfiez-vous des regex trop larges. Une règle comme `^/(.*)$` attrape absolument tout. Si vous la placez en début de fichier, elle court-circuite toutes les autres.
Mon ordre de préférence :
- Regex par structure — quand les URLs suivent un motif régulier
- Redirections individuelles — pour les cas particuliers (5 à 20 URLs)
- 410 — pour les pages vraiment disparues sans équivalent
Le .htaccess se lit de haut en bas. La première règle qui correspond est appliquée. Placez vos cas particuliers avant vos règles générales.
Le cas particulier du nginx
Si votre site tourne sous nginx, il n'y a pas de `.htaccess`. La configuration se trouve dans le bloc `server` :
server {
listen 80;
server_name votresite.com www.votresite.com;
return 301 https://votresite.com$request_uri;
}
server {
listen 443 ssl;
server_name www.votresite.com;
return 301 https://votresite.com$request_uri;
}
La syntaxe est différente, mais la logique est identique. Le `return 301` est plus efficace qu'une `rewrite` sous nginx, car il arrête le traitement immédiatement. C'est ce que les serveurs à forte audience utilisent.
Si vous êtes sur un hébergement mutualisé où vous n'avez accès qu'au `.htaccess`, les règles Apache vous concernent. Si vous avez un VPS ou un serveur dédié, vérifiez si le serveur est Apache ou nginx avant de choisir votre approche.
Ce qu'il faut retenir avant de configurer une redirection 301
Une migration de site réussie, c'est un plan. Pas une série de bricolages au fil de l'eau.
Faites la liste de vos 50 URLs les plus importantes — celles qui reçoivent du trafic, celles qui ont des backlinks. Pour chacune, déterminez la page équivalente sur le nouveau site. Testez chaque redirection après déploiement. Surveillez Google Search Console dans les semaines qui suivent.Une redirection 301, ce n'est pas compliqué. Une ligne de code. Mais le jus de liens, lui, ne se transfère pas par magie. Il faut que le mapping soit juste, que les redirections soient courtes, et que Google ait le temps de recrawler.
J'ai mis trois ans et plusieurs migrations ratées à comprendre ça. La première fois où j'ai tout bien fait — mapping précis, pas de chaîne, pas de 404 sur les anciennes URLs —, le trafic organique est revenu en six semaines, sans perte. La fois où j'ai tout bâclé, il a fallu quatre mois pour récupérer.
La différence entre les deux ? Quelques heures de préparation. Pas plus.
