Vous migrez votre site WordPress vers un serveur dédié et devez importer sa base de données ? L’opération consiste à préparer une base sur le serveur de destination, créer un utilisateur dédié, puis importer une sauvegarde SQL dans cette base.

Le point à garder en tête : la base de données ne contient pas les fichiers de votre site. Les thèmes, extensions, médias et fichiers de configuration doivent être transférés séparément. Et si la boutique continue à recevoir des commandes pendant la migration, un export trop ancien risque de ne pas contenir les dernières données.

Dans ce tutoriel, nous allons préparer la base, importer un fichier SQL via SSH et vérifier que WordPress utilise bien les données attendues. Pour l’ensemble du transfert — fichiers, synchronisation et bascule — consultez aussi mon guide pour migrer WordPress avec WP-CLI et rsync.

Avant de commencer

Ce guide suppose que vous disposez :

d’un accès SSH au serveur de destination ;
d’un serveur MySQL ou MariaDB en fonctionnement et d’un compte autorisé à créer une base et un utilisateur ;
d’un export SQL de votre base WordPress et des fichiers du site ;
d’un moyen de tester le site de destination avant la mise en ligne ;
de sauvegardes vérifiées et d’un plan de retour arrière.

Les commandes utilisent des noms d’exemple : wordpress_site pour la base et wordpress_user pour son utilisateur. Remplacez-les par vos propres valeurs. Les exemples supposent que WordPress et la base de données se trouvent sur le même serveur ; sinon, le nom d’hôte, le compte autorisé et la connexion réseau doivent être adaptés.

Travaillez d’abord sur une base de destination vide et dédiée. Un fichier SQL peut contenir des instructions qui créent, modifient ou remplacent des tables : ne l’importez jamais dans une base existante sans avoir vérifié son contenu et sauvegardé la cible.

1. Sauvegarder la base et les fichiers du site source

Si WP-CLI est disponible sur le serveur source, placez-vous dans le répertoire WordPress et exportez la base :

cd /chemin/vers/wordpress
wp db export /chemin/prive/sauvegarde-wordpress.sqlLangage du code : JavaScript (javascript)

WP-CLI utilise les informations de connexion définies dans wp-config.php. Vérifiez que la commande se termine correctement et que le fichier a bien été créé. Protégez cet export : il peut contenir des informations personnelles et des données sensibles.

Sauvegardez aussi les fichiers WordPress, notamment wp-content/uploads, les extensions, le thème et les éléments de configuration nécessaires. Un export SQL seul ne permet pas de restaurer les médias. La documentation WordPress sur les sauvegardes distingue ces deux parties.

Pour un site actif, prévoyez une synchronisation finale ou une période de maintenance avant la bascule. C’est particulièrement important pour WooCommerce : commandes, comptes et paiements peuvent changer après le premier export. Évitez aussi que la copie de test envoie des emails réels ou effectue des opérations sur les services de paiement.

2. Créer une base de données sur le serveur cible

Connectez-vous au serveur cible en SSH, puis ouvrez le client MySQL ou MariaDB avec un compte administrateur adapté à votre installation. Par exemple, sur une installation utilisant l’authentification locale de l’administrateur :

sudo mysql

La méthode de connexion peut différer selon le serveur. Une fois dans la console SQL, créez la base :

CREATE DATABASE wordpress_site CHARACTER SET utf8mb4;

MySQL recommande utf8mb4 pour les nouvelles bases lorsque c’est possible. Pour un import existant, vérifiez aussi que les collations utilisées par le fichier SQL sont prises en charge par le serveur cible. Créer une base en utf8mb4 ne convertit pas automatiquement les tables définies dans l’export : leurs instructions SQL peuvent préciser leur propre jeu de caractères et leur propre collation. Ne modifiez pas ces valeurs à l’aveugle. Documentation MySQL sur les jeux de caractères.

3. Créer un utilisateur dédié et limiter ses droits à cette base

