Migrer un site WordPress : hébergeur, domaine, WP-CLI

Mis à jour le 1er novembre 2026. Article réécrit : deux scénarios (changement d’hébergeur, changement de domaine), options de wp search-replace vérifiées dans la documentation WP-CLI, démonstration de la casse des données sérialisées, test du nouveau serveur avant la bascule DNS, redirections testées sous Nginx et Apache, consignes de Google datées et procédure de retour arrière.

Migrer un site WordPress, c’est déplacer trois choses : les fichiers, la base de données et l’adresse à laquelle les visiteurs le trouvent. Les incidents viennent rarement de la copie elle-même. Ils viennent d’une sauvegarde jamais restaurée, d’adresses remplacées à la main dans la base, d’une bascule DNS faite sans test ou d’un ancien domaine supprimé trop tôt.

Ce guide distingue deux cas. Si vous changez seulement d’hébergeur et gardez la même adresse, la documentation de WordPress est claire : il suffit de copier les fichiers et la base, puis d’adapter wp-config.php. Si l’adresse change (nouveau domaine, passage à www, passage à HTTPS), il faut en plus remplacer les adresses dans la base et rediriger les anciennes URL. Les commandes supposent un accès SSH et WP-CLI sur les deux serveurs.

Avant de commencer : l’inventaire

À relever	Commande ou endroit	Pourquoi
Version de WordPress et de PHP	`wp core version`, `php -v`	Le serveur cible doit proposer une version de PHP compatible avec le thème et les extensions
Adresses du site	`wp option get home`, `wp option get siteurl`	Ce sont les chaînes à remplacer en cas de changement d’adresse
Jeu de caractères	`wp config get DB_CHARSET`	La base cible doit utiliser le même
Taille de la base et des médias	`wp db size --human-readable`, `du -sh wp-content/uploads`	Durée du transfert et espace disque nécessaire
Tâches planifiées, e-mails, formulaires	`wp cron event list`, réglages SMTP	Ce qui casse souvent sans bruit après une migration
URL à conserver	sitemap, Search Console, journaux du serveur	Base des contrôles et des redirections

Pour le choix du serveur cible, voir notre comparatif des hébergements WordPress. Commencez par un site à jour : la routine de maintenance WordPress automatisée donne la marche à suivre.

Étape 1 : sauvegarder et vérifier

cd /var/www/site
wp db export ~/migration.sql --single-transaction
tar -czf ~/fichiers.tar.gz --exclude='./wp-content/cache' .
tar -tzf ~/fichiers.tar.gz > /dev/null && echo "archive lisible"

wp db export appelle mysqldump avec les identifiants de wp-config.php et lui transmet les options supplémentaires : --single-transaction produit un export cohérent des tables InnoDB sans les verrouiller. Avec GNU tar 1.35, nous avons vérifié que ce motif d’exclusion retire bien le cache tout en gardant wp-config.php et wp-content/uploads. Conservez une copie de ces deux fichiers hors des deux serveurs. Une sauvegarde n’a de valeur qu’une fois restaurée, et la première restauration a lieu à l’étape suivante.

Étape 2 : restaurer sur le nouveau serveur

rsync -avP ~/migration.sql ~/fichiers.tar.gz utilisateur@nouveau-serveur:/home/utilisateur/
# Sur le nouveau serveur :
mkdir -p /var/www/site && tar -xzf ~/fichiers.tar.gz -C /var/www/site
cd /var/www/site
wp config set DB_NAME nouvelle_base
wp config set DB_USER nouvel_utilisateur
wp config set DB_PASSWORD 'mot-de-passe-unique' --quiet
wp db import ~/migration.sql
wp db check

Créez d’abord la base et son utilisateur, avec des droits limités à cette base, dans le panneau de l’hébergeur ou avec MySQL. wp-config.php contient des identifiants : réglez ses permissions pour que seuls son propriétaire et l’utilisateur de PHP puissent le lire.

Étape 3 : remplacer les adresses, en respectant les données sérialisées

Cette étape ne concerne que le changement d’adresse. WordPress, ses extensions et ses thèmes stockent de nombreux réglages sous forme sérialisée par PHP, où chaque chaîne est précédée de sa longueur. Un remplacement SQL classique change la chaîne sans changer la longueur :

