Migrer

Changer d’hébergeur sans perdre son référencement

Une migration bien menée est invisible pour vos visiteurs comme pour Google. Voici la procédure, et les deux pièges qui font échouer les autres.

Mis à jour le 9 septembre 2026

Certains liens de cette page sont des liens d'affiliation : si vous souscrivez après avoir cliqué, nous percevons une commission, sans surcoût pour vous. Cela ne change ni notre classement ni nos réserves, qui reposent sur les caractéristiques réelles des offres. En savoir plus

Changer d'hébergeur est une opération courante, que la plupart des hébergeurs prennent d'ailleurs en charge gratuitement pour attirer un nouveau client. Elle n'a rien de risqué en soi.

Le référencement n'est pas affecté dès lors que deux conditions sont remplies : les adresses des pages restent identiques, et le site demeure accessible pendant la bascule. Tout le reste du travail consiste à garantir ces deux points.

Ce qui menace vraiment le référencement

Contrairement à une crainte répandue, changer de serveur n'a aucune incidence directe sur le classement. Google constate une nouvelle adresse IP, ce qui ne constitue pas un signal négatif. Trois choses seulement peuvent nuire, et elles sont toutes évitables.

Les trois vrais risques d’une migration
Risque	Conséquence	Comment l’éviter
Coupure prolongée	Pages inaccessibles lors du passage du robot	Garder les deux hébergements actifs pendant la bascule
URL modifiées	Pages perdues, liens entrants cassés	Conserver les mêmes adresses, ou poser des redirections permanentes
Adresse de test indexée	Contenu dupliqué entre deux adresses	Bloquer l’indexation de l’adresse temporaire

Une migration qui respecte ces trois points passe totalement inaperçue. Elle améliore même souvent les indicateurs de vitesse si le nouvel hébergement est plus performant.

La procédure, dans l’ordre

1. Souscrire sans résilier

Le nouvel hébergement doit être actif pendant que l'ancien continue de servir le site. Résilier avant d'avoir migré est l'erreur qui transforme une opération simple en urgence.

2. Sauvegarder intégralement

Fichiers et base de données, avant toute manipulation, et stockés ailleurs que sur les deux serveurs concernés. Cette sauvegarde ne servira probablement pas, mais son absence se paie cher dans le cas contraire.

3. Copier et tester

Transférez les fichiers, importez la base, puis testez le site sur le nouveau serveur avant tout changement DNS. Deux méthodes existent : l'adresse temporaire fournie par l'hébergeur, ou la modification du fichier hosts de votre poste, qui permet de voir le nouveau serveur sans que personne d'autre ne soit affecté.

La méthode du fichier hosts est préférable : elle permet de tester exactement l'adresse finale, y compris les liens internes et les certificats, sans risquer qu'une adresse temporaire soit indexée.

4. Abaisser la durée de vie DNS

Quelques jours avant la bascule, réduisez la valeur TTL de vos enregistrements DNS, par exemple à 300 secondes. La propagation du changement sera alors quasi immédiate le jour J, au lieu de s'étaler sur des heures.

5. Basculer

Modifiez les enregistrements DNS vers le nouveau serveur. Pendant la propagation, une partie des visiteurs atteint l'ancien serveur et l'autre le nouveau : c'est pourquoi les deux doivent rester fonctionnels et servir le même contenu.

6. Vérifier, puis attendre

Contrôlez le site, les formulaires, le certificat, et surtout la messagerie. Conservez l'ancien hébergement une à deux semaines : c'est peu coûteux et cela offre un filet de sécurité si un problème apparaît tardivement.

Le piège numéro un : la messagerie

C'est de très loin l'incident le plus fréquent lors d'un changement d'hébergeur, et il ne concerne pas le site mais les e-mails.

Si vos adresses professionnelles sont hébergées chez l'ancien prestataire, la bascule DNS redirige aussi la messagerie. Les messages arrivent alors sur un serveur où les boîtes n'existent pas, et sont perdus ou rejetés.

Noter les enregistrements MX, SPF et DKIM avant toute modification de la zone DNS.
Récupérer le contenu des boîtes avant la bascule, par téléchargement local ou synchronisation vers le nouveau serveur.
Recréer les boîtes sur le nouvel hébergement et les tester avant de basculer, pas après.
Ou dissocier la messagerie en la confiant à un service dédié, ce qui rend les futurs changements d'hébergeur totalement indolores.

Une messagerie professionnelle coupée pendant deux jours passe rarement inaperçue, et les messages perdus pendant cette période ne sont pas récupérables. Traitez ce point avant le site, pas après.

Le piège numéro deux : les éléments invisibles

Une migration réussie ne se limite pas aux fichiers et à la base. Plusieurs éléments ne se copient pas automatiquement et manquent une fois le site en ligne.

Les tâches planifiées, qui déclenchent les publications programmées, les envois automatiques ou les nettoyages de base. Elles ne se copient jamais et doivent être recréées.
Les redirections configurées au niveau du serveur plutôt que dans le site.
Les certificats SSL : le nouveau serveur doit générer le sien, ce qui peut prendre quelques minutes après la bascule DNS.
Les versions de langage, qui peuvent différer entre les deux hébergements et provoquer des erreurs sur un code ancien.
Les fichiers de configuration comme .htaccess, parfois exclus des transferts automatiques parce qu'ils sont masqués.

Établissez la liste de ces éléments avant de migrer plutôt que de les découvrir un par un dans les jours qui suivent.

Après la bascule : que vérifier

Une checklist courte, à passer dans l'heure qui suit puis quelques jours plus tard.

Le site s'affiche correctement en HTTPS, sans avertissement de certificat
Les formulaires de contact envoient réellement, et les messages arrivent
La messagerie fonctionne dans les deux sens, envoi et réception
Les pages internes répondent, pas seulement l'accueil
L'espace d'administration est accessible
Les tâches planifiées se déclenchent
Aucune erreur serveur n'apparaît dans les journaux

Quelques jours après, vérifiez dans la Search Console qu'aucune erreur d'exploration n'est apparue. C'est le seul contrôle réellement utile côté référencement : si les pages restent accessibles et les URL inchangées, il n'y a rien d'autre à surveiller.

Évitez de migrer un vendredi ou la veille d'une période commerciale importante. Non parce que le risque est plus élevé, mais parce que la disponibilité du support, chez vous comme chez l'hébergeur, l'est nettement moins.

Questions fréquentes

Combien de temps dure une migration ?

La copie des fichiers et de la base prend de quelques minutes à quelques heures selon le volume. La propagation DNS demande ensuite jusqu'à quarante-huit heures, pendant lesquelles les deux hébergements doivent rester actifs.

Mon site sera-t-il inaccessible pendant la migration ?

Non, si vous procédez dans le bon ordre. Le nouvel hébergement est préparé et testé pendant que l'ancien continue de servir le site. La bascule DNS se fait ensuite, sans interruption pour le visiteur.

Faut-il prévenir Google ?

Ce n'est pas nécessaire si les URL ne changent pas. Google détectera simplement une nouvelle adresse IP, ce qui n'a pas d'incidence sur le classement. Une déclaration n'est requise qu'en cas de changement de nom de domaine.