Déménager un site web vers un autre hébergement : comment éviter la panne et les problèmes SEO

Déménager votre site web vers un autre hébergement donne l’impression que vous éteignez l’ancien serveur à un moment donné et espérez que le nouveau prendra le relais. C’est exactement comme ça qu’on obtient une interruption inutile, des e-mails manquants ou un site à moitié sur le mauvais serveur.

Un déménagement sûr fonctionne autrement : vous construisez d’abord une copie complète sur le nouvel hébergement, vous la testez pendant que l’ancien site reste simplement en ligne, et ce n’est qu’ensuite que vous modifiez le DNS. Si vous conservez le même nom de domaine et les mêmes URL, un changement d’hébergement n’a d’ailleurs pas besoin d’être une migration SEO classique avec des centaines de redirections.

Quand est-il temps de changer d’hébergement ?

Un changement d’hébergement est pertinent lorsque l’environnement actuel freine structurellement votre site : pannes récurrentes, réponse serveur lente, ressources insuffisantes, assistance peu claire, versions logicielles obsolètes ou une offre qui ne correspond plus au site.

Le prix peut bien sûr aussi être une raison, mais ne déménagez pas uniquement pour quelques euros de différence si, en échange, vous renoncez à un bon support, à des sauvegardes ou à la stabilité. Pour un site d’entreprise, une assistance prévisible est souvent plus importante que l’offre la moins chère.

Vérifie aussi avant de décider si le problème vient réellement de l’hébergement. Un site WordPress lourd avec de mauvais plugins ne devient pas automatiquement rapide sur un autre serveur. Si la performance est la raison principale, examine d’abord ce qui ralentit le site. Le guide Accélérer WordPress aide à distinguer les problèmes d’hébergement des problèmes applicatifs.

Qu’est-ce qui doit réellement être migré ?

Élément	Pourquoi c’est important
Fichiers du site web	WordPress/core, thèmes, plugins, uploads, personnalisations et configuration
Base de données	Pages, produits, paramètres, utilisateurs et beaucoup de données de plugins/de boutique
Domaine/DNS	Détermine vers quel serveur le site web et les services pointent
SSL/TLS	Garantit que HTTPS fonctionne correctement et de manière valide dans le nouvel environnement
E-mail et enregistrements MX	Doit être vérifié séparément si le mail est lié au même domaine
Cronjobs / tâches	Peuvent piloter des commandes, des imports, des sauvegardes ou des synchronisations
Connexions externes	Paiements, API, webhooks, SMTP, formulaires, analytics

Avec WordPress, les fichiers et la base de données sont deux parties distinctes d’un même site. La documentation officielle de WordPress souligne donc que, pour une sauvegarde complète, tu as besoin des deux.

Étape 1. Fais une sauvegarde restaurable avant de changer quoi que ce soit

Commence par une sauvegarde complète des fichiers et de la base de données. Conserve-la en dehors de l’environnement d’hébergement actuel. Une sauvegarde qui se trouve uniquement sur le même serveur aide peu si tu n’y as plus accès pendant la migration.

Vérifie aussi que tu sais comment restaurer. Pour une boutique en ligne ou un site avec beaucoup de changements, le timing est important : une copie de la base de données d’hier peut signifier que de nouvelles commandes, formulaires ou comptes manquent. Planifie donc le moment où tu fais la dernière synchronisation.

Étape 2. Configure le nouvel hébergement avant de modifier ton DNS

Sur le nouvel hébergement, prépare d’abord l’environnement du site, la base de données, la version PHP, les certificats et les réglages serveur nécessaires. Ne mets encore rien en ligne pour le public.

Vérifie que le nouvel environnement est compatible avec ton CMS et tes plugins. WordPress peut être déplacé vers un nouveau serveur sans devoir être réinstallé. Si le domaine et les URL restent identiques, les fichiers et la base de données peuvent souvent être simplement copiés ; si les informations de base de données changent, elles doivent par exemple être mises à jour dans wp-config.php.

