Plan de redirections 301 : la pièce maîtresse d'une migration réussie

Lorsqu'une boutique change de plateforme, de structure d'URL ou de nom de domaine, ses adresses changent. Or Google a indexé les anciennes, et des centaines de sites tiers pointent vers elles. Sans passerelle entre l'ancien et le nouveau, chaque URL connue devient une erreur 404 : le trafic organique s'effondre, le jus de lien accumulé pendant des années disparaît, et les clients qui ont mis une fiche produit en favori tombent dans le vide. C'est exactement ce qu'un plan de redirections 301 empêche.

Chez Omniscrap, nous considérons le plan de redirections comme la pièce maîtresse de toute migration e-commerce. Le reste de la migration peut être impeccable — produits transférés, design refait, performances améliorées — si les redirections sont bâclées, le SEO chute et la récupération prend des mois. Cet article détaille la méthode que nous appliquons, étape par étape, pour bâtir un plan exhaustif et sans angle mort.

301, 302 ou 410 : le bon code pour le bon cas

Avant de cartographier quoi que ce soit, il faut comprendre quel signal envoyer aux moteurs. Une redirection n'est pas qu'un déplacement technique : c'est une instruction de transfert d'autorité.

• 301 — Redirection permanente. L'ancienne URL est remplacée définitivement par une nouvelle. Google transmet la quasi- totalité du signal SEO vers la cible et finit par désindexer l'ancienne. C'est le code par défaut d'une migration.
• 302 — Redirection temporaire. Indique que le déplacement n'est que provisoire. Google conserve l'ancienne URL dans son index et ne transfère pas l'autorité de façon stable. À proscrire dans une migration : c'est l'erreur la plus fréquente quand un serveur est mal configuré.
• 410 — Gone. La ressource a été supprimée volontairement et ne reviendra pas. Plus explicite qu'un 404, elle accélère la désindexation. Idéale pour les produits définitivement retirés sans équivalent.
• 404 — Not Found. La page n'existe pas (ou plus), sans préciser si c'est volontaire. À réserver aux URL réellement inconnues, jamais comme stratégie de migration.

Étape 1 — Crawler l'ancien site et recenser toutes les URLs

On ne peut rediriger que ce qu'on connaît. La première erreur consiste à se contenter du sitemap : il ne reflète que les URL que le CMS expose volontairement, pas celles que Google a réellement indexées ni celles qui reçoivent encore des backlinks. Nous croisons donc plusieurs sources pour obtenir la liste la plus complète possible :

1. Crawl complet de l'ancien site (Screaming Frog, Sitebulb ou équivalent) pour récupérer toutes les URL internes accessibles.
2. Google Search Console : rapport de couverture et performances pour lister les URL indexées et celles qui génèrent encore des impressions et des clics.
3. Sitemap XML existant, qui sert de point de comparaison.
4. Logs serveur (idéalement plusieurs semaines) : ils révèlent les URL réellement appelées par Googlebot et les visiteurs, y compris des adresses orphelines absentes du crawl.
5. Backlinks via un outil de netlinking : les pages qui reçoivent des liens externes sont prioritaires car elles concentrent l'autorité à préserver.

On dédoublonne ensuite l'ensemble dans un tableur pour obtenir la liste maîtresse des URL à traiter, en notant pour chacune ses impressions, clics et backlinks. Cet enrichissement permet de prioriser : une fiche produit avec 40 backlinks mérite une cible précise, une URL technique sans trafic peut basculer en 410.

Étape 2 — Cartographier ancien vers nouveau

Le mapping est le cœur du plan. Chaque ligne de la liste maîtresse reçoit une URL de destination sur le nouveau site et un code HTTP. Quand les deux structures sont régulières, on automatise via des règles. Par exemple, si l'ancien chemin produit était /product/123-nom-du-produit et le nouveau /p/nom-du-produit, une règle de réécriture suffit :

• Apache (.htaccess) : RedirectMatch 301 ^/product/[0-9]+-(.*)$ /p/$1
• Nginx : rewrite ^/product/[0-9]+-(.*)$ /p/$1 permanent;

Mais aucune règle générique ne couvre 100 % des cas : les slugs renommés, les catégories fusionnées et les produits supprimés exigent un mapping manuel, ligne à ligne. Nous combinons donc deux couches : des règles regex pour les patterns réguliers, puis une table de correspondance exacte pour les exceptions. La table exacte est toujours évaluée en premier afin qu'une exception ne soit pas avalée par une règle générale.

Étape 3 — Traiter les cas particuliers

Produits supprimés

Un produit disparu ne doit jamais renvoyer un 404 silencieux s'il recevait du trafic. Deux options : le rediriger en 301 vers le produit de remplacement le plus proche, ou à défaut vers sa catégorie parente. Réserver le 410 aux références définitivement abandonnées sans alternative pertinente — c'est plus honnête vis-à-vis de l'utilisateur qu'une redirection vers une page qui ne répond pas à son intention.

URLs orphelines

Les URLs orphelines sont des adresses qui ne sont liées depuis aucune page du site mais qui existent encore dans l'index ou les logs : anciennes pages promo, paramètres de tracking, versions PDF de fiches, pages issues d'un ancien thème. Comme aucun crawl interne ne les remonte, seules les sources GSC, logs et backlinks les détectent. Elles méritent un traitement explicite : redirection si elles ont de la valeur, 410 sinon. Les ignorer, c'est laisser des 404 surgir des semaines après la mise en ligne.

