Migration WordPress
Changer d’hébergeur sans perdre son site ni son référencement
Une migration WordPress réussie ne se limite pas à copier des fichiers. Elle doit préserver les accès, les données, les emails, les URLs, le référencement et la capacité de revenir en arrière.
Étude informative : les règles, sources et pratiques citées peuvent évoluer et doivent être vérifiées avant toute décision.
Migrer sans casser ce qui fonctionne déjà
Migrer un site WordPress vers un nouvel hébergeur peut sembler simple : on copie le site, on modifie le DNS, puis le site repart. En pratique, c’est une opération à risque si elle est mal préparée.
Le risque ne concerne pas seulement la technique. Une migration peut provoquer une coupure du site, des formulaires qui n’arrivent plus, des emails transactionnels bloqués, des images manquantes, des erreurs 404, un tunnel WooCommerce cassé, des lenteurs, ou une perte de visibilité Google.
Il faut distinguer deux situations : une migration à l’identique, qui déplace le site sans changer ses contenus, URLs ou structure ; et une migration avec refonte ou nettoyage, qui modifie en plus le thème, les contenus, les plugins, les URLs ou l’architecture. Cette deuxième situation est plus risquée pour le SEO et doit être traitée comme un projet plus large.
Règle pratique : si l’urgence est de quitter un hébergeur ou un prestataire, mieux vaut souvent migrer d’abord à l’identique, puis nettoyer ensuite par étapes.
Changer d’hébergeur : une décision souvent prise trop tard
Une PME envisage rarement une migration WordPress par plaisir. La décision arrive souvent après des signaux faibles devenus trop visibles : site lent, support absent, hébergement trop cher, agence indisponible, serveur obsolète, incidents répétés, sauvegardes floues, accès mal documentés, sécurité insuffisante ou besoin de reprendre la maîtrise du site.
Le problème est que la migration est parfois décidée dans l’urgence. On veut partir vite, récupérer le site, changer d’hébergeur ou sortir d’une relation prestataire compliquée. C’est précisément dans ces moments que les erreurs arrivent : sauvegarde incomplète, DNS modifié trop tôt, emails oubliés, URLs perdues, cache non vidé, certificat SSL absent, version PHP incompatible, Search Console non contrôlée.
Si l’urgence est de quitter un hébergeur ou un prestataire, mieux vaut souvent migrer d’abord à l’identique, puis nettoyer ensuite par étapes. Cumuler migration, refonte, changement d’URLs, suppression de plugins et optimisation SEO augmente fortement le risque.
Pour un dirigeant, le sujet n’est pas de devenir technicien. Il est de savoir quoi demander, quoi contrôler et quels risques refuser.
Migration WordPress : de quoi parle-t-on exactement ?
Le mot “migration” recouvre plusieurs réalités. Les confondre crée des attentes irréalistes.
| Type de migration | Ce qui change | Niveau de risque |
|---|---|---|
| Migration d’hébergement à l’identique | le site reste le même, seul le serveur change | modéré si bien préparé |
| Migration de domaine | le site change d’adresse principale | élevé pour le SEO |
| Migration HTTP vers HTTPS | le protocole change | modéré à élevé selon redirections |
| Migration avec refonte | design, contenus, structure ou URLs changent | élevé |
| Migration avec nettoyage | plugins, thème, base, sécurité sont revus | variable, mais nécessite recette |
| Migration WooCommerce | site transactionnel avec commandes et paiements | élevé |
| Migration après incident | site piraté, hébergeur bloqué, accès perdus | élevé à critique |
Une migration d’hébergement sans changement d’URL est généralement moins risquée pour le référencement qu’une migration qui modifie les adresses des pages. Google distingue d’ailleurs les changements d’infrastructure, comme l’hébergement, des migrations avec changement d’URL.
Pourquoi changer d’hébergeur WordPress ?
Les raisons peuvent être légitimes, mais elles doivent être clarifiées avant d’agir. Un changement d’hébergeur ne résout pas tout : un site lourd, mal maintenu ou dépendant d’un thème fragile restera fragile ailleurs.
| Motif | Ce qu’il faut vérifier |
|---|---|
| Site trop lent | le problème vient-il vraiment de l’hébergement ou du site lui-même ? |
| Support insuffisant | quels délais et responsabilités sont attendus ? |
| Coût trop élevé | compare-t-on le même niveau de service ? |
| Sécurité insuffisante | sauvegardes, isolation, logs, mises à jour serveur, accès |
| Besoin d’infogérance | veut-on seulement un serveur ou aussi un accompagnement humain ? |
| Changement de prestataire | les accès et sauvegardes sont-ils récupérables ? |
| Croissance du site | trafic, WooCommerce, médias, base, besoins PHP/MySQL |
| Pannes répétées | problème serveur, plugin, base, cache, DNS ou emails ? |
Avant de migrer : récupérer les accès critiques
Une migration peut être bloquée par un seul accès manquant. Avant toute action technique, il faut vérifier que l’entreprise ou le prestataire mandaté dispose des accès nécessaires.
| Accès | Pourquoi il est indispensable |
|---|---|
| WordPress administrateur | exporter, vérifier, désactiver certains plugins, contrôler le site |
| Hébergement actuel | récupérer fichiers, base, logs, configuration |
| Base de données | exporter et vérifier les données |
| SFTP ou SSH | récupérer proprement les fichiers |
| Registrar du domaine | modifier ou transférer le domaine si nécessaire |
| DNS / Cloudflare | modifier les enregistrements au moment de la bascule |
| Emails / messagerie | éviter de casser MX, SPF, DKIM, DMARC |
| Sauvegardes | disposer d’un point de retour arrière |
| Google Search Console | surveiller indexation, erreurs, sitemap, sécurité |
| Analytics / Tag Manager | vérifier le suivi après migration |
| Licences premium | éviter de perdre mises à jour ou fonctionnalités |
| SMTP / formulaires | tester les envois après migration |
Ce qu’il faut sauvegarder avant toute migration
Une migration sérieuse commence par une sauvegarde complète, vérifiée et récupérable. WordPress rappelle qu’un site ne se résume pas aux fichiers : les contenus, réglages, utilisateurs et données dynamiques sont stockés dans la base de données.
| Élément | Pourquoi |
|---|---|
| Fichiers WordPress | cœur, thèmes, extensions, médias, fichiers techniques |
| Base de données | pages, articles, menus, utilisateurs, réglages, commandes |
| Dossier uploads | images, PDF, documents, médias éditoriaux |
| wp-config.php | configuration critique du site |
| .htaccess / règles serveur | redirections, permaliens, sécurité, cache |
| Tables plugins | WooCommerce, formulaires, SEO, builder, traduction |
| Sauvegardes existantes | historique utile en cas de problème |
| Exports WooCommerce | commandes, clients, produits si besoin |
| Redirections existantes | préserver le SEO et les anciennes URLs |
| Configuration SMTP | formulaires et emails transactionnels |
| Licences et clés API | extensions premium, paiement, anti-spam, CDN |
Une sauvegarde non testée reste une hypothèse. Avant de basculer, il faut au minimum savoir si elle est complète, récente, lisible et restaurable sur un environnement de test.
Migration à l’identique ou migration avec nettoyage ?
Migration à l’identique. Le site est copié tel quel vers un nouvel hébergement. L’objectif est de limiter les changements. C’est souvent l’option la plus sûre lorsque l’urgence est de sortir d’un hébergement problématique.
Migration avec nettoyage. La migration est utilisée pour corriger certains problèmes : supprimer des plugins, changer PHP, nettoyer la base, revoir les caches, renforcer la sécurité, remplacer des outils obsolètes. C’est utile, mais chaque changement supplémentaire augmente le besoin de test.
Si l’objectif est de partir vite, migrez d’abord à l’identique. Si l’objectif est d’améliorer le site, planifiez une seconde étape de nettoyage, testée et documentée.
Google recommande, lors des migrations importantes, de changer une seule chose à la fois lorsque c’est possible : par exemple ne pas cumuler simultanément changement de domaine, changement de CMS et changement de mise en page.
Le risque SEO : ne pas perdre les pages qui comptent
Une migration peut casser le référencement si les URLs, contenus, balises ou signaux techniques changent sans préparation.
| Élément SEO | Risque |
|---|---|
| URLs | erreurs 404, perte de pages indexées |
| Redirections 301 | anciennes URLs non redirigées |
| Balises title/meta | titres ou descriptions perdus |
| Contenus | pages utiles supprimées ou appauvries |
| Maillage interne | liens internes cassés |
| Images | URLs d’images modifiées ou fichiers manquants |
| Sitemap XML | sitemap absent ou non mis à jour |
| Robots.txt | blocage accidentel de Google |
| Noindex | balise oubliée après préproduction |
| Canonicals | mauvaises URLs canoniques |
| Données structurées | schema.org ou balisage perdu |
| Performance | site plus lent après migration |
| Search Console | propriété non vérifiée ou données non suivies |
Pour les migrations avec changement d’URL, Google recommande de préparer une correspondance entre les anciennes URLs et les nouvelles URLs, puis de configurer les redirections depuis les anciennes pages vers leurs nouvelles destinations.
Redirections 301 : le point qui évite beaucoup de pertes
Si les URLs changent, il faut prévoir un plan de redirection. Les anciennes pages doivent pointer vers les nouvelles via des redirections permanentes, généralement des redirections 301.
- permanente lorsque le changement est définitif ;
- page par page autant que possible ;
- logique pour l’utilisateur ;
- testée avant et après mise en ligne ;
- conservée suffisamment longtemps ;
- documentée.
| Mauvaise pratique | Conséquence |
|---|---|
| Rediriger toutes les anciennes pages vers l’accueil | perte de pertinence et mauvaise expérience utilisateur |
| Oublier les anciens articles | erreurs 404 et perte de trafic longue traîne |
| Redirections en chaîne | lenteur et signaux moins propres |
| Utiliser des redirections temporaires au lieu de 301 permanentes | signal moins clair pour les moteurs et suivi plus difficile |
| Supprimer les anciennes URLs sans plan | perte de pages indexées |
| Oublier les fichiers PDF | perte de trafic ou liens entrants cassés |
Le risque email : ne pas casser les messages
Beaucoup de migrations WordPress cassent les emails sans que le site lui-même soit en panne. Le changement d’hébergement web ne doit pas entraîner automatiquement un changement de messagerie.
| Élément | Risque si oublié |
|---|---|
| MX | emails entrants interrompus |
| SPF | emails sortants moins fiables |
| DKIM | signature email absente |
| DMARC | politique d’authentification cassée |
| SMTP WordPress | formulaires non reçus |
| WooCommerce emails | commandes non notifiées |
| Alias et redirections | demandes clients perdues |
| Webmail ancien | messages non migrés |
| DNS Cloudflare | proxy mal configuré sur services email |
Il faut traiter site et emails comme deux sujets distincts, même s’ils utilisent le même domaine.
Le risque technique : PHP, base, plugins, cache
Un site peut fonctionner sur l’ancien serveur et casser sur le nouveau. Les causes sont souvent liées à l’environnement.
| Point technique | À vérifier |
|---|---|
| Version PHP | compatibilité WordPress, thème, plugins |
| Extensions PHP | extensions requises comme json et mysqli, et extensions recommandées selon le site : curl, dom, fileinfo, imagick ou gd, mbstring, openssl, xml, zip, etc. |
| Version MySQL/MariaDB | compatibilité et encodage |
| Limites serveur | mémoire, upload, timeout, max_input_vars |
| Droits fichiers | écriture uploads, cache, logs |
| Cron WordPress | tâches planifiées, emails, imports |
| Cache serveur | purge et compatibilité |
| CDN | règles, cache, SSL, DNS |
| Certificat SSL | HTTPS actif avant bascule publique |
| Permaliens | réécriture URL fonctionnelle |
| Sécurité serveur | WAF, restrictions, headers, accès |
| Logs | capacité à diagnostiquer après migration |
Une migration est donc aussi un test de maturité technique. Elle révèle les dépendances anciennes, les plugins abandonnés, les réglages non documentés et les développements spécifiques.
Le cas WooCommerce : attention aux commandes
Un site WooCommerce doit être migré avec une prudence particulière. Entre la sauvegarde et la bascule, de nouvelles commandes peuvent arriver.
| Sujet WooCommerce | Risque |
|---|---|
| Commandes pendant migration | commandes perdues ou présentes sur l’ancien site |
| Paiements | paiement validé mais commande absente |
| Stocks | incohérences après restauration |
| Comptes clients | créations ou mots de passe récents perdus |
| Emails transactionnels | confirmations non envoyées |
| Factures | numérotation ou exports incomplets |
| Abonnements | renouvellements ou webhooks perturbés |
| Webhooks Stripe/PayPal | notifications envoyées au mauvais site |
Figer les commandes ne se fait pas automatiquement. En pratique, cela peut passer par un mode maintenance, une désactivation temporaire des moyens de paiement WooCommerce, une fenêtre de migration annoncée, ou une bascule à un moment de faible activité. L’objectif est d’éviter qu’une commande soit créée sur l’ancien site pendant que la nouvelle version devient active.
Préproduction : tester avant de basculer
Un site de préproduction, ou staging, est une copie du site utilisée pour tester la migration avant de modifier le site public.
- affichage des pages principales ;
- fonctionnement du back-office ;
- formulaires ;
- panier et tunnel WooCommerce ;
- paiement en mode test ;
- emails transactionnels ;
- performance ;
- erreurs PHP ;
- logs ;
- droits fichiers ;
- permaliens ;
- certificats SSL ;
- indexation bloquée sur la préproduction.
La préproduction doit rester non indexable par Google, mais cette protection doit être retirée uniquement du site public au moment de la bascule.
DNS et bascule : le moment critique
La bascule DNS est le moment où le domaine commence à pointer vers le nouvel hébergement.
| Point | À contrôler |
|---|---|
| TTL | réduire à 300 secondes, si possible 24 à 48 heures avant la bascule |
| Nouvelle IP | correcte et testée |
| Certificat SSL | installé et valide |
| Site prévisualisé | testé sans changer publiquement le DNS |
| Emails | MX/SPF/DKIM/DMARC préservés |
| Cache | purge côté WordPress, serveur et CDN |
| Sauvegarde finale | réalisée juste avant bascule |
| Accès ancien hébergement | conservé temporairement |
| Monitoring | site surveillé après bascule |
| Plan retour arrière | clair et disponible |
Après migration : les contrôles indispensables
Une migration n’est pas terminée quand le site s’affiche. Elle est terminée quand les fonctions critiques sont vérifiées.
| Contrôle | Pourquoi |
|---|---|
| Page d’accueil | vérifier affichage et HTTPS |
| Pages principales | éviter les erreurs visibles |
| Articles importants | préserver trafic SEO |
| Formulaires | vérifier réception email |
| WooCommerce | panier, paiement, commande, emails |
| Back-office | connexion, droits, médias |
| Médias | images et PDF accessibles |
| Sitemap XML | accessible et à jour |
| Robots.txt | ne bloque pas le site public |
| Search Console | propriété vérifiée, sitemap soumis |
| Analytics | suivi toujours actif |
| Redirections | anciennes URLs correctement redirigées |
| Erreurs 404 | à surveiller et corriger |
| Performance | cache, temps de réponse, images |
| Emails | MX, SPF, DKIM, DMARC, SMTP |
| Logs | erreurs PHP ou serveur |
Google recommande d’utiliser Search Console pendant les migrations, de vérifier les propriétés concernées et de surveiller l’indexation, les sitemaps et le trafic.
Que faire si la migration échoue ?
Une migration peut échouer malgré une bonne préparation. Le problème n’est pas l’existence d’un incident, mais l’absence de plan de retour.
| Incident | Réaction possible |
|---|---|
| Site inaccessible | revenir temporairement à l’ancienne IP ou page d’attente |
| Erreur PHP critique | désactiver plugin/thème fautif, consulter logs |
| Base non importée | restaurer une sauvegarde propre |
| Formulaires muets | vérifier SMTP, DNS, destinataires |
| Emails coupés | restaurer MX/SPF/DKIM/DMARC |
| SSL invalide | corriger certificat avant mise en ligne |
| WooCommerce incohérent | figer commandes, rapprocher paiements |
| Forte chute de trafic | vérifier indexation, redirections, noindex, sitemap |
| Anciennes pages en 404 | compléter le plan de redirection |
| Site lent | analyser cache, PHP, base, extensions, serveur |
Le plan de retour doit être décidé avant la migration. Il faut savoir combien de temps on attend avant de revenir en arrière, qui prend la décision et quelles données risquent d’être perdues.
Les erreurs fréquentes
| Erreur | Conséquence |
|---|---|
| Migrer sans sauvegarde complète | retour arrière impossible |
| Modifier DNS avant test | panne visible immédiatement |
| Oublier les emails | demandes clients perdues |
| Confondre migration et refonte | risque SEO et fonctionnel augmenté |
| Ne pas tester WooCommerce | commandes ou paiements cassés |
| Supprimer l’ancien hébergement trop tôt | fichiers ou preuves perdus |
| Oublier Search Console | erreurs SEO non détectées |
| Garder un noindex de préproduction | site public désindexé |
| Ne pas vérifier les redirections 301 | trafic perdu vers erreurs 404 |
| Ne pas vérifier les formulaires | leads non reçus |
| Changer PHP sans test | plugins ou thème incompatibles |
| Ne pas documenter les accès | dépendance persistante |
Checklist dirigeant avant validation
| Question | Si la réponse est floue |
|---|---|
| Avons-nous les accès WordPress, hébergement, DNS et domaine ? | la migration peut être bloquée |
| Le site est-il migré à l’identique ou modifié ? | le niveau de risque est mal évalué |
| Une sauvegarde complète fichiers + base existe-t-elle ? | retour arrière incertain |
| La restauration a-t-elle été testée ? | la sauvegarde reste théorique |
| Les emails sont-ils séparés du sujet hébergement web ? | risque de coupure messagerie |
| Les URLs changent-elles ? | plan de redirection 301 nécessaire |
| Les pages SEO importantes sont-elles identifiées ? | perte possible de trafic utile |
| Search Console est-elle accessible ? | suivi SEO post-migration limité |
| WooCommerce est-il concerné ? | commandes, paiements et stocks à sécuriser |
| Une préproduction a-t-elle été testée ? | erreurs découvertes trop tard |
| Le TTL DNS a-t-il été réduit à l’avance ? | propagation plus lente et retour arrière plus confus |
| Le DNS sera-t-il basculé à un moment calme ? | impact client réduit |
| L’ancien hébergement est-il conservé au moins 30 jours ? | retour arrière et vérifications plus difficiles |
| Qui décide du retour arrière ? | crise mal coordonnée |
| Quels contrôles sont faits après bascule ? | site affiché mais fonctions cassées |
| Les accès inutiles seront-ils supprimés après migration ? | risque de sécurité persistant |
FAQ
Changer d’hébergeur fait-il perdre le référencement ?
Pas nécessairement. Si les URLs, contenus, balises, performances et redirections sont maîtrisés, une migration d’hébergement peut se faire sans perte durable. En revanche, une migration importante peut provoquer des fluctuations temporaires le temps du recrawl et de la réindexation.
Faut-il utiliser un plugin de migration WordPress ?
Un plugin peut aider, mais il ne remplace pas la méthode. Il faut toujours vérifier la sauvegarde, la base, les médias, les formulaires, les emails, les redirections, les performances et les accès.
Peut-on migrer sans changer les URLs ?
Oui. C’est le cas le plus simple : le site garde le même domaine et la même structure d’URL, seul l’hébergement change. Le risque SEO est généralement plus faible, mais les contrôles techniques restent indispensables.
Faut-il prévenir Google ?
Si les URLs ne changent pas, il n’y a généralement pas de changement d’adresse à déclarer. L’outil de changement d’adresse Search Console ne s’utilise que si le site change de domaine ou de sous-domaine. Pour une simple migration d’hébergement avec le même domaine et les mêmes URLs, il faut surtout surveiller Search Console, le sitemap, les erreurs d’exploration, les performances et les redirections éventuelles.
Combien de temps conserver l’ancien hébergement ?
Il est prudent de conserver l’ancien hébergement au moins 30 jours après la bascule, sauf contrainte particulière. Cela permet de récupérer un fichier oublié, comparer les environnements, consulter les logs ou revenir sur un problème découvert tardivement.
Faut-il migrer les emails en même temps que le site ?
Pas forcément. Souvent, il vaut mieux séparer les sujets. Le site peut changer d’hébergement sans modifier la messagerie, à condition de préserver les enregistrements DNS liés aux emails.
Une migration améliore-t-elle automatiquement les performances ?
Non. Un meilleur hébergement peut aider, mais si le site est trop lourd, mal configuré ou saturé de plugins, les gains seront limités. Une migration peut être l’occasion d’un audit, mais ce n’est pas une optimisation automatique.
Que faire si le site est piraté avant migration ?
Il faut éviter de copier aveuglément un site compromis vers un nouvel hébergement. Il faut d’abord isoler, préserver les preuves utiles, diagnostiquer, choisir une sauvegarde saine ou nettoyer, puis migrer. Sinon, la migration déplace aussi l’infection.
Une migration peut-elle casser WooCommerce ?
Oui, surtout si des commandes arrivent pendant la migration ou si les webhooks de paiement, emails transactionnels, stocks ou comptes clients ne sont pas testés. Un e-commerce doit être migré avec une procédure spécifique.
Le DNS met-il toujours 24 à 48 heures à se propager ?
Pas toujours. Le délai dépend notamment du TTL, des caches DNS et des fournisseurs. Mais il faut prévoir une période où certains visiteurs peuvent encore voir l’ancien serveur pendant que d’autres voient le nouveau. C’est pourquoi il faut éviter de supprimer l’ancien hébergement trop vite.
Une migration réussie est une migration préparée
Changer d’hébergeur WordPress n’est pas seulement une opération de copie. C’est une opération de maîtrise : maîtrise des accès, des sauvegardes, des DNS, des emails, du SEO, des tests, des performances et du retour arrière.
Pour une PME, le vrai risque n’est pas de migrer. Le vrai risque est de migrer sans savoir ce qui dépend du site, qui possède les accès, quelles pages génèrent du trafic, quelles données doivent être préservées et comment vérifier que tout fonctionne après bascule.
Une migration réussie doit être presque invisible pour les visiteurs : le site reste accessible, les formulaires fonctionnent, les emails arrivent, les commandes sont enregistrées, Google retrouve les pages, et l’entreprise gagne en maîtrise.
Références utilisées
- Google Search Central — Site moves and migrations : préparation, mapping d’URL, redirections, Search Console et fluctuations possibles.
- Google Search Console — Outil de changement d’adresse : utile en cas de changement de domaine ou sous-domaine, pas pour une simple migration d’hébergement à URLs identiques.
- WordPress.org — Backups : sauvegarde des fichiers et de la base de données.
- Make WordPress Hosting — Server Environment : environnement serveur recommandé et extensions PHP requises ou recommandées.
- ICANN — principes de gestion du nom de domaine, titulaire, DNS, transfert et contacts administratifs.
-
Performance WordPress Pourquoi votre site est lent et comment diagnostiquer avant d’agir
Juillet 2026
-
Maintenance WordPress Que doit contenir un vrai contrat de maintenance ?
Juin 2026
-
Site WordPress en 2026 Les risques d'un site non maintenu
Mai 2026
-
Cyberattaque sur un site WordPress Que faire dans les premières heures ?
Mai 2026
-
Référencement naturel Enjeux, méthodes et axes d'amélioration
Mars 2026
-
Sauvegardes web Pourquoi une sauvegarde n'est utile que si elle est restaurable
Juin 2026