As-tu des éléments spécifiques au serveur comme des redirections, des tâches cron, des règles de sécurité, de la mise en cache ou un CDN ? Intègre-les à ton inventaire. Copier uniquement les pages visibles n’est pas la même chose que migrer tout l’environnement de production.

Étape 3. Copie le site web et la base de données vers le nouveau serveur

Pour un site WordPress, tu peux migrer manuellement, utiliser un outil de migration fiable ou faire effectuer le transfert par un administrateur/une société de hosting. La méthode choisie est moins importante que les vérifications ensuite.

Lors d’une migration manuelle, les fichiers sont placés dans la nouvelle racine web et la base de données est importée. Ensuite, vérifie les connexions à la base de données, les chemins de fichiers, les droits d’écriture et la configuration du serveur. Avec WooCommerce ou d’autres sites dynamiques, il faut être particulièrement vigilant pour qu’aucune nouvelle transaction ne se retrouve désynchronisée entre l’ancienne et la nouvelle base de données pendant le dernier basculement.

Étape 4. Teste le nouvel hébergement pendant que l’ancien site reste en ligne

C’est l’étape qui évite l’indisponibilité. Teste le nouveau site avant le basculement DNS via un nom d’hôte temporaire ou un fichier hosts local, afin que toi seul voies le nouveau serveur tandis que les visiteurs habituels continuent d’aller sur l’ancien.

Ne vérifie pas uniquement la page d’accueil. Ouvre les principales pages d’atterrissage, les formulaires, la fonction de recherche, la connexion, les téléchargements et la navigation mobile. Pour une boutique en ligne, teste les variantes de produits, le panier, le paiement, le prestataire de paiement en mode test sécurisé, les e-mails de confirmation et d’éventuelles intégrations de stock ou avec l’ERP.

Fais aussi attention aux paramètres des robots et de l’indexation. Un environnement de test ne doit pas apparaître par accident dans Google. Google recommande noindex pour un hôte de test temporaire. Lorsque tu passes en production, tu dois bien sûr supprimer ces blocages temporaires.

Étape 5. Vérifie le DNS et baisse au préalable le TTL lorsque c’est pertinent

Le changement d’hébergement définitif se fait lorsque le DNS commence à pointer vers la nouvelle infrastructure. Google conseille, lors d’une migration d’hébergement planifiée, d’abaisser au préalable le TTL des enregistrements DNS concernés à une valeur prudemment basse, par exemple quelques heures, idéalement au moins une semaine avant le déménagement. Ainsi, les caches peuvent se rafraîchir plus vite lorsque tu bascules.

Avant la modification, fais une copie de ta zone DNS actuelle. Ne regarde pas seulement l’enregistrement A ou AAAA du site. Les enregistrements MX, SPF, DKIM, DMARC, les sous-domaines, les enregistrements de vérification et des services externes peuvent tous se trouver dans la même zone. Une zone DNS « propre » erronée peut faire fonctionner ton site web alors que l’e-mail ou d’autres services tombent en panne.

Étape 6. Effectue une dernière synchronisation juste avant la mise en production

Pour un site vitrine, il est possible que rien ne change entre la première copie et la mise en production. Pour une boutique en ligne, un système de réservation ou un formulaire très fréquenté, cela peut être différent. Les nouvelles données qui arrivent sur l’ancienne base de données après avoir réalisé la première copie, tu ne dois pas les perdre.

Planifie donc une courte fenêtre de modification ou une dernière synchronisation contrôlée de la base de données. Pour les boutiques en ligne, il peut être judicieux de mettre temporairement les commandes en pause ou d’utiliser un bref message de maintenance si nécessaire afin de garantir la cohérence des données. Quelques minutes planifiées et clairement communiquées, c’est mieux que de devoir reconstruire des commandes plus tard.

Étape 7. Ne modifie le DNS que lorsque le nouveau site est vraiment prêt