Pagination et filtres

Les pages de pagination (?page=2, /categorie/page/3) se redirigent vers la première page de la catégorie correspondante. Les URL de filtres et facettes (?couleur=rouge&taille=42) sont souvent à faible valeur : on les redirige vers la catégorie sans filtre, sauf les quelques combinaisons qui rankaient déjà et qui justifient une cible dédiée. L'objectif est d'éviter de transférer un index gonflé de pages de filtres vers le nouveau site.

Étape 4 — Éviter les chaînes et les boucles

Une chaîne de redirection se produit quand une URL A redirige vers B, qui redirige elle-même vers C. Chaque saut dilue le signal, ralentit le rendu et consomme du budget de crawl. Une boucle (A vers B, B vers A) provoque une erreur fatale et rend la page inaccessible.

La règle est simple : chaque ancienne URL doit pointer en un seul saut vers sa destination finale réelle (statut 200). Si une cible a elle-même bougé, on met à jour la redirection d'origine pour qu'elle vise directement la nouvelle adresse, plutôt que d'empiler les sauts. Avant la mise en ligne, on teste l'ensemble du fichier de redirections avec un crawler en suivant les redirections pour détecter toute chaîne supérieure à un saut.

Étape 5 — Implémenter

L'implémentation dépend du serveur et de la plateforme cible :

• Apache : directives Redirect 301 et RedirectMatch dans le .htaccess, ou RewriteRule avec le module mod_rewrite pour les patterns complexes.
• Nginx : directives rewrite ... permanent; ou un bloc map pour les longues tables de correspondance exactes, plus performant qu'une succession de règles.
• Module / fonction native du CMS : PrestaShop, Shopify et la plupart des CMS proposent une gestion de redirections en base ou via module. Pratique pour les volumes modérés, mais souvent plus lent qu'une règle serveur sur de gros catalogues.

Pour les catalogues volumineux, nous privilégions le niveau serveur (map Nginx ou fichier de réécriture) afin de ne pas alourdir chaque requête d'un appel base de données. La table exacte doit toujours primer sur les règles regex pour que les exceptions traitées à l'étape 2 ne soient pas court-circuitées.

Étape 6 — Recette et tests

Avant et après bascule, on vérifie que le plan se comporte comme prévu :

1. Échantillon manuel : tester les URL à plus forte valeur (top pages GSC, fiches avec backlinks) et confirmer qu'elles renvoient un 301 propre vers une page 200 pertinente.
2. Crawl complet de la liste maîtresse : passer toutes les anciennes URL dans un crawler en mode « liste » et vérifier les codes de statut. On cherche zéro 404 inattendu, zéro 302, zéro chaîne.
3. Contrôle des cibles : s'assurer qu'aucune redirection ne pointe vers une page elle-même redirigée ou en erreur.
4. Test multi-format : ne pas oublier les images, PDF et flux qui avaient leur propre URL indexée.

Erreurs fréquentes à éviter

• Tout rediriger vers la page d'accueil. Google traite ces redirections de masse comme des soft 404 : il les considère comme des pages inexistantes et ne transfère pas l'autorité. Chaque URL doit viser la page la plus proche de son contenu d'origine.
• Empiler les redirections en chaîne au fil des migrations successives, jusqu'à des cascades de cinq sauts.
• Oublier les images, PDF et autres médias indexés, qui génèrent du trafic via Google Images et les backlinks.
• Utiliser des 302 par défaut faute d'avoir configuré explicitement le code 301.
• Négliger HTTP vers HTTPS et www vers non-www : ces redirections de normalisation doivent rester en un seul saut combiné avec la redirection de migration.

Suivi post-migration

Le plan de redirections n'est pas un livrable « une fois pour toutes ». Dans les semaines qui suivent la bascule, nous surveillons :

• le rapport des pages dans Search Console, en particulier les nouvelles 404 et les « soft 404 » qui apparaissent au fil du recrawl ;
• les logs serveur, qui révèlent les URL encore appelées et non couvertes par le plan ;
• la courbe d'impressions et de clics : une baisse temporaire est normale pendant le recrawl, mais une chute durable signale un trou de redirection.

Chaque 404 détectée donne lieu à l'ajout d'une redirection manquante. C'est ce travail de finition, sur plusieurs semaines, qui sépare une migration qui récupère son trafic en quelques jours d'une migration qui met des mois à s'en remettre.

Conclusion

Un plan de redirections 301 réussi repose sur l'exhaustivité du recensement, la précision du mapping et la rigueur des tests. Crawler toutes les sources, choisir le bon code pour chaque cas, éviter les chaînes et surveiller la Search Console après bascule : c'est cette discipline qui préserve le capital SEO accumulé.

Le plan de redirections s'inscrit dans une démarche plus large. Pour le replacer dans son contexte, consultez notre checklist migration et notre guide complet de la migration. Et si votre projet concerne un changement de plateforme précis, notre article sur la migration WooCommerce vers PrestaShop détaille le mapping d'URL propre à ce passage.