Une migration réussie ne consiste pas seulement à afficher la page d’accueil sur un nouvel hébergement. Il faut préserver les contenus, les données récentes, les services liés au domaine et les parcours importants. Préparez ce qui change, ce qui doit continuer à fonctionner et la manière de revenir à une situation maîtrisée.
Ce guide concerne un site WordPress. Il distingue le déplacement technique, les changements d’URL et la messagerie. Il ne promet ni absence totale d’interruption ni conservation garantie des positions.
1. Définir le périmètre avant de commencer
- Hébergement seulement : le domaine et les chemins restent les mêmes ; le serveur change.
- Changement d’adresse : domaine, protocole ou chemins changent ; une correspondance d’URL est nécessaire.
- Refonte ou changement d’outil : contenu et fonctionnement peuvent également évoluer ; séparez les étapes lorsque c’est possible.
- Messagerie : indiquez explicitement si elle reste en place ou si comptes et messages doivent être transférés.
Pour un déplacement sans changement d’URL, n’ajoutez pas des redirections simplement parce que l’hébergement change. Vérifiez d’abord le fonctionnement et la nouvelle destination technique. Conseils Google pour un changement d’hébergement.
2. Faire l’inventaire et préparer le retour
Conservez contenus, médias, fichiers téléchargeables, réglages utiles, tâches planifiées et services externes. Notez les pages importantes, les URL recevant des liens, les pages d’entrée et les actions commerciales. Vérifiez les accès au domaine, à l’hébergement et aux rapports des moteurs.
Préparez une sauvegarde récupérable et une copie de la zone DNS. Définissez qui décide de la bascule et quels problèmes imposeraient un retour. Un retour DNS ne fusionne pas les commandes créées sur deux serveurs : prévoyez aussi le traitement des données.
3. Préparer une copie de test
Installez la destination avec les versions et ressources nécessaires au site. Protégez l’environnement de préparation et évitez son indexation. Neutralisez ses envois, paiements et effets externes ; n’utilisez pas de véritables transactions pour une simple vérification.
Transférez fichiers et base avec une méthode adaptée à WordPress. Si une adresse change dans des données sérialisées, un remplacement de texte brut peut endommager ces données : utilisez une méthode qui les gère correctement. Une copie à une autre adresse peut demander une procédure de migration distincte de la restauration. Documentation de migration WordPress.
4. Tester avant la bascule
- Ouvrez plusieurs modèles de pages, images et documents.
- Vérifiez navigation, recherche interne, administration et droits nécessaires.
- Testez formulaire et réception du message, avec un destinataire de test maîtrisé.
- Pour une boutique, testez panier et paiement avec le mode de test prévu par la solution.
- Vérifiez intégrations, tâches planifiées et mesure des événements utiles.
- Préparez le certificat et le comportement HTTPS du domaine final avec l’hébergeur.
Notez le résultat attendu de chaque contrôle. La réussite de l’accueil ne prouve pas le fonctionnement des pages de produit, des téléchargements ou des formulaires.
5. Préparer les URL si les adresses changent
Établissez une ligne par ancienne URL importante avec sa destination et son traitement. Recherchez une page réellement équivalente. Pour un contenu supprimé sans remplacement pertinent, prévoyez la réponse adaptée plutôt qu’une redirection systématique vers l’accueil.
Lors d’un changement d’URL, utilisez des redirections permanentes adaptées, mettez à jour liens internes, URL canoniques et sitemaps, puis surveillez les anciennes et nouvelles adresses. Google recommande de conserver les redirections au moins un an ; des fluctuations temporaires restent possibles. Guide Google des changements d’URL.
Modèle fictif : /ancien-service/ → /prestations/service/ si le service correspond réellement. Pour une boutique, les catégories, produits, variantes et paramètres utiles demandent un examen plus précis.
6. Protéger les écritures récentes et la messagerie
Entre la première copie et la bascule, des données peuvent apparaître : commandes, réservations, comptes, commentaires ou formulaires. Définissez un arrêt temporaire des écritures ou une méthode de synchronisation maîtrisée. Réalisez la copie finale selon ce plan et empêchez les deux versions de fonctionner durablement comme deux sources indépendantes.
Pour les e-mails, relevez les MX et l’authentification. Si les boîtes changent, préparez leur création et le transfert des messages séparément. Gardez les anciens accès le temps de confirmer le résultat ; un changement DNS ne copie pas les archives de messagerie.
7. Effectuer la bascule avec un responsable
- Confirmez les tests et la sauvegarde finale.
- Appliquez le plan prévu pour les écritures récentes.
- Modifiez uniquement les destinations DNS ou la délégation préparées, en tenant compte du TTL et de DNSSEC.
- Retirez les protections de préparation qui ne doivent plus s’appliquer aux pages publiques, tout en conservant les restrictions nécessaires ailleurs.
- Activez les règles d’URL et les services prévus, sans faire exécuter les mêmes tâches par deux copies.
- Vérifiez le site final, les messages et les fonctions commerciales.
Ne résiliez pas l’ancien service dès que votre navigateur affiche la nouvelle page. Gardez une période de contrôle adaptée au projet et aux caches, avec un propriétaire clair des données récentes.
8. Contrôler les jours suivants
Vérifiez réponses des pages, redirections, liens, médias, erreurs et formulaires. Contrôlez les outils de mesure : un changement de collecte peut ressembler à une chute de trafic. Surveillez également l’indexation et les pages importantes dans Search Console et Bing Webmaster Tools.
Selon le type de changement, utilisez les outils de changement d’adresse pris en charge pour le cas concerné ; ils ne servent pas à tout déplacement d’hébergement. Gardez un journal des anomalies et corrections plutôt que de modifier plusieurs paramètres sans trace.
Outils cités dans l’article d’origine
Search Console sert au suivi des informations Google ; Screaming Frog SEO Spider à examiner URL et liens ; Moz Pro au contexte de suivi. Redirect Path aide à examiner un parcours de redirections, mais ne configure pas à lui seul les règles du serveur. Les fonctions de redirection de Yoast SEO dépendent du produit utilisé.
PageSpeed Insights, GTmetrix et Pingdom apportent des observations de performance. WordPress, Shopify et Magento restent les plateformes mentionnées dans l’ancienne sélection : leur nom ne garantit pas le succès d’une migration. Ce guide suit WordPress ; un changement de plateforme demande aussi un plan de données et de fonctions.
Checklist et questions fréquentes
- Périmètre, responsable et critères de retour définis.
- Copie récupérable et réglages DNS conservés.
- Destination testée sur les parcours importants.
- URL et règles préparées si les adresses changent.
- Données récentes et messagerie traitées explicitement.
- Contrôles après bascule réalisés et anomalies suivies.
Dois-je modifier mes URL en changeant d’hébergement ?
Non. Gardez-les lorsqu’aucun changement n’est nécessaire à votre projet.
Puis-je tout refaire en même temps ?
Lorsque vous pouvez séparer hébergement, domaine, structure et design, vous facilitez le diagnostic des problèmes.
Pour organiser une migration chez iMasterWeb, présentez le site et le périmètre souhaité. N’envoyez pas de mots de passe dans le formulaire.
Votre site est ancien ? Voyez aussi notre page sur la refonte de site internet.