Si les tests sont au vert, vous adaptez les enregistrements DNS ou les serveurs de noms pertinents. À partir de ce moment, différents fournisseurs d’accès à Internet utiliseront les nouvelles informations à des moments différents. C’est pourquoi l’ancien site doit continuer à fonctionner pendant la transition.

Google Search Central conseille, lors d’un changement d’hébergement sans modification des URL, de surveiller le trafic à la fois sur l’ancienne et la nouvelle infrastructure. Dès que l’ancien serveur ne reçoit plus de trafic et que le nouvel environnement fonctionne correctement pour les utilisateurs et Googlebot, vous pourrez résilier l’ancien hébergement ultérieurement.

Étape 8. Vérifiez le SSL, les formulaires, l’e-mail et les liens externes

Une page d’accueil qui s’ouvre ne signifie pas une migration réussie. Vérifiez HTTPS et la chaîne de certificats, les formulaires, SMTP, la délivrabilité des e-mails, les webhooks, les prestataires de paiement, l’analytics, la vérification Search Console, le cache et les tâches planifiées.

Envoyez vous-même un test via chaque formulaire important. Pour une boutique en ligne, passez une commande test complète si cela peut se faire en toute sécurité. Vérifiez que les confirmations arrivent, que les transactions sont correctement enregistrées et que les systèmes externes reçoivent les bons callbacks.

Consultez également les journaux du serveur et de l’application. Un site peut sembler normal pour les visiteurs alors qu’en arrière-plan apparaissent des messages d’erreur, des time-outs ou des tâches cron qui échouent.

Étape 9. L’URL ne change pas ? Alors gardez-la vraiment identique

Lorsque vous ne changez que l’hébergement, c’est justement un avantage que les URL visibles restent identiques. Conservez les mêmes URL HTTPS, les canoniques, les liens internes et le sitemap. Ainsi, Google n’a pas besoin d’apprendre une nouvelle structure d’URL.

Pendant les tests, n’utilisez pas de nom de domaine temporaire qui pourrait ensuite rester par accident dans les liens, les images ou les canoniques. Après la mise en ligne, contrôlez un échantillon de pages importantes avec Search Console et surveillez les erreurs d’exploration ou d’indexation.

Étape 10. Votre domaine ou votre structure d’URL change aussi ? Traitez cela comme une migration SEO distincte

Un changement d’hébergement et un changement de domaine ne sont pas le même projet. Si d’anciennes URL changent, fais un mapping de chaque ancienne URL importante vers la nouvelle URL la plus pertinente et utilise des redirections permanentes côté serveur, comme 301 ou 308.

Google conseille de ne pas faire toutes les grandes modifications en même temps, lorsque c’est possible. Donc : si tu veux modifier l’hébergement, le domaine, le CMS et le design complet, réduis le risque en séparant ces changements quand c’est réalisable.

Une migration de domaine implique aussi des liens internes mis à jour, des canonicals, hreflang si pertinent, un nouveau sitemap, un suivi dans Search Console et, pour un véritable changement de domaine, l’outil Change of Address. Laisse les redirections en place longtemps ; Google recommande généralement au moins un an.

Que peut-il mal se passer après un déménagement WordPress ?

Symptôme	Orientation probable
Page blanche / 500	Erreur PHP, conflit plugin/thème, configuration ou extension manquante
Error establishing database connection	Mauvaises informations de base de données, hôte ou base de données injoignable
Images manquantes	Fichiers incomplets, droits ou anciens chemins/URL
Boucle de redirection	La configuration HTTPS/proxy/cache/redirection entre en conflit
Le formulaire n’envoie rien	SMTP, DNS, pare-feu ou configuration mail externe
Toi seul vois l’ancien site	Cache DNS local/FAI ou fichier hosts
Le paiement échoue	Webhook, API, SSL, session/cache ou paramètres de paiement

Dans une telle situation, ne supprime pas des plugins au hasard et ne continue pas à modifier le DNS. Note l’erreur, compare l’ancien et le nouveau et procède méthodiquement. Si le site n’est pas du tout accessible après le déménagement, c’est un autre parcours de diagnostic qu’un simple choix d’hébergement.

