Comment migrer un site Web avec WP-CLI

Si vous gérez un grand site WordPress et que vous devez le déplacer vers un nouvel hébergeur, WP-CLI vous offre une voie plus rapide et plus scriptable.

Il ne vous donnera pas de timeouts PHP sur de grandes bases de données. De plus, vous aurez un processus que vous pourrez répéter ou automatiser sur plusieurs sites.

Dans ce tutoriel, je vais vous montrer comment migrer un site WordPress à l'aide de WP-CLI. À la fin, votre site fonctionnera sur le nouveau serveur, et vous aurez confirmé qu'il fonctionne avant qu'un seul visiteur n'atteigne le nouvel hébergeur.

Voici les points clés à retenir :

• La migration WP-CLI est plus rapide que la migration basée sur des plugins pour les grands sites, mais elle nécessite un accès SSH sur les deux serveurs et WP-CLI installé sur chacun.
• L'indicateur --precise sur wp search-replace est la commande la plus importante de ce tutoriel. Sans elle, les données sérialisées se corrompent silencieusement, et les paramètres du thème, les widgets et les options des plugins se réinitialisent sans aucun message d'erreur.
• La copie de wp-config.php de l'ancien serveur vers le nouveau apporte les mauvaises informations d'identification de la base de données. Vous devez mettre à jour DB_NAME, DB_USER, DB_PASSWORD et DB_HOST sur le nouveau serveur avant l'importation.
• Ne basculez jamais le DNS avant d'avoir vérifié que la migration a fonctionné. L'étape 7 couvre une liste de contrôle pré-DNS utilisant wp option get, wp core verify-checksums et un aperçu du fichier hosts.
• wp duplicator build crée une sauvegarde complète du site depuis le terminal avant de commencer. Si quelque chose casse à mi-chemin de la migration, l'URL de récupération d'urgence de Duplicator restaure le site d'origine sans SSH sur l'ancien serveur.
• Si vous migrez vers un nouveau domaine, incluez --skip-columns=guid dans votre commande search-replace. Le remplacement des GUID casse les abonnements RSS.

Table des matières

Quand utiliser WP-CLI pour migrer un site WordPress

WP-CLI n'est pas l'outil adapté à toutes les migrations. Voici quand il est judicieux d'opter pour la ligne de commande (et quand une autre approche convient mieux).

Utilisez WP-CLI quand :

• Votre site est suffisamment grand pour que les outils basés sur le navigateur atteignent des timeouts PHP ou des limites de mémoire en cours de transfert
• Votre hébergeur ne vous donne pas assez d'espace disque temporaire pour créer une sauvegarde complète via le navigateur
• Vous migrez plusieurs sites et souhaitez un processus répétable et scriptable. wp duplicator build dans un script bash gère les sauvegardes par lots sans aucun travail manuel
• Vous souhaitez un contrôle total sur chaque étape : ce qui est transféré, ce qui est remplacé et ce qui est vérifié avant les changements de DNS

Envisagez un plugin de migration plutôt lorsque :

• Vous n’avez pas d’accès SSH sur le serveur source ou destination
• Vous n’êtes pas à l’aise avec la ligne de commande
• Vous souhaitez un processus guidé et visuel avec des indicateurs de progression et un système de retour arrière intégrés

Celui que vous utilisez dépend de votre configuration et de vos préférences.

Ce dont vous avez besoin avant de commencer

Mettez tout cela en place avant d’exécuter une seule commande. Oublier quelque chose en cours de migration (en particulier les identifiants de base de données ou les chemins de fichiers) est la cause d’une base de données partiellement importée et d’un site inaccessible sur les deux serveurs.