Toujours dans la console SQL :

CREATE USER 'wordpress_user'@'localhost' IDENTIFIED BY 'REMPLACER_PAR_UN_MOT_DE_PASSE_FORT';
GRANT ALL PRIVILEGES ON wordpress_site.* TO 'wordpress_user'@'localhost';
SHOW GRANTS FOR 'wordpress_user'@'localhost';Langage du code : JavaScript (javascript)

Remplacez le mot de passe d’exemple par un secret unique. Le même utilisateur figure dans CREATE USER et GRANT, et les droits portent sur wordpress_site.*, pas sur toutes les bases du serveur. localhost suppose une connexion locale ; adaptez le compte au mode de connexion réel si la base est distante.

Cet exemple accorde les privilèges sur cette base dédiée pour faciliter l’import et les opérations WordPress. Selon les extensions et votre politique de sécurité, vous pouvez affiner les droits après avoir identifié ceux qui sont nécessaires, puis tester les mises à jour et les fonctionnalités. La commande SHOW GRANTS permet de contrôler les droits effectivement attribués.

Les mots de passe saisis dans le client SQL peuvent apparaître dans des historiques ou des journaux selon la configuration. Protégez ces accès et consultez la documentation MySQL sur CREATE USER avant de manipuler des secrets.

Quittez ensuite la console :

EXIT;Langage du code : PHP (php)

Sur un hébergement où la base et l’utilisateur sont créés depuis un panneau d’administration, utilisez les valeurs fournies par l’hébergeur et passez à l’étape suivante.

4. Transférer l’export SQL et configurer WordPress

Transférez votre fichier SQL vers le serveur cible par un canal chiffré, par exemple SFTP ou SCP, et placez-le dans un répertoire privé hors du répertoire servi par le site web. Limitez ses permissions et prévoyez sa suppression sécurisée selon vos procédures après vérification.

Dans le wp-config.php du site de destination, renseignez les paramètres de la base cible :

define( 'DB_NAME', 'wordpress_site' );
define( 'DB_USER', 'wordpress_user' );
define( 'DB_PASSWORD', 'VOTRE_MOT_DE_PASSE' );
define( 'DB_HOST', 'localhost' );Langage du code : JavaScript (javascript)

Conservez le préfixe de tables correspondant à celui de la base importée :

$table_prefix = 'wp_';Langage du code : PHP (php)

wp_ est un exemple, pas une valeur à imposer. Si les tables de votre sauvegarde utilisent un autre préfixe, configurez celui-ci. Vérifiez également que DB_HOST correspond aux indications du serveur : le nom d’hôte et, parfois, le port ou le socket peuvent être différents.

Ne changez pas les réglages d’encodage d’un site existant sans comprendre les conséquences sur ses données. La documentation de wp-config.php détaille les paramètres concernés.

5. Importer le fichier SQL

Avec WP-CLI

Si les fichiers WordPress et le wp-config.php cible sont en place :

cd /chemin/vers/wordpress
wp db import /chemin/prive/sauvegarde-wordpress.sqlLangage du code : JavaScript (javascript)

La commande utilise les identifiants de wp-config.php. Elle ne crée pas la base de données et exécute les instructions contenues dans le fichier : la base cible doit donc être prête et le fichier vérifié. Documentation officielle de wp db import.

Avec le client MySQL

Si WP-CLI n’est pas disponible, vous pouvez utiliser le client en indiquant la base cible :

mysql -u wordpress_user -p -h localhost wordpress_site < /chemin/prive/sauvegarde-wordpress.sqlLangage du code : JavaScript (javascript)

Le mot de passe est demandé par le client. Le fichier doit être un export SQL compatible ; il ne s’agit pas d’un fichier XML d’export de contenus WordPress. Si votre sauvegarde est compressée, vérifiez son format et décompressez-la dans un emplacement privé avant l’import, ou utilisez une méthode de lecture adaptée.

