Migration WordPress : changer d’hébergement ou de structure sans casser le site
Fichiers, base de données, DNS, emails, URL, redirections et formulaires : une migration WordPress se prépare avant la bascule. L’IA peut accélérer l’inventaire et certains contrôles, mais pas remplacer les tests.
Une migration WordPress peut sembler simple : exporter les fichiers, déplacer la base de données et modifier quelques paramètres.
En pratique, les problèmes apparaissent souvent après la mise en ligne : formulaire qui n’envoie plus, images manquantes, erreur 404, certificat SSL mal configuré, extension incompatible ou emails transactionnels qui n’arrivent plus.
Le niveau de préparation dépend surtout du type de migration réalisée. Déplacer un site vers un nouvel hébergement sans modifier ses URL n’est pas le même chantier qu’un changement de domaine ou une refonte complète de l’arborescence.
Il existe plusieurs types de migration WordPress
Même domaine, nouveau serveur
Les URL restent identiques. Le chantier concerne surtout les fichiers, la base, PHP, SSL, DNS, emails et performances.
Nouvelle adresse
En plus du transfert technique, les anciennes URL doivent être reliées proprement aux nouvelles avec des redirections adaptées.
Nouveau thème ou nouvelle structure
Le design, les modèles, les extensions ou l’arborescence changent. Les risques concernent aussi le SEO et les parcours utilisateurs.
Lorsque plusieurs changements sont regroupés, l’origine d’une erreur ou d’une baisse de trafic devient beaucoup plus difficile à identifier.
Une migration propre suit un ordre précis
Fichiers, base, plugins, comptes et URL.
Nouvelle installation et environnement de test.
Pages, formulaires, commandes et emails.
DNS, redirections puis surveillance.
Avant la migration, conservez une copie exploitable des fichiers et de la base de données, ainsi que les accès nécessaires à l’ancien et au nouvel hébergement.
Faire l’inventaire avant de déplacer quoi que ce soit
L’inventaire permet de savoir ce que le nouveau serveur doit réellement reprendre et ce qui mérite un contrôle particulier.
Version, thème et extensions
Les plugins actifs, le thème, les extensions premium et les licences doivent être identifiés avant le transfert.
PHP et configuration
La version PHP, les extensions serveur, les limites mémoire et certaines règles peuvent différer entre deux hébergeurs.
Base et médias
La base de données et le dossier des médias doivent être inclus dans la sauvegarde.
Email, API et tâches planifiées
SMTP, webhooks, API, cron et outils externes doivent être répertoriés.
Préparer une vraie possibilité de retour arrière
Les fichiers sont quelque part sur un disque ou un serveur, mais personne n’a vérifié si la base est complète ni comment restaurer le site.
L’ancien serveur reste disponible, les fichiers et la base sont conservés et la procédure pour revenir à l’état précédent est connue.
Tester la copie sur une préproduction
Lorsque le site joue un rôle commercial important, les tests ne devraient pas être réalisés directement sur la version publique.
Attention à l’indexation de la préproduction
Une copie de test ne devrait pas se retrouver dans les résultats de recherche à côté du vrai site.
Mais l’inverse est également dangereux : un blocage ajouté pour protéger la préproduction ne doit pas rester actif après la mise en ligne du nouveau site.
Un noindex,
une protection robots
ou un réglage WordPress oublié
peut empêcher Google
d’explorer correctement la nouvelle version.
Changement d’hébergement sans changement d’URL
Lorsque le domaine reste identique, la migration SEO est généralement plus simple puisque les adresses des pages ne changent pas.
Installer la copie sur le nouveau serveur
Importer les fichiers et la base, puis adapter la configuration du nouvel environnement.
Tester avant le DNS
Vérifier le site sur le nouveau serveur avant d’envoyer les visiteurs dessus.
Basculer le DNS
Les enregistrements concernés sont ensuite modifiés pour pointer vers la nouvelle infrastructure.
Conserver temporairement l’ancien serveur
Il sert de sécurité pendant que le trafic bascule progressivement vers le nouvel hébergement.
Une migration d’hébergement ne concerne pas seulement le site
Le domaine peut également utiliser des services email ou d’autres enregistrements DNS qu’il ne faut pas modifier par erreur.
A et AAAA
Ils peuvent pointer vers l’adresse du serveur qui héberge le site.
MX
Les enregistrements de messagerie ne doivent pas être remplacés simplement parce que le site change d’hébergement.
SPF, DKIM et DMARC
Les réglages de messagerie doivent être conservés ou adaptés si le système d’envoi change.
TTL
Une réduction anticipée du TTL peut faciliter une bascule DNS plus rapide lorsqu’elle est bien préparée.
Vérifier HTTPS et le certificat SSL
Le nouveau serveur doit disposer d’un certificat valide avant ou au moment de la bascule.
Images, scripts ou feuilles de style peuvent générer du contenu mixte.
Les pages, médias, liens internes et appels de fichiers fonctionnent en HTTPS.
Si les URL changent, préparer une correspondance avant la mise en ligne
Une refonte peut modifier le nom des pages, leurs dossiers ou le domaine entier.
Dans ce cas, chaque URL importante de l’ancien site doit être comparée à sa destination dans le nouveau.
/creation-site-web/
/site-internet/
Redirection permanente de l’ancienne page vers sa nouvelle équivalence.
Une redirection doit pointer vers la page réellement équivalente
Rediriger toutes les anciennes pages vers la page d’accueil parce que leur nouvelle destination n’a pas été définie.
Chaque ancienne URL pointe vers la page qui reprend réellement son contenu ou son intention.
Pour un changement d’URL, Google recommande de conserver les redirections permanentes aussi longtemps que possible, généralement au moins un an.
Les redirections ne remplacent pas la mise à jour des liens internes
Une page du nouveau site ne devrait pas continuer à pointer vers une ancienne URL qui redirige ensuite vers la nouvelle.
Menus, boutons, contenus, footer, images, canonicals et sitemap doivent utiliser les nouvelles adresses.
Un changement de domaine demande aussi de corriger les URL stockées dans WordPress
WordPress peut enregistrer des URL dans les contenus, les options, les widgets ou les données générées par certains constructeurs.
Une recherche/remplacement doit donc être réalisée avec un outil adapté à WordPress, en prenant garde aux données sérialisées et aux valeurs de configuration.
Avec Elementor, régénérer et contrôler les fichiers après migration
Styles générés
Après le changement, il peut être nécessaire de régénérer les fichiers CSS produits par Elementor.
Anciennes adresses
Les images, backgrounds et liens doivent être vérifiés si le domaine ou les chemins ont changé.
Anciennes ressources
Les caches WordPress, serveur et CDN peuvent encore servir d’anciens fichiers.
Pages réelles
Une page correcte dans l’éditeur doit aussi être vérifiée côté public sur desktop et mobile.
Tester réellement les formulaires après la migration
Vérifier uniquement que le formulaire s’affiche ne suffit pas.
Envoyer une vraie demande de test.
Contrôler le message affiché au visiteur.
Vérifier que l’email arrive réellement.
Contrôler l’adresse expéditeur et le Reply-To.
Le site peut fonctionner alors que les emails sont cassés
Une migration de serveur peut modifier le fonctionnement de PHP Mail, du SMTP ou de certaines règles de sécurité.
Formulaires
Vérifier que les demandes arrivent dans la boîte réellement utilisée.
Notifications
Réinitialisation de mot de passe et notifications administratives doivent également être testées.
Emails transactionnels
Confirmation de commande, paiement et changements de statut sont particulièrement importants.
Une migration WooCommerce demande une organisation supplémentaire
Une boutique continue à recevoir des commandes, créer des comptes clients et modifier des stocks pendant que la copie est préparée.
Une petite différence entre deux copies peut parfois être corrigée avant la bascule.
Une commande reçue après la dernière copie de base ne doit pas disparaître lors de la mise en production.
Selon le projet, cela peut nécessiter une courte maintenance, une synchronisation finale ou une procédure spécifique pour récupérer les dernières commandes et comptes.
Tester le paiement jusqu’au bout
Sur WooCommerce, l’affichage du bouton de paiement ne garantit pas que la transaction fonctionne.
Vérifier les tâches cron et automatisations
Certains sites exécutent régulièrement des imports, synchronisations, sauvegardes, relances ou traitements automatiques.
Lors d’un changement d’hébergement, les tâches cron configurées directement sur l’ancien serveur ne suivent pas automatiquement WordPress.
Une tâche planifiée, un script PHP ou une règle serveur peut exister en dehors de l’administration WordPress.
Contrôler le SEO avant et après la bascule
Robots et noindex
Vérifier que les pages destinées à Google ne sont pas bloquées par un réglage de préproduction.
Bonnes URL
Les balises canonical doivent pointer vers les URL définitives du nouveau site.
Nouvelle structure
Le sitemap XML doit présenter les URL actuellement utilisées.
Anciennes pages
Les erreurs 404 doivent être surveillées après une modification d’arborescence.
Search Console permet de surveiller ce qui se passe après la migration
Après un changement important d’URL, il est normal que Google ait besoin de temps pour explorer et traiter les nouvelles adresses.
Comparer les performances avant et après
Un changement d’hébergement devrait être contrôlé sur les mêmes pages avant et après la migration.
Temps de réponse
Le nouvel hébergement ne doit pas dégrader le temps de réponse initial.
Pages principales
Accueil, services et pages d’entrée SEO doivent être comparées.
Conditions réelles
Le contrôle ne doit pas être limité à un ordinateur rapide.
Où l’IA peut aider pendant une migration
Classer les URL
Un export volumineux peut être regroupé par type de contenu ou niveau de priorité.
Préparer des correspondances
L’IA peut aider à rapprocher anciennes et nouvelles pages avant validation humaine.
Regrouper les erreurs
Des erreurs serveur ou 404 nombreuses peuvent être classées pour accélérer l’analyse.
Préparer les contrôles
Une liste de pages, fonctionnalités et scénarios de test peut être organisée selon le projet.
Ce que l’IA ne doit pas décider seule
Une correspondance d’URL, une analyse de log, une synthèse ou une série de contrôles.
Les redirections, la suppression d’une page, la bascule DNS, la restauration et les opérations sur les données clients.
Exemple : migration vers un nouvel hébergement avec refonte Elementor
Copie du site, sauvegarde complète, inventaire des URL et installation du nouvel environnement.
Refonte Elementor, tests des pages, formulaires, mobile et performances.
Synchronisation finale, DNS, SSL, contrôle des emails puis surveillance.
Les erreurs qui coûtent cher après une migration
Migrer sans préproduction
Les incompatibilités sont découvertes directement par les visiteurs.
Modifier les URL sans redirections
Les anciennes pages renvoient des erreurs alors qu’elles recevaient encore du trafic ou des liens.
Tester seulement l’affichage
Le site semble fonctionner alors que les formulaires ou confirmations de commandes n’arrivent plus.
Modifier tous les enregistrements
Une mauvaise manipulation peut couper la messagerie en même temps que le site.
Oublier les dernières commandes
La base copiée n’intègre pas les données créées entre l’export et la bascule.
Supprimer l’ancien serveur trop tôt
Le retour arrière devient difficile si un problème important apparaît après coup.
Les premières heures après la bascule sont importantes
Ouvrir les pages stratégiques sans cache.
Envoyer les formulaires importants.
Vérifier redirections, sitemap et indexation.
Surveiller erreurs 404, PHP et serveur.
Questions fréquentes
Peut-on migrer WordPress sans perdre son référencement ?
Oui, à condition de préparer correctement la migration. Si les URL restent identiques, le chantier est généralement plus simple. Si elles changent, il faut notamment préparer les redirections, les liens internes, le sitemap et les contrôles après la bascule.
Faut-il garder l’ancien hébergement après la migration ?
Il est prudent de ne pas le supprimer immédiatement. L’ancien environnement peut servir de sécurité pendant la période de contrôle, notamment lors d’un changement DNS.
Une sauvegarde WordPress suffit-elle ?
Elle doit contenir les éléments nécessaires et pouvoir être restaurée. Conserver une archive sans savoir si elle est complète ni comment revenir en arrière apporte une sécurité limitée.
Faut-il refaire les DNS quand on change d’hébergeur ?
Les enregistrements utilisés pour le site doivent être adaptés au nouvel hébergement. Il faut en revanche éviter de modifier sans raison les enregistrements utilisés par la messagerie ou d’autres services.
L’IA peut-elle automatiser une migration WordPress ?
Elle peut accélérer l’inventaire, l’analyse de fichiers, les correspondances d’URL ou la lecture d’erreurs. La sauvegarde, les tests, les redirections et la bascule doivent rester contrôlés.
Migration et refonte WordPress chez Prestissime
Prestissime peut prendre en charge le déplacement d’un site WordPress vers un nouvel hébergement, une refonte Elementor ou une évolution de sa structure.
Le travail peut comprendre les fichiers, la base de données, les sauvegardes, le DNS, le SSL, les redirections, les formulaires, les emails et les contrôles SEO.
Pour WooCommerce, une attention particulière est portée aux comptes clients, aux commandes, aux moyens de paiement et aux données créées pendant la période de migration.
À lire ensuite sur Prestissime
Retrouvez également nos contenus consacrés à la performance, à la sécurité et à la maintenance WordPress.
Vous devez migrer ou refaire un site WordPress ?
Prestissime peut préparer la migration, transférer le site, sécuriser les URL et contrôler les formulaires, emails, performances et fonctionnalités avant et après la mise en ligne.