• Accès SSH aux deux serveurs. Vous devrez exécuter des commandes sur l’ancien serveur et sur le nouveau serveur à différents moments de ce processus.
• WP-CLI installé sur les deux serveurs. S’il n’est pas encore installé, suivez le guide d’installation officiel. Vous en aurez besoin sur le nouveau serveur pour les étapes de vérification de l’étape 7, pas seulement sur l’ancien serveur.
• Duplicator Pro installé et actif sur l’ancien serveur. Ce plugin de sauvegarde/migration dispose des commandes wp duplicator build, wp duplicator info et wp duplicator cleanup.
• Une nouvelle base de données déjà créée sur le nouveau serveur avec un utilisateur qui a tous les privilèges. wp db import ne crée pas la base de données pour vous — si elle n’existe pas, l’importation échoue.
• Les identifiants de base de données de votre nouveau serveur prêts : DB_NAME, DB_USER, DB_PASSWORD et DB_HOST. Vous en aurez besoin à l’étape 4.
• Les chemins de fichiers absolus pour les deux installations WordPress. Exécutez pwd dans chaque répertoire racine WordPress et copiez la sortie quelque part de pratique.
• Si vous changez de domaine : votre ancienne URL et votre nouvelle URL prêtes à copier/coller exactement comme elles apparaissent dans la base de données, y compris le protocole (https:// vs http://).

Comment migrer un site WordPress avec WP-CLI

Voici ce que vous allez faire. Chaque étape s’appuie directement sur la précédente, alors travaillez dans l’ordre.

• Étape 1 : Exécutez une vérification préalable et créez une sauvegarde complète avec wp duplicator info et wp duplicator build
• Étape 2 : Exportez la base de données de l’ancien serveur en utilisant wp db export
• Étape 3 : Transférez les fichiers WordPress et la base de données vers le nouveau serveur en utilisant rsync et scp
• Étape 4 : Mettez à jour wp-config.php sur le nouveau serveur avec vos nouveaux identifiants de base de données
• Étape 5 : Réinitialisez et importez la base de données sur le nouveau serveur en utilisant wp db reset et wp db import
• Étape 6 : Exécutez une recherche-remplacement pour mettre à jour les URL en utilisant wp search-replace (changements de domaine uniquement)
• Étape 7 : Videz le cache et vérifiez la migration avant de toucher au DNS
• Étape 8 : Mettez à jour le DNS et lancez
• Étape 9 : Nettoyez l’ancien serveur avec wp duplicator cleanup

Étape 1 : Sauvegarder le site d'origine

Avant d’exporter quoi que ce soit, vous avez besoin d’un point de restauration propre sur le serveur d’origine. Si quelque chose tourne mal en cours de migration, vous voulez pouvoir revenir à un site fonctionnel sans vous précipiter.

J'utilise Duplicator pour la protection des sauvegardes WordPress. C'est un plugin de sauvegarde et de migration utilisé par plus de 1,5 million de professionnels WordPress et il intègre des commandes WP-CLI.

Cela signifie que vous pouvez créer une sauvegarde complète du site sans quitter le terminal. Pour un flux de travail en ligne de commande, cela compte.

Commencez par vérifier que la configuration de sauvegarde de Duplicator fonctionne correctement. Connectez-vous en SSH à l'ancien serveur, naviguez jusqu'à la racine de votre WordPress et exécutez :

wp duplicator info

Une fois que cela revient propre, créez votre sauvegarde :

wp duplicator build

Cela crée une sauvegarde complète de votre site depuis le terminal.

Si vous souhaitez enregistrer la sauvegarde dans un emplacement spécifique plutôt que par défaut, utilisez :

wp duplicator build --dir=/path/to/backup/location

Exécutez wp duplicator build --help pour voir tous les indicateurs disponibles, y compris --template=<ID> pour les modèles de sauvegarde prédéfinis et les options de moteur d'archivage comme --phpsqldump, --phpzip et --duparchive.

Si cette migration casse quelque chose, l'URL de récupération d'urgence de Duplicator peut restaurer votre site même si WordPress est complètement bloqué sur l'ancien serveur. C'est votre filet de sécurité avant de toucher à quoi que ce soit d'autre.

Étape 2 : Exporter la base de données de l'ancien serveur

Toujours sur l'ancien serveur, naviguez jusqu'à la racine de votre WordPress et exportez la base de données :

wp db export site-backup.sql

Quand c'est fait, vous verrez : Success: Exported to 'site-backup.sql'.

Le fichier est enregistré dans votre répertoire actuel. Notez où il se trouve, car vous le transférerez à l'étape suivante.

Une chose à faire avant de passer à autre chose. Si votre fichier .sql se retrouve dans un répertoire accessible par le web comme /public_html ou /htdocs, déplacez-le ou supprimez-le immédiatement après le transfert.

Un fichier .sql exposé est une copie complète de votre base de données, y compris les noms d'utilisateur, les mots de passe hachés et chaque élément de contenu du site. Ce n'est pas un risque théorique.

Si vous migrez un réseau WordPress Multisite, ajoutez --all-tables pour capturer les données de l'ensemble du réseau :

wp db export site-backup.sql --all-tables

Étape 3 : Transférer les fichiers WordPress et la base de données vers le nouveau serveur

Deux choses doivent être déplacées vers le nouveau serveur : les fichiers WordPress et l'export .sql que vous venez de créer.

Pour les fichiers, utilisez rsync. Il gère bien les grands transferts, affiche la progression et reprend là où il s'est arrêté si la connexion est interrompue :

rsync -avz --progress /path/to/old-wordpress/ user@newserver:/path/to/new-wordpress/

Avec la barre oblique, rsync copie le contenu du répertoire. Sans elle, rsync copie le répertoire lui-même, ce qui place vos fichiers un niveau plus bas que prévu sur le nouveau serveur.

Exécutez d'abord un essai à blanc pour vérifier ce qui sera transféré avant de vous engager :

rsync -avz --progress --dry-run /path/to/old-wordpress/ user@newserver:/path/to/new-wordpress/

Pour le fichier de base de données, utilisez scp :

scp site-backup.sql user@newserver:/path/to/new-wordpress/

Si vous préférez compresser tout dans une seule archive d'abord, cela fonctionne aussi :

tar -czf site_files.tar.gz .
scp site_backup.sql site_files.tar.gz user@newserver:/path/to/new-wordpress/

Extrayez ensuite sur le nouveau serveur :

tar -xzf site_files.tar.gz

Cette approche fonctionne bien pour les petits sites ou les hôtes qui gèrent les transferts de fichiers uniques de manière plus fiable que les connexions rsync.

Étape 4 : Mettre à jour wp-config.php sur le nouveau serveur

C'est l'étape que la plupart des tutoriels de migration WP-CLI sautent, et c'est la raison la plus fréquente pour laquelle une migration échoue immédiatement après l'importation.

Lorsque vous avez transféré vos fichiers WordPress à l'étape précédente, wp-config.php est venu avec eux. C'est le bon fichier, mais il contient toujours les identifiants de base de données de votre ancien serveur. Si vous lancez l'importation maintenant, WP-CLI essaiera de se connecter à une base de données qui n'existe pas sur le nouveau serveur.

Connectz-vous en SSH au nouveau serveur, naviguez jusqu'à la racine de votre WordPress, et ouvrez wp-config.php :

nano /path/to/new-wordpress/wp-config.php

Mettez à jour ces quatre valeurs avec les détails de la base de données de votre nouveau serveur :

• DB_NAME : le nom de la base de données que vous avez créée sur le nouveau serveur
• DB_USER : le nom d'utilisateur de la base de données
• DB_PASSWORD : le mot de passe de la base de données
• DB_HOST : généralement localhost, mais confirmez avec votre hébergeur. Certains hébergeurs gérés utilisent une valeur différente ici.

Enregistrez et quittez. Sur nano, c'est Ctrl+O pour enregistrer et Ctrl+X pour quitter.

N'oubliez pas cette étape. Si les identifiants sont incorrects, wp db import se connectera à la mauvaise base de données ou échouera avec « Erreur lors de l'établissement de la connexion à la base de données », et il ne sera pas toujours évident que wp-config.php en est la cause.

Étape 5 : Réinitialiser et importer la base de données sur le nouveau serveur

Connectez-vous en SSH au nouveau serveur et naviguez jusqu'à la racine de votre WordPress. Si vous avez une nouvelle installation de WordPress sur le nouveau serveur, supprimez ses tables par défaut avant d'importer. Sauter cette étape peut causer des conflits entre les tables existantes et celles de votre export.

wp db reset --yes

Vous verrez : Succès : Base de données réinitialisée.

L'indicateur --yes ignore l'invite de confirmation. Sans lui, WP-CLI vous demandera de confirmer avant de supprimer toutes les tables.

Importez maintenant la base de données :

wp db import site-backup.sql

Dès que l'importation est confirmée, supprimez le fichier SQL :

rm site-backup.sql

Ensuite, reconnectez-vous en SSH à l'ancien serveur et supprimez-le également là-bas.

Ce n'est pas une simple tâche de ménage. Un fichier .sql situé dans un répertoire accessible via le web est une copie complète de votre base de données. Supprimez-le des deux serveurs avant de faire quoi que ce soit d'autre.

Étape 6 : Exécuter Search-Replace pour mettre à jour les URL

Si vous conservez le même domaine et changez uniquement d'hébergeur, sautez cette étape et passez directement à l'étape 7. Vos URL sont déjà correctes dans la base de données.

Si vous changez de domaine, c'est là que la plupart des migrations échouent silencieusement. Pas avec une erreur — mais avec des paramètres de thème qui semblent incorrects, des widgets qui ont disparu et des options de plugin qui sont revenues aux valeurs par défaut. La cause est presque toujours la même : une recherche-remplacement qui n'a pas correctement géré les données sérialisées.

Avant d'exécuter quoi que ce soit, faites un essai à blanc :

wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables --precise --dry-run

Cela exécute l'opération complète et vous montre un tableau du nombre de remplacements qui seraient effectués par table de base de données, sans enregistrer de modifications. Examinez-le.

Recherchez les tables où vous vous attendez à des remplacements (wp_options, wp_posts, wp_postmeta) et assurez-vous que les décomptes semblent raisonnables. Les zéros inattendus sur ces tables méritent d'être étudiés avant de vous engager.

Lorsque vous êtes satisfait, exécutez-le sans –dry-run :

wp search-replace 'https://ancien-domaine.com' 'https://nouveau-domaine.com' --all-tables --precise

Pourquoi --precise est important : WordPress stocke certaines données sous forme de PHP sérialisé. Les paramètres du personnalisateur de thème, les configurations de widgets, les options de plugin — ceux-ci ne sont pas stockés sous forme de texte brut. Ils sont stockés sous forme de chaînes PHP structurées qui incluent des décomptes de caractères.

Une recherche-remplacement standard basée sur SQL remplace la chaîne d'URL mais ne recalcule pas ces décomptes de caractères. PHP lit le décompte, trouve une discordance et ignore silencieusement les données.

Votre thème se réinitialise. Vos widgets disparaissent. Rien ne génère d'erreur — le site semble simplement incorrect.

L'indicateur --precise force WP-CLI à utiliser PHP au lieu de SQL. Il désérialise chaque valeur, effectue le remplacement, recalcule le nombre de caractères et ré-sérialise le résultat correctement. C'est plus lent sur les bases de données volumineuses. Utilisez-le quand même.

Une chose que wp search-replace ignore correctement par défaut : la colonne guid dans wp_posts. N'essayez pas de forcer le remplacement des GUID.

La documentation WordPress stipule explicitement que les GUID doivent rester constants. Ils identifient les articles pour les lecteurs de flux, et les modifier casse les abonnements RSS.

Si vous migrez un réseau Multisite, ajoutez l'indicateur –network :

wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables --precise --network

La documentation officielle de WordPress décrit un ordre différent : mettez à jour vos URL dans Paramètres » Général sur l'ancien serveur avant de migrer, puis exportez la base de données déjà mise à jour et sautez complètement l'étape de recherche et remplacement sur le nouveau serveur. Ça fonctionne. L'approche de ce tutoriel (migrer d'abord, rechercher et remplacer ensuite) est plus facile à vérifier car vous pouvez effectuer un essai à blanc avant de valider toute modification d'URL.

