NVHCloud
English
Español
Allemagne
États-Unis
Canada
Changer d'hébergement fait peur pour une raison simple : le site est en ligne et doit le rester. La bonne nouvelle, c'est qu'une migration WordPress bien menée est invisible pour vos visiteurs. Le secret tient en une règle : on ne touche au DNS qu'à la toute fin, quand le site fonctionne déjà parfaitement sur le nouveau serveur.
Voici la procédure que nous utilisons, du mutualisé vers un VPS, avec les pièges qui font perdre des commandes ou du référencement.
1. Préparer la migration
L'inventaire
- Les fichiers : tout le contenu de la racine, dont
wp-contentqui contient thème, extensions et médias. - La base de données : un export SQL complet.
- Les e-mails : s'ils sont chez l'hébergeur actuel, ce sont eux le vrai sujet délicat, pas le site.
- La zone DNS : notez chaque enregistrement existant avant d'y toucher.
- Les tâches planifiées et les certificats en place.
Les précautions
- Sauvegardez avant de commencer, et téléchargez la sauvegarde sur votre poste. Pas seulement chez l'hébergeur que vous quittez.
- Notez la version de PHP actuelle du site : vous reproduirez la même au départ, puis vous monterez.
- Choisissez une période creuse, en consultant vos statistiques plutôt qu'au hasard.
- Prévenez votre hébergeur actuel seulement après la bascule, jamais avant : gardez le compte actif quelques jours.
Le TTL indique aux serveurs DNS combien de temps garder l'ancienne adresse en mémoire. Abaissez-le à 300 secondes la veille de la migration : le jour J, le changement se propagera en quelques minutes au lieu de plusieurs heures. C'est l'étape que tout le monde oublie, et c'est elle qui provoque les longues périodes où une partie des visiteurs voit l'ancien site.
2. Préparer le nouveau serveur
Deux approches, selon votre aisance technique :
- Avec un panel : installez Plesk sur le VPS, créez l'hébergement du domaine, et vous retrouvez une interface proche de ce que vous connaissez, avec la gestion des bases, des certificats et des sauvegardes.
- En manuel : Nginx, PHP-FPM et MariaDB. Notre guide installer WordPress sur un VPS détaille l'installation complète, et Nginx avec SSL Let's Encrypt couvre le certificat.
Dans les deux cas, alignez les versions : WordPress recommande PHP 8.3 ou plus récent et MariaDB 10.11 ou MySQL 8.0 au minimum. Si votre site tourne encore en PHP 7.4, installez d'abord la version que vous utilisez aujourd'hui, migrez, puis montez de version une fois le site stable sur le nouveau serveur. Un seul changement à la fois.
3. Transférer les fichiers et la base
La méthode la plus fiable passe par la ligne de commande. Depuis le nouveau serveur, récupérez les fichiers de l'ancien :
rsync -avz --progress -e ssh utilisateur@ancien-hebergeur:/chemin/vers/site/ /var/www/monsite/Si votre mutualisé n'offre pas d'accès SSH, un export en FTP puis un transfert vers le VPS fonctionne aussi, simplement plus lentement.
Pour la base de données, exportez depuis l'ancien hébergement, puis importez :
# sur l'ancien serveur (ou via phpMyAdmin)
mysqldump -u utilisateur -p ancienne_base | gzip > site.sql.gz
# sur le nouveau serveur
mysql -u nouvel_utilisateur -p nouvelle_base < site.sqlMettez ensuite à jour wp-config.php avec le nom de la base, l'utilisateur, le mot de passe et l'hôte (localhost le plus souvent). Vérifiez enfin les droits des fichiers : le serveur web doit être propriétaire du dossier, faute de quoi les mises à jour et les envois de médias échoueront.
WP-CLI simplifie beaucoup d'opérations : wp db export, wp db import, et surtout wp search-replace pour remplacer proprement des URL dans la base, y compris dans les données sérialisées, ce qu'un simple rechercher-remplacer SQL casserait.
4. Tester avant de basculer
C'est l'étape qui rend la migration invisible. Vous allez consulter le site sur le nouveau serveur alors que le public voit encore l'ancien. Sur votre ordinateur, ajoutez une ligne au fichier hosts :
# Windows : C:\Windows\System32\drivers\etc\hosts
# macOS et Linux : /etc/hosts
203.0.113.10 votre-site.fr www.votre-site.frRemplacez l'adresse par celle de votre VPS. Votre navigateur interroge alors le nouveau serveur, sans rien changer pour les visiteurs. Parcourez ensuite cette liste :
- La page d'accueil, une page intérieure, un article, et la recherche.
- Les liens permanents : si les pages intérieures renvoient une erreur 404, il manque la réécriture d'URL côté serveur.
- L'administration, l'envoi d'un média, la mise à jour d'un article.
- Le formulaire de contact et, pour une boutique, un passage complet de commande en mode test.
- Les images : si certaines manquent, une URL absolue traîne encore dans la base.
5. La bascule DNS
Une fois les tests concluants :
- Refaites un export de la base sur l'ancien serveur, pour récupérer les dernières commandes ou commentaires.
- Si le site est actif, passez-le en maintenance quelques minutes le temps de cette synchronisation finale.
- Modifiez les enregistrements
A(etAAAAsi vous avez de l'IPv6) vers l'adresse du VPS. - Émettez le certificat HTTPS sur le nouveau serveur dès que le domaine pointe vers lui.
- Retirez la ligne ajoutée dans votre fichier
hosts, puis vérifiez le site comme un visiteur normal.
Si vos e-mails restent chez votre ancien hébergeur ou chez un service tiers, laissez les enregistrements MX inchangés. Les modifier « pour faire propre » est la meilleure façon de perdre des messages pendant la propagation.
6. Après la migration
- Gardez l'ancien hébergement une à deux semaines. La propagation DNS n'est jamais instantanée partout, et c'est votre filet de sécurité.
- Vérifiez le référencement : dans la Search Console, surveillez les erreurs d'exploration les premiers jours. Les URL ne changent pas, donc votre positionnement ne bouge pas, mais une erreur serveur passée inaperçue se paie.
- Mesurez le gain. Comparez le TTFB avant et après, avec la méthode de notre article WordPress lent : trouver la vraie cause.
- Mettez en place les sauvegardes immédiatement : sur un VPS, elles sont de votre responsabilité. Notre guide sauvegardes VPS avec Borg montre comment les automatiser et les envoyer hors du serveur.
- Sécurisez la machine : pare-feu, fail2ban, clés SSH. Voyez sécuriser son serveur VPS.
- Montez la version de PHP maintenant que le site est stable, et mesurez à nouveau.
Pour choisir la taille du serveur avant de vous lancer, lisez quelle configuration de VPS pour WordPress.
À lire ensuite
Quel VPS pour héberger WordPress ?
RAM, vCPU, disque : quelle configuration de VPS pour un site WordPress selon son trafic, avec ou sans panel, et ce que coûte vraiment l'hébergement.
WordPress lent : les vraies causes
Diagnostiquez un WordPress lent : mesurer le TTFB, distinguer un problème de site d'un problème de serveur, et savoir quand changer d'hébergement.
Installer n8n sur un VPS avec Docker (guide 2026)
Guide pas à pas pour installer n8n sur un VPS Linux : Docker, PostgreSQL, HTTPS automatique avec Caddy, webhooks, mises à jour et sauvegardes.
Questions fréquentes
Combien de temps dure une migration WordPress vers un VPS ?
Comptez deux à trois heures pour un site vitrine classique, réparties sur deux jours : préparation et transfert la veille, bascule DNS le lendemain. Pour une boutique avec beaucoup de médias et de commandes, prévoyez une demi-journée.
Vais-je perdre mon référencement en changeant d'hébergeur ?
Non, si vos URL restent identiques. Google suit les adresses, pas les serveurs. Les seuls risques viennent d'une indisponibilité prolongée, d'erreurs 404 sur les pages intérieures ou d'un site nettement plus lent. Un TTFB amélioré joue plutôt en votre faveur.
Puis-je migrer sans aucune interruption de service ?
En pratique, l'interruption se limite à la synchronisation finale de la base, soit quelques minutes en mode maintenance. En baissant le TTL la veille et en testant le site via le fichier hosts avant la bascule, les visiteurs ne voient rien.
Faut-il installer Plesk sur le VPS ou tout faire à la main ?
Plesk vous donne une interface proche du mutualisé : bases, certificats et sauvegardes en quelques clics, au prix d'un peu de ressources et d'une licence. L'installation manuelle avec Nginx, PHP-FPM et MariaDB est plus légère et plus rapide, mais demande d'être à l'aise en ligne de commande.
Que faire de mes adresses e-mail pendant la migration ?
Le plus simple est de ne pas y toucher : laissez les enregistrements MX pointer vers votre fournisseur actuel. Si vous devez aussi déménager la messagerie, traitez-la comme un projet distinct, après la migration du site, en récupérant d'abord les messages existants.
Mes images ne s'affichent plus après la migration, pourquoi ?
Il reste presque toujours des URL absolues dans la base de données, parfois dans des données sérialisées. Utilisez la commande wp search-replace de WP-CLI, qui gère correctement ces données, plutôt qu'un rechercher-remplacer SQL qui les corromprait.