Avant :  a:1:{s:4:"logo";s:34:"https://ancien-domaine.fr/logo.png";}
Après un remplacement SQL :
         a:1:{s:4:"logo";s:34:"https://www.nouveau-domaine.fr/logo.png";}
Valeur correcte :
         a:1:{s:4:"logo";s:39:"https://www.nouveau-domaine.fr/logo.png";}

Nous avons reproduit ce cas avec PHP 8.3 : la deuxième ligne annonce 34 caractères pour une chaîne qui en compte 39, et unserialize() renvoie false. Le réglage est alors perdu en silence. La documentation de WordPress met en garde contre ce problème ; wp search-replace désérialise les valeurs, les modifie et les réécrit avec la bonne longueur.

wp search-replace 'https://ancien-domaine.fr' 'https://www.nouveau-domaine.fr' \
  --all-tables-with-prefix --skip-columns=guid --dry-run --report-changed-only

wp search-replace 'https://ancien-domaine.fr' 'https://www.nouveau-domaine.fr' \
  --all-tables-with-prefix --skip-columns=guid

wp db search 'ancien-domaine.fr' --all-tables-with-prefix
wp rewrite flush
wp cache flush

Option	Effet
`--dry-run`	Exécute tout et affiche le rapport, sans rien enregistrer
`--skip-columns=guid`	Laisse intacte la colonne `guid`, qui identifie les articles dans les flux RSS
`--all-tables-with-prefix`	Inclut les tables portant le préfixe de WordPress mais non déclarées, souvent créées par des extensions
`--precise`	Traite toutes les colonnes en PHP : plus lent, plus fiable pour des données sérialisées complexes
`--export=fichier.sql`	Écrit le résultat dans un fichier SQL au lieu de modifier la base
`--report-changed-only`	N’affiche que les tables et colonnes modifiées

Sur la colonne guid, la documentation de WordPress est catégorique : « Never, ever, change the contents of the GUID column ». Un article reste le même article quand le domaine change, et un lecteur de flux le réafficherait comme nouveau.