Étape 7 : Vider le cache et vérifier avant de toucher au DNS

Une fois la recherche et le remplacement terminés, il est tentant de passer directement au DNS. Ne le faites pas.

Changer le DNS avant d'avoir confirmé que le site fonctionne signifie que tous les problèmes que vous rencontrerez seront des problèmes en direct, visibles par les visiteurs réels. Prenez dix minutes ici et vérifiez tout sur le nouveau serveur d'abord.

Commencez par vider le cache d'objets :

wp cache flush

Videz ensuite les règles de réécriture :

wp rewrite flush

Vérifiez maintenant que les URL dans la base de données sont correctes. Exécutez ces deux commandes :

wp option get siteurl
wp option get home

Les deux devraient retourner votre domaine correct. Si l'une d'elles retourne l'ancien domaine, vous pouvez les mettre à jour manuellement :

wp option update siteurl 'https://newdomain.com'

wp option update home 'https://newdomain.com'

Ensuite, vérifiez que vos fichiers WordPress principaux ont été transférés sans corruption :

wp core verify-checksums

S'il retourne des erreurs, notez quels fichiers sont signalés. Une poignée de fichiers modifiés dans wp-content est attendue et ne pose pas de problème — ce sont vos fichiers de thème et de plugin, qui ne font pas partie de la comparaison des sommes de contrôle. Les erreurs sur les fichiers principaux dans wp-admin ou wp-includes méritent d'être étudiées.

