Comment migrer son WordPress en local vers un hébergeur ?

On entend souvent que migrer WordPress du local vers un hébergeur, c’est "juste un copier-coller de fichiers". En partie vrai… et en partie une catastrophe annoncée si vous ne savez pas ce que vous faites. Les URLs codées en dur dans la base de données, le fichier wp-config.php qui pointe encore vers localhost, les droits fichiers qui bloquent tout : j’ai vu ces erreurs des dizaines de fois en 14 ans de formation WordPress.

La bonne nouvelle ? En 2026, vous avez plus d’options que jamais. Des plugins qui font tout en trois clics, des outils officiels comme WordPress Studio qui exportent en ZIP natif, et même WP-CLI pour les adeptes du terminal. Bref. Que vous partiez de LocalWP, de WordPress Playground ou d’un bon vieux MAMP, ce guide couvre les cinq méthodes qui marchent vraiment.

Je les ai toutes testées sur des sites clients et sur wpformation.com. La première fois que j’ai migré un WordPress en 2012, j’ai passé un après-midi entier en FTP + phpMyAdmin, avec trois cafés et deux frayeurs. Aujourd’hui, avec Duplicator ou AIOWPM, c’est plié en 15 minutes montre en main. Et après ? Voyons laquelle correspond à votre situation.

Pourquoi migrer du local vers un hébergeur ?

Travailler en local, c’est le luxe du développeur : pas de latence réseau, pas de risque de casser un site en production, et la liberté de tester sans conséquences. Mais un site local ne sert à rien s’il reste sur votre ordinateur. À un moment, il faut le mettre en ligne.

La migration locale vers un hébergeur intervient dans trois cas typiques :

Premier cas, le plus fréquent : vous avez créé votre site WordPress en local, configuré votre thème, installé vos plugins, ajouté vos contenus, et il est prêt pour la mise en ligne. C’est le scénario classique du freelance ou du porteur de projet qui veut tout peaufiner avant le lancement.

Deuxième cas : vous développez un thème enfant ou un plugin, et vous avez besoin de le déployer sur un serveur de production ou de staging pour le tester en conditions réelles (serveur mutualisé, HTTPS, trafic concurrent).

Troisième cas : vous refaites un site existant. Vous travaillez sur la nouvelle version en local pendant que l’ancienne reste en ligne. Une fois la refonte terminée, vous remplacez l’ancien par le nouveau d’un seul coup. C’est la méthode la plus sûre pour une refonte de site WordPress.

La différence entre local, staging et production, ça vous parle ? Le local tourne sur votre machine (pas d’accès externe). Le staging est un clone en ligne accessible par URL temporaire (pour les tests client). La production, c’est le site public, celui que Google indexe. Ce guide couvre le passage du local à la production. Si vous avez besoin de changer de nom de domaine sur un site déjà en ligne, c’est un autre sujet (consultez notre guide déplacer WordPress).

Que faut-il préparer avant la migration ?

Avant de toucher quoi que ce soit, assurez-vous d’avoir ces quatre éléments sous la main :

1. Un hébergeur avec WordPress compatible : PHP 7.4 minimum (idéalement 8.1+), MySQL 5.7+ ou MariaDB 10.4+, et suffisamment d’espace disque. J’héberge wpformation.com chez O2switch depuis 2025 (à partir de 7 € HT/mois pour de l’illimité).
2. Un accès FTP ou SSH : FileZilla pour le FTP, ou un terminal SSH si votre hébergeur le propose. Récupérez les identifiants dans votre espace client.
3. Un accès phpMyAdmin : pour créer la base de données côté hébergeur (nom, utilisateur, mot de passe). Notez ces trois infos, vous en aurez besoin.
4. Un nom de domaine configuré : les DNS doivent pointer vers votre hébergeur. Si c’est fraîchement configuré, attendez la propagation (jusqu’à 24h, en pratique souvent 1-2h).

D’où partez-vous ? Les environnements locaux en 2026

Le paysage des outils de développement local a beaucoup évolué. Avant de choisir votre méthode de migration, identifions votre point de départ :

