Comment gérer les redirections 301 après une migration de site sans perdre son SEO

Vous migrez votre site. Vous préparez le plan de redirection la veille de la mise en ligne, à 23 h, dans un tableur qui contient 400 lignes dont 200 sont vides. Et vous vous dites que ça ira.

Ça ne va jamais. Sur ma dernière refonte, j'avais 1 780 URLs à mapper. J'ai cru que je m'en sortirais en une soirée. J'y ai passé quatre jours, et il m'en manquait encore une trentaine quand le site est passé en prod. Le trafic organique a chuté de 31 % la semaine suivante. Pas à cause d'une pénalité, pas à cause d'un problème d'hébergement : à cause de redirections 301 mal construites. Voici comment gérer une redirection 301 après une migration de site sans revivre ce genre de semaine.

Comment gérer les redirections 301 après une migration de site

La règle de base, celle que tout le monde connaît et que personne n'applique proprement : chaque ancienne URL qui recevait du trafic ou des liens doit avoir une redirection 301 vers une URL vivante du nouveau site. Permanente, donc. Pas une 302.

Mais la vraie difficulté n'est pas là. Elle est dans le mapping : décider quelle ancienne URL va vers quelle nouvelle. C'est ce travail-là qui décide si votre migration passe ou casse.

Construire le mapping, concrètement

Voici la méthode que j'applique maintenant, dans cet ordre, et que je ne sauterais pour rien au monde.

1. Crawler l'ancien site entier. Pas seulement les pages du menu. Toutes celles qui sont liées quelque part, y compris les vieilles pages d'articles que plus personne ne met à jour.
2. Exporter les backlinks. Récupérez la liste des URLs qui reçoivent au moins un lien externe. Ce sont vos priorités absolues : ce sont elles qui portent votre autorité.
3. Croiser avec les données de trafic. Sortez les pages qui génèrent des clics organiques sur les douze derniers mois. Une page sans backlink mais avec du trafic mérite aussi une redirection soignée.
4. Remplir le tableur. Trois colonnes : ancienne URL, nouvelle URL, statut. La colonne statut sert à marquer ce qui est fait, ce qui est à vérifier, ce qui n'a pas d'équivalent.

Ce tableur, c'est votre document de travail pendant toute la migration. Il finit par contenir des choses que vous ne trouviez nulle part ailleurs : quelle page a été fusionnée avec une autre, quelle catégorie a disparu, quel ancien produit n'existe plus du tout.

Et quand une page n'a pas d'équivalent ?

C'est la question qui bloque tout le monde, et la réponse réflexe est souvent la mauvaise. Non, on ne redirige pas tout vers l'accueil par défaut.

Une redirection massive de pages sans rapport vers la home, ça se voit. Le moteur comprend qu'il y a une incohérence entre le contenu de la page d'arrivée et celui de départ. Sur une trentaine de pages, ça passe. Sur 300 pages sans rapport, vous envoyez un signal de qualité douteuse.

Deux cas se distinguent :

• La page a un équivalent thématique proche : redirection 301 vers la page la plus proche, même si ce n'est pas un clone exact.
• La page a définitivement disparu et rien ne la remplace : un code 410 Gone est parfois plus honnête qu'une 301 vers l'accueil. Il indique au moteur que la ressource n'existe plus, sans prétendre à une correspondance.

Bref : la 301 n'est pas un réflexe universel. C'est une décision page par page.

Redirection 301 en .htaccess : syntaxe et pièges

Vous allez écrire vos règles quelque part. Sur un serveur Apache, c'est souvent le fichier .htaccess. Voici la forme standard, celle que vous utiliserez dans 90 % des cas :

Redirect 301 /ancienne-page.html https://exemple.com/nouvelle-page/

Ça marche. Mais les pièges sont ailleurs, dans ce qu'on oublie de tester.

Les pièges qui passent inaperçus

Le premier : la casse et le slash final. /Ancienne-Page, /ancienne-page et /ancienne-page/ sont trois adresses différentes du point de vue du serveur. Si vous n'avez pas testé les trois variantes, une partie de vos visiteurs tombera sur une 404 sans que vous le sachiez.

Le deuxième : les paramètres d'URL. Une ancienne URL avec des paramètres de suivi, de tri ou de pagination ne se redirige pas toujours correctement avec une simple règle statique. Prévoyez une règle avec expression régulière pour capturer ces cas plutôt que d'écrire 40 lignes à la main.

Le troisième, et c'est celui qui m'a coûté le plus cher : les doublons entre www et non-www, et entre http et https. Si vos anciennes URLs pointent vers http://www.exemple.com et que votre nouvelle version vit sur https://exemple.com, vous devez vérifier que la résolution se fait en une seule étape, pas en trois. J'ai vu un site enchaîner http → https, puis www → non-www, puis ancienne page → nouvelle page. Trois sauts pour arriver quelque part. Aucun visiteur ne remarque, mais chaque saut coûte.

Redirection 301 ou 302 : laquelle choisir ?