Prévisualisez le site avant de mettre à jour le DNS. Ajoutez une ligne temporaire au fichier hosts de votre machine locale pointant votre domaine vers l'adresse IP du nouveau serveur. Sur Mac ou Linux, ouvrez /etc/hosts dans un éditeur de texte et ajoutez :

123.456.789.0 yourdomain.com

Remplacez 123.456.789.0 par l'IP de votre nouveau serveur. Enregistrez le fichier, puis ouvrez votre domaine dans un navigateur. Vous regardez maintenant le nouveau serveur pendant que tout le monde continue d'accéder à l'ancien.

Vérifiez chacun de ces points avant de continuer :

• La page d'accueil se charge correctement
• La connexion administrateur fonctionne à /wp-admin
• Les images s'affichent sur les articles et les pages
• Les menus de navigation sont intacts
• Les widgets apparaissent correctement dans la barre latérale ou le pied de page
• L'apparence du thème correspond à l'original

Lorsque tout est vérifié, supprimez la ligne que vous avez ajoutée à votre fichier hosts. Ensuite, vous êtes prêt pour une mise à jour du DNS.

Étape 8 : Mettre à jour le DNS et passer en ligne

Pointez l'enregistrement A de votre domaine vers l'adresse IP de votre nouveau serveur. L'endroit où vous faites cela dépend de l'endroit où les serveurs de noms de votre domaine sont pointés : soit votre bureau d'enregistrement de domaine, soit le gestionnaire DNS de votre fournisseur d'hébergement.

