Migration de site e-commerce : plan étape par étape, redirections 301 et export des données

La migration d'un site e-commerce consiste à déplacer les produits, les clients, les commandes, le contenu et les adresses URL d'une ancienne plateforme vers une nouvelle — de façon à ce qu'un client arrivant depuis un ancien favori, et le robot de Google visitant une ancienne adresse, arrivent tous deux au bon endroit. L'installation de la nouvelle boutique n'est que la plus petite partie de ce travail. L'essentiel du risque se trouve dans ce qui doit être déplacé sans changement : les adresses, les données et les textes sur lesquels votre visibilité s'est construite pendant des années.

Cet article s'appuie sur les recommandations de Google pour le déplacement d'un site avec changement d'adresses, sur la documentation d'export des données publiée par les fournisseurs de plateformes (consultée le 30 septembre 2026), et sur les exigences des Core Web Vitals décrites sur web.dev. Vous ne trouverez ici ni témoignages clients, ni promesse de « zéro baisse » — Google lui-même indique que des fluctuations de classement pendant un déplacement sont à prévoir, pas à éviter. À la place, vous obtenez un plan en sept étapes et une liste de choses à vérifier avant de basculer le domaine.

Quand changer de plateforme a du sens, et quand cela n'en a pas

Une migration a un coût : le temps de l'agence, le temps de votre équipe, le risque d'une baisse de trafic temporaire, et des perturbations dans le traitement des commandes. Elle a du sens quand la plateforme actuelle vous coûte plus que le changement n'en coûterait — en argent, ou en opportunités manquées. Trois raisons courantes :

• Le coût. Les frais d'abonnement, les frais par commande ou par transaction, et les applications payantes augmentent tous avec les ventes. Les plateformes SaaS diffèrent beaucoup à cet égard : certaines facturent des frais par commande, d'autres ajoutent une surtaxe pour l'utilisation d'une passerelle de paiement extérieure à la leur, d'autres ne facturent qu'un abonnement. Avant de supposer qu'une autre plateforme serait moins chère, calculez le coût total pour votre propre volume de commandes dans notre calculateur TCO e-commerce et consultez la répartition dans notre article combien coûte une boutique en ligne.
• Les limites de la plateforme. Pas d'intégration ERP ou entrepôt, impossible de gérer des grilles tarifaires B2B, plusieurs devises ou marchés, et les contournements coûtent plus qu'un nouveau système.
• La fin du support ou du produit. Un moteur open source cesse de recevoir des mises à jour de sécurité pour votre version, ou un fournisseur SaaS change de propriétaire ou disparaît. Ce genre de consolidation se produit dans le SaaS : un fournisseur peut être racheté, ou simplement abandonner une gamme de produits, imposant une migration selon un calendrier qui n'a rien à voir avec vos propres plans. C'est une raison de surveiller la solidité de votre fournisseur, pas seulement sa liste de fonctionnalités.

Une migration n'a généralement pas de sens quand le problème est l'apparence, un thème lent, ou une faible conversion sur une plateforme qui, par ailleurs, répond à vos besoins. Un nouveau thème, l'optimisation des images ou un panier simplifié sont des changements à l'intérieur de la même plateforme — moins chers, et sans le risque de perdre vos adresses. Si vous ne savez pas si votre plateforme suffit encore, comparez les modèles dans notre comparatif des plateformes e-commerce, ou essayez le quiz quelle plateforme e-commerce.

Migration et SEO : ce que dit Google sur le déplacement d'un site avec de nouvelles URL

Google traite ce scénario dans son guide Search Central « Migrer un site », dans la partie consacrée aux déplacements avec changement d'URL. Changer de plateforme modifie presque toujours les adresses : une structure de catégories différente, des terminaisons d'URL produit différentes, des paramètres de filtre différents. Quatre règles découlent de ce document.

Des redirections permanentes côté serveur. Google l'écrit ainsi : « Nous vous recommandons d'utiliser des redirections HTTP permanentes si possible, telles que 301 et 308. » Chaque ancienne adresse doit rediriger directement vers son équivalent nouveau — pas vers la page d'accueil, et pas via une chaîne de plusieurs redirections.

