Comment migrer un site WordPress chez un nouvel hébergeur sans interruption

Copier un site WordPress est rarement la partie difficile. Les interruptions viennent en général du moment de la bascule : le DNS pointe vers un serveur qui n’est pas prêt, la connexion à la base de données échoue, le certificat manque, ou une règle qui force le HTTPS tourne en boucle. Chacun de ces problèmes peut être détecté avant la bascule si vous pouvez ouvrir le site sur le nouveau serveur pendant que le reste du monde voit encore l’ancien.

L’approche de ce guide est simple : l’ancien serveur continue de servir les visiteurs jusqu’à ce que le nouveau ait été vérifié page par page. Le DNS n’est modifié qu’une fois, avec un TTL court, pour que le changement se diffuse en quelques minutes au lieu de plusieurs heures.

• Les accès à l’ancien hébergeur (fichiers et base de données, ou un panneau de contrôle), au nouvel hébergeur et au fournisseur DNS du domaine. Le fournisseur DNS est celui vers lequel pointent les serveurs de noms : souvent le registrar, parfois Cloudflare ou l’ancien hébergeur.
• Une sauvegarde complète du site actuel que vous avez téléchargée, et non une sauvegarde qui n’existe que sur l’ancien serveur.
• L’adresse IP publique du nouveau serveur. En cas de doute, voir Trouver l’IP de votre serveur.
• Les versions de PHP et de la base de données de l’ancien site. Reproduisez-les sur le nouveau serveur, ou vérifiez que votre thème et vos extensions prennent en charge les versions plus récentes.
• La liste des pages importantes : accueil, un article, une catégorie, la recherche, le formulaire de contact, le panier et le paiement si vous utilisez WooCommerce, et wp-admin.

Vérifiez dès maintenant le TTL actuel de l’enregistrement A du domaine avec le vérificateur de TTL. Vous en aurez besoin pour le calendrier de l’étape 1.

1. 1

   Étape 1 : Réduire le TTL la veille

   Dans votre panneau DNS, passez le TTL de l’enregistrement A (et AAAA, s’il existe) à 300 secondes, toujours vers l’ancien serveur. Attendez au moins la durée de l’ancien TTL avant de basculer. Voir Réduire le TTL avant une migration.

2. 2

   Étape 2 : Sauvegarder l’ancien site

   Faites une sauvegarde complète des fichiers et de la base de données, puis téléchargez-la. C’est votre plan de retour en arrière en cas de problème.

3. 3

   Étape 3 : Copier fichiers et base de données chez le nouvel hébergeur

   Utilisez une extension de migration, l’outil de transfert de l’hébergeur ou une copie manuelle avec WP-CLI. Laissez home et siteurl sur le domaine de production.

4. 4

   Étape 4 : Ouvrir le site sur le nouveau serveur

   Créez un lien d’aperçu avec votre domaine et la nouvelle IP. Parcourez les pages clés, connectez-vous à wp-admin et envoyez une image pour confirmer les permissions des fichiers.

5. 5

   Étape 5 : Lancer une exploration QA

   Lancez un rapport QA sur l’aperçu pour repérer les pages cassées, fichiers manquants, boucles de redirection, contenu mixte et URL codées en dur. Corrigez, puis relancez-le.

6. 6

   Étape 6 : Geler le contenu et faire une synchronisation finale

   Bloquez quelques minutes les nouvelles commandes, commentaires et articles sur l’ancien site, puis recopiez la base de données pour ne rien perdre de ce qui a été écrit depuis la première copie.

7. 7

   Étape 7 : Basculer les DNS

   Faites pointer l’enregistrement A du domaine et de www vers la nouvelle IP. Mettez à jour ou supprimez tout ancien enregistrement AAAA pour que les visiteurs IPv6 n’arrivent plus chez l’ancien hébergeur.

8. 8

   Étape 8 : Suivre la propagation et garder l’ancien hébergeur

   Suivez le changement avec le vérificateur de propagation DNS. Gardez l’ancien hébergement quelques jours de plus, jusqu’à ce que ses journaux d’accès ne montrent plus de vrais visiteurs.

Les deux fonctionnent. Choisissez selon la taille du site et les accès dont vous disposez de chaque côté.

Pour une copie manuelle, les commandes ressemblent à ceci. Lancez l’export sur l’ancien serveur et l’import sur le nouveau :

# Old server: export the database and pack the files
wp db export site.sql
tar -czf site-files.tar.gz --exclude=wp-content/cache .

# New server: unpack, import, check the site URL
tar -xzf site-files.tar.gz
wp db import site.sql
wp option get home
wp option get siteurl

Si le nouvel hébergeur vous donne d’autres identifiants de base de données, mettez à jour DB_NAME, DB_USER, DB_PASSWORD et DB_HOST dans wp-config.php avant de tester.

WordPress enregistre sa propre adresse dans la base de données (home et siteurl) et construit la plupart des liens à partir d’elle. Une erreur courante consiste à les remplacer par l’IP du serveur ou un nom d’hôte temporaire pour tester le nouveau serveur. Cela fonctionne jusqu’à la bascule, puis chaque lien codé en dur pointe vers l’adresse temporaire.

Laissez les deux valeurs sur le domaine de production, par exemple https://example.com, et testez le site sous ce nom. C’est exactement ce que fait un lien d’aperçu DNSPeek : il se connecte à la nouvelle IP et demande votre vrai domaine, si bien que WordPress se comporte comme si le DNS avait déjà basculé. Les liens, redirections et cookies de connexion sont réécrits vers l’adresse de l’aperçu, vous pouvez donc vous connecter à wp-admin et parcourir le site. Plus de détails dans la documentation : Prévisualiser un site WordPress chez un nouvel hébergeur.

Beaucoup d’hébergeurs n’émettent un certificat gratuit qu’une fois le domaine pointé vers eux, car la vérification du domaine se fait en HTTP sur le domaine lui-même. Avant la bascule, le nouveau serveur peut présenter un certificat auto-signé ou par défaut. C’est normal et ce n’est pas une raison de reporter.

Dans un aperçu DNSPeek, réglez le mode SSL du lien sur Ignorer la vérification tant que le certificat manque. Sinon, une extension ou une règle qui force le HTTPS peut provoquer une boucle de redirection quand l’aperçu se rabat sur HTTP. Après la bascule, confirmez le vrai certificat avec le vérificateur SSL. Détails : modes SSL.

Sur une boutique ou un site avec connexion, de nouvelles données continuent d’arriver sur l’ancien serveur jusqu’à la bascule. Les commandes, commentaires et nouveaux comptes créés après votre copie seraient perdus. Prévoyez un court gel du contenu : annoncez une fenêtre de maintenance pour les nouvelles commandes, ou mettez l’ancien site en mode maintenance seulement pendant les minutes de la synchronisation finale de la base. Dans les deux cas, les pages continuent de s’afficher pour les lecteurs.

Les passerelles de paiement et les fournisseurs de connexion ne connaissent que votre vrai domaine : ils renvoient donc les clients vers le serveur désigné par le DNS public. Testez le paiement avec une passerelle de test sur l’aperçu, puis passez une vraie commande ou une commande en mode sandbox juste après la bascule. Voir ce que les aperçus ne peuvent pas faire.