La confusion est fréquente, alors posons-la clairement.

Critère	301 (permanente)	302 (temporaire)
Signification	La ressource a définitivement changé d'adresse	La ressource est momentanément ailleurs
Usage typique après migration	Oui, dans l'immense majorité des cas	Non, sauf maintenance courte
Transmission de l'autorité	Conçue pour ça	Pas garantie comme permanente
Mise en cache navigateur	Durable	Brève
Erreur à éviter	Chaîner plusieurs 301	L'utiliser pour une refonte définitive

En clair : après une migration, c'est 301. Si vous mettez une 302 en pensant "je corrigerai plus tard", vous envoyez un signal de temporaire sur un changement qui est en réalité définitif. Le moteur ne traite pas les deux de la même façon.

Spoiler : la 302 n'est pas inutile, elle a sa place pendant une opération de maintenance ou un test A/B. Pas dans une migration.

Chaînes et boucles de redirection : le problème qu'on ne voit pas

Une chaîne, c'est quand A redirige vers B, qui redirige vers C, qui redirige vers D. Vous n'avez pas écrit ça volontairement, mais ça arrive constamment avec les migrations successives.

Comment ? Parce qu'une ancienne redirection que vous aviez posée il y a deux ans pointait vers une URL qui, elle-même, a été redirigée lors de la migration d'aujourd'hui. Vous n'avez touché qu'à la nouvelle règle, mais l'ancienne existe toujours.

Le coût est double. Le moteur doit suivre chaque saut pour comprendre où aller — ce qui consomme du budget de crawl sur des URLs qui ne devraient plus en consommer. Et chaque saut supplémentaire ajoute un risque de perte en route.

Je fixe arbitrairement une limite : au-delà de deux sauts, je corrige. Une seule 301, c'est propre. Deux, ça passe. Trois, non.

Pour les détecter, un crawl de votre propre site avec un outil qui suit les redirections (Screaming Frog et ses équivalents le font tous) affichera directement les chaînes dans le rapport. C'est le seul moment où je regarde ce rapport en entier, ligne par ligne. Le reste de l'année, je le survole.

Vérifier après la mise en ligne : la partie qu'on bâcle

La mise en ligne n'est pas la fin. C'est le début de la partie où on peut encore rattraper ce qui ne marche pas.

Les premières 48 heures

Le rapport de couverture de la Search Console va remonter des erreurs 404 à mesure que le moteur recrawle les anciennes URLs. Vous allez en avoir. La question n'est pas d'éviter les 404, c'est de les traiter vite.

Concrètement : exportez la liste des 404, filtrez celles qui reçoivent des liens externes ou du trafic, et corrigez en priorité celles-là. Une 404 sur une page que personne ne visite, ce n'est pas une urgence. Une 404 sur une page qui recevait 200 visites par semaine, c'est une fuite.

Le suivi sur quatre à six semaines

J'ai arrêté de croire aux vérifications d'un jour. Il faut laisser au moteur le temps de recrawler l'ensemble du site, ce qui peut prendre des semaines selon la taille et la fréquence de crawl dont vous bénéficiez.

Ce que je surveille pendant cette période :

• La position moyenne des pages qui recevaient du trafic avant migration. Une légère baisse est normale, un décrochage complet ne l'est pas.
• Le nombre d'URL indexées : il doit converger vers le nombre réel de pages du nouveau site, pas rester bloqué sur l'ancien.
• Le trafic organique, jour par jour, comparé à la même période l'année précédente. Comparez à vous-même, jamais à une moyenne générique.

Sur ma migration ratée, il m'a fallu cinq semaines pour revenir à mon niveau de trafic antérieur. Cinq semaines pendant lesquelles j'ai corrigé une quarantaine de redirections que je n'avais pas vues à la mise en ligne. Si j'avais fait ce monitoring dès le premier jour, j'aurais gagné deux semaines.

Combien de temps faut-il garder une redirection 301 active ?

Plus longtemps que vous ne le pensez. Techniquement, rien n'oblige à les retirer, et je conseille de les laisser en place aussi longtemps que les anciennes URLs reçoivent des liens externes ou des visites directes.

Concrètement : tant qu'un site externe pointe vers votre ancienne adresse, la redirection a une utilité. Supprimer une 301 trop tôt, c'est perdre ce lien et envoyer vos visiteurs vers une page morte. Je garde les miennes en place sans date de fin. C'est un fichier qui vieillit, mais il ne coûte rien à maintenir et il protège contre les liens oubliés.

Ce que je ferais différemment aujourd'hui

Si vous retenez une seule chose de cet article : le mapping se fait avant la mise en ligne, jamais pendant, jamais après. Sur ma prochaine migration, je commence le tableur deux semaines avant la date de bascule, pas la veille. Et je teste chaque redirection avec un script, pas à l'œil.

Ce n'est pas une question de rigueur technique. C'est une question de temps. Une redirection 301 bien posée prend trente secondes à écrire. Une redirection manquée prend cinq semaines à réparer.