Migrer un site Wix vers WordPress sur cPanel

Ce guide vous accompagne pour sortir un site web de Wix et l’installer sur WordPress autohébergé, sur un serveur cPanel/WHM. Commencez par le fait qui détermine tout le reste : Wix est une plateforme fermée, sans aucune exportation complète du site. Il n’existe ni archive de fichiers, ni vidage de base de données, ni sauvegarde de compte au format cPanel à télécharger. L’outil de transfert de WHM, la façon habituelle de rapatrier un compte depuis un autre serveur cPanel en une commande, n’a donc rien à récupérer. La réponse pratique est de traiter l’opération comme une reconstruction plutôt qu’une restauration. Vous déplacez chaque type de contenu par sa propre voie, puis vous placez une carte de redirections devant le résultat pour que chaque page reste trouvable. À la fin, WordPress servira le domaine, chaque ancienne adresse Wix répondra par une redirection 301, et le courriel arrivera toujours.

Ce que vous allez accomplir

Dresser l’inventaire de chaque URL Wix en ligne à partir du sitemap, pour connaître l’ampleur du travail avant de commencer.
Monter un compte cPanel avec WordPress sur un nom d’hôte temporaire pendant que Wix continue de servir les vrais visiteurs.
Déplacer les billets de blogue, les pages, les images et les produits de boutique par la voie qui fonctionne vraiment pour chacun.
Installer une carte de redirections 301 dans .htaccess qui fait correspondre les chemins /post/<slug> de Wix à vos nouveaux permaliens.
Ordonner la bascule DNS pour que le courriel ne se retrouve jamais sans boîte où atterrir.

Prérequis

Un accès administrateur au site Wix. Il vous faut pour lire le contenu et pour exporter les produits de la boutique.
Un accès au DNS du domaine. Cela veut dire soit l’accès au registraire, soit le panneau des serveurs de noms, selon qui les détient aujourd’hui.
Un compte cPanel sur un serveur que vous contrôlez, ou un accès root à WHM pour en créer un.
Un accès SSH avec WP-CLI, l’outil en ligne de commande de WordPress. Vérifiez avec wp --info. Si votre hébergeur n’offre pas SSH, chaque étape WP-CLI ci-dessous a un équivalent plus lent dans l’admin WordPress, et le travail sur .htaccess se fait dans le gestionnaire de fichiers de cPanel.
dig et curl sur votre propre poste. Les deux sont livrés avec macOS et la plupart des distributions Linux ; sous Windows, utilisez WSL ou Git Bash.
Savoir clairement à qui appartiennent les boîtes courriel. Wix revend Google Workspace, et la possibilité même de déplacer le courriel dépend de qui détient l’abonnement. Confirmez-le avant de toucher à quoi que ce soit.
Une note sur les serveurs web : les serveurs cPanel tournent sous Apache ou LiteSpeed, et les deux lisent .htaccess avec la même syntaxe, donc le travail de redirection s’applique dans les deux cas.

Comment ça fonctionne

Rien ne traverse d’un seul bloc. Chaque type de contenu sort de Wix par une porte différente, et l’une d’elles ne s’ouvre pas du tout si la facturation n’est pas à votre nom.

Les billets de blogue sont la seule pièce qui a une source lisible par une machine. Wix publie un fil RSS, souvent à /blog-feed.xml. Les importateurs intégrés de WordPress, sous Outils > Importer, ne lisent pas le RSS d’une manière qui donne des billets utilisables. Il vous faut donc l’une de deux voies : convertir le fil en WXR, ou utiliser une extension d’importation conçue pour lire ce fil. WXR veut dire WordPress eXtended RSS, et c’est le format XML d’exportation propre à WordPress, celui que l’importateur de WordPress sait lire. Le hic, c’est que le fil Wix ne transporte que les billets les plus récents, souvent les 20 derniers. Tout ce qui est plus ancien se recopie à la main.

Les pages statiques n’ont aucune exportation. Vous les refaites, une par une, en recopiant le texte et en recréant la mise en page dans l’éditeur WordPress. Ça semble sans fin, et c’est pourquoi l’étape d’inventaire compte : 31 pages, c’est un après-midi bien délimité, tandis que « les pages » n’a pas de bord.

