Une migration ne consiste pas seulement à copier des fichiers. WordPress relie une base de données, des médias, du code, des comptes, des tâches planifiées, des URL, des certificats et parfois des services externes. Une page d’accueil visible après la copie ne prouve ni que les formulaires fonctionnent, ni que les commandes sont cohérentes, ni que les moteurs reçoivent les bons signaux.
Cette migration WordPress checklist organise la bascule autour de preuves : inventaire, sauvegarde restaurable, copie cohérente, validation privée, décision de lancement, contrôles publics et critères de retour. Elle ne dépend pas d’un outil particulier et ne divulgue aucune donnée d’infrastructure.
Sommaire
La réponse courte
Définissez d’abord ce qui change : hébergement sans modification d’URL, domaine, protocole, sous-répertoire, architecture ou plusieurs éléments. Évitez de déplacer le site, changer de thème, restructurer toutes les URL et mettre à niveau PHP dans la même fenêtre.
Copiez base et fichiers correspondant au même état. Testez la destination sans l’ouvrir à l’indexation. Préparez les certificats, redirections et enregistrements nécessaires. Figez les écritures pendant la synchronisation finale, basculez, puis vérifiez les pages, médias, connexions, formulaires, tâches et signaux SEO. Revenez à la source si un critère critique convenu échoue et ne peut pas être corrigé dans la fenêtre.
La documentation Migrating WordPress confirme qu’un déplacement peut nécessiter les fichiers, la base, les paramètres de connexion et un traitement adapté des URL. Notre guide de restauration WordPress complète ce point : une archive n’est utile que si le retour a été testé.
Principes qui restent valables
Les outils automatisés ont progressé, mais quatre risques restent constants : oublier une dépendance, mélanger deux états, remplacer des URL de manière destructive et découvrir trop tard qu’aucun retour n’est possible.
Une extension de migration peut accélérer l’export et l’import. Elle ne connaît pas forcément le DNS géré ailleurs, le compte d’envoi transactionnel, une tâche externe, une restriction de paiement, un CDN ou une validation métier. L’automatisation doit donc exécuter une partie du plan, pas devenir le plan.
Une migration WordPress checklist actuelle doit également intégrer les signaux d’indexation, les URL canoniques, les données structurées et les outils de mesure. Ces éléments existaient déjà sous différentes formes, mais leur vérification est désormais indispensable à un transfert éditorial propre.
Définir le périmètre exact
Classez la migration avant de choisir la procédure :
- même domaine et mêmes URL, nouvelle destination ;
- changement de protocole, de domaine ou de sous-domaine ;
- changement de structure d’URL ;
- fusion de contenus ;
- extraction ou intégration dans un multisite ;
- migration comprenant aussi la messagerie ;
- reconstruction applicative accompagnant le déplacement.
Plusieurs catégories peuvent se combiner, mais chaque changement ajouté augmente le nombre de contrôles et complique le retour. La recommandation de Google pour les migrations avec changement d’URL est de modifier une chose à la fois lorsque cela est possible.
Écrivez aussi ce qui ne change pas. Si les URL restent identiques, inutile de créer une campagne de redirections. Si la messagerie n’est pas migrée, elle doit posséder son propre propriétaire et ses propres tests.
Inventorier avant de copier
L’inventaire de départ contient au minimum :
- version WordPress et version PHP prises en charge ;
- thème actif, thème enfant et extensions indispensables ;
- taille de la base, des médias et des autres fichiers utiles ;
- tables qui n’utilisent pas le préfixe principal ;
- URL d’accueil et URL du site ;
- structure des permaliens ;
- comptes administrateurs organisationnels ;
- tâches planifiées ;
- formulaires, paiements, recherche, espace membre et e-mails ;
- DNS, certificats, redirections et en-têtes importants ;
- cache, CDN, stockage ou services externes ;
- sitemap, canoniques, robots et règles d’indexation ;
- pages et parcours critiques à tester.
Conservez les valeurs sensibles dans une fiche privée. L’article de migration, le ticket public ou la capture de présentation ne doit contenir aucun identifiant, chemin, secret, IP ou journal brut.
Préparer une sauvegarde et un retour
Créez une copie cohérente de la base et des fichiers avant toute modification. Notez l’heure et l’état. Conservez-la séparément de la destination et vérifiez que les accès de restauration sont disponibles.
Le plan de retour décrit une action, pas une intention. Il indique qui prend la décision, jusqu’à quelle heure elle reste possible, comment le trafic revient vers la source, comment les écritures produites après la bascule sont traitées et quels contrôles suivent.
Définissez des déclencheurs observables : administration inaccessible, achat ou formulaire critique impossible, contenu récent absent, erreurs applicatives persistantes, certificat invalide ou incohérence de données. Un ralentissement mineur ne se traite pas comme une perte de commandes ; la priorité suit l’impact.
Préparer la destination sans l’indexer
La destination doit être compatible avant la copie : version PHP, modules nécessaires, base, droits de fichiers, HTTPS prévu et capacité adaptée au site. Ne reproduisez pas aveuglément une ancienne configuration ; documentez chaque différence nécessaire.
Testez l’installation via une méthode privée approuvée. Un site de préparation ne doit pas envoyer de courriels ou de paiements réels, exécuter des automatisations de production ni devenir indexable. Utilisez une authentification ou une restriction d’accès en plus d’une directive d’indexation lorsque des données sensibles sont présentes.
Préparez dès maintenant la liste des protections temporaires à retirer au lancement. Google rappelle qu’un noindex ou un blocage de crawl utilisé pendant le développement doit être supprimé au bon moment.
Copier base et fichiers dans le même état
Pour un site peu actif, une courte fenêtre de lecture seule peut suffire. Pour une boutique ou une plateforme avec des écritures fréquentes, planifiez une première copie, puis une synchronisation finale après gel des commandes, comptes, formulaires ou modifications concernées.
Une base récente avec des médias anciens contient des références vers des fichiers absents. Des fichiers récents avec une base ancienne peuvent produire des éléments orphelins. La migration WordPress checklist doit donc enregistrer l’heure des deux copies et la méthode de cohérence.
Importez la base, copiez les fichiers nécessaires et ajustez seulement les paramètres propres à la destination. N’écrasez pas une configuration saine avec des valeurs de l’ancien environnement sans comparaison.
Traiter les URL sans casser les données sérialisées
Si l’adresse change, un simple remplacement de texte dans une exportation SQL peut corrompre les données sérialisées de PHP. Utilisez un outil compatible avec WordPress. La commande officielle `wp search-replace` sait traiter les données sérialisées et propose un mode de simulation.
Commencez par une simulation, examinez les tables incluses, sauvegardez l’export, puis appliquez le remplacement. Contrôlez les URL d’accueil, médias, menus, widgets, champs personnalisés et configurations d’extensions. Les valeurs externes qui ne doivent pas changer doivent être exclues.
Si la structure d’URL évolue, créez une correspondance ancienne URL vers nouvelle destination. Évitez de rediriger toutes les pages vers l’accueil. Une page supprimée sans équivalent doit répondre avec le statut approprié.
Valider avant la bascule
La validation privée doit couvrir plus que l’accueil :
- pages, articles, catégories et recherche ;
- images, documents et téléchargements ;
- connexion, déconnexion et récupération de compte ;
- formulaires avec réception contrôlée ;
- panier, compte et paiement en mode de test si applicable ;
- permaliens et erreurs 404 ;
- tâches planifiées ;
- cache pour visiteurs connectés et déconnectés ;
- redirections, canonicals, schema, robots et sitemap ;
- affichage mobile, clavier et fonctions JavaScript ;
- journaux privés sans erreur nouvelle critique.
Comparez un échantillon de contenus et de comptes entre source et destination. Pour une boutique, ajoutez des totaux métier adaptés et une procédure de réconciliation.
Préparer DNS, HTTPS et redirections
Inventoriez les enregistrements concernés avant la fenêtre. Une modification de site ne doit pas supprimer par accident les entrées de messagerie ou de vérification. Abaissez le TTL suffisamment tôt uniquement si votre stratégie et votre gestionnaire DNS le justifient, puis rétablissez une valeur normale après stabilisation.
Le certificat doit couvrir les noms servis par la destination. Vérifiez HTTPS avant de forcer la redirection. Choisissez la version canonique du domaine et envoyez chaque ancienne URL vers sa destination finale, sans chaîne inutile.
Pour un changement de domaine, le guide Google demande de préparer les propriétés Search Console, les canoniques, les liens internes, le nouveau sitemap et, lorsque le cas s’applique, l’outil de changement d’adresse. Les redirections permanentes doivent rester en place durablement.
Exécuter la bascule
Au début de la fenêtre, confirmez les responsables et le canal de décision. Activez le gel prévu, exécutez la dernière synchronisation, contrôlez ses erreurs, puis appliquez la bascule de trafic. Notez l’heure réelle.
Testez depuis une session déconnectée et plusieurs résolutions si nécessaire. Ne vous fiez pas uniquement à un navigateur qui peut conserver DNS, cache ou cookies. Validez le certificat, les en-têtes, les pages clés, l’administration, les formulaires et une tâche applicative.
La décision est alors explicite : maintenir, corriger dans la fenêtre ou revenir. Évitez la zone grise où la source et la destination acceptent toutes deux des écritures sans mécanisme de réconciliation.
Vérifier e-mails et services externes
Une migration web ne déplace pas automatiquement les boîtes de messagerie. Testez séparément la réception du formulaire, la réinitialisation de mot de passe et les notifications importantes. N’utilisez pas de vraies données client pour un test si une donnée fictive suffit.
Vérifiez les listes d’autorisation, webhooks, URL de retour, clés d’API et règles de pare-feu dans leurs systèmes propriétaires, sans les copier dans le compte rendu public. Toute rotation de secret suit une procédure distincte.
Surveiller après le lancement
Les premières heures servent à détecter les erreurs fonctionnelles ; les jours suivants permettent de voir les 404, tâches tardives, échecs de courrier, écarts de cache et problèmes d’indexation. Gardez la source disponible selon le plan, mais empêchez les écritures concurrentes.
Contrôlez les URL canoniques, le sitemap, les directives robots et un échantillon d’inspection. Google précise qu’une migration d’URL est traitée page par page et peut produire des fluctuations temporaires ; il n’existe pas de délai universel garanti.
Mettez à jour les liens internes et les références externes importantes. Fermez la migration seulement lorsque les critères fonctionnels, de données et de recherche sont atteints.
Migration WordPress checklist finale
- [ ] Périmètre et éléments inchangés écrits.
- [ ] Inventaire technique et fonctionnel terminé.
- [ ] Responsables, fenêtre et critères de décision nommés en privé.
- [ ] Base et fichiers sauvegardés dans un état cohérent.
- [ ] Restauration et retour réalisables.
- [ ] Destination compatible et protégée de l’indexation.
- [ ] Services externes identifiés.
- [ ] Première copie et synchronisation finale planifiées.
- [ ] Remplacement d’URL compatible avec les données sérialisées.
- [ ] Correspondance des anciennes et nouvelles URL prête.
- [ ] DNS, HTTPS, redirections et version canonique vérifiés.
- [ ] Formulaires, e-mails, paiements et tâches testés.
- [ ] Permaliens, médias, comptes et administration testés.
- [ ] Canoniques, robots, sitemap et schema contrôlés.
- [ ] Gel des écritures et réconciliation documentés.
- [ ] Heure de bascule enregistrée.
- [ ] Critères de maintien ou de retour appliqués.
- [ ] Surveillance et fermeture de la migration attribuées.
Points clés à retenir
Une migration réussie n’est pas une copie qui se termine sans message d’erreur. C’est un transfert dont le périmètre est connu, dont les données restent cohérentes, dont les parcours fonctionnent et dont le retour est possible avant que l’incident ne l’impose.
Utilisez cette migration WordPress checklist pour séparer préparation, copie, validation, bascule et surveillance. Changez le moins de variables possible, gardez les preuves privées et prenez la décision finale à partir de contrôles convenus.
Pour évaluer la destination avant le projet, le Pillar Choisir un hébergement WordPress en 2026 fournit une grille de responsabilités, sauvegarde, migration et support.