LocalWP (anciennement Local by Flywheel) reste la référence. Gratuit depuis la version 9, actuellement en 9.2.9, il crée des environnements WordPress isolés avec PHP, MySQL et SSL en quelques clics. Si vous développez en local, il y a de fortes chances que vous l’utilisiez déjà. LocalWP exporte nativement en ZIP (clic droit > Export), ce qui simplifie la migration. Pour les détails d’installation, voir notre tutoriel LocalWP.

WordPress Studio est le petit nouveau d’Automattic (version 1.7.6 en mars 2026). Gratuit, open source, disponible sur Mac et Windows. Son atout : il exporte en ZIP (compatible Jetpack Backup) ou en SQL (base de données seule). Il importe aussi les fichiers .wpress d’All-in-One WP Migration, les ZIP de LocalWP et même les ZIP de WordPress Playground. Pas besoin de Docker ni d’Apache.

WordPress Playground et MyWordPress.net fonctionnent directement dans le navigateur grâce au WebAssembly. C’est génial pour tester, mais attention : ils utilisent SQLite au lieu de MySQL. La migration vers un hébergeur classique nécessite une conversion de base de données (on y revient plus bas).

DDEV et Lando sont des alternatives pour les développeurs avancés qui préfèrent Docker. Si vous êtes sur DDEV ou Lando, vous avez probablement déjà accès à WP-CLI, ce qui rend la méthode 3 naturelle.

Duplicator : la migration WordPress en quelques clics

Duplicator crée un "package" qui contient vos fichiers WordPress ET votre base de données dans une seule archive. Vous téléchargez cette archive + un fichier installer.php, vous les uploadez sur votre hébergeur, et le wizard fait le reste. C’est la méthode que je recommande aux débutants qui veulent comprendre ce qui se passe sans mettre les mains dans le cambouis.

Avec plus d’un million d’installations actives et une note de 4.9/5 sur presque 5 000 avis, c’est le plugin de migration le mieux noté de l’écosystème WordPress. Le projet est maintenu par Syed Balkhi (l’homme derrière WPBeginner), ce qui garantit un suivi actif et des mises à jour régulières.

Étape par étape :

1. Installez Duplicator sur votre WordPress local (Extensions > Ajouter)
2. Allez dans Duplicator > Packages > Créer un nouveau
3. Laissez les réglages par défaut et lancez la construction du package
4. Téléchargez les deux fichiers : l’archive ZIP et installer.php
5. Uploadez ces deux fichiers à la racine de votre hébergeur via FTP
6. Accédez à votre-domaine.com/installer.php dans votre navigateur
7. Renseignez les identifiants de la base de données créée sur l’hébergeur
8. Suivez le wizard jusqu’au bout, Duplicator remplace automatiquement les URLs

Temps estimé : 15 à 30 minutes pour un site standard (< 500 Mo).

Et si le package échoue ? C’est souvent un problème de timeout PHP ou de mémoire insuffisante côté hébergeur. Vérifiez que votre hébergeur autorise au moins 256 Mo de mémoire PHP et un max_execution_time de 300 secondes. Si le problème persiste, essayez d’exclure le dossier wp-content/uploads/ du package et transférez les médias séparément en FTP. C’est plus long, mais ça fonctionne à tous les coups.

All-in-One WP Migration : import, export, c’est plié

Avec 5 millions d’installations actives, c’est le plugin de migration le plus utilisé au monde. Et pour cause : l’interface est d’une simplicité redoutable. Export en un clic, import par glisser-déposer (oui, même dans la version gratuite). Pas de fichier installer.php à uploader séparément, pas de wizard en quatre étapes.

Comment ça marche ?

1. Installez le plugin sur votre WordPress local
2. Allez dans All-in-One WP Migration > Exporter > Fichier
3. Téléchargez le fichier .wpress généré
4. Installez WordPress sur votre hébergeur (installation vierge)
5. Installez le même plugin sur cette installation vierge
6. Allez dans All-in-One WP Migration > Importer > glissez le fichier .wpress
7. Attendez la fin de l’import, reconnectez-vous avec vos identifiants locaux

Temps estimé : 10 à 20 minutes, un peu plus si le fichier est volumineux.

