Migrer WordPress vers un autre hébergeur : le guide

Ce que tu vas apprendre (et pour qui)

Ce guide s’adresse à qui doit changer d’hébergeur WordPress sans y perdre son SEO, ses emails ou une nuit blanche : mutualisé vers mutualisé, mutualisé vers VPS, ou simple changement de prestataire. On couvre les deux méthodes de migration (manuelle et plugin), le test sur une URL provisoire avant bascule, la gestion des DNS et du SSL, et les vérifications à faire juste après. Applicable vers n’importe quel hébergeur — OVH, o2switch, Hostinger, IONOS ou un VPS maison.

Prérequis

• Accès FTP/SSH et phpMyAdmin (ou équivalent) sur l’ancien et le nouvel hébergeur
• Un compte chez le nouvel hébergeur déjà créé, avec la base de données WordPress prête
• Les identifiants du gestionnaire de domaine (souvent différent de l’hébergeur)
• Une sauvegarde complète récente (fichiers + base) avant de toucher à quoi que ce soit
• 2 à 4 heures dans le calendrier, idéalement un jour à faible trafic

1. Choisir sa méthode : export manuel ou plugin

Deux chemins possibles, selon la taille du site et ton niveau de confort technique.

Méthode manuelle : tu télécharges tout wp-content, wp-config.php et le cœur WordPress via FTP ou SSH (se connecter en SSH sur OVH si c’est ton cas), tu exportes la base via phpMyAdmin en SQL, puis tu réimportes sur le nouvel hébergeur.

Méthode plugin : Duplicator ou All-in-One WP Migration génèrent un paquet unique (fichiers + base compressés) que tu réinstalles avec un installeur dédié. Plus simple, mais surveille les limites de taille et les timeouts PHP sur les gros sites — un site déjà lent aggrave ce risque, vaut le coup de nettoyer la base avant de migrer.

2. Préparer le nouvel hébergement et tester sur une URL provisoire

Ne touche pas encore au DNS. Crée le site chez le nouvel hébergeur sous une URL temporaire : soit l’IP directe (http://IP/~utilisateur), soit un sous-domaine fourni par l’hébergeur, soit en modifiant localement ton fichier hosts pour pointer ton domaine vers la nouvelle IP sans propagation publique.

Installe WordPress (ou dépose les fichiers migrés) sur cette URL provisoire, importe la base, puis dans wp-config.php ou via un plugin comme Better Search Replace, remplace toutes les occurrences de l’ancienne URL par la nouvelle URL provisoire — WordPress stocke énormément d’URLs en dur dans la base (images, liens internes, options de thème).

Teste tout : pages, formulaires, panier si e-commerce, menu, admin. C’est le moment de repérer un menu qui ne s’affiche pas ou un formulaire de contact muet — bien plus simple à corriger avant la bascule qu’après.

3. Migrer les fichiers et la base de données

Si tout est validé sur l’URL provisoire :

1. Fais un dernier export à jour des fichiers et de la base (le site source a peut-être évolué depuis le premier test).
2. Transfère le dossier wp-content complet (thème, plugins, uploads) — c’est souvent le plus volumineux et le plus sensible.
3. Réimporte la base via phpMyAdmin ou en ligne de commande (mysql -u user -p base < export.sql), en vérifiant l’encodage UTF-8.
4. Vérifie wp-config.php : nom de base, utilisateur, mot de passe, préfixe de tables doivent correspondre au nouvel environnement.

Une erreur de préfixe ou d’identifiant à ce stade se traduit typiquement par une erreur de connexion à la base de données — un classique à checker en premier si l’écran reste blanc.

4. Basculer les DNS sans coupure

C’est l’étape la plus délicate, pas techniquement, mais en gestion du temps. 24 à 48h avant la bascule, abaisse le TTL (Time To Live) de tes enregistrements DNS chez l’ancien hébergeur à 300 secondes (5 minutes) au lieu des 3600 ou 86400 par défaut. Ça réduit le temps de propagation au moment du changement réel.

Le jour J, modifie les enregistrements A (et CNAME si besoin) pour pointer vers la nouvelle IP. Selon ton registrar, la procédure diffère légèrement : consulte configurer ses DNS sur o2switch, sur Hostinger ou sur IONOS selon ta destination.

Pendant la propagation (quelques minutes à quelques heures avec un TTL bas), garde l’ancien hébergement actif en lecture — ne le coupe surtout pas tout de suite. Si après 24h le domaine ne pointe toujours pas vers le bon serveur, le diagnostic DNS qui ne propage pas t’aide à isoler le blocage.

5. Réémettre le SSL et vérifier les emails

Le certificat SSL ne suit pas le site automatiquement. Sur le nouvel hébergeur, active Let’s Encrypt (ou ton certificat payant) dès que le domaine pointe vers la nouvelle IP — sinon tu récoltes un NET::ERR_CERT_DATE_INVALID ou une alerte de sécurité dans le navigateur des visiteurs.

Les emails professionnels (contact@tondomaine.fr) sont souvent hébergés séparément du site, via des enregistrements MX distincts. Vérifie que ces MX ne sont pas écrasés par la bascule et que ton envoi transactionnel fonctionne toujours — si les emails du site n’arrivent plus, la configuration SMTP est le premier point à contrôler.

6. Vérifications post-migration

Une fois la propagation DNS terminée (vérifiable via un outil de propagation DNS en ligne) :

• Le site charge en HTTPS sans avertissement de contenu mixte
• Les redirections (si présentes) fonctionnent sans boucle
• Sitemap et robots.txt sont accessibles
• La vitesse est comparable ou meilleure qu’avant — sinon, reprends le diagnostic de site lent
• Google Search Console ne signale pas d’erreurs de crawl nouvelles

Pour l’aspect SEO pur (redirections 301, sitemap resoumis, Search Console), le guide changer d’hébergeur sans perdre son référencement détaille la checklist complète à ne pas sauter.

Pièges courants

• TTL laissé haut : sans l’avoir abaissé en amont, la bascule peut prendre 24 à 48h au lieu de quelques minutes, avec des visiteurs qui atterrissent aléatoirement sur l’un ou l’autre serveur.
• Ancien hébergement coupé trop vite : le domaine met du temps à propager partout ; couper l’ancien site avant la fin de propagation crée des coupures pour une partie des visiteurs.
• URLs en dur non remplacées : images cassées, liens internes qui pointent vers l’ancien domaine — Better Search Replace ou WP-CLI (wp search-replace) évitent ce piège.
• SSL oublié : le site répond mais affiche une alerte de sécurité, ce qui fait fuir une bonne partie du trafic en quelques secondes.
• MX écrasés : la migration DNS emporte parfois les enregistrements email par erreur, coupant la réception pendant plusieurs heures.

Une migration bien préparée se joue avant le jour J : URL provisoire testée à fond, TTL abaissé 48h en avance, SSL prêt à être réémis dès que le DNS bascule. Le reste — fichiers, base, redirections — n’est qu’exécution.