Comment changer d'hébergeur sans perdre ses données ni son SEO (guide sans coupure)

La plupart des gens repoussent le changement d'hébergeur pour une seule raison : ils ont peur que le site tombe, que les e-mails s'arrêtent, ou que le classement gagné en des années disparaisse du jour au lendemain. Cette crainte est légitime, car une migration mal menée peut provoquer les trois. Une migration bien menée n'en provoque aucune, et la différence tient presque entièrement à l'ordre des opérations. Déplacez les pièces dans le bon ordre et vos visiteurs ne voient jamais le moindre à-coup. Déplacez-les dans le mauvais ordre et vous découvrez à vos dépens que le DNS ne se met pas à jour instantanément. Ce guide déroule la séquence que nous utilisons, pour que vous puissiez la reproduire.

Comment changer d'hébergeur sans perdre ses données ni son SEO ?

Vous changez d'hébergeur en construisant d'abord une copie complète et fonctionnelle de votre site sur le nouveau serveur, en la testant en privé, puis seulement en pointant votre domaine vers elle. La règle qui évite presque toutes les catastrophes : ne résiliez jamais et n'effacez jamais l'ancien hébergement tant que le nouveau site n'est pas en ligne et vérifié. L'ancien hébergeur est votre filet de sécurité.

Tout le reste découle de ce principe. Comme la nouvelle copie est construite et testée avant qu'aucun visiteur n'y soit envoyé, il n'existe aucune fenêtre où le site est cassé en public. Comme l'ancien hébergement reste en marche sans y toucher, vous pouvez tout annuler en laissant simplement le domaine là où il est. Nous gardons l'environnement précédent intact à chaque migration, pour exactement cette raison, et c'est l'unique habitude qui transforme un déménagement stressant en une opération sans histoire. Le reste de cet article, c'est ce principe découpé en étapes.

Que faut-il sauvegarder et vérifier avant de déplacer quoi que ce soit ?

Avant de toucher au nouvel hébergeur, faites une sauvegarde complète du site actuel et notez comment il est agencé. Cela veut dire chaque fichier, la base de données si le site en utilise une, vos comptes e-mail, vos enregistrements DNS, et une note des versions exactes des logiciels que le site fait tourner. Si vous ne pouvez pas restaurer l'ancien site à partir de ce que vous avez sauvegardé, vous n'êtes pas prêt à commencer.

Un « site web » comporte en général plus de pièces mobiles qu'on ne le croit, et celles qu'on oublie sont justement celles qui cassent après le déménagement. Voici la liste à compléter avant que quoi que ce soit d'autre ne se passe :

• Tous les fichiers du site. Le répertoire public complet, pas seulement le thème ou les pages que vous vous souvenez d'avoir modifiées.
• La base de données. La plupart des sites gérés par un CMS (WordPress et similaires) conservent leur contenu, leurs réglages et leurs utilisateurs dans une base de données, pas dans les fichiers. Une sauvegarde des seuls fichiers restaurera une coquille vide.
• Les comptes e-mail. Les boîtes hébergées chez votre fournisseur actuel ne suivent pas le site automatiquement. Exportez le courrier et notez chaque adresse, sinon vous risquez de perdre des messages quand le domaine bascule.
• Les enregistrements DNS. Faites une capture ou exportez votre zone DNS actuelle : les enregistrements A, les MX pour l'e-mail, les éventuels TXT pour SPF, DKIM et la vérification de domaine. Ils sont faciles à oublier et ce sont eux qui font circuler l'e-mail.
• Les notes de logiciels et de versions. La version de PHP, la version de la base de données, et tout réglage serveur dont le site dépend. Les faire correspondre sur le nouvel hébergeur évite les surprises.
• Un relevé de votre TTL actuel. J'y reviens plus bas, car il décide de la vitesse de la bascule finale.
• Une sauvegarde fraîche du jour. Si votre hébergeur actuel effectue des sauvegardes quotidiennes, récupérez la plus récente comme seconde copie, mais faites tout de même une sauvegarde fraîche vous-même le jour de la migration. Une sauvegarde de la semaine dernière ne contient pas les commandes ni les commentaires de cette semaine.

Quelles sont les étapes pour migrer un site vers un nouvel hébergeur, dans l'ordre ?

Construisez entièrement le nouveau site sur le nouvel hébergeur, confirmez qu'il fonctionne là, abaissez votre TTL DNS, puis pointez le domaine et surveillez. Faites-le dans cet ordre et le site public n'est jamais dans un état à moitié fini. La séquence ci-dessous, c'est tout le travail.

Deux points encadrent la séquence avant de la lancer. Si vous hésitez encore sur le type d'hébergement vers lequel migrer, notre guide sur l'hébergement mutualisé, VPS et infogéré explique quel type convient à quelle situation. Et prévoyez de garder l'ancien hébergeur en marche au moins quelques jours après la bascule, car tant que chaque cache DNS de la planète n'est pas à jour, certains visiteurs sont encore envoyés vers l'ancien serveur, et vous voulez qu'il réponde normalement à leur arrivée.

