Un site Wix ne peut pas être soulevé sur un autre serveur. Point final. Wix dit que le site doit être hébergé et exploité sur ses propres serveurs, donc tout déménagement est une refonte plutôt qu'un transfert. Les données métier autour du site sont différentes : les produits de magasin physique et les contacts ont des exports CSV documentés, tandis que les articles de blog n'ont pas de route d'export native.
Quelle route convient à quelle situation
Commencez par la situation, pas par une liste de dix marques. La plupart des listes comparatives se terminent par un gagnant. C'est ordonnée. Ce n'est pas très utile quand votre véritable question est ce que vous devriez reconstruire.
Voici comment je le formulerais, comme des évaluations conditionnelles et non un classement :
- Petit site, processus d'édition fonctionnel : rester sur Wix est une réponse légitime.
- Équipe marketing visuelle : testez un autre constructeur visuel avec vos propres pages.
- Boutique : évaluez d'abord une plateforme de commerce, puis un constructeur de pages.
- Contenu structuré plus support de développement : testez une approche headless.
Si votre liste restreinte est plus large que cela, l'aperçu des alternatives CMS couvre la décision plus large.
| Site ou rôle | Approche à tester | Modèle d'édition | Responsabilité opérationnelle | Refonte ou validation |
|---|---|---|---|---|
| Petit site de présentation, édition déjà fonctionnelle | Rester sur Wix | Éditeur Wix, inchangé | Wix héberge et met à jour ; vous possédez le contenu, le plan et les renouvellements de domaine | Corrigez le problème spécifique ; confirmez que le plan et la connexion du domaine restent en place |
| Site marketing piloté par modèles | Squarespace | Éditeur hébergé et basé sur des modèles | La plateforme héberge ; l'équipe possède le contenu et la structure des pages | Chaque page et modèle ; formulaires, redirections, métadonnées |
| Site marketing piloté par le design avec un CMS | Webflow ou Framer | Canevas visuel plus collections CMS | La plateforme héberge ; l'équipe possède la modélisation des collections | Conception recréée; collections construites; l'éditeur publie une véritable page |
| Boutique | Shopify | Panneau d'administration de la boutique | La plateforme héberge; l'équipe gère le catalogue, la configuration de la caisse et l'exécution des commandes | CSV de produits modifié; produits numériques, comptes clients, caisse et e-mails de commande |
| Site de contenu, l'équipe possédera l'hébergement | WordPress | Éditeur de blocs plus extensions | L'équipe gère l'hébergement, les mises à jour et le cycle de vie des extensions | Thème et styles; blog par lots; permaliens, formulaires, sauvegardes |
| Contenu structuré, assistance développeur | Astro avec un CMS headless | CMS pour les éditeurs, code pour le front-end | Les développeurs et l'équipe partagent la construction, l'hébergement et la maintenance du CMS | Modèles, aperçu, formulaires, recherche, redirections, flux de publication |
Traiter le tableau comme un plan de test. Ce n'est pas une matrice de fonctionnalités ou de tarification, et je n'ai pas essayé d'en faire une.
Ce que quitter Wix signifie vraiment
La propre page d'aide de Wix est directe. Le site est construit avec la technologie de Wix et, selon Wix, « il doit être hébergé et exploité sur les serveurs de Wix » (Support Wix). La raison invoquée est que l'architecture SaaS repose sur la technologie propriétaire et les services de Wix, de sorte qu'aucun autre hébergeur ne peut l'exécuter. Wix affirme également que le contenu que vous créez vous appartient. Les deux affirmations sont vraies à la fois. Posséder vos mots et images n'est pas la même chose que de posséder un site en exploitation portable.
Partir signifie donc reconstruire sur une autre plateforme, puis transférer toutes les données pour lesquelles il existe une route d'export. Maintenez cette distinction claire. Trois malinterprétations valent la peine d'être éliminées d'emblée:
- Acheter un hébergement ailleurs ne déplace pas le site. Il n'y a rien pour cet hébergeur à exploiter.
- Le domaine est une décision distincte. Wix dit qu'un domaine peut être acheté et géré auprès d'un autre fournisseur et connecté à un site Wix, bien que la connexion nécessite un plan payant. Conserver le domaine ne dit rien sur le lieu où vivent les pages.
- Un iframe n'est pas une migration. Wix dit qu'elle ne peut pas prendre en charge un site intégré, n'est plus en contrôle de son apparence ou de son fonctionnement, et avertit que Google Analytics et les moteurs de recherche peuvent ne pas fonctionner correctement avec les intégrations.
Un autre point: chaque type de données a sa propre histoire d'export. Les pages, les produits, les contacts et les articles ne partent pas par la même porte. La cinquième section les examine l'un après l'autre.
Quand rester sur Wix est le bon choix
Un bon nombre de sites Wix devraient rester en place. Avant de reconstruire, nommez le problème réel: une navigation qui confond les visiteurs, un contenu maigre, une seule image de héros surdimensionnée, une seule application qui ne convient plus, ou un processus d'édition que personne ne suit. Chacun de ces éléments peut être corrigé sans changer de plateforme. Une reconstruction ne fait que les déplacer vers un nouvel endroit.
Si la vitesse est la raison invoquée, rassemblez des preuves avant d'agir. Mesurez d'abord. Un véritable audit de performance vous dira si la cause vient de la plateforme, des images, des applications ou du design de la page. Ne reprenez pas un chiffre lu dans un fil de forum.
Ensuite, dénombrez ce qui fonctionne déjà. Les règles de réservation, les flux de paiement, les e-mails de confirmation, l'acheminement des formulaires et l'accès des membres ont tous demandé des efforts pour être configurés correctement. Les reconstruire coûte du temps et porte le risque d'une défaillance silencieuse le premier jour, par exemple un formulaire de réservation qui s'envoie mais ne notifie personne. Je ne mettrai pas de chiffre dessus, car cela dépend entièrement de votre configuration. Néanmoins, portez-le au bilan à côté du nouveau prix d'abonnement.
Un changement se justifie par un besoin vérifié : un modèle de contenu que Wix ne peut pas vous proposer, une opération de boutique qu'il ne couvre pas, ou un workflow que votre équipe ne peut pas gérer. « Wix ne peut pas se classer » ou « Wix est lent » en tant qu'affirmation générale n'est pas un besoin. C'est une impression.
Comparer la sélection par vrai travail
Chaque option ci-dessous en recoit une, un compromis et un test. Les points forts sont mes évaluations, pas des garanties de fournisseur.
Squarespace
Point fort : une entreprise qui veut un workflow de publication hébergé et basé sur des modèles, et qui est heureuse de travailler à l'intérieur de la structure d'un modèle. Compromis : vous reconstruisez chaque page, et les mises en page inhabituelles peuvent nécessiter un compromis. Test : demandez à votre éditeur de publier une véritable page de service et un article de blog, avec des images, à partir du modèle sélectionné.
Webflow ou Framer
Point fort : les équipes qui veulent un design visuel différent et un workflow CMS. Webflow décrit son CMS autour du contenu visuel et du travail de design, et Framer décrit son CMS autour des collections. Compromis : la structure que vous construisez dans les collections devient quelque chose que l'équipe doit maintenir, et aucune source ne prouve que l'un ou l'autre outil est plus capable que Wix pour vos besoins. Test : modélisez un vrai type de contenu, tel que des études de cas, et demandez à l'éditeur d'ajouter une entrée sans aide.
Shopify
Point fort : le catalogue, le paiement et les opérations de boutique pilotent la décision. Compromis : vous assumez une configuration de boutique que un site vitrine n'a jamais eue, et la documentation de Shopify sur une route de vitrine headless est une décision ultérieure, pas un point de départ. Test : la personne qui traite les commandes exécute une commande complète, du panier à l'e-mail d'exécution, avec un produit qui a des variantes.
WordPress
Point fort : une équipe prête à maîtriser l'hébergement et le cycle de vie des extensions, pour le contrôle que cela donne. La page de fonctionnalités du projet est par où commencer. Compromis : les mises à jour, les sauvegardes et les choix d'extensions deviennent votre responsabilité. Test : demandez qui appliquera les mises à jour au mois six, et demandez à l'éditeur de publier une page avec l'éditeur de blocs. Nous le comparons avec d'autres options dans les alternatives à WordPress, et je ne fais pas la promotion de l'implémentation de WordPress ici.
Astro avec un CMS headless
Point fort : la diffusion de contenu soutenue par les développeurs. La documentation d'Astro le positionne pour les sites axés sur le contenu avec rendu côté serveur. Compromis : Astro est un framework, pas un constructeur visuel clés en main. Vous devez toujours choisir un CMS et concevoir le workflow de publication. Le headless n'est pas non plus exempt de maintenance. Ces objectifs de conception ne prouvent pas un meilleur résultat pour votre site ou pour le SEO. Test : l'éditeur peut-il brouiller et prévisualiser, puis publier sans ouvrir un éditeur de code ? Ce qu'une implémentation headless inclut pour les éditeurs importe plus que le nom du framework.
Ce qui quitte Wix et ce qui nécessite une gestion séparée
C'est là que la revendication d'être « piégé » s'effondre. Certaines données ont une route documentée pour sortir. D'autres non. Gardez les deux idées séparées.
- Produits en magasin physique : Wix Stores exporte les produits avec leurs données au format CSV. La limite est jusqu'à 5 000 lignes par fichier, et vous pouvez exporter tout, une catégorie filtrée ou des articles sélectionnés. L'export de produits numériques n'est actuellement pas pris en charge.
- Contacts : Wix Contacts exporte jusqu'à 50 000 contacts à la fois au format CSV, aux formats Regular, Google ou Outlook. Seul le propriétaire du site peut le faire. Au format Google, les labels ne sont pas exportés, et certains champs arrivent comme des champs personnalisés Google. Le CSV Google est limité à 5 entrées d'e-mail, de téléphone et d'adresse par contact et 16 champs personnalisés.
- Articles de blog : la page de demande de fonctionnalité de Wix indique que, actuellement, il n'est pas possible de exporter les articles de blog vers d'autres plates-formes. Cette page a été vérifiée le 4 novembre 2026, et Wix note que les fonctionnalités planifiées sont sujettes à modification.
Cette dernière ligne décrit le workflow natif documenté. Ce n'est pas la preuve que l'extraction manuelle, une API ou une migration sur mesure est impossible. Les guides tiers décrivent une solution de contournement : WordPress.com indique que Wix propose un flux RSS qui peut importer les 20 articles les plus récents (WordPress.com), et Codeable indique que les blogs plus volumineux nécessitent des lots répétés de 20 (Codeable). WordPress.com indique également que son importateur Wix gère les pages statiques, les images, le titre du site et les menus. Un thème ne recréera pas votre design Wix exact.
Le média des produits arrive comme une étape séparée, selon un guide HighLevel, et le guide de migration Wix de Shopify indique que le CSV des produits doit être édité avant l'importation.
Auditez donc ces éléments séparément : médias, contenu de page, taxonomie de blog, métadonnées, formulaires, réservations, adhésions, paiements, données d'applications et permissions. Un CSV de produit ou de contact ne porte pas un site fonctionnel. Il ne porte pas non plus les comptes de membre authentifiés, car rien dans les exports documentés ne décrit les mots de passe ou les identifiants de connexion. Prévoyez que les membres s'inscrivent ou soient invités à nouveau à moins que votre destination n'en dispose autrement.
Construisez l'étendue de la migration avant de choisir un outil
Commencez par l'étendue. Le choix de l'outil vient après, et devient plus facile une fois que vous avez un inventaire. Écrivez :
- chaque page et son modèle
- chaque type de contenu (articles, services, profils d'équipe, études de cas)
- intégrations, ainsi que dépendances e-mail et DNS
- règles de réservation, opérations boutique et destinations de formulaires
- permissions d'équipe et qui peut publier quoi
- analyse, suivi et configuration du consentement
Puis exécutez deux tests sur chaque plateforme retenue. Demandez à l'éditeur de publier une page représentative, avec de vraies images et un formulaire. Demandez à la personne responsable des prospects, réservations ou commandes d'exécuter un workflow réel de bout en bout. Pour les prospects, cela signifie un prospect qui arrive ; pour les réservations, une réservation confirmée ; pour les commandes, une commande exécutée. Si l'une ou l'autre personne ralentit ou est confuse, vous avez appris quelque chose qu'une liste de fonctionnalités ne montrerait jamais.
Placez la responsabilité à côté des fonctionnalités visuelles. Nommez la personne qui met à jour la plateforme ou les plugins. Notez qui renouvelle le domaine et qui reçoit l'alerte quand un formulaire cesse d'envoyer. Une plateforme qui paraît superbe mais n'a pas de propriétaire nommé pour la maintenance est un problème futur.
Liste de contrôle de validation avant et après le basculement
C'est la liste que je travaillerais. Elle ne promet pas que copier les métadonnées préservera les classements. Personne ne peut promettre cela.
- Indexez l'inventaire des URL et les backlinks connus avant de toucher à quoi que ce soit.
- Conservez les adresses identiques où c'est pratique, et mappez chaque adresse modifiée avec une redirection permanente.
- Vérifiez le contenu des pages, les fichiers téléchargeables, la propriété des images et les copies, le texte alternatif, les métadonnées, les canoniques et les données structurées.
- Testez les formulaires et leurs messages de confirmation, ainsi que les bannières de consentement.
- Testez les réservations, le panier et le paiement (le cas échéant), et l'accès aux membres.
- Vérifiez le suivi et la livraison des e-mails.
- Comparez les nombres de contenu entre source et destination.
- Testez sur mobile et au clavier uniquement.
- Vérifiez les modifications DNS et e-mail avant le basculement, car les modifications DNS peuvent perturber le courrier.
- Conservez le site Wix jusqu'à ce que la validation soit terminée, puis surveillez la recherche et le trafic après le basculement.
Apportez votre URL Wix et les formulaires, réservations ou workflows boutique que vous devez conserver afin que le transfert puisse être évalué avant la reconstruction.
FAQ
Un site Wix peut-il être hébergé ailleurs si je conserve le même design ?
Non. Wix dit que le site doit s'exécuter sur ses serveurs, et un design reconstruit sur une autre plateforme est un nouveau site. Le domaine peut rester auprès de n'importe quel fournisseur et pointer où vous le souhaitez.
Puis-je prendre mes produits et contacts avec moi ?
Les produits physiques et les contacts ont tous deux des exports CSV documentés, avec les limites décrites ci-dessus. Les produits numériques ne sont pas pris en charge dans l'export Wix Stores. Attendez-vous à éditer les fichiers avant de les importer dans une nouvelle plateforme.
Le blog Wix dispose-t-il d'une export native ?
Non, selon la page de demande de fonctionnalités de Wix vérifiée en novembre 2026. Les contournements basés sur RSS décrits par des tiers couvrent 20 articles par import, donc vérifiez le nombre d'articles, les images et la taxonomie après.
Quand un frontend personnalisé se justifie-t-il ?
Quand vous avez du contenu structuré qui demande un modèle défini, des développeurs qui maintiendront la build, et un workflow d'édition que vous avez testé avec l'éditeur réel. Si aucune de ces conditions n'est remplie, un builder hébergé est généralement le choix qui demande moins de maintenance.
Le fait le plus net ici est qu'un site Wix ne peut pas migrer vers un autre hébergeur, donc chaque itinéraire est une reconstruction, avec les produits et contacts transférés par CSV et les articles de blog nécessitant un traitement séparé. Planifiez cette reconstruction avec soin. Testez vos workflows réels, puis comparez les prix.