Connectez-vous, trouvez l'enregistrement A pour votre domaine et mettez à jour l'IP.

La propagation DNS prend de quelques minutes à 48 heures, selon votre registraire et le paramètre TTL (durée de vie) de votre domaine. Pendant cette période, certains visiteurs accéderont à l'ancien serveur et d'autres au nouveau. C'est normal. Ce n'est pas le signe que quelque chose s'est mal passé.

Laissez l'ancien serveur en ligne pendant au moins 24 à 48 heures après la mise à jour du DNS. L'arrêter pendant la propagation signifie que certains visiteurs n'accéderont à rien.

Une fois que vous êtes sûr que la propagation est terminée, effectuez une dernière purge du cache sur le nouveau serveur :

wp cache flush

Étape 9 : Nettoyer avec wp duplicator cleanup

Une fois le nouveau serveur confirmé comme étant en ligne et stable, retournez à l'ancien serveur et exécutez :

wp duplicator cleanup

Cela supprime les fichiers de sauvegarde et toutes les données temporaires que Duplicator a créées pendant le processus de construction à l'étape 1. Cela permet de garder l'ancien serveur propre et d'éliminer tous les artefacts de migration avant de le désaffecter.

N'exécutez ceci qu'après être certain que la migration est terminée. Une fois les fichiers de sauvegarde supprimés, l'option de reprise après sinistre de l'étape 1 disparaît avec eux.

