Une migration WordPress sans interruption demande plus qu’une copie du site et un changement d’adresse IP. L’ancien et le nouvel hébergement doivent répondre correctement pendant la transition, tandis que les données récentes, le DNS et le certificat SSL restent maîtrisés.
Une migration peut souvent se faire sans coupure visible, mais un site vitrine n’a pas les mêmes contraintes qu’une boutique WooCommerce ou un espace membre. Cet article se concentre sur la continuité de service. Pour le projet complet, consultez notre checklist de migration WordPress.
À retenir
Une bascule discrète exige une copie testée, des URL inchangées, un SSL prêt, un TTL réduit suffisamment tôt et deux serveurs maintenus en ligne pendant la transition. Sur un site transactionnel, il faut aussi protéger les nouvelles données.
Réussir une migration WordPress sans interruption : ce que cela signifie vraiment
Une bascule invisible, pas une promesse absolue
Une migration sans interruption visible signifie que chaque visiteur reçoit une page fonctionnelle, qu’il soit encore dirigé vers l’ancien serveur ou déjà vers le nouveau. Pendant la propagation DNS, les deux infrastructures doivent servir le même site, avec les mêmes URL publiques et un certificat HTTPS valide.
Google décrit ce scénario dans son guide sur le changement d’hébergement sans changement d’URL : préparer et tester la cible, modifier les DNS, surveiller les deux serveurs, puis fermer l’ancien lorsqu’il n’est plus utilisé.
Le DNS ne déplace ni les fichiers ni la base. Il dirige les requêtes. Réduire le TTL d’un environnement mal testé ne fait qu’exposer le problème plus vite.
Les sites dynamiques demandent une stratégie supplémentaire
Une copie récente et une synchronisation finale conviennent généralement à un site vitrine. La situation change lorsque WordPress enregistre des données en temps réel :
- commandes et paiements WooCommerce;
- formulaires et demandes de soumission;
- réservations ou inscriptions;
- comptes membres et commentaires.
Une commande reçue sur l’ancien serveur après la dernière copie ne se retrouve pas automatiquement sur le nouveau. Il faut donc prévoir un gel temporaire, une synchronisation différentielle ou une architecture plus avancée. Une courte fenêtre contrôlée vaut mieux qu’une promesse irréaliste qui expose l’entreprise à une perte de données.
Un service de migration WordPress doit donc définir la continuité attendue avant l’intervention : pages accessibles, formulaires reçus, paiements conservés, courriels fonctionnels et procédure de retour arrière.
Préparer les DNS, le TTL et le SSL avant la bascule
Tester le nouvel hébergement sans modifier le site public
Le nouvel environnement doit être complet avant de recevoir du trafic. La documentation WordPress pour déplacer un site confirme qu’un transfert conservant les URL repose sur la copie des fichiers et de la base, avec adaptation de wp-config.php si les accès changent.
Testez-le avec une adresse temporaire, un environnement protégé ou une entrée locale dans le fichier hosts, qui permet d’ouvrir le domaine sur la nouvelle IP sans modifier le DNS public.
Le contrôle doit dépasser la page d’accueil :
- pages, images et téléchargements;
- administration, formulaires et fonctions importantes;
- permaliens, redirections, balises canoniques et sitemap;
- cache, tâches planifiées et journaux d’erreurs;
- PHP, base de données et extensions serveur.
Une version PHP compatible avec WordPress est indispensable. Une page d’accueil correcte ne valide pas les fonctions moins visibles.
Si une adresse temporaire est accessible publiquement, empêchez son indexation et protégez-la lorsque c’est possible. Google recommande de retirer ces restrictions avant la mise en ligne afin que son robot puisse accéder normalement à la nouvelle infrastructure.
Réduire le TTL suffisamment tôt
Le TTL, ou Time To Live, indique combien de temps un résolveur DNS peut conserver une réponse en cache. Un TTL plus court permet aux nouvelles valeurs d’être demandées plus rapidement après la modification.
La documentation de Cloudflare sur le TTL DNS montre que les limites dépendent du fournisseur et du type d’enregistrement. Il n’existe donc pas de valeur universelle.
Réduire le TTL au moment de la bascule est trop tard : des réponses sont déjà en cache selon l’ancienne valeur. Google recommande une valeur basse mais raisonnable, appliquée suffisamment tôt; son guide évoque au moins une semaine d’avance.
La séquence correcte est la suivante :
- relever le TTL actuel des enregistrements Web;
- choisir une valeur acceptée par le fournisseur DNS;
- appliquer cette valeur plusieurs jours avant la bascule;
- attendre que les anciens caches aient eu le temps d’expirer;
- modifier les enregistrements seulement lorsque le nouveau site est validé.
Après stabilisation, le TTL peut être remonté selon les besoins de l’infrastructure.
Préparer le SSL et modifier uniquement les bons enregistrements
Le nouvel hébergement doit répondre en HTTPS dès que les premiers visiteurs y arrivent. Vérifiez le domaine principal, la version www si elle est utilisée, la chaîne du certificat et les redirections HTTP vers HTTPS.
La validation DNS-01 décrite par Let’s Encrypt permet de préparer un certificat avant que le domaine pointe vers le nouveau serveur. Sinon, coordonnez précisément son émission avec l’hébergeur.
Lors d’un simple changement d’hébergement, on modifie généralement A, AAAA ou CNAME, selon la configuration. Ne remplacez pas toute la zone DNS et ne touchez pas aux enregistrements MX ou TXT par réflexe : la messagerie peut dépendre d’un autre fournisseur.
Le choix du nouvel hébergement Web WordPress doit aussi tenir compte de la compatibilité SSL, du cache, des tâches cron, du CDN et des règles de sécurité qui pourraient bloquer des visiteurs ou Googlebot après la bascule.
Exécuter la fenêtre de bascule et surveiller les deux serveurs
Organiser le jour J dans le bon ordre
Choisissez la fenêtre selon les données réelles de fréquentation. Une soirée n’est pas automatiquement idéale : une boutique peut y vendre davantage.
Un déroulé simple peut suivre cet ordre :
- confirmer la sauvegarde et la procédure de retour arrière;
- limiter temporairement les publications ou transactions si nécessaire;
- effectuer la dernière synchronisation des fichiers et de la base;
- refaire les tests critiques sur le nouvel hébergement;
- confirmer le SSL, les redirections et l’absence de blocage noindex;
- modifier les enregistrements DNS du site;
- purger les caches et suivre les erreurs sur les deux serveurs.
Documentez chaque action et son résultat plutôt que de vous fier à une estimation générique.
Contrôler le trafic et garder un retour arrière possible
Après la modification DNS, testez depuis plusieurs réseaux ou résolveurs : pages importantes, administration, formulaires, transactions, réponses HTTP et journaux. Un monitoring WordPress détecte une indisponibilité, mais ne remplace pas ces contrôles.
Surveillez aussi Search Console. Google indique que la fréquence d’exploration peut varier temporairement après un changement d’infrastructure. L’essentiel est que Googlebot obtienne des réponses rapides et valides.
Ne fermez pas l’ancien hébergement après un délai arbitraire. Retirez-le lorsque ses journaux ne montrent plus de trafic utile et que la cible est stable.
En cas d’incident majeur, rétablir l’ancienne cible DNS peut servir de retour arrière. Un TTL court accélère ce mouvement sans le rendre instantané pour tous les caches.
La maintenance WordPress après une migration ou une refonte prolonge ensuite la surveillance : erreurs applicatives, performances, indexation, formulaires, tâches planifiées et stabilité des sauvegardes.du nouveau site fonctionnent et que l’ancien serveur ne reçoit plus de trafic utile.
FAQ sur la migration WordPress sans interruption
Peut-on garantir zéro seconde d’interruption?
Non. La bascule peut souvent être invisible, mais elle dépend du DNS, du SSL, des deux serveurs et de la synchronisation. Un site transactionnel peut exiger une courte fenêtre contrôlée.
Quel TTL choisir avant une migration WordPress?
Choisissez une valeur basse acceptée par votre fournisseur et appliquez-la assez tôt pour laisser expirer les caches fondés sur l’ancienne valeur.
Faut-il changer les serveurs de noms?
Pas nécessairement. Si le fournisseur DNS reste le même, modifier les seuls enregistrements Web limite le risque. Un changement de serveurs de noms exige de vérifier toute la zone.
Combien de temps faut-il garder l’ancien hébergement?
Il n’existe pas de durée universelle. Gardez-le jusqu’à ce que ses journaux montrent que le trafic l’a quitté et que le nouveau serveur fonctionne correctement.
Les courriels sont-ils automatiquement migrés avec WordPress?
Non. Le site et le service de courriel peuvent être hébergés séparément. Vérifiez les enregistrements MX et la responsabilité de la migration avant de modifier la zone DNS.
Conclusion
Migrer WordPress sans interruption repose surtout sur la préparation. Deux serveurs fonctionnels, un TTL réduit en avance, un SSL prêt, une synchronisation finale et une surveillance active limitent fortement le risque de coupure visible.
Pour un site transactionnel, construisez la fenêtre autour des données réelles et d’un plan de retour arrière. Vous préparez un changement d’hébergeur? Vous pouvez parler à un expert CapsuleWeb pour obtenir un plan de bascule adapté, sans promesse générique.