Les images et les fichiers vivent sur le domaine statique de Wix, static.wixstatic.com. Il faut les télécharger et les téléverser dans la médiathèque WordPress. Laisser les adresses Wix en place a l’air de fonctionner, et c’est là le piège : ces images se chargent très bien jusqu’au jour où le site Wix ferme, puis elles cassent toutes d’un coup.

Les produits de boutique sont le cas le plus accueillant. Wix Stores offre un export CSV, et WooCommerce a un importateur CSV. Les noms de colonnes ne concordent pas, alors vous les remappez dans l’écran de correspondance des champs de l’importateur.

La partie qui coûte le plus cher si vous la sautez, c’est la structure des URL. Wix sert les billets à /post/<slug>. WordPress ne produira pas cette forme tout seul, donc sans instruction contraire, chaque lien entrant et chaque résultat de recherche bien classé aboutit sur une 404. Une carte de redirections 301 des anciens chemins vers les nouveaux permaliens est obligatoire : c’est la différence entre garder votre trafic et repartir de zéro. Si le classement compte ici, lisez notre guide sur la préservation du classement lors d’une migration en parallèle avec celui-ci.

L’ordre compte aussi, parce que deux étapes peuvent échouer en silence.

Étape par étape

Inventoriez le site à partir de son sitemap. Wix publie un index de sitemaps qui pointe vers un sitemap enfant par type de contenu.

curl -s https://example.com/sitemap.xml

Sortie attendue :

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <sitemap><loc>https://example.com/pages-sitemap.xml</loc></sitemap>
  <sitemap><loc>https://example.com/blog-posts-sitemap.xml</loc></sitemap>
  <sitemap><loc>https://example.com/store-products-sitemap.xml</loc></sitemap>
</sitemapindex>

Récupérez les enfants et aplatissez-les en une seule liste :

for s in pages blog-posts store-products; do
  curl -s "https://example.com/$s-sitemap.xml" \
    | grep -o '<loc>[^<]*</loc>' | sed 's|</*loc>||g'
done | sort -u > ~/wix-urls.txt
wc -l < ~/wix-urls.txt
grep -c '/post/' ~/wix-urls.txt

Attendu : un total comme 73, puis la part du blogue comme 41. Ces deux nombres, c’est l’ampleur de votre projet. Un sitemap enfant qui répond 404 veut dire que ce type de contenu n’existe pas : retirez-le du plan. Notre guide d’inventaire avant migration couvre ce qu’il faut noter d’autre avant de commencer.

Découvrez ce que le DNS dit vraiment. C’est ce qui détermine si vous déplacez des serveurs de noms ou un seul enregistrement.
```
dig +short NS example.com
dig +short A example.com
dig +short MX example.com
```
Attendu, pour un domaine dont Wix détient les serveurs de noms :
```
ns6.wixdns.net.
ns7.wixdns.net.
185.230.63.171
1 aspmx.l.google.com.
5 alt1.aspmx.l.google.com.
```
Voici comment le lire. Des serveurs de noms Wix veulent dire que Wix détient toute la zone. À la bascule, vous déplacez les serveurs de noms et devez recréer chaque enregistrement à la main du nouveau côté, y compris MX, SPF et DKIM. Des serveurs de noms chez le registraire avec une IP Wix dans l’enregistrement A veulent dire que vous ne changez que cet enregistrement, ce qui est bien moins risqué. Des enregistrements MX Google veulent dire que les boîtes sont sur Google Workspace, et votre prochain appel est à la facturation de Wix pour savoir si l’abonnement est le vôtre ou le leur.
Créez le compte cPanel et installez WordPress sur un nom d’hôte temporaire. Dans WHM, utilisez Account Functions > Create a New Account. Ensuite, pointez un sous-domaine comme new.example.com vers le nouveau serveur avec un enregistrement A, et bâtissez là. Le nom d’hôte temporaire vous laisse travailler sur une vraie adresse HTTPS pendant que Wix continue de servir les visiteurs.

