Changer d’hébergeur, passer d’un site local à la production, migrer depuis un autre CMS vers WordPress ou transférer votre site vers un nouveau serveur : la migration WordPress est une étape que la plupart des propriétaires de sites affrontent un jour.
Le problème : une migration mal exécutée peut entraîner une perte de données, un site en panne pendant des heures et une chute brutale de votre référencement Google. Avec la bonne méthode et les bonnes précautions, tout se passe sans accroc.
Une migration WordPress réussie ne consiste pas seulement à copier un site d’un point A à un point B. C’est un déplacement complet d’un écosystème : les fichiers du site, la base de données, les réglages PHP, les accès my sql, le fichier wp-config.php, les redirections, les emails, les performances et l’hébergement. C’est aussi un bon moment pour faire le tri. Chez Galopins, on voit la migration comme une occasion de rendre un site web plus propre : moins de plugins, moins de médias inutiles, moins de scripts tiers, une base plus légère et un hébergement mieux dimensionné.
Ce point est rarement mis en avant dans les guides de migration WordPress, alors qu’il change beaucoup de choses : migrer un site trop lourd tel quel, c’est déplacer le problème. Avant le transfert, il faut donc se demander ce qui mérite vraiment d’être conservé. Les anciennes images non utilisées, les brouillons, les révisions d’articles, les tables abandonnées par des extensions supprimées et les sauvegardes stockées dans wp-content peuvent représenter plusieurs centaines de Mo. Les supprimer avant migration réduit le temps de transfert, les risques d’erreur et la charge serveur après mise en ligne.
Pourquoi migrer un site WordPress ?
La situation la plus courante est le changement d’hébergeur : site devenu lent, support technique défaillant, ou offre plus performante ailleurs. Autre cas fréquent : la mise en production d’un site développé en local par votre équipe ou votre agence web.
Il y a aussi les migrations de CMS : passer de Wix, Squarespace ou Jimdo vers WordPress pour gagner en flexibilité, en fonctionnalités et en performance SEO. WordPress propulse plus de 40 % des sites web dans le monde pour une raison : c’est le CMS le plus puissant et le plus évolutif du marché.
Enfin, la migration dans le cadre d’une refonte de site, où l’on change structure, design, thème et parfois nom de domaine en même temps. C’est le scénario le plus complexe et celui qui nécessite le plus de préparation.
Les 3 méthodes de migration comparées
Méthode 1 — Par plugin (la plus simple)
C’est la méthode recommandée pour la majorité des sites de petite et moyenne taille. All-in-One WP Migration est le plugin le plus populaire (plus d’un million d’installations actives, note de 4.9/5) : export en un clic, import sur le nouveau serveur, remplacement automatique des URLs. Idéal pour les sites de moins de 500 Mo.
Duplicator est une alternative solide pour les sites plus lourds : il crée un package complet (fichiers + base de données) téléchargeable, avec un installeur qui guide le processus étape par étape.
Limite : les plugins peuvent échouer sur les très gros sites ou avec des configurations serveur restrictives (mémoire PHP insuffisante, timeout). Si le plugin plante, passez à la méthode 3.
Méthode 2 — Par WP-CLI (pour les habitués)
WP-CLI est l’outil en ligne de commande de WordPress. Il permet d’exporter la base, de transférer les fichiers et de faire le search-replace des URLs en quelques commandes. Rapide et fiable, c’est la méthode préférée des agences et des développeurs qui migrent régulièrement.
Prérequis : un accès SSH sur les deux serveurs (ancien et nouveau). Des hébergeurs comme O2switch, Infomaniak ou PlanetHoster incluent SSH dans leurs offres standard.
Conseil : ajoutez –dry-run à la commande search-replace pour simuler les remplacements sans modifier la base. Vous verrez le nombre de remplacements prévus et pourrez vérifier avant d’appliquer.
Le vrai avantage de WP-CLI n’est pas seulement la rapidité. C’est la fiabilité du remplacement d’URLs dans les données sérialisées. WordPress stocke beaucoup de réglages sous forme de tableaux PHP sérialisés, notamment dans wp_options et wp_postmeta. Un simple « rechercher/remplacer » dans un fichier SQL peut casser ces valeurs, car la longueur des chaînes est enregistrée dans la donnée. La commande wp search-replace gère ce cas proprement et permet un test avec –dry-run avant application.
Exemple de logique prudente : exporter la base, lancer un premier search-replace en simulation, exclure les colonnes qui ne doivent pas changer comme guid selon le contexte, puis seulement appliquer le remplacement. Pour un multisite, il faut être encore plus attentif : les tables, les chemins de fichiers, le wp-config.php, le .htaccess, les valeurs home, siteurl et parfois fileupload_url doivent être revus site par site.
Méthode 3 — Manuelle (le filet de sécurité)
Téléchargement des fichiers par FTP (via FileZilla ou Transmit), export de la base de données via phpMyAdmin, upload sur le nouveau serveur, modification du fichier wp-config.php et remplacement des URLs dans la base avec un outil comme Search Replace DB. C’est la méthode la plus longue mais aussi la plus robuste quand les plugins échouent. Elle a le mérite de vous faire comprendre comment WordPress fonctionne sous le capot.
La checklist avant migration
Avant de toucher à quoi que ce soit :
Sauvegardez tout. Fichiers + base de données. Vérifiez que la sauvegarde est exploitable en la restaurant sur un environnement de test. Une sauvegarde non testée n’est pas une sauvegarde.
Notez tous les accès. FTP, base de données, panneau d’administration, compte hébergeur, DNS — pour l’ancien ET le nouveau serveur.
Mettez à jour WordPress, thèmes et plugins sur l’ancien site avant de migrer. Migrer un site avec des versions obsolètes multiplie les risques d’incompatibilité.
Vérifiez la compatibilité du nouveau serveur. Même version de PHP, mêmes extensions PHP activées (mysqli, curl, imagick, etc.), assez de mémoire (256 Mo minimum recommandé) et un max_execution_time de 300 secondes au moins.
Mettez le site en mode maintenance pour éviter les modifications pendant le transfert. Un utilisateur qui passe commande pendant que vous exportez la base = des données perdues.
Anticipez les emails. Si vous utilisez des emails liés au domaine (@votreentreprise.com), le changement de DNS peut les casser temporairement. Prévoyez la configuration des enregistrements MX sur le nouveau serveur avant le basculement.
Ajoutez aussi un audit de sobriété technique. Listez les extensions actives, le poids du dossier uploads, la taille de la base de données, les tables anormalement volumineuses et les scripts tiers chargés sur le front. Ce travail paraît secondaire, mais il évite de migrer des déchets numériques. Dans une logique d’éco-conception, chaque fichier inutile transféré est une dette : il consomme du stockage, ralentit les sauvegardes, complique les restaurations et peut maintenir des failles de sécurité dormantes.
Vérifiez ensuite la compatibilité du nouvel hébergement avec les prérequis actuels de WordPress. WordPress recommande PHP 8.3 ou plus, MariaDB 10.6 ou plus, ou MySQL 8.0 ou plus, avec HTTPS et un serveur Apache ou Nginx configuré correctement. Même si WordPress peut encore fonctionner avec des versions plus anciennes, ces versions sont en fin de vie et exposent davantage le site aux vulnérabilités. C’est un point important à demander à l’hébergeur avant la migration, pas après l’apparition des erreurs 500.
Enfin, baissez le TTL DNS 24 à 48 heures avant la bascule. Cette petite opération réduit la durée pendant laquelle certains visiteurs arrivent encore sur l’ancien serveur pendant que d’autres voient déjà le nouveau. Pour un site vitrine, ce décalage est souvent acceptable. Pour WooCommerce, un espace membre ou un site avec formulaires critiques, il faut prévoir une fenêtre de gel des données : plus aucune commande, inscription ou modification de contenu ne doit être enregistrée sur l’ancien site pendant le transfert final.
Les pièges SEO d’une migration WordPress
C’est le sujet que tout le monde néglige, et c’est pourtant celui qui peut vous coûter le plus cher.
Les URLs qui changent
Si la structure de vos URLs change (par exemple de /?p=123 à /blog/mon-article/), vous devez mettre en place des redirections 301 pour chaque ancienne URL vers la nouvelle. Sans ça, Google affiche des pages 404, votre trafic organique s’effondre et vos backlinks perdent leur valeur. Si vous avez 200 pages, ça fait 200 redirections à configurer. C’est fastidieux mais non négociable.
Le site en noindex
WordPress a une case « Décourager les moteurs de recherche d’indexer ce site » dans Réglages > Lecture. Elle est souvent cochée en développement et oubliée lors du passage en production. Résultat : votre site disparaît complètement des résultats Google. Vérifiez cette case immédiatement après chaque migration. C’est l’erreur n°1 des migrations ratées.
Le sitemap et la Search Console
Après migration, soumettez votre sitemap XML dans Google Search Console. Si vous avez changé de domaine, utilisez l’outil « Changement d’adresse » de la Search Console. Surveillez les erreurs d’exploration dans les jours qui suivent : un pic de 404 est le signe que des redirections manquent.
Les performances du nouveau serveur
Un site qui était rapide sur l’ancien hébergeur peut être lent sur le nouveau si les ressources ne sont pas adaptées. Testez les Core Web Vitals (LCP, CLS, FID) après migration avec Google PageSpeed Insights et comparez avec les valeurs avant migration. Si les performances se dégradent, c’est un signal que le nouveau serveur n’est pas au niveau.
Le piège invisible : le nouveau serveur peut être techniquement plus puissant, mais moins bien réglé pour WordPress. Après migration, contrôlez le cache serveur, la compression Brotli ou Gzip, HTTP/2 ou HTTP/3, la version de PHP, l’OPcache, la limite mémoire PHP, les tâches cron et le cache objet si le site est dynamique. Le RGESN recommande notamment de mettre en cache les données les plus utilisées côté serveur quand c’est pertinent. Pour un site WordPress, cela peut faire la différence entre une page générée à chaque visite et une page servie rapidement avec moins de calcul.
Dans une approche Galopins, la performance n’est pas seulement un sujet SEO. C’est aussi un sujet d’empreinte. Un site plus léger demande moins de ressources serveur, transfère moins de données et fonctionne mieux sur des terminaux anciens ou des connexions moyennes. La migration est donc un bon moment pour supprimer les polices inutiles, convertir les images lourdes en formats modernes, limiter les animations coûteuses et retirer les scripts marketing qui ne sont plus réellement exploités.
Le contenu mixte HTTP/HTTPS
Après migration, assurez-vous que toutes les URLs internes pointent bien en HTTPS. Du contenu mixte (images ou scripts appelés en HTTP sur une page HTTPS) génère des avertissements de sécurité dans le navigateur et peut impacter votre SEO. Un search-replace de http://votresite.com vers https://votresite.com dans la base de données règle le problème.
Après la migration : la checklist de vérification
Parcourez le site page par page : les images s’affichent-elles correctement ? Les formulaires fonctionnent-ils ? Les liens internes pointent-ils vers les bonnes URLs ? Testez les fonctionnalités clés (panier, formulaire de contact, espace membre). Vérifiez que Google Analytics, les pixels de tracking et les balises de conversion sont bien en place. Contrôlez que le HTTPS fonctionne sur toutes les pages. Lancez un crawl avec Screaming Frog ou Sitebulb pour détecter les 404 et les redirections cassées. Et décochez cette case noindex si ce n’est pas déjà fait.
Ajoutez une vérification des données qui ne se voient pas en front : options du thème, champs ACF, menus, widgets, règles de cache, tâches planifiées, webhooks, clés API, emails transactionnels, rôles utilisateurs et permissions. Sur WooCommerce, testez au minimum une commande complète en mode test, un remboursement, un email client, une variation produit, un code promo et une mise à jour de stock.
Surveillez également les logs serveur pendant 48 à 72 heures. Les erreurs PHP, les appels AJAX en échec, les tâches cron bloquées ou les requêtes lentes ne sont pas toujours visibles pendant une navigation manuelle. C’est souvent là que se cachent les problèmes qui dégradent progressivement un site après une migration apparemment réussie.
Consultez notre checklist complète avant, pendant et après migration: Voir la liste
Faire soi-même ou faire appel à un professionnel ?
Pour une migration simple (même hébergeur, pas de changement de domaine, site de petite taille), un plugin comme All-in-One WP Migration et ce guide suffisent. Comptez une à deux heures si tout se passe bien.
Pour une migration complexe — changement de domaine, refonte simultanée, migration depuis un autre CMS, site avec du trafic important et des enjeux SEO forts — faire appel à une agence web spécialisée WordPress est le choix le plus sûr. Le coût est rapidement amorti par le temps gagné et les erreurs évitées, surtout quand votre référencement est en jeu. Une chute de trafic organique de 30 % pendant 3 mois suite à une migration bâclée peut coûter bien plus cher qu’un accompagnement professionnel.
Chez Galopins, nous gérons des migrations WordPress de bout en bout : audit du site existant, choix de la méthode, transfert, vérification SEO, mise en production et suivi post-migration. Nous sommes aussi experts en création et refonte de sites WordPress/Elementor, ce qui nous permet de combiner migr
