Migration SEO : refaire votre site sans perdre le trafic gagné en dix ans
Une migration SEO (le transfert d'un site existant vers de nouvelles adresses sans perdre ses positions) ne se joue pas le jour du lancement. Elle se joue des semaines avant, dans un tableau que personne ne voit : la correspondance entre chaque ancienne URL et sa nouvelle destination.
Nous développons les sites que nous migrons. WordPress, PrestaShop, Laravel. Nous avons accès au code et au serveur, donc aux règles de réécriture. Donc quand il faut poser 800 redirections en 301 (le transfert permanent qui indique à Google la nouvelle adresse d'une page), ce n'est pas une réunion de plus entre trois prestataires : c'est une ligne de configuration. Même chose pour corriger une balise canonical (celle qui désigne l'URL de référence d'une page) ou pour retirer un noindex (interdiction d'indexer) oublié en préproduction, la copie du site sur laquelle on teste avant la mise en ligne.
Ce que vous trouverez ici : pourquoi une refonte (la reconstruction du site sur une nouvelle base technique ou graphique) fait perdre du trafic, les six erreurs qui coûtent le plus cher, notre plan de migration en cinq phases, et ce que nous contrôlons après la mise en ligne.
En bref
Cinq points pour cadrer une migration SEO avant de toucher au code.
Inventaire d’URL, redirections 301, bascule et 90 jours de suivi : pour une structure déjà en place qui refond sans offrir son trafic aux concurrents.
Une migration SEO en bref
Ce que change un développement sur mesure
Choisir le bon point d’entrée
Quatre portes distinctes, une intention chacune. Choisissez celle qui décrit votre situation ; les autres restent un clic plus loin.
- Audit SEO si vous plafonnez et vous ne savez pas pourquoi.
- SEO technique si le frein est le code, l’indexation ou la performance.
- SEO local si vous êtes invisible sur métier + ville / Maps.
- Migration SEO vous êtes au bon endroit (vous refondez ou changez d’URL / de CMS).
Nous travaillons avec des structures déjà établies, dont l’activité tourne, y compris pour un premier site quand l’entreprise a déjà des clients et un historique.
Notre plan de migration en étapes
Une migration site web se pilote comme un projet de développement : des phases et des livrables, avec des points de contrôle à chaque étape. Voici les cinq nôtres.
Trente minutes avec Florian pour cadrer l’inventaire et le plan de redirections.
1. Inventaire : savoir ce qu'on déplace
On rassemble toutes les URL existantes depuis plusieurs sources pour s'assurer de l'exhaustivité :
- le crawl complet de l'ancien site ;
- les sitemaps déclarés ;
- les données de performance Search Console (12 mois minimum) ;
- l'analytics, pour les pages qui convertissent ;
- les logs serveur, pour les pages réellement visitées et explorées ;
- les backlinks, pour le capital de liens.
On y ajoute les fichiers PDF, les images utilisées dans les articles, les pages de remerciement et les landing pages publicitaires. Toutes ces adresses reçoivent du trafic ou des liens, et beaucoup disparaissent des refontes par accident.
Livrable : un fichier d'inventaire avec, pour chaque URL, trafic, conversions, liens entrants et priorité (P1 / P2 / P3).
2. Correspondances : le plan de redirections
Chaque URL de l'inventaire reçoit une destination et une décision. C'est l'étape la plus longue et la plus utile.
On la construit avec vous, parce que la bonne destination n'est pas toujours celle qui ressemble le plus : elle est celle qui répond au même besoin. Une ancienne page « tarifs hébergement » peut légitimement atterrir sur une page « offres » refondue, pas sur l'accueil.
Livrable : la matrice de redirections, testée automatiquement, avec le nombre d'URL concernées sur votre projet.
3. Préproduction : tout vérifier avant d'exposer
Le nouveau site tourne sur un environnement de recette, protégé de l'indexation. C'est là qu'on teste :
- les redirections en masse (code HTTP, destination finale, nombre de sauts) ;
- les canonicals sur un échantillon de pages types : accueil, catégorie, produit, article, page service ;
- les
noindexet lerobots.txtde préproduction, avec la liste exacte de ce qu'il faudra retirer au lancement ; - les performances et le rendu mobile sur les gabarits principaux ;
- le tracking : GA4 et événements de conversion, plus le bandeau de consentement.
C'est aussi le moment de décider de la stratégie : migration en une fois, ou section par section. Sur un site de taille moyenne, tout migrer d'un coup est généralement plus propre. Sur un très gros volume, on avance par lots.
4. Lancement : une seule chose à la fois
Google recommande de ne pas empiler les changements. Un changement de nom de domaine et un changement de CMS le même jour, c'est déjà deux causes possibles pour un seul problème. Une nouvelle mise en page par-dessus ne rend le diagnostic que plus difficile.
Le jour J, on active les redirections, on retire les protections de préproduction, on vérifie les canonical, on soumet le sitemap. Si le domaine change, on déclare le changement d'adresse dans la Search Console : pour toutes les variantes du domaine, y compris les sous-domaines et les versions avec et sans www. La demande couvre 180 jours.
On choisit une fenêtre de faible trafic. Et on garde les redirections en place au moins un an, idéalement plus.
5. Suivi : les 90 jours qui comptent
Le lancement n'est pas la fin de la migration, c'est le début de l'observation. Pendant trois mois, on compare semaine après semaine : clics, impressions, positions, pages indexées, erreurs d'exploration.
Les erreurs qui coûtent le plus
Voici ce que nous retrouvons le plus souvent quand on nous appelle pour un site qui a chuté après refonte. Aucune de ces erreurs n'est technique au sens noble du terme. Toutes sont des oublis de coordination.
404, chaînes et soft 404 vers la home
C’est la première cause, de loin. L’ancien site avait /services/audit-seo/, le nouveau a /expertise/audit. Sans règle de redirection, l’ancienne adresse renvoie une 404.
Google recommande des redirections permanentes côté serveur, en 301 ou 308, appliquées directement de l’ancienne URL vers la nouvelle, sans étape intermédiaire (redirections et recherche Google). Deux pièges classiques :
Les chaînes de redirection. A → B → C. Googlebot suit jusqu’à 10 sauts, mais chaque saut ajoute de la latence et brouille le signal. On vise une seule étape, jamais plus de deux.
La redirection massive vers l’accueil. Tout envoyer sur la home est interprété comme une erreur de type « soft 404 » : la page d’arrivée ne correspond pas à la demande. Google l’explique noir sur blanc dans sa documentation.
Ancienne URL → nouvelle URL → décision
Changer /produit/chaise-bois en /p/chaise-bois-2026 paraît anodin. Sur un catalogue de 2 000 références, c’est 2 000 décisions à documenter.
Le plan de redirections, c’est ce document : ancienne URL, nouvelle URL, type de redirection, priorité, statut de test. Chaque ligne doit être tranchée avant le lancement : redirection 301, fusion vers une page existante, maintien à l’identique, ou suppression assumée en 410.
Sur une migration vers PrestaShop, nous priorisons d’abord par trafic et par conversions, ensuite par les liens entrants. Une fiche produit qui génère une part significative du chiffre d’affaires en naturel ne peut pas être traitée comme une page catégorie vide.
Une refonte qui fait perdre 40 % de trafic, ça arrive souvent
Vous avez investi dans un site plus rapide et plus clair, avec un design plus soigné. Trois semaines plus tard, la Search Console affiche une courbe qui s'effondre. Les appels entrants baissent. Le commercial demande ce qui se passe.
Ce scénario n'a rien d'exceptionnel. Il se produit dans des entreprises qui avaient un site correct et du contenu qui répondait à de vraies recherches. Leur nouveau site ne reprend pas les mêmes adresses. Résultat : Google arrive sur des pages en 404 et sort les anciennes de son index. Il doit ensuite reconstruire sa compréhension du site depuis zéro.
Une part de fluctuation est normale. Google le documente clairement : après un déplacement, le classement bouge pendant que les nouvelles URL sont explorées et indexées, et il faut en général plusieurs semaines avant que les nouvelles adresses prennent la place des anciennes (documentation Google sur les migrations de sites).
Une chute de 40 % qui dure, en revanche, n'est pas une fluctuation. C'est un signal : des URL ont été perdues en route, ou redirigées vers une page qui ne correspond pas à l'intention de recherche d'origine.
La question à se poser avant de lancer quoi que ce soit : si Google recrawlait votre site demain, retrouverait-il chaque page à la même place sémantique ? Si la réponse est « à peu près », il y a un travail de correspondance à faire avant la mise en ligne, pas après.
Une refonte sans perdre de trafic, ce n'est pas une refonte prudente. C'est une refonte dont la mécanique d'URL a été traitée comme un livrable, au même titre que le design.
Contenu supprimé pour faire propre
Le nouveau site est plus léger. On a retiré les vieux articles et les pages services redondantes. Les fiches obsolètes ont suivi. C’est souvent une bonne intention éditoriale, rarement une bonne décision SEO.
Une page qui capte un volume régulier de visites par mois et qui n’a plus d’équivalent, c’est du trafic offert aux concurrents. Les options, dans cet ordre de préférence :
- Reprendre le contenu dans la nouvelle architecture, même raccourci.
- Fusionner plusieurs pages faibles en une page forte, et rediriger les anciennes vers celle-ci.
- Supprimer franchement, en 410, en assumant la perte et en vérifiant qu’aucun lien entrant utile ne pointait dessus.
Ce qui ne se fait pas : supprimer la page et rediriger vers la home par défaut.
Canonicals oubliés ou recopiés
Sur un nouveau site, la balise canonical doit pointer vers elle-même sur chaque page. C’est la base. Ce qui arrive plus souvent qu’on ne le croit : un canonical hérité du modèle de démo, ou un canonical qui pointe vers l’ancienne URL. Il arrive aussi que la balise soit purement et simplement absente sur les pages paginées et les filtres e-commerce.
Conséquence : Google consolide les signaux vers une URL qui n’est pas celle que vous voulez voir ranker. Sur PrestaShop et WordPress, ces réglages sont souvent dans un module ou dans un template, et une refonte WordPress les remet à zéro sans prévenir.
Sitemap qui liste l'ancien site
Le fichier sitemap.xml du nouveau site doit contenir les nouvelles URL, uniquement. Pas de mix : les anciennes adresses n’ont rien à y faire, et un sitemap généré depuis une base de données non mise à jour produit le même effet.
À la mise en ligne, on soumet le nouveau sitemap dans la Search Console et on retire l’ancien. C’est le moyen le plus rapide d’aider Google à découvrir les nouvelles adresses.
Perte de netlinking
Les liens externes pointent vers vos anciennes URL. Sans redirection, ces liens atterrissent en 404 et la valeur qu’ils transmettaient se perd. C’est tout l’enjeu du netlinking (les liens entrants depuis d’autres sites).
Bonne nouvelle : les redirections 301 et les autres redirections permanentes ne font pas perdre de PageRank, c’est explicite dans la documentation Google. Encore faut-il qu’elles existent.
Le travail complémentaire, souvent négligé : lister les principaux domaines référents et contacter les partenaires pour les liens les plus stratégiques. Les liens internes, eux, se mettent à jour dès le lancement. Les profils sociaux et les campagnes publicitaires comptent aussi : une annonce qui pointe vers une URL morte, c’est du budget jeté.
On identifie les redirections manquantes et les canonicals à corriger.
Ce que nous contrôlons après le lancement
Voici la liste que nous déroulons, avec un rythme défini. Elle fait partie du livrable, pas d'une prestation optionnelle.
À J+1
- toutes les URL P1 testées, code 200 attendu ;
- absence de boucle et de chaîne de redirection sur l’échantillon complet ;
robots.txtet balisesnoindexde préproduction effectivement retirés ;- sitemap accessible et à jour ;
- tracking opérationnel.
À J+7
- rapport « Pages » de la Search Console : erreurs 404, 5xx, pages exclues ;
- comparaison clics / impressions avec la période précédente, par page et par requête ;
- vérification des liens internes cassés ;
- contrôle des canonicals sur les nouvelles pages générées automatiquement.
À J+30
- évolution du nombre de pages indexées sur le nouveau domaine ;
- positions sur les requêtes prioritaires ;
- contrôle des données structurées (produits, avis, organisation) ;
- Core Web Vitals sur mobile.
À J+90
- bilan de trafic par rapport à la baseline d’avant refonte ;
- identification des pages qui n’ont pas récupéré et diagnostic au cas par cas ;
- mise à jour du plan de redirections pour les URL encore manquantes ;
- décision sur les redirections à conserver au-delà d’un an.
Ce cadre n’est pas de la surqualité. C’est ce qui permet de dire, trois mois après, si la refonte a tenu ses promesses, chiffres à l’appui.
jour J ?
Inventaire, matrice 301, préproduction et suivi 90 jours.
Refonte technique ou refonte SEO : la différence
Ces deux projets avancent souvent ensemble. Ils ne se traitent pas au même endroit.
La refonte technique concerne le socle technique, le design, la performance, l’accessibilité, l’ergonomie. Elle se pilote côté code : framework, thème, composants, cache, images.
La refonte SEO concerne la structure d’URL, les correspondances, le contenu, le maillage interne (les liens entre vos pages), les canonicals, les données structurées et la migration du capital de liens. Elle se pilote côté code et côté éditorial.
Le problème, c’est que la refonte SEO arrive souvent en dernier, quand le site est déjà construit. À ce stade, les URL sont fixées et les contenus ont été réécrits. Il ne reste qu’à documenter les dégâts.
Autrement dit : le SEO d’une refonte de site ne se traite pas à la fin, il se traite à l’architecture. C’est là qu’on décide si /blog/ devient /ressources/ et si les fiches produits gardent leurs identifiants. C’est aussi là qu’on tranche le sort des pages villes, conservées ou fusionnées. Ces décisions coûtent zéro en amont et beaucoup en aval.
Un repère simple : si personne dans le projet ne peut citer la personne qui tient la matrice de redirections, le risque est ouvert.
Questions fréquentes sur la migration SEO
-
Combien de temps prend une migration SEO ?
Le projet en lui-même dépend du volume : quelques semaines pour un site vitrine de quelques dizaines de pages, davantage pour un catalogue e-commerce de plusieurs milliers d'URL. Ce qui ne se compresse pas, c'est l'observation après lancement : comptez 90 jours de suivi actif, et parfois plus sur les gros volumes. Le devis se construit après le cadrage, selon l'inventaire réel.
-
Peut-on vraiment faire une refonte sans perdre de trafic ?
Oui, à condition d'accepter une petite fluctuation temporaire. Une refonte bien préparée conserve l'essentiel du trafic et peut en gagner, parce que la nouvelle structure est meilleure. Une refonte mal préparée perd 20, 40, parfois 80 %, et met des mois à s'en remettre.
-
Faut-il garder les redirections 301 indéfiniment ?
Google recommande de les conserver au moins un an, le temps que tous les signaux soient transférés. Dans les faits, nous les laissons en place tant que l'ancienne URL reçoit du trafic ou des liens. Elles ne coûtent presque rien côté serveur et protègent votre référencement.
-
Migration SEO ou nouveau site : par où commencer ?
Par l'inventaire. Toujours. Avant de choisir un thème ou un CMS, et avant même de comparer les agences, listez vos URL et leur trafic. C'est ce document qui dira si votre refonte est un projet de design ou un projet de migration déguisé.
-
Changer de nom de domaine fait-il perdre des positions ?
Pas mécaniquement. Un changement de nom de domaine bien exécuté (redirections 301 sur toutes les variantes et déclaration dans la Search Console, avec un sitemap à jour) transfère l'essentiel. Ce qui coûte cher, c'est de le faire en même temps qu'une refonte complète, sans plan de correspondance.
-
Mon site a perdu du trafic après une refonte : que faire maintenant ?
Dans l'ordre : chercher les 404 sur les anciennes URL qui avaient du trafic, vérifier les canonicals, vérifier qu'aucun
noindexn'est resté, comparer les pages qui ont chuté avec leurs anciennes versions. Dans la majorité des cas, les redirections manquantes expliquent l'essentiel de la perte, et se corrigent.
