Migrer son WordPress d'hébergeur sans couper le site : la checklist

La peur de la migration est le premier carburant des mauvais hébergeurs : des milliers de sites restent sur des offres lentes, chères ou à l’abandon parce que leur propriétaire redoute la coupure, la perte de données ou la casse SEO. Cette peur est légitime quand on migre à l’arrache, et infondée quand on migre avec méthode.

Nous migrons régulièrement des sites clients, du site vitrine à la boutique WooCommerce en production, et le standard est toujours le même : zéro coupure visible, zéro email perdu, zéro impact SEO. Pas grâce à un outil magique, grâce à un ordre des opérations qui ne laisse rien au hasard.

Voici cette méthode, étape par étape, avec les pièges que nous avons réellement rencontrés, dont deux ou trois que vous ne trouverez dans aucun tutoriel.

Étape 0 : l’audit préalable (celui que tout le monde saute)

Avant de copier quoi que ce soit, faites l’inventaire. C’est l’étape sacrifiée dans tous les tutoriels, et c’est elle qui évite les mauvaises surprises à J+3.

• Versions : PHP et MySQL/MariaDB de l’ancien serveur. Le nouveau doit proposer au moins les mêmes ; un saut de version PHP se teste en recette, pas en production.
• La taille réelle : base de données et dossier uploads. Une migration de 300 Mo et une de 30 Go ne s’organisent pas pareil.
• Les tâches planifiées : crons serveur, tâches WP-Cron critiques (sauvegardes, synchronisations, envois programmés). Elles devront être recréées.
• Les emails : vos adresses sont-elles hébergées chez le même prestataire que le site ? C’est LE point qui transforme une migration de site en migration d’emails non anticipée. Listez les enregistrements DNS actuels (MX, SPF, DKIM) avant de toucher à quoi que ce soit.
• Les services liés à l’IP ou au serveur : pare-feu applicatif, restrictions d’IP chez des tiers (API bancaires, ERP), certificats particuliers.
• Le TTL des DNS : repérez où sont gérés vos DNS et notez le TTL actuel de l’enregistrement principal. Il servira à l’étape 4.

Profitez-en pour faire le ménage : une migration est le meilleur moment pour supprimer les plugins abandonnés et les thèmes inutilisés. Et si votre site a surtout besoin d’une refonte, posez-vous la question avant de déménager l’existant ; notre article refonte de site : quand faut-il s’y résoudre ? aide à trancher.

Étape 1 : copier fichiers et base de données

La copie elle-même est la partie la plus documentée, donc la plus simple :

1. Les fichiers : tout le dossier WordPress, wp-content en tête (thèmes, plugins, uploads), via SSH/rsync idéalement, SFTP sinon.
2. La base de données : un export complet (mysqldump ou phpMyAdmin), fait au même moment que la copie des fichiers pour rester cohérent.
3. Les plugins de migration (Duplicator, All-in-One WP Migration, Migrate Guru) font ce travail correctement pour les sites simples ; au-delà de quelques Go ou sur un hébergement mutualisé qui coupe les scripts longs, la copie manuelle reste plus fiable.

Beaucoup d’hébergeurs sérieux font cette étape pour vous : la migration est offerte et illimitée chez Copilhost (lien partenaire, sans surcoût pour vous), et Hostinger propose aussi une migration gratuite. Déléguer la copie ne dispense pas du reste de la checklist : la recette et la bascule restent votre responsabilité.

Étape 2 : la recette sur domaine temporaire

C’est l’étape qui sépare les migrations sereines des migrations à suspense : le site doit tourner et être testé sur le nouveau serveur avant que le public y soit envoyé.

Deux façons de faire : le domaine temporaire fourni par le nouvel hébergeur (avec un search-replace propre des URLs, en respectant les données sérialisées, ce que fait WP-CLI avec wp search-replace), ou la modification du fichier hosts de votre machine pour voir le vrai domaine servi par le nouveau serveur sans toucher aux DNS. La seconde évite tout search-replace, nous la préférons quand c’est possible.

Sur un hébergement managé avec staging natif, cette étape devient triviale : chez Copilhost par exemple, le site migré arrive sur un domaine temporaire, se teste, se clone ; la recette est le mode de fonctionnement normal de la plateforme, pas un échafaudage à construire.

La checklist de recette, a minima : pages clés, menus, formulaires (avec envoi réel), recherche, connexion admin, et pour une boutique un achat test complet, paiement compris. Vérifiez aussi les versions PHP et les erreurs dans les logs.

Étape 3 : les pièges vécus (la partie que les tutoriels n’ont pas)

Trois pièges rencontrés en production, qui ne se voient qu’après la bascule si on ne les connaît pas :

Les clés chiffrées liées aux salts WordPress. Certains plugins, notamment de paiement, chiffrent leurs clés API en base en utilisant les salts de wp-config.php (les constantes AUTH_KEY, NONCE_SALT, etc.). Si vous régénérez ces salts en migrant, ou si votre outil de migration en génère de nouveaux, le plugin ne peut plus déchiffrer ses clés : le paiement tombe en panne silencieusement. Nous l’avons vécu avec un module de paiement en plusieurs fois : la solution est de conserver les salts d’origine, ou de re-saisir les clés API après migration. À tester impérativement par un achat réel.