Comment éviter une interruption de service lors d’un déménagement de site web ?

Le principe est simple : l’ancien environnement reste disponible jusqu’à ce que le nouveau ait prouvé qu’il fonctionne et que le DNS ait été en grande partie basculé. Tu copies donc d’abord, tu testes ensuite, et tu ne bascules qu’en dernier.

Sur un site dynamique, « zéro interruption » ne signifie pas la même chose que « zéro risque de migration ». Pendant la transition, des commandes, des réservations ou des formulaires peuvent encore arriver sur l’ancien environnement. C’est pourquoi la cohérence des données est tout aussi importante que la question de savoir si la page d’accueil reste en ligne.

Quand vaut-il mieux faire réaliser le transfert ?

Un simple site vitrine, avec suffisamment de connaissances techniques, peut être transféré par vous-même. Faites appel à de l’aide dès que des e-mails, des commandes de boutique en ligne, des comptes membres, le multilingue, du sur-mesure, des API externes ou des positions SEO importantes entrent en jeu.

Même lorsque vous n’avez pas accès au DNS, à la base de données ou à l’ancien hébergement, il est judicieux de commencer par régler la propriété et les accès. Une migration sous pression temporelle alors que l’ancien prestataire veut déjà couper le service est précisément le scénario dans lequel les erreurs deviennent coûteuses.

Moonbeetle peut accompagner les transferts techniques et les contrôles via les services de webmaster. La séquence la plus sûre est toujours la même : inventorier, copier, tester, basculer, contrôler, et seulement ensuite fermer l’ancien environnement.

Questions fréquentes sur le transfert d’un site web vers un autre hébergement

Vais-je perdre mes positions Google si je change d’hébergement ?

Pas automatiquement. Si votre domaine et vos URL restent identiques et que le nouveau serveur continue de servir les pages de façon rapide et fiable, un changement d’hébergement est surtout une modification d’infrastructure. Google avertit toutefois que l’activité de crawl peut fluctuer temporairement. Les gros problèmes surviennent surtout en cas d’indisponibilité, de blocages ou de modifications d’URL inattendues.

Dois-je mettre en place des redirections 301 si seul l’hébergement change ?

Normalement non si toutes les URL visibles restent exactement les mêmes. Les redirections sont nécessaires lorsque les URL ou les domaines changent. Vérifiez toutefois que HTTPS, www/non-www et les redirections existantes conservent le même comportement.

Combien de temps l’ancien hébergement doit-il rester en service ?

Jusqu’à ce que tu sois sûr que les utilisateurs, les robots d’exploration et les services utilisent le nouvel environnement et que l’ancien serveur ne reçoive plus de trafic pertinent. Google conseille de surveiller les logs des deux environnements pendant la transition.

Puis-je migrer un site WordPress sans le reconstruire ?

Oui. WordPress indique explicitement que, lors d’un transfert vers un nouveau serveur, tu n’as pas besoin de réinstaller. Tu déplaces les fichiers et la base de données, et tu ajustes la configuration là où le nouvel environnement l’exige.

Faut-il migrer l’e-mail avec le site web ?

Pas nécessairement. Le site web et l’e-mail peuvent rester chez des fournisseurs différents. Mais vérifie soigneusement les enregistrements MX, SPF, DKIM et DMARC afin qu’une modification du DNS n’interrompe pas le courrier par inadvertance.

Quand une migration d’hébergement est-elle aussi une migration SEO ?

Dès que le nom de domaine, le protocole ou les chemins d’URL changent de manière visible. Dans ce cas, tu as besoin d’un mapping d’URL, de redirections permanentes et de contrôles supplémentaires dans la Search Console.

Ressources pour des vérifications complémentaires

• Google Search Central — changer d’hébergement sans modification des URL
• Google Search Central — migrations de site avec modifications des URL
• Ressources pour développeurs WordPress — Déplacer WordPress
• Ressources pour développeurs WordPress — Sauvegardes