Si vous souhaitez conserver la sauvegarde comme archive à long terme, déplacez-la vers un stockage distant avant d'exécuter le nettoyage.

Dépannage des erreurs courantes de migration WP-CLI

Même une migration soignée peut rencontrer des obstacles. Voici les points de défaillance les plus courants, à quoi ils ressemblent et comment les résoudre.

« Erreur de connexion à la base de données » après l'importation

Ce que vous voyez : WordPress affiche un écran blanc ou le message « Erreur de connexion à la base de données » sur le nouveau serveur immédiatement après l'importation.

Pourquoi cela se produit : wp-config.php contient toujours les identifiants de la base de données de l'ancien serveur. C'est l'erreur la plus courante dans une migration WP-CLI et elle est facile à manquer si vous avez transféré les fichiers avant de mettre à jour la configuration.

Comment le résoudre : Ouvrez wp-config.php sur le nouveau serveur et mettez à jour DB_NAME, DB_USER, DB_PASSWORD et DB_HOST pour correspondre à la base de données de votre nouveau serveur. Enregistrez le fichier et rechargez le site.

Paramètres du thème, widgets ou options de plugin réinitialisés après la migration

Ce que vous voyez : Le site se charge, mais le thème semble incorrect, les widgets sont manquants ou les paramètres des plugins sont revenus aux valeurs par défaut. Aucun message d'erreur nulle part.

Pourquoi cela se produit : Vous avez exécuté wp search-replace sans l'indicateur --precise. Le remplacement de l'URL a corrompu les données sérialisées dans la base de données, et WordPress a silencieusement ignoré les valeurs incorrectes.

Comment le résoudre : Réexécutez search-replace avec --precise et --all-tables :

wp search-replace 'https://ancien-domaine.com' 'https://nouveau-domaine.com' --all-tables --precise

Si les données sont déjà gravement corrompues et que la réexécution de search-replace ne restaure pas les paramètres, restaurez la sauvegarde Duplicator que vous avez créée à l'étape 1 et repassez par la migration.

« wp : commande introuvable » sur le nouveau serveur

Ce que vous voyez : Toute commande WP-CLI sur le nouveau serveur renvoie wp: command not found ou command not found: wp.

Pourquoi cela se produit : WP-CLI n'est pas installé sur le nouveau serveur, ou il est installé mais pas dans votre PATH.

Comment le corriger : Installez WP-CLI sur le nouveau serveur. Si vous n’avez pas la permission de rendre le fichier exécutable sur votre hébergement, vous pouvez exécuter les commandes en utilisant php wp-cli.phar au lieu de wp.

rsync se termine avec « Permission refusée »

Ce que vous voyez : rsync s’exécute mais se termine prématurément avec une ou plusieurs erreurs « Permission refusée » sur des fichiers ou répertoires spécifiques.

Pourquoi cela se produit : Soit votre clé SSH n’est pas correctement configurée pour le serveur de destination, soit il y a une inadéquation de propriété de fichier entre les deux serveurs.

Comment le corriger : Vérifiez d’abord l’accès à la clé SSH avec ssh user@newserver. Si cela échoue, réglez l’authentification de la clé avant de réessayer rsync. Si la connexion fonctionne mais que des fichiers spécifiques sont refusés, vous devrez peut-être utiliser chown sur les fichiers transférés sur le nouveau serveur pour qu’ils correspondent à l’utilisateur web utilisé par votre hébergement — généralement www-data sur Ubuntu ou le nom d’utilisateur du compte sur les hébergements cPanel.

Le site se charge mais les images sont cassées

