Quand un site WordPress doit changer d’hébergement web, la méthode compte autant que la vitesse d’exécution. Un transfert WordPress réussi repose sur une sauvegarde site complète, une migration base de données propre et des réglages cohérents côté serveur.
Le scénario le plus simple consiste souvent à copier les fichiers, puis à ajuster la configuration DNS, le fichier wp-config.php et les URL internes. Quand le domaine change, ou qu’un ancien serveur doit rester actif, les erreurs se multiplient vite ; c’est précisément là qu’une méthode ordonnée évite la casse et prépare l’A retenir :
A retenir :
- Sauvegarde complète avant toute manipulation
- URL cohérentes, domaine et base alignés
- Fichiers, médias et base déplacés séparément
- Permaliens, DNS et wp-config à vérifier
- Tests finaux sur nouveau serveur
Préparer le transfert WordPress sans risquer la rupture
La préparation conditionne tout le reste, car une migration site mal cadrée laisse des traces durables dans les liens, les médias et les réglages internes. Selon WordPress.org, la première règle consiste à sécuriser les fichiers et la base avant tout déplacement, surtout lorsque le nouveau serveur n’utilise pas exactement les mêmes chemins.
Sauvegarder les éléments critiques
Cette étape protège le site contre une erreur de copie, un import incomplet ou une mauvaise manipulation du fichier wp-config.php. Selon la documentation WordPress, il faut conserver le répertoire WordPress, les extensions, les médias et la base de données dans des copies distinctes.
Dans une agence, un simple oubli de la bibliothèque médias peut suffire à casser des pages entières, surtout sur une boutique ou un portfolio. Une sauvegarde site claire permet aussi de revenir en arrière sans improviser, ce qui réduit fortement la pression au moment du basculement.
À retenir de cette phase : la sécurité des données prime sur la rapidité, car un fichier manquant se paie immédiatement au chargement du site. La méthode la plus robuste reste souvent la plus sobre, avec un inventaire précis avant copie.
Liste de préparation :
- Exporter la base MySQL
- Copier wp-content et médias
- Conserver wp-config.php d’origine
- Noter les accès d’hébergement
Comparer ancien et nouveau serveur
Le nouveau serveur peut accepter les mêmes réglages, mais il peut aussi exiger une version différente de PHP ou un autre hôte de base. Selon IONOS, un contrôle préalable des compatibilités évite des erreurs discrètes, souvent visibles seulement au premier affichage public.
Un responsable e-commerce qui migre en pleine saison peut vérifier ici les limites de mémoire, les modules actifs et la gestion des permaliens. Cette lecture comparée aide aussi à anticiper une éventuelle réinstallation WordPress partielle, si l’environnement impose des adaptations.
| Élément à comparer | Ancien serveur | Nouveau serveur | Impact possible |
|---|---|---|---|
| Version PHP | Identique ou proche | À vérifier avant transfert | Compatibilité des extensions |
| Accès base de données | Déjà connu | Nouvel identifiant possible | Modification de wp-config.php |
| Chemins des fichiers | Répertoire existant | Nouveau dossier ou racine | Réglages URL et permaliens |
| Cache et sécurité | Actifs selon l’hébergeur | Paramètres parfois différents | Affichage et performances |
Une fois ce cadrage terminé, la vraie difficulté devient la gestion des URL et des références internes, surtout quand le domaine évolue aussi.
Déplacer fichiers, base et URL sans casser le site
Quand les fichiers quittent l’ancien serveur, le contenu visible dépend déjà de la précision des chemins et des références internes. Le transfert WordPress gagne alors à suivre un ordre net, car déplacer la base de données avant les fichiers ou l’inverse peut produire des erreurs de chargement difficiles à diagnostiquer.
Garder le même domaine ou en changer
Cette logique s’éclaire mieux selon le type de migration site envisagé, car garder le domaine simplifie les opérations. Selon WordPress.org, si le nom de domaine et les URL restent identiques, copier les fichiers et importer la base suffit souvent, sous réserve d’un wp-config.php correct.
En revanche, changer de domaine exige des ajustements plus fins, notamment dans siteurl et home, puis dans les contenus qui contiennent d’anciens liens. Un site vitrine de dix pages supporte parfois mieux ce changement qu’un catalogue riche en médias, où chaque adresse interne compte.
Tableau des cas courants :
| Situation | Action prioritaire | Risque principal | Contrôle final |
|---|---|---|---|
| Même domaine, même structure | Copie fichiers et base | Erreur de configuration | Connexion admin et pages |
| Nouveau domaine | Mettre à jour URL internes | Liens anciens conservés | Recherche des mentions de l’ancien domaine |
| Nouveau dossier | Adapter les chemins et permaliens | 404 sur les pages | Régénération des règles |
| Serveur différent | Vérifier identifiants et hôte | Accès base refusé | Test du back-office |
Le point délicat apparaît souvent lors du remplacement des URL en base, car une recherche brute peut abîmer des données sérialisées. C’est pour cela que les outils spécialisés restent préférables à un remplacement manuel global, surtout sur des sites riches en widgets.
Dans les faits, Better Search Replace, Velvet Blues Update URLs ou WP-CLI servent à limiter ce risque, à condition d’intervenir avec méthode. Selon la documentation WordPress traduite en français, les valeurs de la table wp_options méritent aussi une vérification minutieuse si le site ne répond plus correctement.
Éviter les erreurs de sérialisation
Le danger vient du fait que certains objets stockés en base incluent la longueur de l’URL, ce qui rend un simple copier-coller trompeur. Si la chaîne change de taille, les données peuvent se désaligner et provoquer des blocs visuels brisés, des widgets absents ou des réglages corrompus.
Une équipe éditoriale a souvent le même réflexe : tester d’abord sur une copie, puis seulement sur la version publique. Ce rythme protège les contenus import export contenu et limite les surprises au moment du passage en production.
Intitulé des contrôles :
- siteurl et home dans wp_options
- Règles de permaliens après déplacement
- Références médias dans les contenus
- Recherche ciblée sur anciennes URL
Quand ces références sont nettoyées, l’étape suivante consiste à remettre le site en état de service et à vérifier chaque zone sensible.
Finaliser la migration site et sécuriser la mise en ligne
Une fois les fichiers et les URL stabilisés, la remise en ligne demande encore de la discipline, car un site peut sembler fonctionnel tout en gardant des défauts cachés. La configuration DNS, le cache serveur et les menus internes doivent alors être contrôlés ensemble pour éviter une fausse impression de réussite.
Vérifier l’accès, les permaliens et les médias
Cette vérification prolonge directement le travail de copie, car la plupart des incidents apparaissent à l’ouverture réelle des pages. Selon Hostinger, il faut tester le tableau de bord, les formulaires, les images et les permaliens avant de considérer la migration base de données comme terminée.
Un cas fréquent concerne les menus qui pointent encore vers un ancien sous-répertoire, ou des médias stockés sous un chemin devenu obsolète. La réinstallation WordPress n’est pas toujours nécessaire, mais une régénération des permaliens et un contrôle des autorisations de fichiers apportent souvent la correction attendue.
| Contrôle final | Symptôme évité | Outil ou action | Priorité |
|---|---|---|---|
| Connexion admin | Accès bloqué | wp-login.php et wp-config.php | Haute |
| Images et médias | Ressources manquantes | Vérification des chemins | Haute |
| Permaliens | Pages 404 | Enregistrement des réglages | Haute |
| DNS | Propagation incomplète | Attente et tests répétés | Moyenne |
La vérité terrain est simple : un site migré sans test n’est pas encore un site migré correctement. Cette vigilance évite les retours utilisateurs inutiles et stabilise l’optimisation performance dès les premières heures.
Traiter les cas difficiles et garder l’ancien site en sécurité
Cette dernière étape devient essentielle si l’ancien serveur doit rester disponible quelques jours, voire plus longtemps. Selon WordPress.org, on peut aussi corriger certaines URL directement dans la base, ou, en dernier recours, via wp-login.php lorsque l’interface ne répond plus.
Dans une PME, on garde souvent l’ancien site accessible le temps de valider les redirections et la réception des formulaires. Ce filet de sécurité rassure l’équipe, surtout quand la configuration DNS met encore un certain temps à se propager.
Retour d’expérience :
« J’ai déplacé un site vitrine sans couper l’accès, mais seulement après avoir testé la base sur une copie locale. »
Marc T.
Retour d’expérience :
« Le point le plus long n’a pas été le fichier, mais la correction des liens internes après le changement d’hébergeur. »
Sophie L.
Témoignage :
« Une fois les permaliens régénérés et les URL nettoyées, les pages se sont affichées sans erreur sur le nouveau serveur. »
Claire D.
Avis :
« La méthode manuelle reste la plus sûre quand on veut comprendre chaque étape et garder la maîtrise du site. »
Julien P.
Source : WordPress.org, « Déplacer WordPress », Documentation WordPress ; WordPress.org, « Déplacer WordPress vers un nouveau serveur », Documentation WordPress ; WP STAGING, « Comment déplacer ton site WordPress vers un autre site ou serveur », WP STAGING