Installez avec WP-CLI plutôt qu’avec un installateur en un clic, parce que le même outil fait la réécriture de base de données dont vous aurez besoin plus tard :
```
cd ~/public_html
wp core download
wp config create --dbname=exmpl_wp --dbuser=exmpl_wp --dbpass='REPLACE_ME'
wp core install --url=https://new.example.com --title='Example Inc' \
  --admin_user=admin --admin_email=you@example.com --skip-email
wp core version
wp option get siteurl
```
Attendu : Success: WordPress installed successfully., puis une version comme 6.8.2, puis https://new.example.com. Si wp option get siteurl affiche autre chose, arrêtez et corrigez-le tout de suite, parce que chaque lien que WordPress génère vient de cette valeur.

Réglez les permaliens pour qu’ils correspondent à la cible de votre carte de redirections :
```
wp rewrite structure '/%postname%/' --hard
```
Attendu : Success: Rewrite structure set. L’option --hard écrit les règles dans .htaccess au lieu de les garder uniquement en base de données.
Migrez le contenu. Commencez par le blogue, car c’est la seule partie qu’une machine peut faire. Vérifiez ce que le fil contient vraiment :
```
curl -s https://example.com/blog-feed.xml | grep -c '<item>'
```
Attendu : 20. Comparez avec le 41 de l’étape 1. L’écart, c’est le nombre de billets que vous recopierez à la main. Passez le fil dans un convertisseur RSS vers WXR tiers, puis importez le fichier obtenu sous Outils > Importer > WordPress. Comptez ensuite ce qui a atterri :
```
wp post list --post_type=post --format=count
```
Attendu : un nombre qui correspond à votre import. Refaites les pages statiques à la main dans l’éditeur de blocs, et exportez les produits de boutique depuis Wix en CSV avant de faire correspondre les colonnes dans l’importateur de WooCommerce.
Réhébergez les médias. Trouvez d’abord combien de références pointent encore vers Wix :
```
wp db query "SELECT COUNT(*) FROM wp_posts WHERE post_content LIKE '%wixstatic.com%';" --skip-column-names
```
Attendu : un compte comme 18. Pour une poignée d’images, rapatriez chacune directement :
```
wp media import 'https://static.wixstatic.com/media/abc123~mv2.jpg' --post_id=14 --title='Storefront'
```
Attendu : Success: Imported file ... as attachment ID 212. Pour un site plus gros, une extension d’importation d’images externes parcourra les billets et fera la même chose en lot. Une fois les fichiers présents localement, confirmez combien de références restent avant de changer le moindre texte :
```
wp search-replace 'static.wixstatic.com' 'example.com' --dry-run --all-tables
```
--dry-run ne change rien : il affiche un tableau du nombre de remplacements que recevrait chaque colonne, terminé par une ligne comme Success: 24 replacements to be made. --all-tables inclut les tables que WP-CLI sauterait autrement, comme celles d’extensions ayant leur propre préfixe. Utilisez WP-CLI pour ça plutôt qu’un REPLACE SQL, parce que WordPress range beaucoup de réglages en données PHP sérialisées, où chaque chaîne porte son propre préfixe de longueur. WP-CLI désérialise, remplace, puis re-sérialise, donc les longueurs restent justes. Un remplacement SQL brut laisse les anciennes longueurs en place et corrompt ces lignes en silence.

