Un client m'appelle un vendredi soir, panique dans la voix. Sa refonte vient d'être mise en ligne. Le trafic organique a chuté de 40 % en cinq jours. Je regarde les logs, je crawle le site, et je découvre la scène classique : toutes les anciennes URL renvoient vers la page d'accueil. Des centaines de pages produits, d'articles, de fiches catégories, tout redirigé vers la home. Google déteste ça. Vous aussi, vous allez détester le mois de récupération qui a suivi.
Configurer des redirections 301 après une refonte, ce n'est pas un détail technique qu'on délègue à la fin. C'est la colonne vertébrale du transfert d'autorité entre l'ancien site et le nouveau. Rater cette étape, c'est jeter par la fenêtre des années de positionnement.
Points clés à retenir
- Une 301 doit pointer vers l'URL la plus proche en contenu, jamais vers la page d'accueil par défaut.
- Le mapping se prépare avant la mise en ligne, pas après.
- Chaque redirection doit être testée une par une. Un code 200 sur une page censée rediriger est une anomalie.
- Les chaînes de redirections diluent l'autorité : A vers B vers C vaut mieux que A vers C directement, mais A vers B qui n'existe plus, c'est un lien mort.
- On garde les 301 en place pendant des années, pas des mois.
- Les redirections côté client (JavaScript) ne transmettent pas l'autorité SEO.
Comprendre ce qu'une 301 transfère vraiment
La plupart des guides explique qu'une 301 est une « redirection permanente ». Cela ne dit rien sur ce qui se passe réellement. Ce que la 301 transmet, c'est un signal à Google : « le contenu que tu connaissais à cette adresse a déménagé définitivement ici ». L'index se met à jour, l'autorité accumulée par les liens entrants continue de pointer vers le nouveau contenu.
Le problème vient d'une confusion fréquente entre rediriger l'utilisateur et rediriger le robot. Un utilisateur, vous pouvez le tromper : n'importe quelle page d'atterrissage fera l'affaire s'il trouve ce qu'il cherche. Googlebot, non. Lui compare la sémantique de la page source et de la page cible. Un guide sur le référencement redirigé vers une page catégorie « chaussures de randonnée », il note l'incohérence et n'attribue aucun transfert utile.
Pourquoi la page d'accueil est le pire choix par défaut
Rediriger tout vers la home, c'est l'erreur que j'ai vue le plus souvent en audit. Je peux comprendre la logique du développeur pressé : au moins, personne ne tombe sur une 404. Sauf que Google interprète ces redirections en masse comme un signal de contenu supprimé. Résultat : les pages sortent de l'index une par une, et le trafic s'effondre progressivement sur plusieurs semaines — ce qui donne l'illusion que le problème vient d'ailleurs.
Le bon réflexe, c'est la correspondance une à une. Une ancienne URL, une nouvelle URL, un lien logique.
Préparer le tableau de correspondance avant la mise en ligne
Le travail de mapping se fait sur un tableur, pas dans le CMS. Concrètement, je récupère trois sources : un export de toutes les URL indexées depuis la Search Console, un crawl complet de l'ancien site, et les logs serveur des six derniers mois pour repérer les pages réellement visitées. Le croisement de ces trois jeux de données donne la liste réelle des URL à rediriger — souvent 30 à 40 % du total, pas la totalité.
Ensuite, pour chaque ancienne URL, je cherche la nouvelle page qui reprend le sujet. Si elle n'existe pas, trois options :
- La page a été fusionnée avec une autre : on redirige vers cette page fusionnée.
- Le contenu a disparu mais reste pertinent : on redirige vers la catégorie parente la plus proche.
- Rien ne correspond : on laisse en 404. Un 404 propre vaut mieux qu'une redirection mensongère.
Automatiser la génération du mapping
Sur un site de 200 URL, le mapping manuel se fait en une après-midi. Sur 5 000, il faut autre chose. Je crawle l'ancien site avec un outil type Screaming Frog en récupérant les balises title et H1, je fais pareil sur le nouveau, et je fais tourner une correspondance par similarité de titres. Ça donne un premier jet à 70-80 % correct, qu'on corrige ensuite manuellement. Gain de temps énorme.
Attention : ce pré-remplissage n'est qu'un point de départ. Une similarité de titres peut rapprocher deux pages qui n'ont rien à voir. J'ai déjà vu un « Guide du référencement local » apparié avec un « Guide de randonnée en local ».
Écrire les règles 301 : code copiable
Voilà la partie que les guides oublient systématiquement. Du code réel, à adapter.
Configuration avec Apache (.htaccess)
Redirect 301 /ancien-guide-referencement/ https://exemple.fr/nouveau-guide-referencement/
Redirect 301 /produits/chaussures-rando/ https://exemple.fr/chaussures-randonnee/
Redirect 301 /blog/2021/ https://exemple.fr/blog/
Pour des redirections conditionnelles ou avec des règles de réécriture plus fines :
RewriteEngine On
RewriteRule ^ancien-dossier/(.*)$ /nouveau-dossier/$1 [R=301,L]
Configuration avec Nginx
Nginx ne lit pas de fichier .htaccess. Les règles se placent dans le bloc server :
location = /ancien-guide-referencement/ {
return 301 https://exemple.fr/nouveau-guide-referencement/;
}
Redirection de masse sur un préfixe
location ^~ /ancien-dossier/ {
return 301 https://exemple.fr/nouveau-dossier/$1;
}
Pour un site sous WordPress, les extensions type Redirection ou Rank Math gèrent ça sans toucher au serveur, avec une interface pour importer un CSV de correspondances. C'est ce que je recommande pour un client qui n'a pas d'admin système sous la main : l'import CSV de 500 correspondances prend trois minutes.
Ce que vous ne devez jamais faire
Une redirection en JavaScript — du type window.location.replace — n'est pas une 301. Le robot peut ignorer le JavaScript, et quand il l'exécute, l'autorité n'est pas transférée de la même manière. Même chose pour une balise meta refresh. Ces méthodes fonctionnent pour l'utilisateur, pas pour le référencement.
Vérifier les 301 une par une
Une fois les règles en place, on teste. En local d'abord, puis en production juste après la bascule.
| Test | Outil | Ce qu'on cherche |
|---|---|---|
| Code HTTP de chaque ancienne URL | Curl en ligne de commande, Screaming Frog | 301 attendu, jamais 302, 200 ou 404 |
| Chaînes de redirection | Screaming Frog (rapport redirections) | Aucune URL ne doit apparaître dans plus d'une redirection |
| Cible finale | Vérification visuelle manuelle | La page cible répond bien 200 et son contenu correspond |
| Indexation | Search Console (couverture) | Les anciennes URL disparaissent, les nouvelles apparaissent |
curl -I https://exemple.fr/ancienne-url/ renvoie le code HTTP en une ligne. Pour 500 URL, un script qui boucle sur la liste et sort un CSV fait le travail en quelques secondes. Je le lance systématiquement avant et après la mise en ligne, et je compare les deux fichiers.
Les erreurs que j'ai vues le plus souvent
Une chaîne de redirection qui traverse trois URLs, c'est une perte de jus à chaque saut. Une redirection A vers B où B est lui-même en 404, c'est encore pire. Et les redirections en boucle — A redirige vers B qui redirige vers A — bloquent purement et simplement la page. Ce genre de chose arrive quand on modifie les règles à la volée sans tester.
Combien de temps conserver les 301 actives
La question revient toujours. La réponse courte : indéfiniment. Il n'y a aucune bonne raison de retirer une 301 qui fonctionne. Les liens externes qui pointaient vers l'ancienne URL continuent d'exister, les marque-pages utilisateurs aussi, et les moteurs mettent du temps à consolider les signaux.
J'ai vu un site retirer ses redirections un an après une refonte, « pour nettoyer le .htaccess ». Deux mois plus tard, le trafic sur les pages concernées était divisé par deux. Le fichier de règles n'est pas un dépotoir, mais on ne le vide pas non plus par esthétique.
Un site que j'ai suivi a conservé ses 301 pendant quatre ans avant qu'une migration serveur ne les efface accidentellement. On les a reconstituées en une journée à partir de l'historique Git. Leçon retenue : versionner le fichier .htaccess comme n'importe quel autre fichier de code.
Ce qui compte vraiment au final
La redirection 301 n'est pas un problème technique. C'est un problème de rigueur. Le développeur qui met en ligne sans mapping ne fait pas une erreur de compétence, il fait une erreur de méthode. Le mapping se prépare sur un tableur, se vérifie URL par URL, et se teste après déploiement. Le reste, c'est de la syntaxe qu'on peut copier-coller.
Si vous devez retenir une seule chose de cet article : ne déléguez jamais la préparation du mapping. Ni à un stagiaire, ni à une extension qui « trouve automatiquement les correspondances ». Les outils donnent un point de départ. La décision finale, elle, demande qu'on ouvre les deux pages et qu'on vérifie à l'œil si le sujet correspond vraiment. C'est fastidieux. C'est aussi la seule étape qui distingue une refonte réussie d'une catastrophe silencieuse.
