Changer d’hébergeur WordPress en limitant la coupure pour les visiteurs
Changer d’hébergeur ne se limite pas à copier des fichiers : la base WordPress contient des données sérialisées qui encapsulent des URL, et un remplacement mal fait les corrompt silencieusement. Voici la méthode que je suis, du premier export jusqu’à la bascule DNS finale.
Ce que le remplacement d’URL touche en profondeur
WordPress enregistre une partie de ses réglages (options de thème, configuration de widgets, préférences de plugins) sous forme de données PHP sérialisées dans des colonnes texte de la base MySQL. Une chaîne sérialisée encode la longueur exacte de chaque sous-chaîne qu’elle contient : par exemple, s:22:"https://ancien-site.fr" signifie « une chaîne de 22 caractères, dont voici le contenu ». Si le site en test ou de destination utilise une URL différente (adresse temporaire, sous-domaine, IP), et qu’on la remplace par un simple UPDATE SQL avec REPLACE(), le nombre déclaré avant les guillemets ne correspond plus à la nouvelle longueur de chaîne.
Ce n’est pas un cas marginal : sur une boutique WooCommerce, l’adresse de l’ancien site peut apparaître dans des dizaines d’enregistrements sérialisés différents (réglages de passerelle de paiement, widgets de panier, préférences d’extensions de livraison), chacun potentiellement corrompu par un remplacement brut. C’est ce volume dispersé qui rend le problème difficile à détecter à l’œil nu avant qu’un client ne signale un dysfonctionnement précis.
WordPress échoue alors à désérialiser correctement la donnée : réglages de thème réinitialisés à leurs valeurs par défaut, widgets qui disparaissent de la colonne latérale, options de plugin vides, souvent sans message d’erreur visible avant plusieurs jours. La bonne méthode passe par un outil qui recalcule ces longueurs à chaque remplacement, typiquement la commande wp search-replace ancienne-url nouvelle-url --all-tables de WP-CLI.
Comment je change d’hébergeur sans coupure visible
-
Copie des fichiers et de la base
Je copie l’intégralité des fichiers du site et un export complet de la base de données vers le nouvel hébergement, sans toucher au site en production.
-
Adaptation de wp-config.php
Je renseigne les nouveaux identifiants de connexion à la base de données (nom, utilisateur, mot de passe, hôte) dans wp-config.php sur le nouvel environnement.
-
Correction des URL avec wp search-replace
Si le site de test est accessible sous une adresse différente (sous-domaine temporaire, IP), je corrige les URL enregistrées avec wp search-replace, qui recalcule les longueurs des chaînes sérialisées au lieu de les casser.
-
Validation via le fichier hosts local
Je teste le site sur le nouvel hébergement en modifiant temporairement le fichier hosts de ma machine, ce qui permet de pointer vers le nouveau serveur sans modifier le DNS public ni affecter les visiteurs.
-
Réduction du TTL DNS en amont
Quelques jours avant la bascule, je réduis le TTL (durée de vie) des enregistrements DNS pour accélérer la propagation du changement le moment venu.
-
Bascule DNS ou serveur à faible trafic
Je programme le changement de pointage à un horaire de faible fréquentation, et je reprends les commandes ou messages reçus entre la copie initiale et la bascule finale si le site vend en ligne.
Pour aller plus loin
-
Changer de nom de domaine sans perdre son référencement
Le même mécanisme de sérialisation s’applique, avec en plus la gestion des redirections 301 vers le nouveau domaine.
-
Passer un site WordPress en HTTPS
Un changement d’URL de même nature, du protocole cette fois, qui suit la même logique de correction.
-
Choisir un hébergement pour de l’e-commerce
Les critères que je vérifie avant de recommander un hébergeur pour une boutique WooCommerce.
-
Comprendre la sérialisation PHP
La définition complète du mécanisme évoqué sur cette page.
Décrivez votre besoin en 1 minute
Quelques questions ciblées pour que je vous réponde avec une estimation, pas avec un questionnaire de plus.