Lancez la vraie commande, sans --dry-run, seulement une fois les fichiers présents au chemin correspondant sur votre serveur. Un échange de chaîne ne déplace pas un fichier. Toute référence qui casse encore après coup demande un nouvel import, pas plus de substitution.
Bâtissez et installez la carte 301. Transformez les URL de billets Wix de l’étape 1 en lignes de redirection :
```
grep '/post/' ~/wix-urls.txt \
  | sed -E 's#https://example\.com/post/([^/]+)/?#Redirect 301 /post/\1 https://example.com/\1/#' \
  > ~/redirects.conf
head -2 ~/redirects.conf
```
Attendu :
```
Redirect 301 /post/spring-maintenance-checklist https://example.com/spring-maintenance-checklist/
Redirect 301 /post/choosing-a-contractor https://example.com/choosing-a-contractor/
```
Ajoutez une ligne à la main pour chaque page statique dont vous avez changé le slug, puis collez le bloc dans ~/public_html/.htaccess, au-dessus du marqueur # BEGIN WordPress :
```
# --- Anciens chemins Wix : gardez ce bloc au-dessus du bloc WordPress ---
Redirect 301 /post/spring-maintenance-checklist https://example.com/spring-maintenance-checklist/
Redirect 301 /about-1 https://example.com/about/
RedirectMatch 301 ^/post/(.*)$ https://example.com/$1/
# --- fin des anciens chemins Wix ---

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
```
Deux règles sur ce placement. Le bloc WordPress se termine par une règle fourre-tout qui envoie toute requête non satisfaite vers index.php : les lignes de redirection placées en dessous n’ont donc jamais leur tour, et WordPress répond 404 à la place. Et WordPress réécrit tout ce qui se trouve entre les marqueurs BEGIN et END chaque fois que vous enregistrez les réglages de permaliens, alors ce que vous mettez à l’intérieur disparaît sans avertissement. La ligne RedirectMatch sert de filet pour les billets oubliés ; les lignes précises viennent d’abord, et elle va en dernier.

Vérifiez sur le nom d’hôte temporaire avant de bouger le DNS :
```
curl -sI https://new.example.com/post/spring-maintenance-checklist | head -3
```
Attendu :
```
HTTP/1.1 301 Moved Permanently
Date: Fri, 12 Sep 2026 14:02:11 GMT
Location: https://example.com/spring-maintenance-checklist/
```
Un 200 ici veut dire que le bloc de redirections est sous les règles WordPress, ou dans le mauvais fichier. Une 404 veut dire la même chose, avec un slug qui n’existe pas encore du nouveau côté.
Basculez dans cet ordre : les boîtes courriel, puis le MX, puis l’enregistrement A. La veille, baissez le TTL des enregistrements que vous allez changer à 300 secondes, pour que les erreurs expirent en cinq minutes.

Si le courriel s’en vient sur cPanel, créez chaque boîte d’abord et confirmez que chacune accepte un message :
```
uapi --user=exmpl Email add_pop email=info@example.com password='REPLACE_ME' quota=2048
```
Attendu : un bloc YAML se terminant par status: 1. Connectez-vous au webmail du serveur et envoyez un test vers et depuis une adresse externe avant de changer quoi que ce soit dans le DNS. Si Google Workspace reste où il est, laissez les enregistrements MX exactement comme dig les a rapportés à l’étape 2 et ne changez rien au courriel.

Changez ensuite le MX, attendez le TTL, et seulement là pointez l’enregistrement A vers le nouveau serveur. Terminez en effaçant le nom d’hôte temporaire de la base de données :
```
wp search-replace 'new.example.com' 'example.com' --all-tables
wp option get siteurl
```
Attendu : un nombre de remplacements, puis https://example.com.

Valider que ça fonctionne

Parcourez chaque nouvelle URL et n’affichez que ce qui n’est pas un 200 :

sed 's#/post/##' ~/wix-urls.txt > ~/new-urls.txt
while read -r u; do
  printf '%s  %s\n' "$(curl -s -o /dev/null -w '%{http_code}' "$u")" "$u"
done < ~/new-urls.txt | grep -v '^200'

Attendu : aucune sortie du tout. Chaque ligne qui apparaît est une page que vous devez encore.

Confirmez que plus rien ne référence Wix, en base de données comme dans la page rendue :

wp db query "SELECT COUNT(*) FROM wp_posts WHERE post_content LIKE '%wix%.com%';" --skip-column-names
curl -s https://example.com/ | grep -c 'wixstatic'

Attendu : 0 des deux côtés. Un compte non nul, c’est une image qui cassera le jour où le site Wix fermera.

Vérifiez au moins trois anciennes URL au hasard, en mêlant billets et pages :

for p in /post/spring-maintenance-checklist /post/choosing-a-contractor /about-1; do
  printf '%s  %s  %s\n' \
    "$(curl -s -o /dev/null -w '%{http_code}' "https://example.com$p")" "$p" \
    "$(curl -sI "https://example.com$p" | awk -F': ' '/^[Ll]ocation/{print $2}' | tr -d '\r')"
