Migrer un site WordPress - Guide Complet pour un Transfert Réussi

Ce que change vraiment un transfert de site WordPress

Je distingue toujours trois cas, parce qu’ils n’exigent pas le même niveau de vigilance: changement de serveur, changement de domaine ou les deux en même temps. Si vous ne changez que d’hébergement, le site peut parfois être déplacé sans toucher à ses URLs publiques. En revanche, dès que le domaine change, il faut gérer les liens internes, les médias, les paramètres WordPress et les redirections.

Une fois le périmètre clarifié, je peux préparer le chantier sans improviser, et c’est là que la plupart des problèmes se désamorcent avant même le transfert.

Préparer la migration sans prendre de risques

La préparation compte plus que la technique de copie elle-même. Avant de toucher au moindre fichier, je sécurise systématiquement trois choses: une copie complète du site, l’accès aux identifiants d’hébergement, et une vision nette de ce qui doit rester identique ou non après le transfert. Sur un site e-commerce ou un site à forte activité, je prévois aussi une fenêtre de gel pour éviter de perdre des commandes ou des contenus publiés pendant l’opération.

• Sauvegarder les fichiers du site, en particulier `wp-content`, les thèmes, les plugins et les uploads.
• Exporter la base de données complète, pas seulement les articles ou les pages.
• Noter la version de WordPress, du thème et des extensions critiques.
• Vérifier l’accès à phpMyAdmin, au panneau d’hébergement ou à WP-CLI.
• Prévoir le certificat SSL du nouveau domaine si l’URL change.
• Documenter les points sensibles: cache, SMTP, cron, CDN, formulaires, analytics.

J’insiste aussi sur un point souvent négligé: si votre site dépend d’intégrations tierces, il faut vérifier leurs réglages avant la bascule, sinon le site peut sembler intact mais cesser d’envoyer des emails, de remonter des commandes ou de publier correctement ses contenus. Avec cette base propre, on peut choisir la méthode la plus adaptée au contexte.

Migrer à la main ou avec un plugin

Je ne traite pas toutes les migrations de la même manière. Pour un petit site vitrine, un plugin de migration suffit souvent et permet de gagner du temps. Pour un site complexe, multilingue, WooCommerce ou très personnalisé, je préfère souvent une méthode plus contrôlée, quitte à passer par WP-CLI ou par une manipulation plus manuelle.

Dans la pratique, je vois souvent deux familles d’outils utiles: un cloneur complet comme Duplicator pour déplacer fichiers et base ensemble, puis un outil de remplacement d’URL comme Better Search Replace ou une commande WP-CLI pour finir le travail proprement. Le bon choix dépend surtout de la taille du site, de votre accès serveur et du niveau de contrôle que vous voulez garder.

Une fois la méthode choisie, le transfert suit presque toujours la même logique, et c’est ce déroulé qu’il faut exécuter sans sauter d’étapes.

Dérouler la migration pas à pas

Voici l’ordre que j’applique le plus souvent quand je dois déplacer un site proprement vers un nouveau serveur ou un nouveau domaine.

1. Mettre le site en sécurité: je fige les modifications si le site reçoit des contenus, des commandes ou des inscriptions en continu.
2. Faire une sauvegarde complète: fichiers, base de données, fichiers de configuration et, si possible, une copie stockée hors du serveur d’origine.
3. Préparer le nouvel environnement: nouveau serveur, nouvelle base de données, version PHP compatible, WordPress prêt à recevoir le contenu.
4. Copier les fichiers: je transfère l’arborescence du site, en gardant un œil particulier sur `wp-content`.
5. Importer la base de données: c’est elle qui contient les articles, les réglages, les menus, les widgets et une grande partie de la configuration.
6. Ajuster `wp-config.php` si nécessaire: si le nom de base, l’utilisateur ou le mot de passe changent, je corrige immédiatement ce fichier.
7. Remplacer les anciennes URLs: je fais un search/replace prudent sur le domaine ou le chemin, en évitant de casser les données sérialisées.
8. Rafraîchir les permaliens: j’enregistre à nouveau la structure des URLs pour régénérer les règles de réécriture.
9. Tester le site en privé: je contrôle la page d’accueil, les liens internes, les images, les formulaires, la connexion admin et les pages clés.

Si vous passez par WP-CLI, la commande de remplacement reste l’un des moyens les plus propres pour travailler sur une base volumineuse, parce qu’elle gère la sérialisation et permet un test préalable avec `--dry-run`. Le point important, ce n’est pas seulement de remplacer une chaîne: c’est de préserver l’intégrité des données pendant le remplacement.

Quand le site répond correctement sur le nouvel environnement, je passe aussitôt au nettoyage des URLs et des réglages sensibles, car c’est là que beaucoup de migrations semblent terminées alors qu’elles ne le sont pas vraiment.

Corriger les URL et les réglages sensibles

Le piège classique, c’est le site qui s’affiche mais qui conserve encore des traces de l’ancien domaine dans la base. On le voit dans les images, dans certains liens, dans les widgets, dans les réglages de thème, parfois même dans des scripts ou des blocs construits à la main. C’est aussi là qu’intervient la notion de données sérialisées: certaines chaînes stockées en base contiennent leur longueur exacte, donc un remplacement brutal peut les corrompre.