• 1. Créez le compte et un environnement identique sur le nouvel hébergeur. Versions de PHP et de base de données identiques ou plus récentes, même type de serveur là où cela compte. Ne pointez pas encore votre domaine dessus.
• 2. Copiez les fichiers et importez la base de données sur le nouveau serveur. Gardez la structure des fichiers identique pour n'avoir rien à réécrire.
• 3. Faites répondre le site sur une adresse temporaire fournie par le nouvel hébergeur, ou en modifiant le fichier hosts de votre ordinateur, afin de charger le vrai site depuis le nouveau serveur pendant que le public voit encore l'ancien.
• 4. Testez tout sur le nouveau serveur. Ouvrez les pages clés, envoyez un formulaire, connectez-vous, vérifiez que les images et les téléchargements se chargent, et confirmez que les parties pilotées par la base fonctionnent. Corrigez les problèmes ici, en privé, là où aucun visiteur ne peut les voir.
• 5. Abaissez votre TTL DNS sur le domaine à une valeur courte (300 secondes est courant) au moins un jour avant la bascule, pour que le changement final se propage en minutes plutôt qu'en heures.
• 6. Réduisez les écritures juste avant la bascule. Sur un site actif, mettez brièvement en pause tout ce qui modifie la base (nouvelles commandes, commentaires) et faites une synchronisation finale des fichiers et des données pour que rien créé dans la dernière heure ne reste bloqué sur l'ancien serveur.
• 7. Mettez à jour les enregistrements DNS pour pointer le domaine vers l'adresse IP du nouvel hébergeur, et ne mettez à jour les MX que si votre e-mail déménage aussi.
• 8. Surveillez les deux serveurs pendant que le DNS se propage. Le trafic passe progressivement de l'ancien au nouveau à mesure que les caches expirent. Comme les deux servent le même site, les visiteurs obtiennent une page qui fonctionne quel que soit celui qu'ils atteignent.

Comment garder le site en ligne pendant le déménagement, sans aucune coupure ?

Le zéro coupure vient du recouvrement : le nouveau site fonctionne pleinement avant que vous ne changiez le DNS, et l'ancien continue de tourner après. À aucun moment le domaine ne pointe vers un serveur vide ou cassé. Abaisser votre TTL au préalable réduit le basculement d'heures à minutes.

Ce que la plupart des gens comprennent mal, c'est de traiter le DNS comme un interrupteur qui bascule instantanément. Ce n'est pas le cas. Chaque réseau qui a interrogé votre domaine récemment garde l'ancienne réponse jusqu'à l'expiration de sa copie en cache, et ce délai d'expiration, c'est votre TTL. Si votre TTL est réglé à 24 heures, certains visiteurs continuent de tomber sur l'ancien serveur pendant une journée entière après le changement, ce qui est parfaitement acceptable si l'ancien serveur sert toujours le même site, et une vraie panne si vous l'avez déjà démantelé. Voilà pourquoi la séquence compte plus que n'importe quelle étape prise seule. Abaissez le TTL un jour à l'avance, gardez les deux serveurs actifs pendant la transition, et la « coupure » que tout le monde redoute n'a jamais vraiment d'endroit où se produire.

Comment éviter de perdre son classement SEO en changeant d'hébergeur ?

Si vous gardez le même domaine et les mêmes adresses de pages, un changement d'hébergeur à lui seul ne vous coûte pas de classement, car Google indexe vos URL, pas votre serveur. Vous perdez du SEO quand le déménagement casse quelque chose : le site tombe pendant la bascule, les adresses changent, le HTTPS cesse de fonctionner, ou un blocage d'exploration hérité de la copie de test passe avec. Protégez ces quatre points et votre classement voyage avec vous.

C'est ici que des attentes honnêtes vous épargnent beaucoup d'inquiétude. Un pur changement d'hébergeur, même domaine, mêmes URL, même contenu, est quasiment invisible pour les moteurs de recherche. Il n'y a aucun « changement d'hébergeur » à signaler à Google, et aucune raison que le classement chute. Les problèmes apparaissent quand une migration est mélangée à d'autres changements ou menée sans soin. Surveillez précisément ceci :

• Ne changez pas vos URL sauf nécessité. Gardez chaque page à la même adresse. Si une migration est aussi une refonte et que les adresses changent bel et bien, mettez une redirection permanente 301 de chaque ancienne URL vers son équivalent, une à une, et non tout déversé sur la page d'accueil.
• Évitez les coupures pendant l'exploration. Une courte panne nuit rarement, mais des erreurs répétées pendant que Googlebot passe, oui. La méthode sans coupure ci-dessus est votre protection ici.
• Transférez le HTTPS correctement. Assurez-vous que le nouvel hébergeur sert votre site en HTTPS avec un certificat valide avant la bascule, et que la redirection de http vers https fonctionne toujours. Notre hébergement inclut un certificat SSL gratuit, donc la version sécurisée continue de répondre sans interruption.
• Vérifiez qu'aucune exploration n'est bloquée sur la nouvelle copie. Les sites de test et de préproduction sont d'ordinaire bloqués aux moteurs par une balise noindex ou une interdiction dans robots.txt. Ce blocage survit souvent à la copie vers le nouvel hébergeur. Confirmez que le site en ligne est explorable avant et après la bascule.
• Gardez le contenu identique. Le classement est rattaché aux pages que Google connaît déjà. Si le texte, les titres et les intitulés changent pendant le déménagement, vous avez modifié la chose qui est classée, pas seulement l'endroit où elle est hébergée.
• Vérifiez l'indexation. Après la bascule, ouvrez Google Search Console et utilisez l'inspection d'URL sur quelques pages importantes pour confirmer qu'elles restent explorables et indexées. Vous n'avez pas besoin de l'outil de changement d'adresse pour un changement d'hébergeur : cet outil ne sert qu'à déménager vers un domaine différent.