Avez-vous un site qui dépasse 500 Mo ? La limite d’import dépend de la configuration PHP de votre hébergeur (upload_max_filesize). Si votre hébergeur limite à 128 Mo, vous pouvez modifier le .htaccess pour augmenter ce seuil, ou opter pour l’extension Unlimited (payante) qui contourne toutes les restrictions. Depuis la version 7.82, AIOWPM gère même la conversion SQLite vers MySQL, ce qui en fait la meilleure option si vous venez de WordPress Playground.

Un détail que j’apprécie : AIOWPM fait le search-replace des URLs automatiquement pendant l’import. Vous n’avez pas à vous soucier de remplacer localhost par votre nom de domaine, le plugin s’en charge. C’est un gain de temps considérable par rapport à la migration manuelle, et ça élimine le risque de casser la sérialisation des données.

Petit bémol : contrairement à Duplicator qui crée un package autonome, AIOWPM nécessite d’avoir WordPress déjà installé sur le serveur de destination. Ça ajoute une étape (l’installation de WordPress vierge), mais c’est vite fait via l’installateur automatique de la plupart des hébergeurs (Softaculous, cPanel, etc.).

Comment migrer WordPress avec WP-CLI ?

WP-CLI (version 2.12.0 en mars 2026), c’est l’interface en ligne de commande officielle de WordPress. Si le terminal ça vous parle, c’est de loin la méthode la plus propre et la plus rapide. Pas de plugin à installer, pas de fichier intermédiaire qui traîne, et surtout la possibilité d’automatiser tout le processus.

Pré-requis : WP-CLI installé en local, un accès SSH sur votre hébergeur (la plupart des hébergeurs sérieux le proposent, y compris O2switch), et rsync ou scp pour le transfert de fichiers.

Les quatre commandes clés :

# 1. Exporter la base de données locale
wp db export local-db.sql

# 2. Transférer les fichiers vers l'hébergeur
rsync -avz ./wordpress/ user@serveur:/public_html/

# 3. Importer la base sur l'hébergeur
wp db import local-db.sql

# 4. Remplacer les URLs (local → production)
wp search-replace 'http://localhost:10003' 'https://votre-domaine.com' --precise

Le flag --precise force PHP à traiter chaque colonne (au lieu de SQL brut). C’est plus lent, mais ça gère correctement les données sérialisées (options, widgets, réglages de thème). Sans ce flag, vous risquez de casser la sérialisation et de vous retrouver avec un site aux réglages fantaisistes.

Bon. Cette méthode n’est pas pour tout le monde. Mais si vous gérez plusieurs sites ou que vous faites des migrations régulièrement, WP-CLI vous fera gagner un temps considérable. Sur wpformation.com, c’est la méthode que j’utilise pour tous les déploiements en production… le jour où j’ai arrêté de chercher le bouton dans un plugin, j’ai gagné 2 heures par semaine.

Nota : si votre hébergeur ne propose pas d’accès SSH, vous ne pourrez pas utiliser WP-CLI côté serveur. Vérifiez dans votre espace client ou demandez au support. Des hébergeurs comme O2switch, Infomaniak, ou PlanetHoster incluent SSH dans leurs offres standard. Pour un tutoriel détaillé, consultez notre guide complet WP-CLI.

Comment faire une migration manuelle par FTP ?

La migration manuelle, c’est la méthode old-school. Pas de plugin, pas de magie, juste du FTP et du phpMyAdmin. Pourquoi la connaître ? Parce que le jour où un plugin de migration plante (et ça arrive), c’est votre filet de sécurité. Et parce que comprendre le mécanisme vous rendra plus à l’aise avec WordPress en général.

Transférer les fichiers par FTP

Connectez-vous à votre hébergeur via FileZilla ou un autre client FTP. Uploadez l’intégralité du dossier WordPress local vers le répertoire racine de votre hébergeur (souvent public_html/ ou www/). Tous les fichiers : wp-admin/, wp-content/, wp-includes/, et les fichiers à la racine comme wp-config.php, .htaccess et index.php.

Utilisez le mode de transfert "binaire" (pas "ASCII") pour éviter les problèmes d’encodage sur les fichiers PHP. Et activez le transfert simultané de 3-4 fichiers max dans les réglages de FileZilla, pour ne pas surcharger le serveur. Certains hébergeurs mutualisés bloquent les connexions FTP trop agressives.

