Migrer un site WordPress vers un nouvel hébergeur sans interruption

Migrer un site WordPress ne consiste pas simplement à copier des fichiers et à importer une base de données. Une migration maîtrisée doit préserver l’accès au site, le HTTPS, la messagerie, le référencement et les données générées pendant la transition. L’objectif d’une migration « sans interruption » est de maintenir deux environnements fonctionnels le temps que les requêtes basculent vers le nouveau serveur.

Avant de commencer, vérifiez que la destination dispose de suffisamment d’espace disque, de mémoire, d’une version de PHP compatible et d’un système de sauvegarde adapté. Ces critères doivent guider le choix parmi les solutions d’hébergement web, en particulier pour une boutique WooCommerce ou un site à fort trafic.

1. Réaliser un audit du site actuel

Documentez l’environnement de départ : versions de WordPress et de PHP, thème actif, extensions, tâches planifiées, volume de la base de données, espace utilisé, zone DNS, certificat SSL et service de messagerie. Recensez également les paiements, API, webhooks, CDN, outils statistiques et services SMTP externes.

• Repérez les extensions obsolètes ou incompatibles.
• Conservez les règles personnalisées de .htaccess, Nginx ou du panneau d’hébergement.
• Notez les limites PHP et les extensions serveur indispensables.
• Exportez la zone DNS et archivez les paramètres importants.
• Identifiez les données susceptibles d’évoluer : commandes, formulaires, comptes et réservations.

Prévoyez l’opération pendant une période calme, sans considérer pour autant que le site sera inactif. Une boutique ou une plateforme d’adhésion peut nécessiter un court passage en lecture seule lors de la synchronisation finale.

2. Préparer des sauvegardes et un plan de retour arrière

Créez des sauvegardes indépendantes des fichiers WordPress et de la base de données. Ne dépendez pas uniquement d’une extension de migration ni d’une copie stockée sur le serveur source. Placez les archives sur un espace distinct, contrôlez leur taille et vérifiez que l’export SQL peut être lu et restauré.

Gardez l’ancien hébergement actif pendant toute la propagation DNS. Le plan de repli doit préciser qui peut rétablir les anciens enregistrements, où se trouvent les sauvegardes validées et comment traiter les nouvelles transactions en cas de retour vers le serveur précédent.

3. Réduire le TTL DNS suffisamment tôt

Le TTL indique pendant combien de temps un résolveur peut conserver un enregistrement DNS en cache. Réduisez à l’avance le TTL des enregistrements A et AAAA concernés. Un changement tardif n’efface pas les informations déjà mises en cache : celles-ci restent valables jusqu’à l’expiration de leur ancien TTL.

Ne modifiez pas les entrées MX, SPF, DKIM ou DMARC simplement parce que le site change d’hébergement. Le web et la messagerie sont souvent gérés séparément. Les enregistrements e-mail doivent rester identiques, sauf si une migration de messagerie est prévue en parallèle.

4. Installer et tester WordPress sur la destination

Copiez le cœur de WordPress, les médias, les thèmes et les extensions. Exportez la base depuis la source, importez-la sur le nouvel hébergement, puis renseignez les nouveaux accès dans wp-config.php. Si le nom de domaine ne change pas, conservez les URL de production dans WordPress.

Testez avant de modifier le DNS public. Une entrée locale dans le fichier hosts permet d’associer le domaine à la nouvelle adresse IP uniquement sur votre ordinateur. Le navigateur utilise ainsi le véritable nom de domaine tout en consultant le serveur de destination.

Contrôles fonctionnels à effectuer

• Pages principales, articles, archives, recherche et navigation.
• Connexion à l’administration, ajout de médias et mises à jour.
• Formulaires, notifications et authentification SMTP.
• Panier, paiement, comptes clients, taxes et retours des prestataires.
• Redirections, balises canoniques, directives robots et sitemap XML.
• Affichage mobile, cache, journaux et en-têtes de sécurité.

Si le changement touche aussi l’architecture, les conteneurs ou le stockage, une migration cloud structurée permet de coordonner les dépendances applicatives, réseau et base de données.

5. Activer et contrôler le certificat SSL

Le nouveau serveur doit présenter un certificat valide pour tous les noms publics utilisés, notamment le domaine principal et sa variante www. Selon l’hébergeur, le certificat peut être émis par validation DNS, par validation temporaire du trafic ou installé manuellement lorsque son transfert est autorisé.

Contrôlez le HTTPS avec le fichier hosts : chaîne de certification, date d’expiration, noms couverts et redirection de HTTP vers HTTPS. Recherchez aussi le contenu mixte provenant de ressources encore appelées en HTTP. Évitez d’activer HSTS pour la première fois pendant la migration, car une politique erronée peut rester mémorisée par les navigateurs.

6. Synchroniser les données et basculer le DNS

Juste avant la bascule, placez les sites très dynamiques en maintenance contrôlée ou en lecture seule. Effectuez un dernier export de la base, synchronisez les médias récents, videz les caches et empêchez les tâches planifiées de s’exécuter simultanément sur les deux serveurs.

Remplacez uniquement les enregistrements A et AAAA nécessaires. Si un changement de serveurs de noms est imposé, comparez minutieusement l’ancienne et la nouvelle zone. Une entrée oubliée peut couper la messagerie, un sous-domaine ou un service de validation.

Pendant la propagation, les visiteurs peuvent atteindre l’un ou l’autre serveur. Maintenez donc les deux sites opérationnels et évitez de publier séparément sur chaque copie. Surveillez les journaux d’accès, les erreurs PHP, les formulaires, les commandes et la consommation de ressources.

7. Préserver la messagerie et les e-mails du site

Une migration web peut perturber les e-mails même si les boîtes restent chez le même prestataire. La zone DNS peut être recopiée de manière incomplète, tandis que les formulaires WordPress commencent à envoyer depuis une nouvelle adresse IP.

Liste de vérification e-mail

• Conserver tous les enregistrements MX et leurs priorités.
• Recopier l’enregistrement SPF complet sans en créer plusieurs pour le même nom.
• Préserver les sélecteurs et les clés publiques DKIM.
• Maintenir la politique DMARC et ses adresses de rapport.
• Vérifier les CNAME de découverte automatique et les accès webmail.
• Autoriser le nouveau service d’envoi ou utiliser un SMTP authentifié.
• Tester les échanges avec des fournisseurs externes et examiner les résultats d’authentification.

Pour les messages importants, ne comptez pas uniquement sur la fonction mail de PHP. Un service SMTP authentifié ou une plateforme d’e-mails transactionnels fournit généralement des journaux plus exploitables et une identité d’envoi mieux maîtrisée.

8. Effectuer les vérifications après migration

Analysez le site afin de détecter les liens cassés, images absentes, boucles de redirection et erreurs serveur. Contrôlez les outils pour webmasters, les statistiques, le cache, les tâches cron, les sauvegardes et la supervision de sécurité. Les URL canoniques et le sitemap doivent toujours employer le domaine HTTPS préféré.

Conservez l’environnement source jusqu’à expiration des caches DNS et après validation du nouveau serveur sur un cycle d’activité normal. Réalisez ensuite une archive finale, révoquez les anciens accès et fermez proprement l’hébergement précédent.

Conclusion pratique

Une migration WordPress à faible risque repose sur un ordre précis : audit, sauvegarde, réduction du TTL, préproduction, tests, SSL, synchronisation, bascule DNS limitée, protection de la messagerie et surveillance. Pour faire analyser les dépendances ou encadrer une migration sensible, vous pouvez contacter l’équipe developer.ma avant toute modification du DNS de production.