Changer d’hébergeur sans perdre son référencement ni ses e-mails

Changer d’hébergeur sans perdre son référencement ni ses e-mails demande de séparer deux sujets : le site, qui peut être préparé et testé sur le nouveau serveur avant toute bascule, et le DNS, qui décide où arrivent les visiteurs et les messages. Si les adresses des pages restent identiques, que le site est recetté avant la bascule et que les enregistrements de messagerie (MX, SPF, DKIM) sont conservés, le risque est fortement réduit, sans être nul.

Aucune migration ne peut être promise sans incident ; l’objectif est de la préparer pour qu’un problème soit détecté et corrigé vite. Cet article donne la méthode, étape par étape. Notre page DevOps et hébergement décrit l’accompagnement que nous proposons, et celle de la refonte de site web s’applique si la migration s’accompagne d’une évolution du site.

Qu’est-ce qui peut réellement coûter du référencement lors d’une migration ?

Pour Google, changer d’hébergeur sans changer les adresses est un cas plus simple qu’un changement de domaine. Google documente le déplacement d’un site sans modification d’URL et recommande de vérifier que le nouveau serveur répond correctement avant de basculer (Google Search Central, déplacer un site sans changement d’URL). Les pertes viennent généralement d’erreurs évitables :

• pages qui répondent en erreur ou lentement sur le nouveau serveur ;
• fichier robots.txt ou balise noindex de l’environnement de test laissé en production ;
• redirections HTTP vers HTTPS absentes ou en boucle, certificat invalide ;
• URL modifiées sans redirection ;
• indisponibilité prolongée au moment de la bascule.

Si, en plus de l’hébergeur, vous changez de domaine ou d’adresses, le sujet devient une migration de site avec changement d’URL, décrite dans la documentation de Google. Notre article sur la refonte d’un site en conservant son référencement traite ce cas.

Quelle préparation faire avant de toucher au DNS ?

1. Inventaire. Notez le domaine, le registrar, l’hébergeur actuel, les sous-domaines, les certificats, les tâches planifiées, les services tiers (formulaires, paiement, messagerie) et les accès de chaque élément.
2. Sauvegarde complète. Fichiers, base de données et configuration, stockées hors de l’ancien hébergeur. Testez la restauration : une sauvegarde jamais restaurée est une hypothèse. Voir notre article sur la règle 3-2-1.
3. Capture de l’existant. Exportez la liste des URL (plan du site, Search Console), les redirections existantes, les fichiers robots.txt et sitemap, et quelques mesures de référence (pages indexées, performances).
4. État du DNS. Exportez la zone DNS complète, y compris les enregistrements que l’on oublie : MX, SPF, DKIM, DMARC, vérifications de domaine, sous-domaines.
5. Plan de retour arrière. Décidez à l’avance comment revenir à l’ancien hébergeur si un problème bloquant apparaît, et conservez l’ancien service actif pendant la transition.

Une règle utile : n’annulez jamais l’ancien contrat avant d’avoir vérifié que tout fonctionne et qu’aucune donnée n’y reste uniquement.

Comment protéger ses e-mails pendant la migration ?

Le site et la messagerie utilisent souvent le même nom de domaine, mais ne sont pas forcément hébergés au même endroit. Ce sont les enregistrements MX du DNS qui indiquent où livrer les e-mails. Si vous changez les serveurs de noms ou recréez la zone DNS sans reprendre ces enregistrements, les messages peuvent cesser d’arriver ou être mal livrés.

Précautions :

• copier toute la zone DNS avant de modifier quoi que ce soit, puis la recréer à l’identique chez le nouveau fournisseur de DNS si vous en changez ;
• ne modifier que l’enregistrement A ou CNAME du site lorsque seul l’hébergement web change, en laissant MX, SPF, DKIM et DMARC intacts ;
• vérifier ensuite l’envoi et la réception depuis plusieurs adresses, et le résultat des contrôles d’authentification ;
• contrôler les e-mails envoyés par le site (formulaire de contact, commandes) : le nouveau serveur doit être autorisé à envoyer pour votre domaine.

Notre article sur SPF, DKIM et DMARC explique comment ces enregistrements protègent l’envoi de vos messages. Si votre messagerie est hébergée par le même prestataire que le site, prévoyez aussi sa migration, boîtes et historique compris, avec un calendrier distinct.

Comment tester le nouveau site avant la bascule (recette) ?

La recette consiste à vérifier le site sur le nouvel hébergeur alors que le public voit encore l’ancien. Selon les environnements, on peut y accéder via une adresse provisoire ou en pointant temporairement le nom de domaine vers le nouveau serveur sur un poste de test.

