Pour migrer un site WordPress sans risque, sauvegardez d’abord l’intégralité des fichiers et de la base de données, puis choisissez entre transfert manuel (FTP/SSH et SQL) si vous avez accès au serveur, ou un plugin dédié si vous n’y avez pas accès. Gardez l’ancien hébergement actif une à deux semaines après la bascule pour pouvoir revenir en arrière en cas de problème.
En bref:
- La migration d’un site WordPress doit impérativement commencer par une sauvegarde complète hors site pour éviter toute perte de données ou corruption.
- Lors d’un transfert volumineux, l’utilisation de WP-CLI ou rsync via SSH est privilégiée pour conserver permissions, liens symboliques et fiabiliser le transfert.
- La mise à jour correcte du fichier wp-config.php et l’utilisation de WP-CLI pour remplacer les URLs évitent de casser les données sérialisées dans la base.
- Il est recommandé de garder l’ancien hébergement actif entre 7 et 14 jours après la migration pour pouvoir revenir en cas de problème.
- La vérification post-migration doit couvrir la disponibilité des pages clés, la compatibilité des paiements en ligne, la conformité SEO et la surveillance des erreurs pendant plusieurs jours.
Table des matières
- Pourquoi migrer et comment choisir entre méthode manuelle et plugin
- Checklist préparatoire avant toute migration
- Sauvegarder les fichiers du site : FTP, SFTP, SSH et rsync
- Exporter la base de données de l’ancien site
- Créer la base de données sur la cible et préparer les accès
- Importer la base de données sur le serveur cible
- Mettre à jour wp-config.php et les fichiers de configuration
- Téléverser les fichiers sur le nouvel hébergement
- Remplacer les anciennes URLs sans casser les données sérialisées
- Plugins de migration : options pratiques et limites
- Méthodes avancées : WP-CLI, multisite, WooCommerce et automatisation
- Vérifications post-migration et checklist de mise en production
- Expérience agence : erreurs fréquentes et bonnes pratiques
- Confiez-nous la migration : offre de migration et maintenance
- Sources
- Questions fréquentes
Pourquoi migrer et comment choisir entre méthode manuelle et plugin
Un changement d’hébergeur, un nom de domaine à mettre à jour ou la création d’un environnement de test sont les trois raisons les plus fréquentes de migrer un site WordPress. Le choix de la méthode dépend surtout de ce que vous avez sous la main : accès SSH, taille du site, présence de WooCommerce ou d’un multisite.
- Si vous disposez d’un accès SSH ou FTP et d’un minimum d’aisance technique, la méthode manuelle offre un contrôle total sur chaque étape.
- Si vous n’avez ni accès serveur ni notions de base de données, un plugin de migration reste la solution la plus rapide à mettre en œuvre.
- Un site avec WooCommerce ou un réseau multisite demande une attention particulière : les webhooks, les clés API et les tables spécifiques ne se migrent pas toujours automatiquement.
- Un gros site (plusieurs gigaoctets de médias) favorise le transfert par SSH ou rsync plutôt que par FTP classique, plus lent et plus sujet aux coupures.
Le risque principal, quelle que soit la méthode, reste l’oubli d’une sauvegarde avant manipulation ou la corruption des données sérialisées lors du remplacement des URLs. La documentation officielle de WordPress détaille les étapes de migration d’un site et insiste sur la sauvegarde préalable des fichiers et de la base avant toute modification.
Checklist préparatoire avant toute migration
Avant de toucher au moindre fichier, quelques vérifications évitent la plupart des mauvaises surprises. Cette phase de préparation prend rarement plus d’une heure, mais elle conditionne la réussite de tout le reste.
- Réalisez une sauvegarde complète (fichiers et base) et conservez-en une copie hors du serveur d’origine, idéalement selon une logique 3-2-1 (trois copies, deux supports, un hors site).
- Abaissez le TTL des enregistrements DNS entre 48 et 72 heures avant la bascule, afin que le changement de serveur se propage plus vite au moment voulu.
- Vérifiez que la version PHP et la version MySQL du serveur cible sont compatibles avec votre thème et vos extensions actuels.
- Contrôlez les quotas disque disponibles et les limites PHP (upload_max_filesize, max_execution_time) sur le nouvel hébergement.
- Centralisez dans un seul endroit sécurisé les identifiants FTP, SSH, phpMyAdmin ainsi que les clés API externes (paiement, emailing, cartes).
- Passez le site en mode maintenance pour éviter que des commandes ou des articles soient créés pendant le transfert.
Conseil de pro : notez la version exacte de PHP et de MySQL de l’ancien serveur avant de migrer : un écart de version mal anticipé est la cause la plus fréquente d’erreurs après import.
Un audit rapide du site (thèmes actifs, extensions installées, taille de la base) permet aussi de repérer les éléments obsolètes à ne pas emporter avec vous. Migrer un site alourdi par des extensions abandonnées ou des tables orphelines ne fait que reporter le problème sur le nouvel hébergement.
Sauvegarder les fichiers du site : FTP, SFTP, SSH et rsync
Trois éléments doivent impérativement être récupérés avant toute migration : le dossier wp-content (thèmes, extensions, médias), le fichier wp-config.php et le fichier .htaccess. Oublier l’un de ces trois éléments oblige généralement à tout reprendre depuis le début.
- Pour un site de petite taille ou si vous découvrez la manipulation, un client FTP ou SFTP classique fait très bien l’affaire.
- Pour un site volumineux ou si vous voulez une opération plus fiable, une connexion SSH avec rsync conserve les permissions de fichiers et les liens symboliques, ce que le FTP gère mal.
- Excluez les dossiers de cache (wp-content/cache, wp-content/uploads/cache) de l’archive : ils sont régénérés automatiquement et alourdissent inutilement le transfert.
La documentation officielle de WordPress recommande d’ailleurs rsync via SSH comme méthode la plus fiable pour transférer de gros volumes de fichiers en conservant permissions et liens symboliques.
Conseil de pro : une fois l’archive téléchargée, comparez sa taille et, si possible, une somme de contrôle (checksum) avec celle du dossier d’origine avant de la considérer comme fiable.
Exporter la base de données de l’ancien site
L’export de la base de données est l’étape la plus sensible de toute la procédure : une erreur d’encodage ou une table oubliée peut casser des pages entières une fois le site relancé sur le nouveau serveur.
- Dans phpMyAdmin, choisissez l’export personnalisé plutôt que l’export rapide, sélectionnez l’intégralité des tables, structure et données, et forcez l’encodage utf8mb4 pour éviter les problèmes d’accents et d’émojis.
- Pour les bases volumineuses, préférez WP-CLI avec la commande wp db export, qui contourne les limites de temps et de mémoire imposées par le navigateur.
- Sur un site en production, chiffrez ou protégez l’archive SQL exportée : elle contient les mots de passe hachés des utilisateurs et parfois des données de facturation.
- Fractionnez le fichier SQL si une table dépasse plusieurs centaines de mégaoctets, cela facilite grandement le diagnostic en cas d’erreur d’import.
WP-CLI propose des commandes robustes pour exporter et importer la base tout en préservant la structure des données, comme le détaille la documentation officielle des commandes WP-CLI.
Créer la base de données sur la cible et préparer les accès
Avant d’importer quoi que ce soit, la nouvelle base doit exister et disposer d’un utilisateur dédié avec les bons droits. Cette étape se fait en quelques minutes mais conditionne la réussite de l’import qui suit.
- Créez la base et l’utilisateur associé via cPanel, Plesk, ou en ligne de commande MySQL selon l’interface proposée par votre hébergeur.
- Accordez à cet utilisateur uniquement les droits nécessaires au fonctionnement de WordPress (SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX), sans privilèges administrateur superflus.
- Testez la connexion à la nouvelle base avant l’import, par exemple via un client MySQL ou une ligne de commande simple, pour éviter de découvrir un problème d’accès après coup.
- Choisissez un mot de passe complexe et différent de celui de l’ancien serveur : c’est le moment idéal pour renouveler les identifiants sensibles.
Importer la base de données sur le serveur cible
Une fois la base créée, l’import du fichier SQL peut se heurter à des limites d’upload ou de temps d’exécution, surtout sur les gros sites.
- Pour un fichier volumineux, privilégiez l’import via la ligne de commande mysql plutôt que l’interface phpMyAdmin, souvent bridée par des limites d’upload.
- Avec WP-CLI installé sur le serveur cible, la commande wp db import backup.sql reste l’option la plus fiable, car elle contourne les restrictions PHP liées aux formulaires web.
- En cas d’erreur d’import, consultez d’abord les journaux d’erreur MySQL : un dépassement de délai ou une table verrouillée y apparaît généralement clairement.
- Si l’erreur persiste, découpez le fichier SQL en plusieurs parties et importez-les une à une pour isoler la table problématique.
Mettre à jour wp-config.php et les fichiers de configuration
Le fichier wp-config.php est le pont entre WordPress et la base de données : sans mise à jour correcte, le site affiche une erreur de connexion dès la première visite.
- Modifiez les constantes DB_NAME, DB_USER, DB_PASSWORD et DB_HOST pour qu’elles correspondent exactement aux informations de la nouvelle base.
- Régénérez les clés de sécurité (AUTH_KEY, SECURE_AUTH_KEY et les autres constantes de sécurité) si vous soupçonnez une exposition des anciennes clés.
- Vérifiez que le fichier .htaccess (ou la configuration Nginx équivalente) a bien été transféré et qu’il correspond à la structure de permaliens du site.
- Contrôlez que le certificat SSL est actif sur le nouveau serveur avant de forcer une redirection HTTPS, sous peine de rendre le site inaccessible.
La documentation officielle de WordPress rappelle que la mise à jour de wp-config.php et la vérification des permaliens font partie des étapes indispensables d’une migration réussie.
Téléverser les fichiers sur le nouvel hébergement
Le transfert des fichiers vers le nouveau serveur suit la même logique que la sauvegarde initiale, mais dans l’autre sens, avec une exigence supplémentaire : vérifier que rien n’a été perdu ou corrompu en chemin.
- Préférez toujours SFTP ou SSH à un FTP classique non chiffré, en particulier lorsque les identifiants transitent sur un réseau public.
- Avec un accès SSH, la commande rsync accompagnée des options archive, compress et partial accélère le transfert et permet de le reprendre en cas de coupure réseau.
- Une fois le transfert terminé, vérifiez que tous les dossiers critiques sont présents : thèmes, extensions, et surtout l’intégralité de wp-content/uploads.
- Si certaines vignettes d’images manquent après la migration, une extension de régénération des tailles d’images résout généralement le problème sans tout retélécharger.
Conseil de pro : comparez le nombre de fichiers entre l’ancien et le nouveau serveur avant de couper l’accès à l’hébergement d’origine, un écart de quelques fichiers trahit souvent un transfert interrompu.
Remplacer les anciennes URLs sans casser les données sérialisées
Changer de domaine ou de sous-domaine implique de remplacer toutes les occurrences de l’ancienne URL dans la base de données, mais WordPress stocke une partie de ses réglages sous forme de données sérialisées : un simple remplacement de texte dans phpMyAdmin peut corrompre ces champs et rendre des pages entières illisibles.
- WP-CLI reste l’outil le plus sûr pour cette opération grâce à sa commande search-replace, qui comprend nativement la structure sérialisée des données.
- Utilisez l’option recurse-objects pour parcourir correctement les tableaux et objets sérialisés imbriqués.
- Ajoutez skip-columns=guid pour ne pas modifier la colonne GUID des articles, ce que WordPress déconseille explicitement après publication.
- Après le remplacement, vérifiez manuellement les champs personnalisés (ACF), les widgets et les réglages des constructeurs de page, qui stockent souvent leurs données sous forme sérialisée.
La commande search-replace de WP-CLI préserve l’intégrité des données sérialisées lors d’un changement d’URL, ce que confirme la documentation officielle de la commande, contrairement à un remplacement SQL brut qui les corrompt souvent silencieusement.
Plugins de migration : options pratiques et limites
Pour qui ne dispose pas d’un accès SSH ou souhaite simplement gagner du temps, les plugins de migration automatisent l’essentiel du processus décrit plus haut. Leur principe reste globalement le même : exporter le site (fichiers et base) dans une archive unique, puis l’importer sur le serveur cible.
- All-in-One WP Migration facilite l’export et l’import complet d’un site via un fichier au format .wpress et propose une prise en charge WP-CLI ainsi qu’un stockage cloud, ce qui en fait une option adaptée aux sites peu techniques, comme le décrit sa page officielle sur WordPress.org.
- Duplicator crée un paquet regroupant fichiers et base de données, installable sur une nouvelle destination sans avoir besoin d’installer WordPress au préalable, selon la documentation du plugin.
- Migrate Guru propose des migrations en un clic et peut prendre en charge des sites de grande taille en déportant le travail de traitement vers ses propres serveurs plutôt que de solliciter l’hébergeur d’origine.
- Certains de ces plugins imposent des limites de taille sur la version gratuite ou nécessitent une extension payante pour les gros sites ou les configurations multisites, comme le précise la page de Duplicator.
La procédure type reste simple : installez le plugin sur l’ancien site, générez l’archive d’export, installez une copie minimale de WordPress sur le nouveau serveur (ou le même plugin), puis lancez l’import. Réalisez malgré tout une sauvegarde manuelle en parallèle avant de lancer l’import : un plugin qui échoue en cours de route peut laisser le site dans un état intermédiaire difficile à diagnostiquer.
Méthodes avancées : WP-CLI, multisite, WooCommerce et automatisation
Pour les sites plus complexes ou les migrations récurrentes, l’ensemble des étapes précédentes peut être scripté via WP-CLI, ce qui réduit le risque d’erreur humaine et accélère considérablement le processus.
- Une suite typique combine wp db export, le transfert du fichier via SFTP ou rsync, puis wp db import et wp search-replace sur le serveur cible.
- Pour une installation multisite, une migration automatisée échoue souvent sur les tables wp_blogs et wp_site : il faut vérifier manuellement les champs siteurl et home dans les tables wp_options de chaque sous-site, comme le signale la documentation officielle sur les migrations.
- Sur une boutique WooCommerce, contrôlez systématiquement les webhooks de paiement et les clés API après la migration, et passez une commande de test pour valider que les notifications fonctionnent réellement.
- WP-CLI se prête bien à l’intégration dans des pipelines d’automatisation pour les sites mis à jour fréquemment, permettant de reproduire la même procédure de migration à chaque déploiement, comme le décrit la référence des commandes WP-CLI.
Ces méthodes demandent un minimum d’aisance avec la ligne de commande, mais elles évitent les approximations d’une migration manuelle refaite à chaque fois différemment.
Vérifications post-migration et checklist de mise en production
La migration ne se termine pas au moment où le site s’affiche correctement sur le nouveau serveur : une série de vérifications reste nécessaire avant de considérer l’opération comme terminée.
- Testez les pages critiques (accueil, contact, panier, tunnel de commande) ainsi que tous les formulaires du site.
- Vérifiez les connexions clients et, sur une boutique en ligne, passez une transaction de test pour confirmer que les paiements aboutissent réellement.
- Contrôlez les redirections 301 depuis les anciennes URLs, le fichier sitemap.xml, le fichier robots.txt et les balises canoniques.
- Réenregistrez le nouveau sitemap dans Google Search Console et surveillez l’indexation dans les jours suivants.
- Surveillez les journaux d’erreurs et les métriques de performance pendant 48 à 72 heures tout en gardant l’ancien hébergement accessible pour un retour arrière rapide.
Conseil de pro : *gardez l’ancien hébergement actif entre 7 et 14 jours après la bascule : ce délai réduit le risque opérationnel et facilite un rollback si un problème apparaît après coup. C’est une pratique confirmée par la page officielle du plugin All-in-One WP Migration pour les migrations critiques.
Un guide interne détaille par ailleurs les précautions à prendre pour ne pas perdre son référencement lors d’une refonte de site WordPress, utile en complément de cette checklist.
Expérience agence : erreurs fréquentes et bonnes pratiques
Sur le terrain, les migrations qui échouent partagent souvent les mêmes causes : une sauvegarde incomplète, un cache non vidé après la bascule, ou des webhooks de paiement oubliés sur une boutique WooCommerce. Le cache est probablement le piège le plus sournois : le site semble cassé alors qu’il fonctionne, simplement parce que le navigateur ou un plugin de cache affiche encore l’ancienne version.
La fréquence de sauvegarde recommandée dépend directement de l’activité du site : un site vitrine peu mis à jour s’en tient à quelques sauvegardes par an, tandis qu’une boutique en ligne active gagne à en programmer plusieurs par mois, voire une par semaine. WordPress recommande d’ailleurs des sauvegardes régulières comme pratique de sécurité de base, quelle que soit la fréquence retenue.
Un autre écueil fréquent : lancer une migration sans environnement de test intermédiaire. Un site cloné sur un sous-domaine ou un serveur de préproduction permet de repérer les problèmes avant qu’ils n’affectent les visiteurs réels, ce qui coûte quelques minutes de préparation pour économiser des heures de correction dans l’urgence.
— Aurélie
Confiez-nous la migration : offre de migration et maintenance
Suivre cette procédure demande du temps et une tolérance zéro à l’erreur, surtout sur un site qui génère du chiffre d’affaires. Un accompagnement complet incluant la migration technique, la maintenance et le debug WordPress, avec des tests systématiques avant et après bascule et un plan de retour arrière prêt en cas d’imprévu est une option proposée par certaines agences.
Nous prenons en charge l’ensemble du transfert (fichiers, base de données, URLs, vérifications SEO) en gardant votre ancien hébergement actif jusqu’à validation complète du nouveau site. Ce service s’inscrit dans une offre plus large de maintenance de sites WordPress, pensée pour sécuriser la suite une fois la migration terminée, sauvegardes automatiques et surveillance comprises.
Si votre site nécessite en plus une refonte technique ou une reconstruction sur mesure, notre équipe de développement WordPress sur mesure peut intervenir en parallèle de la migration. Pour discuter de votre projet et obtenir un devis adapté à la taille de votre site, consultez notre offre de création de site internet.
Sources
Cette procédure s’appuie sur la documentation officielle de WordPress consacrée aux migrations, sur la référence des commandes WP-CLI, ainsi que sur les pages officielles des plugins All-in-One WP Migration et Duplicator sur WordPress.org. Un guide interne complémentaire aborde les stratégies de sauvegarde avant migration.
Questions fréquentes
Comment transférer mon site web vers un autre hébergeur ?
Sauvegardez d’abord l’intégralité des fichiers et de la base de données, créez la nouvelle base sur le serveur cible, puis transférez les fichiers via SFTP ou SSH avant d’importer la base et de mettre à jour wp-config.php. Terminez par le remplacement des anciennes URLs et une série de vérifications avant de basculer les DNS.
Comment puis-je récupérer mon site WordPress ?
Vous pouvez restaurer un site à partir d’une sauvegarde complète des fichiers et de la base de données, réimportée sur un serveur fonctionnel. En l’absence de sauvegarde récente, un hébergeur conserve parfois des copies automatiques récupérables sur demande, mais ce n’est jamais garanti.
Comment puis-je cloner un site web WordPress ?
Un plugin comme Duplicator permet de créer un paquet regroupant fichiers et base de données, installable ensuite sur une nouvelle destination, comme le décrit sa documentation officielle. La méthode manuelle équivalente consiste à exporter la base via WP-CLI et à copier les fichiers par rsync vers le nouvel emplacement.
Qu’est-ce que la migration de site internet ?
La migration de site internet désigne le transfert complet d’un site, fichiers et base de données inclus, d’un serveur ou d’un hébergeur vers un autre, souvent accompagné d’un changement de domaine ou d’une mise à jour des URLs. Elle implique aussi des vérifications techniques et SEO après la bascule pour s’assurer que rien n’a été perdu au passage.
