Pour migrer WordPress vers LiteSpeed, copiez les fichiers et la base sur un hébergement compatible, testez cette copie avant de modifier le DNS, puis ouvrez les écritures sur un seul serveur. Installer LiteSpeed Cache ne réalise pas ce transfert. Le point décisif concerne les données créées pendant l'opération : commandes, formulaires, comptes et médias peuvent diverger si les deux versions du site restent actives. Cette méthode vise un WordPress simple conservant son domaine et ses URL, avec accès aux fichiers, à la base et à la zone DNS. Une boutique exige une fenêtre de gel des écritures ; le multisite demande un plan spécifique. L'objectif est une bascule vérifiable, avec un retour arrière qui préserve les nouvelles données.
À retenir
Validez la copie avant le DNS, utilisez un seul cache de page et gardez une seule base ouverte aux écritures. Un affichage correct de l'accueil ne valide pas une migration.
Sommaire : Préparer · Sauvegarder · Tester · Vérifier le cache · Basculer · Revenir en arrière
| Point de contrôle | Preuve attendue avant ouverture |
|---|---|
| Copie | Fichiers et base restaurés, médias accessibles |
| Destination | IP cible confirmée, HTTPS valide pour le domaine |
| Cache public | Réponse HIT sur une page anonyme éligible |
| Données privées | Panier, compte et paiement restent propres à chaque session |
| Écritures | Source gelée, dernières données transférées |
| Retour | État sauvegardé et procédure de récupération des nouvelles données |
1. Préparer le périmètre pour migrer WordPress
Une migration vers LiteSpeed change le serveur qui exécute WordPress ; elle ne nécessite pas de changer simultanément le domaine, le thème ou la version PHP. Avant de migrer WordPress, relevez PHP, les extensions PHP requises, la taille des fichiers, le volume SQL et les tâches planifiées. Notez aussi les connexions externes : SMTP, stockage distant, paiements et webhooks.
Choisissez un transfert assisté pour migrer WordPress si vous ne maîtrisez pas l'import SQL et la validation DNS. Chez Tomco, la migration gratuite d'un site est proposée à partir de l'offre Pro avec un engagement d'un an, selon le périmètre documenté sur la page hébergement web. Une offre de transfert ne dispense pas de définir les contrôles métier avec le responsable du site.
Pour migrer WordPress vous-même, préparez l'accès SFTP et l'outil d'administration SQL des deux hébergements. Confirmez que la cible dispose de LiteSpeed et de son moteur de cache : le nom du plugin ne constitue pas cette preuve. Réservez les optimisations avancées au travail d'optimisation des performances WordPress, après la bascule.
2. Sauvegarder puis restaurer une copie isolée
La sauvegarde préalable associe les fichiers du site et sa base de données dans un état cohérent. Pour migrer WordPress, l'export des articles depuis le menu Outils ne suffit pas : il ne remplace pas la copie des extensions, des réglages et des médias. La procédure officielle de migration WordPress distingue le déplacement à URL constante du changement d'adresse.
Téléchargez les fichiers, y compris les fichiers cachés utiles, puis exportez la base avec le gestionnaire SQL de votre hébergement. Conservez cette archive hors du répertoire public. Relevez son horodatage et vérifiez qu'elle se décompresse ; le vrai test consiste à restaurer la base et les fichiers sur la cible. Un export produit pendant des écritures concurrentes peut nécessiter une méthode de sauvegarde cohérente adaptée au moteur SQL.
Créez une base distincte sur la cible, importez le SQL puis adaptez ses identifiants dans wp-config.php. Ne laissez jamais la copie de test écrire dans la base de production. Gardez home et siteurl inchangés si domaine, protocole et chemin restent identiques. Un remplacement SQL global improvisé peut casser les valeurs sérialisées.
Tomco conserve les sauvegardes quotidiennes 90 jours, comme indiqué dans ses caractéristiques techniques. Cette profondeur de rétention ne remplace ni l'export final avant transfert ni un test de restauration. Pour migrer WordPress proprement, gardez la copie externe jusqu'à la fin de la recette et à la vérification de la première sauvegarde cible.
3. Tester le serveur cible avant le DNS
Un test avant DNS envoie une requête au nouveau serveur tout en conservant le domaine attendu par HTTPS et WordPress. Cela permet de migrer WordPress sans exposer une copie non validée. Le certificat du domaine doit déjà être utilisable sur la cible ; organisez son installation avec l'hébergeur avant la bascule.
Avec curl, remplacez le domaine et l'IP de documentation par vos valeurs :
SITE_HOST='www.example.com'
TARGET_IP='192.0.2.10'
curl --resolve "${SITE_HOST}:443:${TARGET_IP}" \
--silent --show-error --fail \
--dump-header - --output /dev/null \
--write-out 'IP=%{remote_ip} HTTP=%{http_code}\n' \
"https://${SITE_HOST}/"L'option --resolve, décrite dans la documentation curl, ne change que la résolution de cet appel. Vérifiez l'IP affichée, le statut HTTP et les éventuelles redirections. Si le site redirige vers le domaine sans www, testez aussi ce nom avec sa propre entrée. N'ajoutez pas --insecure pour faire disparaître une erreur TLS : corrigez le certificat.
Pour la recette navigateur, utilisez une résolution locale contrôlée ou l'aperçu HTTPS proposé par l'hébergeur. Protégez la copie contre l'accès public. Désactivez ses envois réels d'e-mails, ses tâches planifiées et les paiements de production pendant les essais. Tester avant de migrer WordPress signifie parcourir connexion, recherche, formulaires, images, liens permanents et achat en environnement de test, pas seulement l'accueil.
Vérifiez les URL canoniques et l'absence de domaine temporaire dans les liens. Une page doit conserver son adresse et répondre avec le statut attendu. Préparez le retrait des protections de préproduction lors de l'ouverture, notamment une éventuelle directive noindex.
4. Activer LiteSpeed Cache et vérifier un HIT
Un cache HIT signifie que la réponse provient du cache ; un MISS indique qu'elle n'a pas été servie depuis ce cache. Pour migrer WordPress vers LiteSpeed, commencez avec le seul cache de page, sans cumuler minification, report JavaScript et autres transformations susceptibles de masquer un défaut.
Sur la copie cible, désactivez l'ancien plugin de cache de page avant d'activer LiteSpeed Cache. Suivez la vérification officielle de LSCache : une page publique éligible, consultée sans connexion, doit pouvoir renvoyer X-LiteSpeed-Cache: hit. Le cache objet Redis joue un autre rôle ; il ne remplace pas cette vérification.
Le test suivant réutilise les variables définies plus haut et effectue deux requêtes GET sans cookies :
for ATTEMPT in 1 2; do
curl --resolve "${SITE_HOST}:443:${TARGET_IP}" \
--silent --show-error --fail \
--dump-header - --output /dev/null \
--write-out 'HTTP=%{http_code} TTFB=%{time_starttransfer}s\n' \
"https://${SITE_HOST}/"
doneUn premier MISS suivi d'un HIT est cohérent ; deux HIT le sont aussi si la page était déjà chaude. Deux MISS imposent une recherche : exclusion, cookie, protection de préproduction, purge répétée ou configuration serveur. Retirez temporairement une protection uniquement dans un environnement à accès maîtrisé pour tester le cache anonyme. Un CDN peut émettre ses propres en-têtes ; ce test vise directement la cible.
Avant de migrer WordPress en production, contrôlez séparément panier, paiement et compte client avec deux sessions distinctes. Ces parcours ne doivent jamais diffuser les données privées d'une autre session. Un meilleur TTFB ne valide ni cette isolation ni le fonctionnement du paiement.
5. Basculer sans diviser les écritures
La bascule fiable maintient une seule base autorisée à recevoir commandes, comptes et formulaires. Pour migrer WordPress avec des données actives, une copie réalisée la veille est insuffisante : les nouvelles écritures doivent rejoindre la cible avant son ouverture.
Réduisez le TTL des enregistrements web assez tôt pour laisser expirer leur ancienne durée de cache. Par exemple, si le TTL actuel est de 24 heures, une réduction effectuée cinq minutes avant le transfert n'efface pas les réponses déjà conservées. Le TTL facilite la transition ; il n'assure pas une bascule simultanée de tous les visiteurs.
Au créneau convenu, bloquez les écritures sur la source, y compris celles des tâches et intégrations. Effectuez la synchronisation finale de la base et des médias, vérifiez-la, puis modifiez les enregistrements web concernés : A, AAAA si utilisé, et nom avec www. Conservez MX et TXT si la messagerie reste en place.
L'ancienne origine doit rester en maintenance pour les visiteurs qui la joignent encore, ou transférer leurs requêtes vers la cible par un mécanisme configuré et testé. Une redirection vers le même domaine ne corrige pas un cache DNS ancien. Ouvrez ensuite la cible, réactivez les services nécessaires uniquement là et vérifiez les notifications de paiement. Migrer WordPress ne doit pas déclencher deux fois les mêmes tâches.
6. Surveiller et préparer le retour arrière
Le retour arrière dépend des données reçues après la bascule, pas seulement de l'état du DNS. Avant de migrer WordPress, définissez qui décide d'arrêter l'opération, quels parcours bloquent l'ouverture et comment récupérer les nouvelles commandes.
Si la cible n'a encore reçu aucune écriture, revenir à la source intacte reste simple, sous réserve du délai DNS et de la réouverture contrôlée. Si elle a déjà reçu des commandes, ne restaurez pas aveuglément l'ancienne base : bloquez les écritures, sauvegardez l'état cible et faites rapprocher les données avant de choisir l'origine active. Un import complet de l'ancienne base effacerait les nouveautés.
Après avoir fait migrer WordPress, inspectez les erreurs PHP, les réponses 5xx, les redirections, les e-mails et une transaction complète dans le mode adapté au service. Comparez le TTFB dans les mêmes conditions réseau et de cache, sans attribuer un gain universel à LiteSpeed. Pour migrer WordPress jusqu'au bout, consignez l'heure, l'IP active, la dernière commande contrôlée et la première sauvegarde restaurable. Résiliez l'ancien hébergement seulement après cette recette et la récupération des services encore utilisés.