Les caches serveur à re-flusher dans le bon contexte. Les hébergements modernes empilent les caches (OPcache, cache objet, cache de page, CDN). Piège vécu : un cache vidé en ligne de commande ne l’est pas forcément pour les visiteurs, car le contexte CLI et le contexte web ne partagent pas toujours le même cache. Après la bascule, purgez tous les niveaux, y compris depuis l’admin web, et vérifiez en navigation privée.

Les emails. Deux volets. Si vos boîtes mail étaient chez l’ancien hébergeur, il faut les migrer ou les conserver là-bas, et surtout reporter les enregistrements MX à l’identique. Et dans tous les cas, le nouveau serveur envoie les emails transactionnels (confirmations de commande, formulaires) depuis une nouvelle IP : mettez à jour SPF et DKIM, sous peine de voir ces emails partir en spam. Un envoi de test vers Gmail et Outlook après bascule fait partie de la recette.

Étape 4 : la bascule DNS sans coupure

La bascule proprement dite se joue sur un paramètre que personne ne regarde : le TTL.

Moment	Action	Pourquoi
J-2	Abaisser le TTL de l’enregistrement A/CNAME à 300 s	Le monde entier « oubliera » l’ancienne IP en 5 minutes au lieu de 24 h
J	Geler le contenu (plus de commandes/articles : maintenance courte côté admin si besoin)	Éviter qu’une commande arrive sur l’ancien serveur pendant la propagation
J	Resynchroniser base et uploads (delta depuis la copie initiale)	La copie de l’étape 1 a vieilli
J	Changer l’enregistrement DNS vers le nouveau serveur	La bascule elle-même : 5 minutes de propagation grâce au TTL réduit
J	Vérifier le SSL sur le nouveau serveur	Certificat émis et servi avant l’arrivée du trafic
J+2	Remonter le TTL, garder l’ancien serveur en vie 1 à 2 semaines	Filet de sécurité et retardataires DNS

Pour une boutique, le gel de contenu est le point critique : on bascule au creux du trafic, avec une resynchronisation finale juste avant le changement DNS. Bien exécuté, le processus se traduit par quelques minutes de lecture seule, jamais par un site hors ligne.

Côté SEO : mêmes URLs, même contenu, même certificat ; Google ne voit qu’un changement d’IP, qui n’a aucun effet sur le classement. Les seules migrations qui coûtent du SEO sont celles qui changent les URLs en même temps que le serveur ; ne mélangez jamais les deux chantiers.

Où migrer ? Deux réponses selon votre profil

Puisque la question suit toujours : petit budget et site simple, un mutualisé moderne type Hostinger fait le travail (plans WordPress dès 2,99 €/mois sur engagement long, staging inclus à partir du plan Business). Site à enjeu, boutique ou parc de sites, un hébergement WordPress managé type Copilhost change l’exploitation au quotidien : staging en un clic, sauvegardes répliquées avec Time Machine, monitoring, et cette particularité que nous détaillons ailleurs, un serveur MCP par site que des agents IA peuvent piloter. Notre comparatif des hébergements WordPress détaille les deux profils, et le troisième larron auquel on ne pense pas : le statique gratuit. Un critère qui tranche vite : la géographie de votre audience. Copilhost est français et taillé pour un public français ; pour un site qui vise le Brésil ou l’international (nous opérons des sites des deux côtés de l’Atlantique), Hostinger a l’atout du réseau mondial, datacenter de São Paulo compris.

Et si vous préférez ne toucher à rien vous-même, migrer des WordPress sans coupure fait partie de nos services : c’est un travail de méthode, et la méthode, vous venez de la lire.

Questions fréquentes

Combien de temps dure une migration WordPress ?

Le calendrier complet s’étale sur une semaine (audit, copie, recette, TTL abaissé à J-2, bascule, surveillance), mais le travail effectif représente quelques heures pour un site vitrine et une à deux journées pour une boutique avec recette complète. La coupure visible, elle, doit être nulle ; au pire quelques minutes de gel des commandes pour un e-commerce au moment de la resynchronisation finale.

Vais-je perdre mon référencement en changeant d’hébergeur ?

Non, si les URLs ne changent pas : Google ne classe pas des serveurs, il classe des pages. Un changement d’IP est invisible pour le classement. Les risques réels sont indirects : un site plus lent après migration (mauvais dimensionnement), un SSL manquant à la bascule, ou un robots.txt de recette laissé en « noindex » sur la production. Les trois figurent dans la checklist de recette, précisément pour ça.

Puis-je utiliser un simple plugin de migration ?

Pour un site vitrine de taille raisonnable, oui : Duplicator ou équivalent automatisent copie et search-replace correctement. Leurs limites apparaissent avec le volume (uploads de plusieurs Go), les hébergements qui tuent les scripts longs, et les cas particuliers listés plus haut (salts, emails, crons), qu’aucun plugin ne gère à votre place. Le plugin remplace l’étape de copie, pas la méthode.

Que faire de l’ancien hébergement après la migration ?

Le garder actif une à deux semaines : c’est votre filet de sécurité si un problème apparaît en production et c’est là que les derniers résolveurs DNS retardataires enverront quelques visiteurs. Passé ce délai, vérifiez une dernière fois que les emails et DNS ne dépendent plus de lui, récupérez une archive complète que vous conservez, puis résiliez. Et pensez à couper le renouvellement automatique : les hébergeurs comptent sur l’oubli.