Selon la taille de votre site et votre connexion, comptez entre 20 minutes et 2 heures. Les images dans wp-content/uploads/ représentent souvent 80% du temps de transfert.

Exporter et importer la base de données

Côté local, ouvrez phpMyAdmin (ou Adminer si vous êtes sur LocalWP). Sélectionnez votre base WordPress dans le panneau de gauche, cliquez sur l’onglet Exporter, choisissez le format SQL (méthode rapide), et cliquez sur Exécuter. Vous obtenez un fichier .sql qui contient toute la structure et les données de votre base. Gardez-le précieusement.

Côté hébergeur, commencez par créer une nouvelle base de données vide dans votre panneau de contrôle (cPanel > Bases de données MySQL). Notez bien le nom de la base, l’utilisateur et le mot de passe, vous en aurez besoin pour wp-config.php. Ouvrez ensuite phpMyAdmin sur cette base vide, cliquez sur l’onglet Importer, sélectionnez votre fichier .sql exporté depuis le local, et validez. L’import peut prendre quelques secondes à quelques minutes selon la taille de la base.

Corriger wp-config.php et les URLs

C’est l’étape que tout le monde oublie. Ouvrez wp-config.php sur le serveur et modifiez les quatre lignes de connexion à la base de données :

define('DB_NAME', 'nom_de_votre_base');
define('DB_USER', 'utilisateur_base');
define('DB_PASSWORD', 'mot_de_passe');
define('DB_HOST', 'localhost');

Ensuite, corrigez les URLs dans la base de données. Dans phpMyAdmin, exécutez ces deux requêtes SQL :

UPDATE wp_options SET option_value = 'https://votre-domaine.com'
WHERE option_name IN ('siteurl', 'home');

Mais attention, ça ne suffit pas. Ces deux requêtes SQL corrigent uniquement les réglages généraux. Les URLs sont aussi codées en dur dans les contenus des articles, les widgets, les menus, et les options sérialisées des plugins et du thème. Utilisez le plugin Better Search Replace (ou WP-CLI si vous avez un accès SSH) pour faire un remplacement complet de http://localhost:XXXX par https://votre-domaine.com sur l’ensemble des tables.

Temps total de la migration manuelle : comptez à minima 1 à 2 heures, davantage si c’est votre première fois.

InstaWP : du staging cloud vers la production

InstaWP prend le problème à l’envers. Au lieu de migrer vos fichiers manuellement, vous poussez votre site local vers un staging cloud hébergé par InstaWP, puis vous synchronisez ce staging avec votre hébergeur de production. Le tout avec un système de 2-way sync : production vers staging, staging vers production, au choix.

L’avantage ? Vous ne touchez jamais au FTP ni à phpMyAdmin. Le plugin gère le transfert, la synchronisation sélective (choisir quels fichiers, plugins ou tables pousser), et le rollback en cas de problème.

La limite : InstaWP est un service SaaS. Vous avez besoin d’un compte (gratuit pour les fonctions de base, payant pour les sites volumineux et le support prioritaire). Et le staging est hébergé sur les serveurs InstaWP, pas sur votre hébergeur. Pour un débutant qui veut éviter toute manipulation technique, c’est une option intéressante. Pour un pro qui gère ses propres serveurs, Duplicator ou WP-CLI restent plus directs.

Un avantage souvent sous-estimé : InstaWP propose trois modes de staging. Le staging rapide (sans médias, idéal pour tester un plugin), le staging personnalisé (vous choisissez ce que vous excluez), et le staging complet (copie intégrale). Pour une migration local vers hébergeur, c’est le staging complet qui nous intéresse. Et c’est pas fini… le 2-way sync vous permet aussi de ramener des modifications de production vers votre local, ce qui est génial pour garder les deux environnements synchronisés.

Quelle méthode choisir ?

Voici un tableau comparatif pour vous aider à trancher :