Conserver les redirections longtemps. Littéralement : « Conservez les redirections aussi longtemps que possible, généralement au moins un an. » Un an est un minimum, pas une date de suppression : les liens vers vos produits dans d'anciens articles, sur des forums et dans les favoris des clients ne disparaissent pas après douze mois.

Un nouveau sitemap. Google conseille : « Envoyez le nouveau sitemap dans la Search Console. » L'outil de changement d'adresse de Search Console ne s'applique que lors d'un déplacement d'un domaine ou sous-domaine vers un autre — c'est-à-dire un changement de domaine ou de sous-domaine. Si la boutique reste sur le même domaine et que seuls les chemins changent, cet outil n'est pas nécessaire.

Les fluctuations de classement sont normales. Google le dit clairement : « La visibilité de votre contenu dans la recherche sur le Web peut fluctuer temporairement pendant la migration. » Et sur la durée : « En règle générale, quelques semaines peuvent être nécessaires à la migration de la majorité des pages d'un site de petite à moyenne taille. »

Cette dernière phrase a une conséquence gênante pour quiconque vend des services de migration : aucun prestataire honnête ne peut vous garantir que vos positions ne baisseront pas. Une migration bien préparée raccourcit la période de fluctuation et en réduit l'ampleur, car Google retrouve rapidement chaque ancienne page à sa nouvelle adresse. Elle ne supprime toutefois pas la phase de réexploration. Si quelqu'un promet une « migration sans baisse de classement », demandez sur quoi cela se fonde — et prévoyez votre budget et vos campagnes de façon à ce que quelques semaines plus faibles ne coulent pas vos ventes.

Plan de migration d'un site e-commerce en sept étapes

L'ordre compte plus que la vitesse : on détermine d'abord ce qui doit être déplacé, puis on le déplace, puis on teste, et on ne bascule qu'ensuite. Chaque étape a besoin d'un responsable — une personne qui voit l'ensemble et valide le passage à l'étape suivante. Ce n'est pas forcément un développeur, mais quelqu'un qui relie la plateforme, le marketing, le service client et le SEO. Chaque point ici est aussi disponible sous forme de checklist dans notre checklist de migration de boutique.

1. Inventaire des URL

Rassemblez une liste complète des adresses de l'ancienne boutique : produits (y compris ceux abandonnés, s'ils ont du trafic ou des liens), catégories, pages d'information, articles de blog, pages de marque, et URL filtrées importantes. Il y a trois sources : un robot d'exploration qui parcourt la boutique comme le ferait un moteur de recherche, le sitemap de la plateforme actuelle, et Search Console avec l'analytique, qui montreront les adresses avec du trafic et des impressions — y compris celles vers lesquelles aucun lien de menu ne pointe plus. Repérez les adresses qui apportent du trafic, des ventes ou des liens externes : ce sont elles qui demandent le plus d'attention.

C'est aussi un bon moment pour faire du rangement, avec modération. Supprimer une catégorie vide ou un produit disparu depuis des années ne pose pas de problème — à condition que son adresse reçoive quand même une redirection vers la page la plus pertinente.

2. Plan de redirection

Le plan de redirection est un tableau à deux colonnes : ancienne adresse et nouvelle adresse. C'est le document le plus important de toute la migration. Règles :

• chaque ancienne adresse pointe vers exactement une nouvelle adresse précise — produit vers produit, catégorie vers catégorie ;
• un produit abandonné sans successeur redirige vers la catégorie à laquelle il appartenait, pas vers la page d'accueil ;
• les redirections doivent être permanentes (301 ou 308) et s'exécuter côté serveur, pas via un script dans le navigateur ;
• aucune chaîne : si l'ancienne boutique avait déjà des redirections issues de changements antérieurs, mettez-les à jour pour qu'elles pointent directement vers l'adresse finale.

Les adresses qui posent le plus de problèmes lors d'une migration sont celles générées automatiquement : variantes de produits, pagination, résultats de filtres. Déterminez à l'avance comment la nouvelle plateforme construit ces URL et si elle peut conserver les anciens chemins. Si c'est le cas, conserver la même structure d'URL est la protection la plus simple contre les fluctuations.

3. Export des données : produits, clients, commandes

Sur les plateformes SaaS, l'export est le principal — souvent le seul — moyen d'emporter vos données avec vous. Les fournisseurs le décrivent dans leur documentation, mais l'étendue varie selon la plateforme. Selon les pages d'aide consultées le 30 septembre 2026 :