En cas d’erreur, arrêtez-vous pour identifier la première erreur affichée. Une importation interrompue peut laisser une base partiellement remplie : ne relancez pas aveuglément sur une cible dont l’état n’est plus connu.

6. Vérifier l’import et le site

Après l’import, quelques contrôles permettent de détecter les problèmes avant la bascule :

Vérifiez que la commande s’est terminée sans erreur et que les tables attendues existent, avec le bon préfixe : wp db tables depuis le répertoire WordPress cible.
Contrôlez l’affichage des articles, pages, images et caractères accentués.
Connectez-vous à l’administration et testez les permaliens, la recherche et les fonctionnalités du thème.
Pour WooCommerce, vérifiez les produits, le panier, la commande et les emails dans un environnement adapté, sans déclencher de vrais paiements ni de notifications clients involontaires.
Testez les formulaires et leurs destinataires ; vérifiez les tâches programmées et intégrations externes.
Après validation, protégez ou retirez les fichiers SQL temporaires et vérifiez que le site de test ne reste pas accessible publiquement par erreur.

Une commande qui se termine correctement ne suffit pas à prouver que toutes les fonctionnalités ou les dernières données sont présentes : les tests doivent correspondre à votre site et à la méthode de migration choisie.

Faut-il remplacer l’ancien nom de domaine ?

Si le domaine et les chemins restent identiques, ne lancez pas de remplacement d’URL par automatisme.

Si le domaine ou le chemin change, certaines valeurs enregistrées dans la base doivent être adaptées. WordPress et ses extensions peuvent stocker des données sérialisées : une substitution SQL brute ou une modification globale du fichier d’export peut les endommager.

WP-CLI propose wp search-replace, qui prend en charge les données PHP sérialisées. Commencez par une sauvegarde et une simulation :

wp search-replace 'https://ancien.example' 'https://nouveau.example' --skip-columns=guid --dry-runLangage du code : JavaScript (javascript)

Lisez le rapport, vérifiez le périmètre des tables et le contexte multisite éventuel. La commande sans --dry-run modifie la base : ne l’exécutez qu’après validation. Des URL peuvent aussi être stockées dans des fichiers ou systèmes externes. Certaines constantes dans wp-config.php, comme WP_HOME et WP_SITEURL, peuvent remplacer les valeurs de la base ; elles doivent être vérifiées séparément. Documentation WP-CLI sur search-replace.

Erreurs fréquentes

« Error establishing a database connection »

Vérifiez le nom de la base, l’utilisateur, le mot de passe et DB_HOST. Confirmez que le serveur SQL est accessible et que les privilèges correspondent au compte et à l’hôte réellement utilisés. Ne publiez pas les identifiants dans un ticket de support ou un journal partagé.

WordPress propose une nouvelle installation

Vérifiez que la base importée est bien celle renseignée dans wp-config.php, que les tables attendues existent et que $table_prefix correspond à leur préfixe. Ne poursuivez pas l’installation tant que la cause n’est pas identifiée.

Collation inconnue ou caractères illisibles

Comparez les versions du serveur source et de destination, les collations demandées dans l’export et celles disponibles sur la cible. Une conversion d’encodage ou de collation nécessite une analyse et des tests sur copie : changer une valeur au hasard peut dégrader les données.

Images manquantes

L’import SQL ne transfère pas les fichiers de la médiathèque. Vérifiez la copie de wp-content/uploads, les permissions, les URL et, si nécessaire, le stockage externe utilisé par le site.

Se faire accompagner pour la migration

Si vous préférez déléguer la préparation, les tests et la bascule, je peux prendre en charge votre migration WordPress. Un audit WordPress permet aussi d’identifier les problèmes avant le transfert. Pour une boutique, découvrez mon accompagnement comme développeur WooCommerce ; l’hébergement WordPress géré peut également faire partie du projet selon votre besoin.

Créer et importer une base de données WordPress en SSH