Méthode	Difficulté	Gratuit	SSH requis	Temps estimé	Idéal pour
Duplicator	Facile	Oui	Non	15-30 min	Sites < 500 Mo
All-in-One WP Migration	Très facile	Oui	Non	10-20 min	Première migration
WP-CLI	Avancé	Oui	Oui	10-15 min	Développeurs, CI/CD
FTP + phpMyAdmin	Intermédiaire	Oui	Non	1-2h	Comprendre le mécanisme
InstaWP	Facile	Freemium	Non	20-40 min	Staging cloud, équipes

Mon conseil : si c’est votre première migration, partez sur All-in-One WP Migration. C’est le plus simple et le plus tolérant aux erreurs. Si vous migrez régulièrement, investissez 30 minutes pour apprendre WP-CLI, vous ne le regretterez pas. Et si vous travaillez en équipe avec un staging partagé, InstaWP mérite un essai.

Un point qui revient souvent en formation : "je peux utiliser l’export XML intégré de WordPress (Outils > Exporter) pour migrer mon site ?" La réponse : non, pas pour une migration complète. L’export XML ne transfère que les contenus (articles, pages, médias). Pas les plugins, pas les réglages, pas le thème, pas les utilisateurs. C’est utile pour importer des contenus d’un site à l’autre, mais pour une vraie migration, il faut l’une des cinq méthodes ci-dessus.

Peut-on migrer un site WordPress Playground vers un vrai hébergeur ?

Oui, mais pas en copier-coller. WordPress Playground et MyWordPress.net utilisent SQLite comme base de données (via le plugin SQLite Database Integration). Les hébergeurs classiques tournent sur MySQL ou MariaDB. Ce n’est pas le même moteur, pas le même format de fichier.

La bonne nouvelle : All-in-One WP Migration gère automatiquement la conversion SQLite vers MySQL depuis la version 7.82. Concrètement, vous exportez votre site Playground en fichier .wpress, vous installez WordPress + AIOWPM sur votre hébergeur, vous importez le fichier, et le plugin convertit la base de données au passage. Pas de manipulation SQL manuelle.

Si vous êtes sur WordPress Studio, c’est encore plus simple : Studio exporte en ZIP ou SQL natif, et il importe les fichiers .wpress et les ZIP de Playground. Vous pouvez donc transiter par Studio avant de migrer vers votre hébergeur.

Et le projet Data Liberation ? WordPress travaille sur un système de migration native entre Playground et les installations classiques. Le projet est actif sur GitHub (phases 1 à 3 en cours sur 5), avec pour objectif à terme de permettre le clonage et la synchronisation entre n’importe quelle installation WordPress. Mais en mars 2026, ce n’est pas encore assez mature pour une utilisation en production. Pour l’instant, AIOWPM reste la solution la plus fiable pour migrer depuis Playground.

WordPress Studio comme intermédiaire : si vous avez développé dans WordPress Playground et que vous voulez passer par un outil local avant de migrer, Studio accepte les fichiers ZIP de Playground en import. Vous pouvez donc transiter par Studio (qui utilise aussi SQLite mais avec un export SQL compatible MySQL), puis utiliser l’export ZIP ou SQL de Studio pour pousser vers votre hébergeur via Duplicator ou AIOWPM. C’est un chemin un peu plus long, mais qui vous donne plus de contrôle sur le processus.

Les 7 pièges à éviter lors de la migration

J’ai vu ces erreurs des dizaines de fois en formation. Chaque fois que je dis "c’est bon, le site est migré", il y a toujours un stagiaire qui lève la main pour dire "mais chez moi ça marche pas"… et c’est presque toujours l’une de ces sept erreurs. On l’oublie trop souvent, mais la migration ne s’arrête pas au transfert des fichiers :