• Shopify : l'export des clients, des commandes et des produits en CSV est documenté dans le centre d'aide (clients, commandes, produits).
• Wix : export des produits en CSV jusqu'à 5 000 lignes, hors produits numériques (aide Wix), export des commandes en CSV, et des contacts jusqu'à 50 000 à la fois.
• Squarespace : produits jusqu'à 10 000 (aide Squarespace), export des commandes en CSV « disponible pour tous les forfaits », et des clients sous forme de fichier CSV.
• BigCommerce : commandes et clients en CSV ou XML, produits en CSV (aide BigCommerce, en anglais, sur les commandes et les clients) ; selon sa page tarifaire, une boutique d'essai non convertie en abonnement est conservée 90 jours, puis supprimée.

Deux conséquences pratiques. D'abord, un fichier CSV, ce sont des données, pas une boutique : le thème, la configuration des paiements et de la livraison, les règles de remise, les applications et les redirections doivent tous être reconstruits à la main. Ensuite, exporter depuis l'ancienne plateforme n'est que la moitié du travail — l'autre moitié est l'import dans la nouvelle. Les colonnes correspondent rarement, donc avant la migration réelle, faites un export et un import test sur quelques dizaines d'enregistrements, variantes de produits et images incluses.

Vérifiez les conditions de sortie d'une plateforme SaaS avant de vous y engager, pas après — nous expliquons pourquoi cela fait partie de l'évaluation de tout service cloud dans notre article sur la sécurité des données dans le cloud, et plus généralement sur le modèle par abonnement dans notre guide du SaaS.

