Pour migrer un site WordPress vers un autre hébergement, préparez une copie complète des fichiers et de la base, transférez-la sur la destination, puis testez-la avant de modifier le pointage du domaine. La bascule doit aussi préserver les demandes ou commandes reçues depuis la première copie et le fonctionnement de vos e-mails.
Le transfert ne s’arrête pas à la copie
- 01Préparer
Accès, sauvegarde et périmètre
- 02Transférer
Fichiers et base vers la destination
- 03Tester
Pages et parcours avant ouverture
- 04Basculer
Données finales, DNS et contrôles
Ce guide concerne un WordPress auto-hébergé existant, d’abord avec le même domaine et les mêmes adresses de pages. Une partie distincte traite le changement de domaine. Une migration Divi 5, une refonte graphique ou la conversion d’un autre CMS sont d’autres projets.
Quel type de migration WordPress préparez-vous ?
Commencez par décrire ce qui change. Déplacer un site ne nécessite pas toujours de modifier ses URL ni de transférer son nom de domaine. Le domaine peut rester chez son fournisseur actuel pendant que le site change d’hébergement.
| Votre situation | Ce qui change | Le point à préparer |
|---|---|---|
| Nouvel hébergement, même domaine | Le serveur qui répond pour le site. | Copie, compatibilité, pointage DNS et messagerie. |
| Nouveau domaine ou nouvelles URL | L’adresse utilisée par les visiteurs et les moteurs. | Correspondance des pages, liens et redirections. |
| Copie pour travailler à part | Un environnement de test est ajouté. | Protection de la copie et isolation des opérations réelles. |
Si vous souhaitez seulement essayer une extension ou préparer un changement de menu, utilisez plutôt un site de test WordPress. Il n’est pas nécessaire de déménager le site public pour chaque intervention.
Évitez de tout changer en même temps. Un nouveau serveur, un nouveau domaine et un nouveau design compliquent le diagnostic si un problème apparaît. Séparez les opérations quand le projet le permet.
Que préparer avant de transférer le site ?
Identifiez la source et la destination sans vous fier uniquement au nom des dossiers. L’objectif est de savoir ce que vous copiez, où vous l’installez et ce qui doit rester actif pendant l’opération.
Les informations à rassembler
- Les accès : administration WordPress, hébergements, fichiers, base et gestion DNS. Transmettez les secrets par un moyen sécurisé, pas dans un brief public.
- La sauvegarde : fichiers et base cohérents, datés, récupérables indépendamment du seul serveur source.
- La destination : espace disponible, versions PHP et base compatibles, certificat HTTPS et limites de transfert.
- Les services liés : e-mails, formulaires, paiement, CRM, tâches planifiées, CDN et sauvegardes externes.
- Les responsabilités : qui réalise le transfert, valide les tests et décide la bascule ou son report.
Le guide pour sauvegarder et restaurer WordPress détaille la copie complète. Un export XML d’articles ne remplace pas les fichiers, les extensions, les réglages et la base nécessaires au fonctionnement du site.
Repérer les données qui continuent d’arriver
Sur un site vitrine, ce peuvent être des modifications de contenu et des demandes enregistrées par formulaire. Sur une boutique, ajoutez les commandes, paiements, comptes et stocks. La copie du matin n’intègre pas automatiquement l’activité de l’après-midi.
- Où vivent ces données ? Dans WordPress, une boîte mail ou un service externe.
- Peut-on interrompre leur création ? Définir une fenêtre ou une méthode de synchronisation adaptée.
- Comment vérifier leur conservation ? Préparer un contrôle avant et après transfert.
Si vous ne maîtrisez pas ces accès ou les données à préserver, faites cadrer l’intervention avant de lancer l’import. Une assistance WordPress ponctuelle permet d’examiner le besoin et les contraintes, sans assimiler chaque transfert à une refonte complète.
Hébergeur, extension ou migration manuelle : quelle méthode choisir ?
Choisissez selon les accès disponibles et le fonctionnement du site, pas seulement selon la promesse « en un clic ». Un transfert annoncé comme terminé n’est pas encore une recette du site.
| Méthode | Intérêt | À vérifier |
|---|---|---|
| Service du nouvel hébergeur | Une équipe ou un outil prend en charge le transfert. | Éligibilité, périmètre, données récentes, DNS et e-mails réellement compris. |
| Extension de migration | Copie et import guidés depuis WordPress. | Compatibilité, taille, stockage, limites de licence et destination écrasée. |
| Fichiers et base transférés manuellement | Contrôle précis du déplacement et de la configuration. | Compétences serveur, configuration, remplacement des URL si nécessaire et procédure de reprise. |
Avec une extension, utilisez la procédure de son éditeur pour votre version. Vérifiez si elle importe dans une installation vide ou remplace une installation existante. Un outil de clonage, un outil de sauvegarde et un outil de synchronisation ne proposent pas forcément les mêmes fonctions.
Trois questions avant d’accepter une migration incluse
- Le prestataire transfère-t-il uniquement WordPress ou aussi les boîtes mail ?
- Qui contrôle les formulaires et les fonctions spécifiques après la copie ?
- Qui gère la dernière synchronisation et le pointage du domaine ?
La méthode manuelle est documentée par WordPress. Elle reste technique : n’improvisez pas des modifications de base ou de configuration sur le site public pour contourner un import qui échoue.
Comment transférer et tester WordPress avant la bascule ?
Préparez d’abord une destination qui ne contient rien à conserver, ou dont le remplacement est expressément prévu. Ne lancez pas une restauration sur un autre site actif par erreur.
La progression à suivre
- Créer la copie de départ. Relever son horodatage et vérifier la présence des fichiers et de la base attendus.
- Préparer la destination. Créer l’environnement et les accès nécessaires selon la méthode retenue ; vérifier ressources et compatibilité.
- Importer les éléments. Utiliser le service ou l’extension choisis. En manuel, transférer les fichiers, importer la base et adapter la connexion dans
wp-config.php. - Ouvrir la copie sans changer le pointage public. Employer la prévisualisation prévue par l’hébergeur ou une méthode de test encadrée.
- Comparer avec le site source. Examiner les pages importantes, médias, menus, administration et fonctions propres au projet.
Une prévisualisation peut utiliser une adresse temporaire ou une résolution locale du domaine. La seconde méthode conserve l’adresse habituelle mais ne modifie la destination que pour le poste configuré. Elle ne prouve pas que tous les visiteurs arrivent déjà sur le nouveau serveur. Faites préciser la méthode adaptée à votre hébergement et au HTTPS.
Tester sans provoquer de vraies opérations
La copie peut garder les identifiants et connexions de la production. Avant un test, vérifiez les destinataires des e-mails, paiements, webhooks et synchronisations. Gardez aussi son accès protégé et son indexation maîtrisée.
- Un formulaire : utiliser un destinataire de test prévu, puis contrôler la réception.
- Une boutique : vérifier le mode de test du prestataire de paiement et les notifications.
- Un service externe : empêcher les écritures ou envois réels involontaires.
Les précautions et le transfert des changements sont détaillés dans le guide Site de test. Pour cette migration, notez le résultat des tests sur la destination et les écarts à corriger avant ouverture.
Comment basculer sans oublier les données récentes et les e-mails ?
La destination testée représente un état du site, pas nécessairement son dernier état. Définissez comment récupérer les nouveautés et qui peut encore écrire sur chaque installation pendant le changement.
Une copie peut devenir ancienne avant son ouverture
Fichiers et base sont transférés pour les essais.
Des contenus, demandes ou commandes peuvent arriver.
Synchronisation cadrée ou pause des écritures, puis contrôle.
Organiser la dernière copie et le DNS
- Prévoir la fenêtre de bascule. Éviter les périodes sensibles et informer les personnes qui publient ou administrent le site.
- Définir les écritures autorisées. Une pause peut convenir à certains sites ; les transactions et services externes exigent un plan spécifique. Le mode maintenance ne synchronise pas les données à lui seul.
- Effectuer la synchronisation finale prévue. Conserver les travaux et données qui ne doivent pas être écrasés, puis retester les points concernés.
- Modifier le pointage dans la bonne zone DNS. Mettre à jour les enregistrements du site requis par la destination, sans remplacer aveuglément toute la zone.
- Contrôler où arrivent les requêtes. Le cache DNS de certains résolveurs peut conserver l’ancienne destination ; surveiller les deux environnements pendant cette transition.
Une modification de serveurs de noms peut déplacer l’ensemble de la gestion DNS. Un changement d’enregistrement du site n’a pas le même périmètre. Préservez les enregistrements utilisés par la messagerie, notamment MX et les réglages d’authentification nécessaires, sauf migration mail prévue séparément.
Un domaine, deux services à distinguer
Après ouverture, testez l’envoi des formulaires et la réception des messages. Si le site s’affiche mais que les demandes n’arrivent plus, le guide WordPress n’envoie pas de mail permet de distinguer l’envoi depuis le site de la réception dans la boîte.
Que faire si le domaine ou les URL changent ?
Le déménagement technique et le changement d’adresse sont deux sujets distincts. Si vous conservez exactement les URL, vous n’avez pas à créer des redirections uniquement parce que le serveur change. Si elles changent, préparez une correspondance vers les pages pertinentes, pas un renvoi général vers l’accueil.
Exemple pédagogique de correspondance d’URL
ancien.example/services/↓Nouvelle page équivalentenouveau.example/services/Redirection permanente directeancien.example/offre-arretee/↓Pas de destination pertinenteRéponse 404 ou 410 adaptée
Pas de redirection artificielle vers l’accueil.
Préparer les adresses avant de lancer le remplacement
Inventoriez les pages et médias utiles, puis vérifiez les liens internes et les réglages du site. Un remplacement brut dans un export SQL peut endommager des données sérialisées. Utilisez une méthode compatible avec WordPress, une sauvegarde et un essai préalable ; ne changez pas indistinctement tous les champs contenant l’ancien domaine.
- Les liens : menus, boutons, contenus, médias et connexions externes utilisent les adresses attendues.
- Les moteurs : canonical, sitemap et consignes robots correspondent à la nouvelle version publique.
- Les anciennes URL : leur réponse et leur destination sont vérifiées, sans boucle ni chaîne évitable.
Les consignes de migration de Google expliquent ce suivi. Pour un changement de domaine concerné par l’outil de changement d’adresse de Search Console, vérifiez ses conditions et les propriétés avant utilisation. Une simple bascule d’hébergeur ne demande pas cette déclaration.
Personne ne peut garantir un trafic strictement identique après une migration. Préparez un état des URL et de leurs performances avant l’opération, puis comparez les données ensuite. Une page accessible, une page indexable et une page effectivement indexée sont trois constats différents.
Que vérifier après migration et quand arrêter l’ancien hébergement ?
La vérification se fait sur l’adresse publique réelle, sans session administrateur, puis dans l’administration et les services concernés. L’accueil qui s’ouvre ne prouve pas que les demandes ou commandes fonctionnent.
La recette de la destination publique
- Pages et médias : accueil, prestations, pages intérieures, images, documents et liens importants.
- Parcours : formulaire réellement reçu, connexion et fonctions particulières ; paiement selon un protocole adapté si concerné.
- HTTPS : certificat valide pour les domaines servis et absence d’éléments essentiels chargés depuis une adresse incorrecte.
- Visibilité : protection de test et exclusions involontaires retirées uniquement sur les contenus publics attendus.
- Données : dernières modifications et opérations conservées, absence d’écritures oubliées sur l’ancien serveur.
- Suivi : sauvegardes, tâches planifiées, envois et outils de mesure vérifiés sur le nouvel environnement.
Si le certificat bloque l’accès, commencez par identifier le message et le domaine concernés avec le guide problème de certificat SSL WordPress. Ne contournez pas une alerte de sécurité pour déclarer le site opérationnel.
Ne résiliez pas sur la seule base d’un écran réussi
Conservez l’ancien environnement le temps nécessaire au plan de transition : destination validée, résolution DNS contrôlée, données réconciliées et services dépendants identifiés. Un délai fixe ne convient pas à tous les sites.
- Avant l’arrêt : récupérer une copie indépendante et préserver les éléments utiles.
- Avant la résiliation : vérifier si domaine, messagerie ou autres sites dépendent du même contrat.
- Après : organiser la suppression des copies devenues inutiles et la fermeture des accès temporaires.
Si le domaine change, ne confondez pas arrêt de l’ancien hébergement et abandon de l’ancien domaine : les redirections doivent rester servies selon le dispositif prévu. Le guide indexation WordPress aide à lire les contrôles moteurs sans assimiler une soumission de sitemap à une indexation obtenue.
Que faire si la migration ne fonctionne pas ?
Relevez l’URL, le moment, le message et la destination réellement consultée. Ne relancez pas des imports successifs sans savoir ce que le précédent a remplacé. Gardez les journaux et un état récupérable avant de corriger.
| Le symptôme | Premier contrôle | Précaution |
|---|---|---|
| Connexion à la base impossible | Nom de base, utilisateur, hôte et import sur la bonne destination. | Ne pas modifier les accès de la source par confusion. |
| Ancienne version encore visible | Résolution DNS, serveur atteint et caches concernés. | Identifier la couche avant de purger ou de réimporter. |
| Images ou liens cassés | Présence des fichiers, chemins et adresses enregistrées. | Pas de remplacement global non vérifié dans la base. |
| Site visible, formulaire sans réception | Configuration d’envoi, destinataire et traces de livraison. | Une confirmation affichée ne prouve pas la réception. |
| Erreur serveur ou page indisponible | Journaux, compatibilité et différence avec la source. | Ne pas désactiver toutes les protections au hasard. |
Exemple : revenir en arrière sur une boutique
Situation fictive, sans résultat client : une commande a été reçue sur le nouveau serveur avant qu’un problème de paiement soit repéré. Revenir au serveur source sans récupérer cette commande peut la faire disparaître de l’administration visible.
La décision porte sur les données autant que sur le DNS : suspendre les écritures si nécessaire, identifier les opérations des deux côtés, puis choisir la reprise et la vérifier. Une simple remise de l’ancienne adresse IP ne réconcilie pas les deux bases.
En cas d’incident public, présentez le symptôme et les dernières actions effectuées pour cadrer le dépannage du site internet. La correction doit viser la cause observée, pas effacer les données récentes pour retrouver un écran qui s’affiche.
Questions fréquentes sur la migration WordPress
Peut-on migrer WordPress gratuitement ?
Un hébergeur peut inclure un transfert et une extension peut proposer des fonctions gratuites. Vérifiez le périmètre, les limites de taille, les licences et les services exclus. Cela ne rend pas gratuits l’hébergement, la préparation ou les contrôles. Un devis peut être nécessaire pour un site particulier.
Combien de temps faut-il prévoir ?
Le temps de copie dépend notamment du volume, des accès et des limites des serveurs. Ajoutez préparation, essais, synchronisation finale et contrôle du pointage. La durée de travail n’est pas la durée d’interruption ; elle doit être évaluée pour votre site, sans promesse universelle.
Faut-il transférer le domaine chez le nouvel hébergeur ?
Pas obligatoirement. Le fournisseur du domaine, l’hébergeur du site et le fournisseur de messagerie peuvent être différents. Il faut disposer des accès à la zone DNS réellement utilisée et savoir quels enregistrements changer. Un transfert de domaine est une opération distincte.
Peut-on utiliser cette procédure pour un multisite ?
Ne l’appliquez pas comme une recette automatique. Un réseau WordPress multisite peut avoir des contraintes de domaines, de tables et de chemins spécifiques. Vérifiez la compatibilité de l’outil et une procédure dédiée avant de déplacer le réseau ou un site isolé.
Préparer votre migration avec un périmètre clair
Commencez par une fiche de transfert courte : site source, destination, domaine conservé ou non, fonctions sensibles et personne qui valide. Ce cadrage permet de choisir une méthode avant de toucher à la production.
Un exemple de demande à adapter
Exemple fictif : « Je souhaite déplacer mon site vitrine vers un nouvel hébergeur en conservant le domaine. Il comporte un formulaire et des articles. La messagerie reste chez son fournisseur actuel. Pouvez-vous préciser la copie, les tests, le pointage et les contrôles compris dans l’intervention ? »
Vous souhaitez déléguer cette opération ? Présentez le périmètre dans une demande d’assistance WordPress. Pour le suivi après transfert, la maintenance WordPress est un accompagnement distinct, à définir selon les besoins du site. Parlons de votre transfert.
