Une redirection qui pointe vers une 404. Vous avez déjà vu cette blague ? Moi, une seule fois, sur un client qui avait migré 1 200 URLs un dimanche soir. Le lundi matin, la Search Console affichait 400 erreurs « Page introuvable » et le trafic organique avait chuté de 38 % en dix jours. La redirection existait. Elle était juste mauvaise.
Configurer une redirection 301 sans perdre de jus, ce n'est pas un problème de plugin. C'est un problème de méthode. Je vais vous montrer comment je procède concrètement, ce que j'ai raté les premières fois, et les seuils que je surveille avant de dormir tranquille.
Points clés à retenir
- Une redirection 301 transfère l'essentiel des signaux, mais elle reste un indice pour Google, pas une garantie mécanique.
- Les chaînes de redirections (301 vers 301) diluent les signaux et ralentissent le crawl : on ne redirige jamais vers une URL qui redirige déjà.
- Le mapping URL à URL se prépare avant la mise en ligne, dans un tableur, pas dans la panique du déploiement.
- Une 301 active en permanence est une bonne pratique, pas une option : la supprimer trois mois après, c'est jeter l'autorité accumulée.
- Le contrôle post-migration se fait sur les logs serveur et via un crawl complet, pas uniquement sur un ressenti dans la Search Console.
Configurer une redirection 301 sans perte de jus : la méthode que j'utilise
« Le jus SEO, c'est un mythe. » J'ai entendu ça en 2023, d'un développeur senior persuadé que tout se valait après une refonte. Six mois plus tard, son ancien site avait perdu 62 % de ses backlinks entrants selon son propre audit Ahrefs, et sa page produit phare était passée de la position 3 à la page 4. Le jus n'est pas un mythe. C'est juste qu'il ne se comporte pas comme un fluide qu'on verse d'un pot à l'autre.
Google traite une 301 comme un signal fort. Pas comme une certitude. La différence compte énormément quand vous configurez des centaines de redirections d'un coup.
Ce qui se transfère réellement dans une 301
Quand vous mettez en place une redirection permanente, plusieurs choses voyagent :
- L'autorité des liens entrants qui pointaient vers l'ancienne URL (dans une très large mesure).
- L'historique de crawl, à condition que la nouvelle URL soit indexable et cohérente.
- La pertinence thématique, mais uniquement si le contenu de destination correspond au sujet de l'ancienne page.
Ce qui ne voyage pas : les classements acquis. Un top 3 ne se transforme pas mécaniquement en top 3 sur la nouvelle URL. Il faut quelques semaines pour que les signaux se consolident, et parfois la page se stabilise un cran en dessous. C'est normal. Ce n'est pas un échec.
Le mapping URL à URL : le vrai travail se fait ici
Avant de toucher à la moindre ligne de configuration, je construis un tableau avec trois colonnes : ancienne URL, nouvelle URL, type de correspondance. Ce tableau, c'est 80 % du résultat. Une redirection vers la page d'accueil au lieu de la page équivalente, c'est le meilleur moyen d'envoyer Google dans le mur.
Règle simple que je me suis fixée : une ancienne URL = une nouvelle URL thématiquement équivalente. Si aucune équivalence n'existe, on ne redirige pas vers la home par défaut. On laisse en 410 (disparition définitive) ou on redirige vers la catégorie parente la plus proche.
Concrètement, ce travail a pris quatre jours sur un projet de 3 000 URLs l'an dernier. Quatre jours, c'est long. C'est aussi ce qui nous a évité de perdre la moitié du trafic.
Les procédures techniques, serveur par serveur
Le cœur de la requête « comment configurer » se joue ici. Selon votre stack, la syntaxe change complètement. Voici ce que j'utilise dans les trois cas les plus fréquents.
Apache et le fichier .htaccess
Sur un serveur Apache, les redirections 301 s'écrivent soit avec Redirect 301, soit avec RewriteRule. La première est plus simple, la seconde plus flexible.
Redirect 301 /ancienne-page/ https://exemple.fr/nouvelle-page/Pour un lot de redirections, préférez RewriteRule avec des expressions régulières. Attention à l'ordre des règles : Apache les applique de haut en bas, et une règle mal placée peut capter des URLs qu'elle ne devait pas toucher. J'ai perdu une demi-journée là-dessus un jour, en redirigeant toute la section /blog/ vers une seule page.
Nginx : la directive return 301
Sur Nginx, la syntaxe est plus propre :
location = /ancienne-page/ {
return 301 https://exemple.fr/nouvelle-page/;
}Le location = avec le signe égal indique une correspondance exacte. C'est ce que vous voulez pour des redirections une-à-une. Pour des redirections par lot, on passe sur location ~ avec une regex, mais là il faut être très prudent.
WordPress et les plugins de redirection
Sous WordPress, deux approches : le plugin ou la règle serveur. Le plugin (Redirection, Yoast Premium, Rank Math) est pratique pour un petit site. Au-delà de 500 redirections, il commence à taper dans la base de données à chaque appel et peut ralentir le site. Sur un projet à 4 000 redirections, j'ai basculé toutes les règles côté serveur et gagné environ 200 ms de temps de réponse moyen. Ça n'a rien à voir avec le SEO directement, mais ça compte.
| Stack | Outil | Idéal pour | Limite principale |
|---|---|---|---|
| Apache | .htaccess | Petits et moyens sites, mutualisé | Performance dégradée au-delà de quelques centaines de règles |
| Nginx | Directive return 301 | Grosses volumétries, sites à fort trafic | Rechargement serveur nécessaire à chaque modification |
| WordPress | Plugin Redirection | Sites éditoriaux, non-techniques | Charge SQL sur gros volumes |
| Cloudflare | Bulk Redirects | Redirections massives, edge | Quota selon le plan, moins de contrôle sur le contexte |
Les erreurs qui coûtent vraiment du jus
Franchement, la plupart des pertes de trafic que je vois après une migration ne viennent pas de la redirection elle-même. Elles viennent de ce qui se passe autour.
Chaînes de redirections et boucles
Une chaîne, c'est quand l'URL A redirige vers B, qui redirige vers C. Chaque saut supplémentaire dilue les signaux et consomme du budget de crawl. Dans un audit récent, j'ai trouvé une chaîne de quatre redirections successives sur la page de contact d'un client. Quatre. Chaque nouvelle refonte avait empilé sa propre règle sans nettoyer les précédentes.
La règle est simple : on redirige toujours de l'ancienne URL vers l'URL finale, en un seul saut. Si B redirige déjà vers C, alors A doit pointer directement vers C.
Rediriger vers une page qui n'existe pas
C'est l'erreur numéro un, et elle est invisible au premier coup d'œil. Une redirection 301 qui pointe vers une 404, c'est pire qu'une absence de redirection : Google découvre la chaîne, suit le signal, et trouve une impasse. Le jus part à la poubelle. Le contrôle systématique après déploiement, avec un crawl complet, est la seule manière de détecter ça.
Rediriger vers une page non pertinente
Rediriger toutes vos anciennes pages produits supprimées vers votre page d'accueil, c'est tentant. C'est aussi ce qui envoie le signal le plus confus possible à Google : « cette ancienne page parlait de chaussures de randonnée, maintenant elle pointe vers une page qui parle de tout et de rien ». La pertinence se perd, et avec elle une partie de la valeur.
Préférez une redirection vers la catégorie la plus proche. Ou, si vraiment rien ne correspond, une 410 propre.
Vérification et suivi : ce que je fais dans les 30 jours
La mise en ligne n'est que la moitié du travail. Voici la séquence que j'applique systématiquement.
- J+0 : crawl complet avec Screaming Frog sur les anciennes URLs. Objectif : zéro 404 sur les URLs qui avaient du trafic.
- J+2 : vérification que la Search Console a bien détecté les 301 (rapport « Pages » puis section « Erreurs de redirection »).
- J+7 : analyse des logs serveur pour repérer les redirections les plus sollicitées et celles qui ne sont jamais appelées.
- J+30 : comparaison du trafic organique par URL. Là, on voit ce qui a tenu et ce qui a décroché.
Il y a toujours des surprises à J+30. La dernière en date : une page de tutoriel qui avait gardé sa position, mais une page de documentation technique qui avait perdu 12 places parce que sa nouvelle URL avait un slug trop différent de l'ancien. On a corrigé le slug, et deux semaines plus tard c'était revenu.
Combien de temps garder une redirection 301 active ?
Le plus longtemps possible. Idéalement, indéfiniment. Je sais que la tentation est forte de nettoyer après six mois, histoire de garder un fichier .htaccess propre. Sauf qu'un backlink externe pointe vers l'ancienne URL pour toujours. Si vous supprimez la redirection, ce lien tombe dans le vide.
Sur un site que je maintiens depuis 2019, on a encore des redirections actives de la première refonte. Elles ne coûtent rien. Elles rapportent.
Les cas particuliers qu'on oublie systématiquement
Quelques situations qui méritent une mention à part.
Migration HTTP vers HTTPS
Ici, une règle absolue : la redirection HTTP → HTTPS doit être en 301, jamais en 302. Et elle doit être globale. J'ai déjà vu un site où seule la home redirigeait, le reste restait accessible en HTTP. Google a mis des mois à s'y retrouver.
Redirections et sites multilingues
Avec des balises hreflang en place, une redirection mal ciblée peut casser l'association entre versions linguistiques. Si votre /fr/page/ redirige vers /en/page/, vous venez de dire à Google que votre page française n'existe plus. Redirigez toujours vers la même langue.
Redirections et paramètres d'URL
Les URLs avec paramètres (?utm_source=, ?page=2) peuvent générer des redirections involontaires si votre règle est trop large. Testez toujours avec quelques exemples réels avant de déployer une regex.
Une chose à garder en tête
La redirection 301 est un outil de continuité. Pas une baguette magique. Elle conserve ce qui existe déjà, elle ne crée rien. Si votre nouvelle page est moins bonne que l'ancienne, aucun 301 ne sauvera son classement.
La vraie question n'est pas « comment configurer une redirection 301 sans perte de jus ». C'est « est-ce que ma nouvelle URL mérite l'autorité que je lui transfère ». Quand la réponse est oui, la configuration devient un détail technique. Quand la réponse est non, aucune ligne de code ne compensera.
