Migrer un site WordPress : les 12 étapes d’une migration sans casse

Migrer un site WordPress d’un hébergeur à un autre est une opération que nous réalisons chaque
mois — et qui, bien menée, est invisible pour vos visiteurs : zéro coupure,
zéro e-mail perdu, zéro impact SEO. Mal menée, c’est l’inverse : site en carafe pendant la
propagation DNS, base copiée à moitié, e-mails qui disparaissent pendant 48 h. La différence ne
tient pas à un outil magique mais à un ordre d’opérations strict. Le voici,
étape par étape, tel que nous l’appliquons.

Phase 1 : préparer (étapes 1 à 3)

1. L’inventaire complet — l’étape que tout le monde saute

• →Le site : taille des fichiers (le dossier uploads/ pèse parfois plusieurs Go), taille de la base, version PHP requise, extensions nécessitant une licence à réactiver.
• →Les e-mails : combien de boîtes sur le domaine, quel volume, qui les utilise ? C’est LE point qui transforme une migration réussie en catastrophe s’il est oublié — les e-mails ne suivent pas le site automatiquement.
• →Le domaine : où est-il enregistré ? Chez l’hébergeur qu’on quitte (il faudra le transférer ou au minimum en garder la main) ou chez un registrar indépendant (plus simple) ?
• →Les services annexes : sous-domaines, certificats SSL spécifiques, tâches cron serveur, redirections existantes dans la configuration.

2. Baisser le TTL DNS — 48 h avant

Le TTL (time to live) dit aux fournisseurs d’accès combien de temps garder en cache l’adresse de
votre serveur. S’il est à 24 h, la bascule mettra jusqu’à 24 h à se propager. On
l’abaisse à 300 secondes (5 min) 24 à 48 h avant la bascule : le
jour J, la transition devient quasi instantanée. Petit réglage, énorme différence.

3. Sauvegarde complète et vérifiée

Fichiers + base, stockée hors des deux serveurs (l’ancien ET le nouveau). C’est le filet de tout
le reste.

Phase 2 : copier (étapes 4 à 6)

4. Copier les fichiers

Par SSH/rsync quand l’hébergeur le permet (fiable, reprend en cas d’interruption), sinon FTP ou
un plugin de migration. Attention aux limites des plugins gratuits sur les gros sites — au-delà de
quelques Go, All-in-One WP Migration et consorts atteignent leurs quotas ou explosent les timeouts ;
c’est la copie manuelle qui redevient la méthode sérieuse.

5. Copier la base de données

Export SQL complet (mysqldump ou phpMyAdmin), import sur le nouveau serveur. Vérifiez le
jeu de caractères (utf8mb4) — une base importée dans le mauvais encodage donne des
accents cassés partout, un classique.

6. Adapter la configuration

wp-config.php : nouveaux identifiants de base, éventuellement nouveau préfixe de
chemin. Si le domaine ne change pas (cas d’un simple changement d’hébergeur), aucune
réécriture d’URL n’est nécessaire — c’est ce qui rend ce type de migration si sûr pour le
SEO.

Phase 3 : tester en aveugle (étapes 7 et 8) — le secret des migrations réussies

7. Vérification fonctionnelle complète

• Pages clés, images (le dossier uploads/ est-il complet ?), menus, recherche interne.
• Formulaires : envoi réel jusqu’à réception de l’e-mail.
• E-commerce : commande test complète, paiement en mode sandbox.
• Backoffice : connexion, édition, upload de média.
• Version PHP et extensions : aucun avertissement de compatibilité.

8. Préparer le certificat SSL

Le nouveau serveur doit servir le HTTPS dès la première seconde de la bascule. Selon l’hébergeur,
le certificat Let’s Encrypt peut être émis avant la bascule ou dans les minutes qui la suivent —
à vérifier avant, pas après.

Phase 4 : basculer (étapes 9 et 10)

9. Geler le contenu et resynchroniser

Entre la copie initiale et la bascule, le site a pu bouger : nouveaux articles, nouvelles
commandes, nouveaux commentaires. On gèle les modifications (ou on passe l’ancien site en
lecture seule), puis on resynchronise fichiers et base une dernière fois. Sur un
e-commerce actif, cette resynchronisation finale est la différence entre zéro commande perdue et un
trou de plusieurs heures dans les ventes.

10. Basculer le DNS

On pointe le domaine vers le nouveau serveur. Avec le TTL abaissé à l’étape 2, la propagation
prend quelques minutes. On garde l’ancien serveur allumé encore une à deux semaines :
les caches DNS récalcitrants y arrivent encore un moment, et il sert de filet.

Phase 5 : contrôler (étapes 11 et 12)

11. Surveillance post-bascule

• →Monitoring d’uptime sur les premières 72 h, vérification du HTTPS, des formulaires, du tunnel de commande — depuis plusieurs réseaux (fibre, 4G).
• →Les e-mails : boîtes recréées ou migrées, enregistrements MX, SPF, DKIM et DMARC mis à jour — sans quoi vos e-mails partent en spam chez vos destinataires. C’est le point de contrôle n°1 de nos post-migrations.
• →Search Console : aucune action requise si le domaine n’a pas changé, mais on surveille couverture et erreurs d’exploration la semaine suivante.

12. Résilier proprement

Une fois tout validé (comptez deux semaines de recul) : récupération d’une dernière
sauvegarde de l’ancien hébergement, résiliation, et vérification que le domaine et vos accès vous
appartiennent bien en propre. Si le domaine était chez l’ancien hébergeur, c’est le moment du
transfert — jamais dans la précipitation, un domaine bloqué en cours de transfert est un site
mort.

Combien de temps, quel risque ?

Pour un site vitrine standard, ce déroulé représente quelques heures de travail étalées sur une
semaine (à cause des délais DNS). Pour un e-commerce ou un site à fort trafic, comptez une
préparation plus poussée et une bascule programmée en heures creuses. Le risque, lui, dépend presque
entièrement du respect de l’ordre des opérations — et si votre migration s’accompagne d’un
changement de domaine ou d’URLs, un chantier SEO spécifique s’ajoute : c’est
l’objet de notre checklist migration
& SEO.

Sources : protocole de migration EVICO ; documentation DNS (TTL et
propagation) ; limites constatées des plugins de migration sur sites volumineux ;
bonnes pratiques SPF/DKIM/DMARC.