1. Le mixed content HTTP/HTTPS : votre site local tournait en HTTP, votre hébergeur force le HTTPS. Résultat : des images cassées, des scripts bloqués, un cadenas absent. Le search-replace doit couvrir http:// vers https:// dans toute la base.
2. Les permalinks cassés : après migration, toutes les pages renvoient une erreur 404 sauf la homepage. C’est presque toujours un problème de .htaccess. Allez dans Réglages > Permaliens et cliquez sur "Enregistrer les modifications" (sans rien changer). WordPress régénère le .htaccess.
3. Le wp-config.php oublié : les identifiants de base de données pointent encore vers localhost. Page blanche garantie.
4. Les URLs codées en dur : même après un search-replace sur les tables principales, des URLs locales peuvent se cacher dans les options sérialisées, les widgets, les réglages de thème. Utilisez --all-tables-with-prefix en WP-CLI ou cochez "toutes les tables" dans Better Search Replace.
5. Les droits fichiers incorrects : sur Linux, les dossiers doivent être en 755 et les fichiers en 644. Si vous transférez depuis Windows, les permissions peuvent être anarchiques. Corrigez via SSH ou demandez à votre hébergeur.
6. Le cache du navigateur : vous voyez encore l’ancien site alors que la migration est terminée. Videz le cache navigateur, testez en navigation privée.
7. Les emails transactionnels : en local, les emails WordPress ne partent pas (pas de serveur SMTP). En production, vérifiez que les emails de formulaire, de commande WooCommerce ou de réinitialisation de mot de passe arrivent bien. Un plugin SMTP (WP Mail SMTP, FluentSMTP) règle le problème.

Que vérifier après la migration ?

Pas de panique, voici une checklist en 12 points. Prenez 15 minutes pour la parcourir, ça vous évitera des surprises :

1. Homepage : le site s’affiche correctement, pas de page blanche ni d’erreur PHP
2. Permalinks : naviguez sur 3-4 pages internes, vérifiez que les URLs fonctionnent
3. Images : vérifiez que les images s’affichent (médiathèque + contenu), pas de liens cassés
4. Formulaires : envoyez un formulaire test, vérifiez la réception
5. SSL/HTTPS : le cadenas apparaît dans la barre d’adresse, pas de mixed content
6. Connexion admin : connectez-vous au tableau de bord, vérifiez les réglages
7. Plugins : tous les plugins sont activés et fonctionnels
8. Cache : installez et configurez un plugin de cache (LiteSpeed Cache, WP Rocket…)
9. Cron WordPress : vérifiez que les tâches planifiées fonctionnent (publications programmées, sauvegardes)
10. SEO : vérifiez que le site n’est pas en "Demander aux moteurs de recherche de ne pas indexer ce site" (Réglages > Lecture). Soumettez votre sitemap dans la Google Search Console
11. Analytics : installez votre code de suivi GA4 ou Matomo
12. Sauvegarde : configurez une sauvegarde automatique. C’est votre première action post-migration. Pas demain, maintenant

Pour un audit plus complet de votre site après migration, consultez notre guide d’audit WordPress express et vérifiez la santé globale de votre site.

Questions fréquentes sur la migration WordPress

Puis-je migrer un site WordPress Playground vers un vrai hébergeur ?

Oui. WordPress Playground utilise SQLite, pas MySQL. All-in-One WP Migration (v7.82+) convertit automatiquement la base SQLite en MySQL lors de l’import. Exportez votre site Playground en fichier .wpress, installez WordPress + AIOWPM sur votre hébergeur, et importez le fichier. La conversion est transparente.

Quelle méthode choisir si mon site dépasse 1 Go ?

Pour les sites volumineux, WP-CLI est la meilleure option : pas de limite de taille, transfert par rsync (reprend en cas d’interruption), et remplacement d’URLs fiable avec –precise. Duplicator Pro (49,50 $/an) est une alternative si vous n’avez pas d’accès SSH. Évitez la migration manuelle FTP pour les gros sites, le transfert prend des heures et une coupure réseau peut corrompre les fichiers.

Faut-il réinstaller les plugins après la migration ?

Non. Les cinq méthodes décrites ici transfèrent les plugins avec le reste du site. Ils seront déjà installés et activés après la migration. En revanche, certains plugins liés à l’environnement local (comme les outils de debug) peuvent nécessiter une désactivation manuelle sur le serveur de production.

Comment gérer les emails transactionnels après migration ?

En local, les emails WordPress ne partent généralement pas (pas de serveur SMTP configuré). En production, installez un plugin SMTP comme WP Mail SMTP ou FluentSMTP et configurez-le avec les identifiants de votre fournisseur email (Gmail, SendGrid, Brevo…). Envoyez un email test pour vérifier que tout fonctionne.