• `home` et `siteurl` doivent pointer vers la bonne adresse si le domaine a changé.
• Les URLs internes doivent être cohérentes partout, y compris dans les menus et les boutons.
• Le HTTPS doit être uniforme pour éviter le contenu mixte.
• Les médias doivent charger depuis le bon chemin, sans pointeur résiduel vers l’ancien hébergement.
• Les permaliens doivent être régénérés pour éviter les erreurs 404 sur les articles et les pages.
• Le cache et le CDN doivent être purgés, sinon vous testez parfois une ancienne version du site sans le savoir.

Je fais aussi attention à ne pas toucher au `guid` des contenus dans la base, sauf cas très particulier. Ce champ sert d’identifiant et ne doit pas être modifié à la légère. Dès que tout cela est propre, il devient possible de sécuriser l’impact SEO avant que les moteurs ne réévaluent le site.

Protéger le SEO pendant le changement de domaine

Un changement de domaine sans redirections sérieuses peut faire perdre une partie du trafic très vite. C’est pour cela que je recommande systématiquement des redirections 301 page par page, ou au minimum par gabarit logique, plutôt qu’un simple renvoi de tout le site vers la page d’accueil. Une redirection propre dit aux moteurs de recherche qu’une page a changé d’adresse de manière permanente, ce qui aide à transférer la valeur SEO.

• Rediriger les anciennes URLs vers les pages les plus proches du nouveau site.
• Mettre à jour le sitemap XML et le soumettre à nouveau dans les outils de suivi.
• Vérifier les balises canonical pour éviter les incohérences entre anciennes et nouvelles URLs.
• Contrôler les 404 pendant au moins 2 à 4 semaines après la mise en ligne.
• Garder l’ancien domaine actif suffisamment longtemps pour que les robots et les visiteurs suivent les redirections.
• Surveiller les performances du trafic organique avant et après la bascule.

En pratique, je laisse souvent l’ancien domaine accessible pendant plusieurs semaines, parfois plus, afin que les liens externes continuent d’atterrir correctement et que les moteurs aient le temps de recrawler les nouvelles pages. La propagation DNS, elle, peut prendre de quelques minutes à 24 ou 48 heures selon les cas, donc il faut parfois accepter une période de transition plutôt que de chercher un basculement instantané.

Une fois cet aspect sécurisé, je me concentre sur les erreurs que je vois revenir le plus souvent, parce qu’elles sont simples à éviter quand on sait où regarder.

Les erreurs qui coûtent le plus cher

La plupart des migrations ratées ne viennent pas d’un problème technique complexe, mais d’un enchaînement de petites négligences. Avec un peu d’expérience, on remarque vite que les mêmes oublis reviennent encore et encore.

• Ne pas sauvegarder avant de commencer: c’est l’erreur la plus bête et la plus coûteuse.
• Modifier l’URL sans search/replace correct: le site s’ouvre, mais des liens ou des images restent cassés.
• Oublier le HTTPS: cela crée des avertissements de sécurité ou du contenu mixte.
• Ne pas purger les caches: on croit le problème résolu alors qu’on voit juste une vieille version.
• Rediriger tout vers la page d’accueil: cela affaiblit l’expérience utilisateur et le SEO.
• Ne pas tester les formulaires et les emails: sur un site pro, cela peut bloquer des leads ou des ventes sans alerte visible.
• Changer plusieurs choses à la fois: nouveau serveur, nouveau thème, nouvelles extensions et nouveau domaine en même temps, c’est souvent trop.

Je conseille aussi de vérifier les tâches planifiées, les connexions SMTP, les intégrations de paiement et les webhooks, surtout si le site est actif commercialement. Un transfert peut être visuellement réussi tout en cassant une fonction invisible mais critique. Avec cette liste en tête, la vérification finale devient beaucoup plus simple.

Ce que je contrôle avant de refermer le chantier

Avant de considérer le transfert comme terminé, je refais une tournée courte mais méthodique. Je teste la page d’accueil, plusieurs articles, les menus, la recherche interne, le formulaire de contact, la connexion administrateur et, si le site vend quelque chose, le tunnel de commande complet. Je regarde aussi le journal des erreurs, les redirections en place et les premières remontées de Search Console.

• Le site s’ouvre bien sur le nouveau domaine ou le nouvel hébergement.
• Les anciennes URLs renvoient vers les nouvelles avec un code 301.
• Les images, CSS et scripts se chargent sans mélange HTTP/HTTPS.
• Les formulaires envoient bien les emails.
• Les permaliens fonctionnent sans 404 inattendus.
• Le cache, le CDN et les plugins critiques ont été purgés ou reconfigurés.

Si vous devez retenir une seule idée, c’est celle-ci: une migration réussie n’est pas seulement une copie de fichiers, c’est une reprise en main complète de l’environnement, des URLs et des redirections. C’est cette rigueur qui fait la différence entre un simple déplacement technique et un site qui repart proprement, sans perte inutile de trafic ni de crédibilité.