Vérifiez au minimum :

• les pages principales, avec images, styles et scripts ;
• les formulaires et la réception des e-mails de notification ;
• le fonctionnement du HTTPS et la redirection depuis HTTP ;
• le robots.txt, la balise noindex et le sitemap : l’environnement de test ne doit pas être bloqué ni indexable par erreur ;
• les redirections existantes et la page 404 ;
• les performances et les erreurs dans les journaux ;
• les connexions aux services tiers (paiement, agenda, API).

Protégez l’environnement de test s’il contient de vraies données, et désactivez les envois réels de paiements ou de messages pendant les essais.

Comment réaliser la bascule DNS avec le moins de risque ?

Le DNS fonctionne avec une durée de vie (TTL) : tant qu’elle n’est pas écoulée, certains visiteurs peuvent encore être dirigés vers l’ancienne adresse. Une pratique courante consiste à abaisser le TTL quelques jours avant la bascule, afin que le changement se propage plus vite, puis à le remonter après validation. Vérifiez ce que permet votre fournisseur DNS.

Un déroulé simple :

1. Choisir un créneau calme, avec une personne disponible pour contrôler.
2. Geler les contenus (pas de commande ni de publication) le temps de la migration finale, ou resynchroniser la base juste avant la bascule.
3. Modifier l’enregistrement concerné (A, AAAA ou CNAME) vers le nouveau serveur.
4. Contrôler le site, le HTTPS, les e-mails et les formulaires depuis plusieurs réseaux.
5. Garder l’ancien hébergement actif quelques jours, le temps de la propagation et de la vérification.
6. Surveiller les erreurs, la disponibilité (voir supervision et alertes) et la Search Console.

Pendant la période de transition, assurez-vous que l’ancien et le nouveau serveur affichent la même chose : sinon, des visiteurs verront des versions différentes.

Que surveiller dans les jours qui suivent ?

• Search Console : erreurs d’exploration, pages exclues, problèmes de sécurité ou de serveur. Si besoin, demandez une nouvelle exploration de pages importantes (Google, demander une exploration).
• Réception et envoi des e-mails, y compris les messages en spam.
• Journaux d’erreurs du nouveau serveur (404, 500, certificats).
• Performances : un serveur différent peut changer les temps de réponse, dans un sens ou dans l’autre.
• Sauvegardes : vérifiez que le nouvel hébergeur sauvegarde bien ce qui doit l’être, et testez une restauration.

Un léger mouvement dans les rapports est possible après un changement technique ; ne tirez pas de conclusion sur quelques jours, mais corrigez immédiatement toute erreur visible.

Exemple fictif : un site de PME et sa messagerie

Cet exemple est fictif et ne décrit ni un client ni un résultat mesuré.

Une PME souhaite quitter un hébergement mutualisé jugé lent. Avant la migration, elle exporte la zone DNS et constate que la messagerie est gérée par un autre service, via des enregistrements MX. Elle prépare le nouveau site sur une adresse provisoire, vérifie le formulaire et le HTTPS, abaisse le TTL, puis ne modifie que l’enregistrement du site. Les enregistrements de messagerie restent inchangés. Elle conserve l’ancien hébergement une semaine, surveille la Search Console et résilie seulement après vérification. La valeur de la méthode tient ici à la séparation du site et de la messagerie, pas à un résultat chiffré.

FAQ

Combien de temps dure la propagation DNS ?

Elle dépend du TTL et des caches des fournisseurs ; elle peut être rapide ou prendre plus longtemps. C’est pourquoi on garde l’ancien serveur actif pendant la transition.

Dois-je prévenir Google d’un changement d’hébergeur ?

Sans changement d’adresses, aucune déclaration particulière n’est requise ; il suffit que le nouveau serveur réponde correctement. Surveillez la Search Console. Un changement de domaine, lui, se déclare via l’outil de changement d’adresse.

Peut-on migrer sans coupure ?

Dans de nombreux cas, la coupure peut être très courte ou imperceptible si le site est prêt et testé, mais cela dépend de l’application, de la base de données et du DNS. Demandez le plan de bascule par écrit.

Conclusion

Une migration d’hébergeur réussie repose sur la préparation : sauvegarde testée, zone DNS exportée, recette sur le nouveau serveur, bascule limitée au site, ancien hébergement conservé le temps de vérifier. Si vous souhaitez organiser la vôtre, consultez notre page DevOps et hébergement, celle de la refonte de site web ou contactez-nous.