Mon hébergeur propose un outil de migration gratuit, dois-je l’utiliser ?

Certains hébergeurs (SiteGround, Cloudways, WP Engine) proposent des outils de migration intégrés ou des plugins dédiés. Ils fonctionnent bien pour migrer VERS leur plateforme, mais sont rarement utilisables dans l’autre sens. Si vous migrez du local vers cet hébergeur, leur outil peut simplifier le processus. Vérifiez la documentation de votre hébergeur avant d’installer un plugin tiers.

WordPress Studio peut-il remplacer LocalWP pour le développement local ?

WordPress Studio (v1.7.6, gratuit) est une alternative crédible à LocalWP. Il ne nécessite ni Docker ni Apache, importe les formats .wpress et .zip, et exporte en ZIP ou SQL. Son point faible : Studio Sync ne fonctionne qu’avec WordPress.com Business et Pressable. Pour les autres hébergeurs, l’export se fait manuellement. LocalWP reste plus mature, avec une communauté plus large et des add-ons comme Local Connect (WP Engine/Flywheel).

Comment migrer sans perdre le référencement ?

Si vous gardez le même nom de domaine (ce qui est le cas dans une migration local vers hébergeur), le SEO n’est pas impacté. Vérifiez simplement que le site n’est pas en noindex (Réglages > Lecture), que le sitemap XML est accessible, et soumettez-le dans la Google Search Console. Si vous changez de domaine, c’est un autre sujet qui nécessite des redirections 301.

Que faire si la migration échoue à mi-chemin ?

Pas de panique. Si vous avez suivi le conseil de sauvegarde en début d’article, votre site local est intact. Côté hébergeur, supprimez les fichiers partiellement transférés, videz la base de données, et recommencez. Si vous utilisiez Duplicator ou AIOWPM, vérifiez que la taille du fichier ne dépasse pas les limites PHP de votre hébergeur. En dernier recours, la migration manuelle FTP + phpMyAdmin fonctionne toujours.

Peut-on automatiser la migration avec WP-CLI ?

Oui. Vous pouvez créer un script bash qui enchaîne wp db export, rsync, wp db import et wp search-replace. Certains développeurs intègrent ce processus dans un pipeline CI/CD (GitHub Actions, GitLab CI) pour déployer automatiquement à chaque push sur la branche main. C’est la méthode la plus professionnelle pour les projets en équipe.

LocalWP ou WordPress Studio : lequel choisir en 2026 ?

LocalWP (v9.2.9) est le choix sûr : mature, communauté active, add-ons (Live Links, Cloud Backups), et surtout Local Connect pour pousser vers WP Engine et Flywheel. WordPress Studio (v1.7.6) est plus léger, ne nécessite aucune dépendance, et son import multi-format (.wpress, .zip, .sql) est un vrai atout. Si vous travaillez avec WordPress.com ou Pressable, Studio Sync est imbattable. Pour tous les autres cas, LocalWP reste la valeur sûre.

Migrer WordPress du local vers un hébergeur, ce n’est plus le parcours du combattant que c’était il y a dix ans. Entre les plugins tout-en-un, les outils officiels comme WordPress Studio, et WP-CLI pour les pros, vous avez l’embarras du choix. Le plus important n’est pas la méthode que vous choisissez, mais de faire une sauvegarde AVANT et de vérifier les URLs APRÈS. Autant éviter de se retrouver avec un site en production qui pointe encore vers localhost…

Si tu débutes, commence par All-in-One WP Migration. C’est le plus tolérant aux erreurs et le plus rapide à prendre en main. Si tu es développeur, passe à WP-CLI et ne regarde plus en arrière. Et si tu veux d’abord tester WordPress sans rien installer, MyWordPress.net dans ton navigateur est un excellent point de départ avant de passer aux choses sérieuses.

Pour aller plus loin dans l’écosystème WordPress, découvrez comment réaliser une refonte complète de votre site ou comment migrer depuis Wix vers WordPress si vous venez d’une autre plateforme. Certain d’en avoir oublié, mais les cinq méthodes de ce guide couvrent 99% des cas que je rencontre en formation.