done

Attendu : trois lignes commençant chacune par 301 et se terminant par la nouvelle adresse. Si le courriel a bougé, confirmez que les enregistrements résolvent, puis prouvez la livraison avec un vrai message :

dig +short MX example.com

Attendu : votre nouveau serveur de courriel, pas l’ancien. Envoyez un message depuis un compte externe vers chaque boîte et confirmez qu’il arrive avant de considérer la bascule terminée. Nos tests de fumée après migration énumèrent le reste de ce qu’il faut vérifier le premier jour.

Dépannage

Les images se chargent encore depuis Wix, et le site a l’air correct. C’est la panne qui attend son heure. La page s’affiche parce que static.wixstatic.com sert encore ces fichiers, et elle continuera jusqu’à l’expiration de l’abonnement Wix. Lancez les deux comptes de la section de validation pendant que l’ancien site est encore en ligne. Tout résultat non nul veut dire que ces images n’ont jamais été téléchargées : réimportez les fichiers et revérifiez, plutôt que de remplacer les adresses par substitution.
Les billets importés ont la date du jour et le mauvais auteur. La voie RSS transporte un ensemble de champs limité, et les convertisseurs diffèrent dans leur façon de rendre les dates de publication et les signatures. Vérifiez-en une poignée avant d’en corriger des centaines : wp post list --post_type=post --fields=ID,post_date,post_author --posts_per_page=10. Corrigez les dates en lot avec wp post update <ID> --post_date='2024-03-11 09:00:00', et réattribuez la signature avec wp post update <ID> --post_author=2. Des dates justes comptent pour les pages d’archives et pour la façon dont les moteurs de recherche lisent l’historique du site.
Les anciennes URL répondent 404 même si les redirections sont dans .htaccess. C’est presque toujours le placement. Ouvrez ~/public_html/.htaccess et confirmez que votre bloc se trouve au-dessus de # BEGIN WordPress : tout ce qui est sous les règles WordPress n’est jamais atteint, et tout ce qui est entre les marqueurs est effacé à l’enregistrement des permaliens. Confirmez avec grep -n 'BEGIN WordPress' ~/public_html/.htaccess et comparez le numéro de ligne avec celui de votre premier Redirect.
Le courriel rebondit juste après la bascule. L’enregistrement MX a bougé avant que les boîtes existent, alors le nouveau serveur a refusé le courriel d’adresses dont il n’avait jamais entendu parler. Ces messages sont perdus. Créez chaque boîte et testez la livraison d’abord, puis changez le MX. Si c’est déjà arrivé, créez les boîtes manquantes tout de suite, puis demandez aux expéditeurs de renvoyer ; rien ne récupère un message que le serveur a déjà refusé.

Quand ce n’est pas la bonne approche

Un site vitrine de cinq pages sans blogue est habituellement plus rapide à refaire de zéro qu’à migrer. Il n’y a aucun import de billets à lancer, les images sont peu nombreuses, et vous recopieriez chaque page à la main de toute façon. Choisissez un thème, refaites les cinq pages, et gardez seulement la carte de redirections de ce guide, dont vous avez encore besoin.

L’autre cas est un site dont la vraie valeur tient à une application native Wix : réservations, adhésions, espace de cours ou communauté payante. Ces fonctions n’ont pas d’équivalent exportable vers WordPress. La migration n’est pas vraiment planifiée tant que vous n’avez pas choisi l’extension qui remplace la fonctionnalité et confirmé qu’elle gère vos membres ou vos rendez-vous existants. Un site qui a l’air correct mais qui ne peut pas prendre une réservation est pire que celui que vous avez quitté.

Si votre source est un hébergeur traditionnel plutôt qu’une plateforme fermée, notre guide de migration depuis un hôte générique est un meilleur point de départ. La documentation de référence des deux outils qui font le gros du travail est la commande search-replace de WP-CLI et le module mod_alias d’Apache, qui définit Redirect et RedirectMatch.

Un WordPress qui rapporte vraiment mérite un opérateur — Stack Harbor opère cette pile sous WordPress Entreprise ; réservez une consultation d’infrastructure.