Ce que vous voyez : Les pages se chargent correctement, mais les images affichent des icônes d’image cassée sur tout le site.

Pourquoi cela se produit : Soit le dossier wp-content/uploads n’a pas été complètement transféré, soit les URL d’images codées en dur dans le contenu des articles n’ont pas été capturées par search-replace.

Comment le corriger : Réexécutez rsync en ciblant uniquement le dossier uploads pour capturer les fichiers qui n’ont pas été transférés :

rsync -avz --progress /path/to/old-wordpress/wp-content/uploads/ user@newserver:/path/to/new-wordpress/wp-content/uploads/

Ensuite, réexécutez search-replace avec --dry-run pour vérifier si des URL d’images font encore référence à l’ancien domaine.

Rien ne fonctionne : Restaurez et recommencez

Si le site est complètement cassé et que vous ne parvenez pas à identifier une cause claire, ne passez pas des heures à déboguer un état de migration à moitié effectué. Restaurez la sauvegarde Duplicator Pro que vous avez créée à l’étape 1.

L’URL de récupération d’urgence de Duplicator peut ramener l’ancien site même si WordPress est verrouillé.

Une fois que vous êtes revenu à un état de fonctionnement propre, reprenez les étapes lentement. Utilisez –dry-run sur rsync et wp search-replace avant de valider quoi que ce soit, et vérifiez les informations d’identification de wp-config.php avant d’exécuter l’importation.

Questions fréquemment posées (FAQ)

Votre site est sur le nouveau serveur. Voici ce qu'il faut surveiller ensuite.

Vous avez exporté la base de données, transféré les fichiers, mis à jour wp-config.php, importé, effectué une recherche-remplacement, vérifié tout sur le nouveau serveur et basculé le DNS. C'est la migration complète.

Les premières 48 heures méritent une attention particulière. La propagation DNS signifie que certains visiteurs accéderont toujours à l'ancien serveur pendant cette période, alors ne le désactivez pas encore.

Surveillez les couches de mise en cache qui pourraient servir du contenu obsolète. Une purge complète du cache sur le nouveau serveur une fois la propagation confirmée prend dix secondes et élimine de nombreux problèmes d'affichage.

Si quelque chose semble encore incorrect après la fin de la propagation, utilisez wp search-replace --dry-run comme outil de diagnostic avant de toucher à quoi que ce soit :

wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables --precise --dry-run

Cela vous montre quelles tables contiennent encore l'ancien domaine sans apporter de modifications. C'est le moyen le plus rapide de confirmer si une URL persistante est une erreur de recherche-remplacement ou quelque chose codé en dur dans un fichier de thème.

Les URL codées en dur dans les fichiers de thème personnalisés ne seront pas du tout détectées par la recherche-remplacement. Vous devrez les trouver et les mettre à jour manuellement dans le code du thème.

Migrez en toute confiance avec Duplicator Pro

Une migration sans sauvegarde est un pari. Les serveurs se comportent de manière inattendue, les importations sont interrompues et les données sérialisées ne survivent pas toujours à une recherche-remplacement proprement.

Avoir un point de restauration avant de commencer signifie que chacune de ces situations est un inconvénient mineur au lieu d'un problème sérieux.

Duplicator Pro fait de la sauvegarde une seule commande depuis le terminal : wp duplicator build. Et si quelque chose tourne mal, l'URL de récupération d'urgence ramène votre site d'origine même si WordPress est complètement bloqué.

Plus de 1,5 million de professionnels WordPress utilisent Duplicator Pro pour sauvegarder, migrer et cloner leurs sites. Rejoignez-les !

Si ce tutoriel vous a aidé, ces guides méritent également d'être mis en favoris.

• Comment déplacer un site WordPress vers un nouvel hébergeur
• Pourquoi vous ne pouvez pas vous connecter à WordPress après une migration
• Migration DNS effectuée correctement : Comment éviter les erreurs les plus courantes
• La liste de contrôle complète des tests WordPress après migration
• Comment auditer le contenu avant une migration de site web
• Comment migrer un site WordPress GRATUITEMENT