Passer à PrestaShop. PrestaShop est un logiciel open source : la boutique peut tourner sur votre propre serveur, ou sur PrestaShop Hosted, qui coûte, selon la page tarifaire du fournisseur, 29 € HT par mois sans engagement, ou 24 € HT par mois en facturation annuelle (consulté le 30.09.2026 et le 01.10.2026 ; le fournisseur n'affiche pas de prix en francs suisses, donc ces montants restent en euros, non convertis ; les prix changent). À propos de la version Hosted, le fournisseur écrit que vous êtes « libre de récupérer toutes les données liées à votre e-commerce si vous souhaitez arrêter votre abonnement ». Le travail principal consiste à faire correspondre vos colonnes exportées au format d'import de PrestaShop et à reconstruire votre structure de catégories pour que le plan de redirection ait des cibles.

Passer à Shopify. Shopify permet de tester un import avant de payer : selon la page tarifaire suisse de Shopify (consultée le 30.09.2026 et le 01.10.2026), l'essai est de 3 jours, puis CHF 1/mois pendant 3 mois. Le forfait Basic coûte CHF 29/mois en facturation mensuelle ou CHF 21/mois en facturation annuelle ; la page ne précise pas si ces montants incluent la TVA. Vérifiez les coûts de paiement avant de décider : si vous conservez votre propre arrangement avec une passerelle externe, Shopify ajoute des frais de transaction tiers — 2 % sur Basic, 1 % sur Grow, 0,6 % sur Advanced et 0,2 % sur Plus, selon la page suisse — en plus des frais de la passerelle elle-même. Cela ne s'applique pas aux méthodes manuelles comme le paiement à la livraison. L'alternative est Shopify Payments, disponible en Suisse.

4. Contenu et métadonnées

Descriptions de produits et de catégories, titres de pages, meta descriptions, titres de section, textes alternatifs des images, données structurées des produits, articles de blog. C'est ce qui fait que la page à la nouvelle adresse est « la même page » — et non une nouvelle que Google doit évaluer depuis zéro. Comparez l'export de contenu de l'ancienne et de la nouvelle boutique champ par champ, sur un échantillon de vos produits les plus visités. Un problème fréquent : le nouveau thème génère titres et descriptions selon son propre modèle et écrase ceux que quelqu'un a mis des années à peaufiner.

Une règle compte plus que les autres ici : ne changez pas tout en même temps. Une nouvelle plateforme, une nouvelle structure de catégories, de nouveaux textes et une nouvelle apparence, tout le même jour, sont quatre changements dont vous ne pourrez jamais séparer les effets après coup. Déplacez d'abord la boutique aussi fidèlement que possible, et ne prévoyez la refonte du contenu et du design qu'une fois le trafic stabilisé.

5. Un environnement de test

La nouvelle boutique se construit sur une copie de vos données, dans un environnement de test bloqué à l'indexation — par mot de passe, ou par restriction d'accès. Une copie de test visible par Google est un doublon de votre boutique à une autre adresse. Il en va de même après la migration : ne laissez pas une ancienne version accessible publiquement « au cas où » sur un sous-domaine ; conservez une copie complète des données et des fichiers, pas une seconde boutique en fonctionnement.

6. Tests avant la bascule

Sur l'environnement de test, vérifiez :

• les redirections — tout le plan, automatiquement : chaque ancienne adresse répond-elle avec un code 301 ou 308, redirige-t-elle directement vers la bonne nouvelle adresse, et n'y a-t-il ni boucle ni erreur 404 ;
• le parcours d'achat — pour chaque mode de paiement et chaque mode de livraison : une commande test, un e-mail de confirmation, une facture, un retour ;
• l'analytique — les événements d'ajout au panier, de début de commande et d'achat se déclenchent-ils correctement, et les paiements revenant de la passerelle sont-ils correctement enregistrés ;
• les intégrations — entrepôt, ERP, marketplace, transporteurs ;
• la performance — Core Web Vitals sur les modèles clés : page d'accueil, catégorie, produit, panier (plus de détails plus bas).

7. Jour de bascule

Choisissez un jour avec moins de trafic et sans campagne promotionnelle en cours. Suspendez brièvement les changements de catalogue pour que le dernier export soit complet, transférez les commandes passées dans les dernières heures, activez les redirections, basculez le domaine, et vérifiez immédiatement en direct un échantillon d'anciennes adresses et une commande test. Soumettez le nouveau sitemap dans la Search Console le même jour. Mettez à jour les campagnes payantes pour qu'elles pointent directement vers les nouvelles adresses plutôt que de dépendre des redirections.

Les données et comptes clients après la migration

Les comptes clients sont la partie la plus sous-estimée d'une migration. Deux choses doivent être réglées avec les deux fournisseurs — ancien et nouveau — avant de fixer une date de bascule.

Mots de passe. La documentation d'export citée plus haut couvre les données clients, mais ne promet pas que les mots de passe pourront être transférés. Demandez à l'ancien fournisseur si, et sous quelle forme, les mots de passe peuvent être exportés, et au nouveau s'il peut les accepter. Si l'une des réponses est « non », prévoyez votre communication : un e-mail aux clients concernant la nouvelle boutique avec des instructions pour définir un mot de passe, envoyé le jour de la bascule, plus un message clair sur la page de connexion.

Consentements et historique. Un client, c'est plus qu'une adresse e-mail. Vérifiez si l'export inclut les données de consentement marketing (avec une date et une source, si l'ancienne plateforme les enregistre), l'historique des commandes nécessaire pour traiter les réclamations et les retours, et les adresses de livraison. Ne transférez les consentements à la newsletter que si vous en avez la trace — et vérifiez avec le responsable de la protection des données de votre entreprise comment traiter le transfert de données personnelles. Rappelez-vous aussi qu'un export de clients est un fichier de données personnelles : conservez-le et transmettez-le comme toute autre base de données clients, et supprimez les copies de travail une fois la migration terminée.

Commandes. Le fait que l'ancienne plateforme exporte les commandes en CSV ne signifie pas que la nouvelle les importera comme un historique complet. Parfois une archive hors plateforme suffit ; parfois l'historique doit être visible sur le compte du client. Réglez ce point dès le début, car il déterminera l'étendue du travail.

Performance et Core Web Vitals après la migration

Une nouvelle plateforme et un nouveau thème changent la vitesse d'une boutique — pour le mieux ou pour le pire. Mesurez donc les Core Web Vitals avant la migration, sur les mêmes types de pages que vous mesurerez après. Sans point de référence, vous ne pourrez pas savoir si le déplacement a réellement aidé.

