Changer d'hébergeur ou de serveur un site WordPress

Un site WordPress change d'hébergeur ou de serveur pour de bonnes raisons : des performances insuffisantes, une offre trop chère, une version de PHP qui n'est plus maintenue, un besoin de sécurité ou de support. Le contenu ne change pas, mais tout ce qui le fait tourner déménage : les fichiers, la base de données, la configuration, le certificat. Bien mené, ce déménagement est invisible pour les visiteurs comme pour Google.

Cet article traite du déménagement d'un site qui est déjà sous WordPress. Si votre site n'y est pas encore, voyez nos articles sur la migration d'un site HTML vers WordPress et la migration de Wix vers WordPress.

Un site WordPress tient en deux parties, à déplacer ensemble :

• les fichiers : le cœur de WordPress, le dossier wp-content (thèmes, extensions, médias téléversés), le fichier wp-config.php et, sur Apache, le fichier .htaccess qui porte les permaliens et les redirections ;
• la base de données : articles, pages, réglages, comptes, commentaires, commandes s'il y a une boutique.

S'y ajoutent ce qui vit chez l'hébergeur et ne se copie pas : le certificat HTTPS, les tâches planifiées, les adresses électroniques du domaine, les règles du serveur web s'il s'agit de Nginx. Faites-en la liste avant de commencer.

Des extensions comme Duplicator ou All-in-One WP Migration rassemblent fichiers et base dans une archive, que l'on restaure sur le nouveau serveur. Beaucoup d'hébergeurs proposent aussi leur propre outil de migration. C'est la voie la plus simple pour un site de taille modeste ; sur un gros site, la taille de l'archive ou les limites du serveur peuvent la faire échouer.

On copie les fichiers par SFTP ou rsync, on exporte la base (mysqldump ou WP-CLI) et on l'importe sur le nouveau serveur, puis on met à jour wp-config.php avec les nouveaux identifiants de base. Si l'adresse du site change, le rechercher-remplacer se fait avec wp search-replace ou une extension qui respecte les données sérialisées : un remplacement brut dans le fichier SQL casse les réglages des thèmes et des extensions.

1. Sauvegardez le site complet, fichiers et base, et gardez-le hors des deux serveurs.
2. Testez le nouveau serveur avant de basculer : en faisant pointer le domaine vers la nouvelle adresse IP sur votre seul poste (fichier hosts), vous voyez le site tel qu'il sera, avec son vrai nom de domaine.
3. Baissez la durée de vie (TTL) des enregistrements DNS un ou deux jours avant, pour que le changement se propage vite.
4. Gelez les contenus pendant la bascule : un commentaire ou une commande reçus sur l'ancien serveur après la copie seraient perdus.
5. Changez les DNS, et laissez l'ancien serveur en ligne quelques jours, le temps que tous les visiteurs arrivent sur le nouveau.

Tant que les adresses des pages restent identiques, un changement d'hébergeur ne demande aucune redirection. C'est différent si vous profitez du déménagement pour changer de nom de domaine, passer en HTTPS ou modifier la structure des permaliens : chaque ancienne URL doit alors répondre par une redirection 301 vers la nouvelle, en un seul saut. Pour un changement de domaine, déclarez-le aussi dans la Search Console (outil de changement d'adresse). Voir notre article sur le passage au protocole HTTPS et celui sur les redirections dans WordPress.

Crawlez le site avant le déménagement et gardez la liste de ses URL avec leur code de réponse ; recrawlez-le après la bascule et comparez. Vérifiez aussi ce qui se perd le plus souvent :

• la case « Demander aux moteurs de recherche de ne pas indexer ce site », cochée sur le serveur de test et recopiée telle quelle ;
• le fichier robots.txt et le sitemap, qui doivent répondre sur le nouveau serveur ;
• le certificat HTTPS, installé et valide avant le changement de DNS ;
• les temps de réponse, qui étaient souvent la raison du déménagement : comparez-les.

Suivez ensuite la Search Console pendant quelques semaines : erreurs d'exploration, pages indexées, positions.

Si le déménagement s'accompagne d'une refonte ou d'un changement d'adresses, le plan de redirection devient l'enjeu principal. Swan crawle l'ancien site et la préproduction, propose pour chaque ancienne URL la page qui la remplace par proximité sémantique, vous fait valider les cas douteux, puis contrôle les redirections avant et après la mise en ligne. Les étapes communes à tout changement de plateforme sont décrites dans la procédure de changement de CMS.