Migrer un site vers une nouvelle plateforme : ne perdre ni données ni positions
La peur du déménagement repose sur une histoire que tout le monde a entendue : « des connaissances ont migré leur site et perdu tout leur trafic ». L'histoire est vraie — mais la cause n'était pas la migration, plutôt une poignée de détails oubliés. Voyons ce qui fait réellement chuter les positions et à quoi ressemble une migration après laquelle rien ne change dans Google.
Ce qui fait vraiment chuter les positions
Un moteur ne sanctionne pas un changement de plateforme : il réagit au fait que des pages sont soudain inaccessibles ou méconnaissables. Presque toutes les chutes après migration tiennent à cinq causes :
- Des adresses modifiées sans redirections. Le nouveau CMS a produit ses propres URL, les anciennes renvoient 404 — et les positions comme les backlinks partent avec elles.
- Des métadonnées non reprises. Title et description ont été générés depuis un gabarit, et une page qui tenait depuis des années sur un intitulé précis est devenue « Catégorie — Boutique ».
- Un noindex oublié. L'environnement de test avait été fermé à l'indexation — et personne ne l'a rouvert après la mise en ligne.
- Des doublons issus des filtres. La nouvelle plateforme génère des pages à paramètres : au lieu d'une page forte, l'index en contient quarante faibles.
- Tout n'a pas été migré. Des produits sans description ni photo, des catégories vides, des articles de blog disparus — la valeur globale du site pour le moteur a baissé.
Ce qu'il faut absolument transférer
La liste minimale sans laquelle une migration ne peut être considérée comme terminée :
- Produits et catalogue — avec caractéristiques, photos, catégories, marques, stocks et prix, ainsi que les filtres.
- Commandes et clients — historique avec contenu et statuts, comptes, adresses de livraison, avis. C'est ce qu'on « oublie » le plus souvent, parce que cela ne se voit pas sur le site.
- Contenu — pages, articles, documents, versions linguistiques.
- La couche SEO — structure d'URL, title et description de chaque page, canonical, sitemap, robots, données structurées.
Un mot sur les commandes et les clients : techniquement, le site fonctionnera sans eux, c'est pourquoi les migrations bon marché les laissent dans l'ancienne base. Six mois plus tard, l'ancien hébergement est coupé — et tout l'historique d'achats disparaît avec lui. Ce n'est pas une hypothèse : c'est la perte la plus fréquente lors d'une migration.
Redirections 301 : comment bien faire
La migration idéale est celle où les adresses ne changent pas du tout : aucune redirection n'est alors nécessaire. Si la plateforme impose une autre structure, une règle simple s'applique : chaque ancienne adresse mène à son équivalent nouveau le plus proche, en 301, en un seul saut.
- Ne renvoyez pas tout vers l'accueil : une redirection massive vers « / » est interprétée par Google comme une soft 404, et la page disparaît purement et simplement.
- Évitez les chaînes : ancienne → intermédiaire → nouvelle. Chaque maillon coûte du poids et du temps.
- Vérifiez par liste et non par échantillon : chaque adresse de l'ancien sitemap doit renvoyer 200 ou 301, aucune 404.
- N'oubliez pas les versions avec et sans www, http et https — ce sont aussi des adresses.
L'ordre qui ne laisse rien se perdre
- On relève la référence. Avant tout travail, on exporte la carte complète de l'ancien site : toutes les adresses, title, description, H1 et positions du jour. C'est le point de comparaison.
- On construit la nouvelle plateforme à part. L'ancien site continue de tourner et de vendre pendant ce temps.
- Migration d'essai sur une copie. On compare les volumes : il y avait 4 312 produits — il y en a 4 312. Pas « à peu près autant ».
- Carte des redirections. Chaque adresse de la référence reçoit son équivalent.
- Bascule dans la fenêtre de trafic la plus faible. L'ancien environnement reste actif quelques jours — retour arrière en une minute.
- Deux semaines de surveillance. Search Console, positions, 404, demandes, formulaires, paiement.
Check-list du premier jour après la mise en ligne
- robots.txt ouvert, meta noindex retirés — vérifiés à la main, pas « ça devrait aller ».
- Nouveau sitemap.xml généré et soumis dans la Search Console.
- Contrôle par sondage de 20 à 30 anciennes adresses : toutes renvoient 200 ou 301.
- Title et description des pages clés conformes à la référence.
- Formulaires, panier et paiement testés de bout en bout, avec une vraie commande de test.
- Compteurs analytiques et conversions opérationnels, objectifs non perdus.
- Vitesse : Core Web Vitals pas moins bons que sur l'ancien site.
La règle de vérification principale : un code 200 ne signifie pas encore que la page est intacte. Comparez à la référence — contenu, métadonnées, nombre de produits dans la catégorie.
Coût et durée
La migration d'un site vitrine ou corporate prend 2 à 4 semaines ; une boutique de plusieurs milliers de produits avec intégrations, à partir de 5 semaines. Le prix se compose de la nouvelle plateforme au tarif (à partir de €294 pour une vitrine, à partir de €490 pour une boutique) et du travail de reprise des données, dont l'ampleur apparaît après l'audit.
À ne pas confondre avec un simple changement d'hébergeur sans changer de moteur : c'est le même système sur un nouveau serveur, un à deux jours de travail, à partir de €50. Si on vous propose de « migrer votre site vers une nouvelle plateforme » à ce prix, on migrera probablement le design en laissant les données derrière.