Comment vérifier que la migration a vraiment fonctionné ?

Parcourez le nouveau site comme le feraient un vrai visiteur et un moteur de recherche : chargez les pages principales, testez un formulaire et une connexion, envoyez un e-mail de test dans les deux sens, et inspectez deux ou trois URL dans Search Console. La migration est terminée quand le nouveau serveur passe tout cela et que l'ancien ne reçoit plus de trafic.

Une migration qui « a l'air bien » sur la page d'accueil peut encore être cassée trois clics plus loin, alors vérifiez les parties qui échouent en silence :

• Formulaires et paiement. Envoyez un vrai formulaire et complétez une transaction de test si vous vendez en ligne. Ils dépendent de réglages serveur qui ne suivent pas toujours.
• E-mail dans les deux sens. Envoyez un message vers un compte du domaine et un autre depuis ce compte. Des MX cassés se voient ici et nulle part ailleurs.
• Images, téléchargements et liens. Chargez les pages avec des médias et cliquez sur les liens internes pour attraper tout ce qui pointe encore vers l'ancien serveur ou une adresse temporaire.
• HTTPS et redirections. Confirmez que le cadenas s'affiche et que les adresses http redirigent vers https.
• État d'indexation. L'inspection d'URL dans Search Console vous dit que la page en ligne est atteignable et indexable.
• Trafic sur l'ancien serveur. Quand ses journaux se taisent, le DNS a fini de se propager et vous pouvez le retirer sans risque.

Quelles erreurs provoquent des coupures ou des pertes de données lors d'un changement d'hébergeur ?

Les échecs qui coûtent réellement leur site et leur classement aux gens sont prévisibles, et chacun d'eux vient d'une entorse à la règle « testez d'abord, gardez l'ancien hébergeur ». Les connaître à l'avance, c'est l'essentiel de la protection.

• Résilier l'ancien hébergeur trop tôt. L'erreur la plus coûteuse. Une fois l'ancien serveur parti, votre filet de sécurité et votre solution de repli partent avec lui, et tout DNS qui pointe encore là-bas ne tombe sur rien.
• Oublier la base de données. Copier les fichiers mais pas la base laisse un site de contenu vide. Le contenu vit dans la base, pas dans les fichiers.
• Ne pas abaisser le TTL d'abord. Sautez cette étape et la bascule qui devrait prendre des minutes traîne des heures, avec des visiteurs répartis entre les serveurs tout du long.
• Perdre l'e-mail dans le déménagement. Les boîtes et les MX sont faciles à négliger parce qu'ils semblent distincts du site. Exportez le courrier et copiez les enregistrements avant de toucher au DNS.
• Laisser un blocage de préproduction en place. Une balise noindex ou une interdiction robots.txt copiée depuis le site de test peut retirer discrètement vos pages en ligne de Google, des jours plus tard.
• Changer d'URL sans redirections. Si les adresses changent et que rien ne redirige les anciennes, vous gardez la perte de trafic et vous tendez à Google une série de liens morts.

Faut-il migrer le site soi-même ou le faire faire ?

Faites-le vous-même si vous êtes à l'aise avec les sauvegardes, le DNS et les bases de données et que le site est simple. Faites-le faire si le site rapporte de l'argent, tourne sur une base de données, ou si vous n'êtes pas certain de pouvoir le restaurer depuis votre propre sauvegarde. Le coût d'une migration ratée est presque toujours supérieur à celui d'une migration propre.

Il n'y a de honte dans aucun des deux choix, et le facteur de décision honnête, c'est ce qu'une erreur vous coûterait. Un petit site vitrine que vous pouvez reconstruire en une après-midi est un bon terrain d'entraînement. Une boutique qui prend des commandes, ou un site qui a mis des années à se classer, n'est pas l'endroit pour apprendre le DNS sous pression. C'est exactement le travail pour lequel existe notre service de migration de site : nous construisons et testons le nouveau site avant de toucher à votre domaine, nous le déplaçons sans coupure et sans perte de données, et nous gardons l'ancien environnement comme solution de repli jusqu'à ce que le nouveau soit confirmé. Si vous déménagez parce que votre hébergement actuel manque de fiabilité, notre hébergement web infogéré inclut des sauvegardes quotidiennes et un SSL gratuit, si bien que le prochain déménagement, s'il y en a jamais un, part d'une base bien plus sûre.