Si vous avez d'anciennes notes d'audit, un élément y est obsolète. Le FID (First Input Delay) ne fait plus partie des Core Web Vitals. L'équipe de web.dev a annoncé en janvier 2024 que l'INP deviendrait officiellement une Core Web Vital et remplacerait le FID le 12 mars 2024 (annonce sur web.dev, en anglais). L'INP (Interaction to Next Paint) mesure la rapidité avec laquelle une page répond aux actions de l'utilisateur — clics, appuis, frappes au clavier.

Les seuils, selon web.dev : « Un INP inférieur ou égal à 200 millisecondes signifie que la page a une bonne réactivité » ; entre 200 et 500 ms, la réactivité doit être améliorée, et au-delà de 500 ms elle est mauvaise. Lors d'une migration, portez une attention particulière aux scripts tiers — widgets de chat, avis, recommandations, pixels publicitaires — et aux filtres de catégories. Chaque application conservée est du code supplémentaire exécuté dans le navigateur du client, donc vérifiez celles dont vous avez encore besoin.

Ce qu'il faut mesurer avant et après : LCP, INP et CLS pour la page d'accueil, la catégorie, la fiche produit et le panier, séparément sur mobile et sur ordinateur, dans Search Console et dans PageSpeed Insights. Les données de terrain issues de vraies visites s'accumulent avec un décalage, donc vous ne verrez le tableau complet que quelques semaines après la migration. Le SEO technique d'une boutique est traité plus en détail dans notre vue d'ensemble du SEO e-commerce ; les éléments du panier et de la commande à vérifier en même temps figurent dans notre checklist UX de boutique.

Les 90 premiers jours après la migration : que surveiller

La migration ne se termine pas le jour de la bascule. Pendant les trois premiers mois, vous observez si Google et les clients retrouvent leur chemin vers les nouvelles adresses.

Première semaine. Vérifiez les erreurs 404 quotidiennement — dans Search Console et dans les journaux du serveur ou l'interface d'administration de la plateforme. Toute ancienne adresse qui renvoie une 404 mais a du trafic ou des liens est ajoutée au plan de redirection. Vérifiez que les commandes arrivent, que les paiements sont bien encaissés, que les e-mails arrivent. Comparez la conversion avec la même période avant la migration.

Premier mois. Dans Search Console, suivez l'état d'indexation des nouvelles adresses et la disparition des anciennes des résultats. Comparez le trafic organique et les impressions avec la période précédant le déplacement — en vous rappelant que, selon Google, des fluctuations temporaires pendant quelques semaines sont normales. Demandez aux propriétaires de vos liens externes les plus importants — partenaires, annuaires, comparateurs — de mettre à jour leurs adresses. La redirection fonctionne, mais un lien direct est plus fiable.

Deuxième et troisième mois. Une fois le trafic stabilisé, commencez les changements reportés : contenu, design, structure. Introduisez-les séparément pour pouvoir observer leur effet. Comparez les Core Web Vitals avec la mesure d'avant la migration.

Pendant toute l'année et au-delà. Ne supprimez pas les redirections. Google recommande de les conserver « généralement au moins un an », et en pratique aussi longtemps que la boutique fonctionne. Si vous changez à nouveau de serveur ou de plateforme un jour, le plan de redirection de cette migration fait partie de la boutique qu'il faudra déplacer à son tour.

Si la nouvelle boutique fonctionne en SaaS, la disponibilité et le délai de réaction aux incidents sont fixés par le contrat avec votre fournisseur — vérifiez ce qu'il promet réellement avant de vous y fier.

Migrer vers le headless

Un cas particulier est le passage à une architecture headless : la vitrine devient une application séparée, et le moteur (SaaS ou open source) fournit les produits, le panier et les commandes via une API. Toutes les règles de cet article — le plan de redirection, les tests d'export et d'import, l'environnement de test, le suivi — s'appliquent de la même façon. S'ajoute le fait que les URL, les métadonnées et les données structurées sont désormais générées par votre propre vitrine plutôt qu'héritées d'un thème de plateforme, donc vous devez les concevoir plutôt que les recevoir toutes faites. Nous expliquons quand ce passage est rentable, et quand une boutique classique suffit, dans notre article sur le e-commerce headless. Nous construisons nous-mêmes des boutiques dans ce modèle — les détails sont sur notre page boutique headless.

Tous nos articles sur le choix et le changement de plateforme se trouvent dans l'aperçu des plateformes e-commerce.