Répétez le remplacement pour chaque variante encore présente (http://, avec ou sans www). La commande wp db search liste ce qui reste : certains constructeurs de pages enregistrent les adresses avec des barres obliques échappées (https:\/\/ancien-domaine.fr), qui demandent un remplacement spécifique. Sur un multisite, ajoutez --network et relisez la documentation avant d’agir.

Étape 4 : tester avant de toucher aux DNS

Le nouveau serveur peut être testé sous sa vraie adresse sans modifier les DNS. curl --resolve force la résolution vers la nouvelle IP pour une seule commande :

curl -sI --resolve www.nouveau-domaine.fr:443:203.0.113.10 https://www.nouveau-domaine.fr/
curl -s --resolve www.nouveau-domaine.fr:443:203.0.113.10 https://www.nouveau-domaine.fr/contact/ | grep -c "<form"

Pour naviguer, ajoutez la même correspondance dans le fichier hosts de votre poste. Le certificat HTTPS doit être en place avant la bascule ; notre guide de redirection HTTP vers HTTPS détaille les configurations. Testez les pages de l’inventaire, un envoi de formulaire, la connexion à l’administration, et sur WooCommerce une commande de test.

Quelques jours avant, réduisez la durée de vie (TTL) des enregistrements DNS concernés auprès de votre registrar, pour que le changement se propage vite et qu’un retour soit rapide. Vérifiez la valeur actuelle :

dig +noall +answer www.nouveau-domaine.fr

Étape 5 : basculer

Passez l’ancien site en maintenance pour figer le contenu (wp maintenance-mode activate). Sur une boutique, choisissez une heure creuse.
Refaites l’export de la base et synchronisez les médias ajoutés depuis la première copie (rsync -av wp-content/uploads/ utilisateur@nouveau-serveur:/var/www/site/wp-content/uploads/).
Importez la base sur le nouveau serveur et relancez le remplacement d’adresses si le domaine change.
Modifiez les enregistrements DNS, puis suivez les deux journaux d’accès : le trafic doit glisser de l’ancien serveur vers le nouveau.

Étape 6 : rediriger les anciennes adresses

En cas de changement de domaine, l’ancien domaine doit rester enregistré et configuré pour rediriger chaque URL vers son équivalent. Avec Nginx :

server {
    listen 443 ssl;
    server_name ancien-domaine.fr www.ancien-domaine.fr;
    ssl_certificate     /etc/ssl/ancien-domaine.fr/fullchain.pem;
    ssl_certificate_key /etc/ssl/ancien-domaine.fr/privkey.pem;
    return 301 https://www.nouveau-domaine.fr$request_uri;
}

Avec Apache, dans le .htaccess de l’ancien domaine :

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?ancien-domaine\.fr$ [NC]
RewriteRule ^(.*)$ https://www.nouveau-domaine.fr/$1 [R=301,L]

Si des adresses changent aussi de chemin, ajoutez des règles page à page (Redirect 301 /ancienne-page/ https://www.nouveau-domaine.fr/nouvelle-page/) avant la règle générale. Évitez les chaînes de redirections et le renvoi de toutes les pages vers l’accueil.

La page de Google sur les migrations (mise à jour le 20 août 2026) recommande des redirections permanentes côté serveur (301 ou 308) conservées aussi longtemps que possible, en général au moins un an. L’outil de changement d’adresse de la Search Console ne sert que pour un passage d’un domaine ou sous-domaine à un autre, pas pour un passage à HTTPS ou à www. Soumettez le nouveau sitemap ; pour un site de taille moyenne, Google indique qu’il faut quelques semaines ou plus avant que les nouvelles URL remplacent les anciennes. Les journaux du serveur montrent les 404 et les redirections encore demandées : voir notre guide pour lire les attaques et erreurs dans les logs.

Retour arrière

Fixez avant la bascule ce qui déclencherait un retour : pages principales inaccessibles, paiement en échec, base incohérente. Tant que l’ancien serveur et sa base sont intacts, le retour consiste à remettre les DNS sur l’ancienne IP, d’où l’intérêt d’un TTL court. Les commandes, commentaires ou comptes créés sur le nouveau serveur entre-temps ne reviennent pas seuls : notez l’heure de bascule pour les retrouver. Ne résiliez l’ancien hébergement qu’après plusieurs jours sans incident. Le plan de reprise après sinistre explique comment tester une restauration.

Où l’IA aide, et où elle n’a pas sa place

Un assistant d’IA peut rapprocher deux listes d’URL et proposer une table de redirections, relire un script de migration ou résumer des journaux d’erreurs anonymisés. Chaque proposition se vérifie à la main, en priorité pour les pages qui reçoivent du trafic. Ne lui transmettez jamais wp-config.php, un export de base ou des mots de passe : un export contient les comptes et souvent des données de clients. Pour un site que vous comptez ensuite alimenter avec l’IA, voir comment créer un blog WordPress avec l’IA.

Questions fréquentes

Faut-il changer les adresses dans la base si je garde le même domaine ?

Non. Si le domaine et le protocole restent identiques, copiez les fichiers et la base, adaptez wp-config.php et basculez les DNS. Le remplacement n’est nécessaire que si l’adresse change.

Puis-je utiliser une extension de migration à la place de WP-CLI ?

Oui, sans accès SSH c’est souvent la seule solution. Les limites de taille et de durée d’exécution dépendent de l’hébergement : testez la restauration sur le serveur cible avant la bascule.

Combien de temps garder l’ancien domaine et ses redirections ?

Google recommande de garder les redirections au moins un an, et plus longtemps si possible. Conservez donc le nom de domaine enregistré au moins aussi longtemps.

L’IA peut-elle faire la migration à ma place ?

Non. Elle peut rédiger des brouillons de commandes ou une table de redirections, mais chaque commande doit être relue et testée sur le serveur cible, avec une sauvegarde restaurable.

Sources

WordPress Developer Resources, Moving WordPress
WP-CLI, wp search-replace, wp db export, wp db search
Google Search Central, Déplacer un site en modifiant les URL, mis à jour le 20 août 2026
nginx, Module ngx_http_rewrite_module (return)
Apache HTTP Server, mod_rewrite et mod_alias (Redirect)
curl, option —resolve

L'équipe Genisoft Agence web PrestaShop & WordPress

Agence web spécialisée PrestaShop et WordPress : création, maintenance, sécurité, performance et référencement. Nos tutoriels sont issus de nos interventions sur de vraies boutiques.

L'agence Genisoft → LinkedIn →