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

Ce que tu vas apprendre

Changer d’hébergeur ne devrait jamais faire baisser ton trafic organique. Pourtant, on voit régulièrement des sites perdre des positions durement acquises après une migration mal préparée — TTL trop haut, redirections oubliées, robots.txt écrasé par une config par défaut du nouvel hébergeur. Ce guide détaille la méthode pour basculer d’un hébergeur à un autre (Hostinger, IONOS, Gandi, o2switch, ou un serveur dédié) sans période noire pour Google et sans perdre le positionnement acquis. Il s’adresse aux responsables de sites établis (PME, e-commerce, sites vitrines à trafic organique significatif) qui envisagent une migration technique — pas une refonte de contenu.

Prérequis

• Accès admin au DNS actuel et au nouveau (zone DNS modifiable des deux côtés pendant la transition)
• Accès Search Console et Google Analytics (ou équivalent) sur la propriété du site
• Une copie complète du site (fichiers + base de données) exportée et testée
• Liste des URLs indexées (export Search Console ou crawl avec un outil comme Screaming Frog)
• Certificat SSL prêt à être réémis chez le nouvel hébergeur
• Une fenêtre de bascule choisie en heure creuse (trafic faible)

1. Abaisser le TTL DNS plusieurs jours avant

Le TTL (Time To Live) définit combien de temps les résolveurs DNS gardent en cache l’ancienne adresse IP. Un TTL par défaut à 24h ou 48h signifie que certains visiteurs (et certains bots) continueront de taper l’ancien serveur pendant deux jours après la bascule — pendant que d’autres verront déjà le nouveau. Ce grand écart temporel est la première source de désindexation partielle.

Trois à sept jours avant la migration, connecte-toi à la zone DNS actuelle et réduis le TTL à 300 secondes (5 minutes) sur les enregistrements A, AAAA et CNAME concernés. Si tu ne sais pas où trouver cette zone, les guides DNS sur Hostinger et DNS sur IONOS détaillent l’interface pas à pas selon le registrar. Attends que le TTL précédent expire complètement avant de considérer la propagation comme homogène — c’est-à-dire que si l’ancien TTL était de 86400 secondes, il faut attendre 24h après la modification avant d’être sûr que tous les résolveurs ont bien le nouveau TTL court en cache.

Ce point est non négociable : sans TTL bas, tu ne contrôles pas le timing de la bascule, et un site partiellement accessible sur deux serveurs différents pendant 48h est le pire scénario pour le crawl de Google.

2. Préparer le double hébergement (ancien + nouveau en parallèle)

Le nouvel hébergement doit être opérationnel, testé et identique fonctionnellement à l’ancien avant de toucher au DNS. Concrètement :

• Déploie le site complet chez le nouvel hébergeur (fichiers, base, plugins, thème)
• Teste-le via l’IP directe du nouveau serveur ou via un fichier hosts local modifié sur ta machine, pour vérifier que tout fonctionne sans passer par le DNS public
• Vérifie que les URLs générées dynamiquement (liens internes, images, formulaires) pointent bien vers le bon domaine et pas vers une IP ou un chemin temporaire
• Contrôle que le certificat SSL est déjà commandé ou prêt à être réémis instantanément (Let’s Encrypt automatique, ou SSL fourni par l’hébergeur) — un certificat expiré ou mal configuré au moment de la bascule casse immédiatement la confiance et le crawl HTTPS

L’ancien hébergement reste actif et servi en parallèle jusqu’à ce que la propagation DNS soit terminée à 100 %. C’est ce qu’on appelle le double hébergement : les deux environnements tournent en même temps, avec le même contenu, pour qu’aucun visiteur ni aucun bot ne tombe sur une erreur pendant la transition.

3. Garder des URLs strictement identiques

C’est la règle la plus simple à énoncer et la plus souvent violée en pratique. Une migration d’hébergeur n’est pas une refonte : la structure d’URL doit rester rigoureusement identique — même arborescence, mêmes slugs, mêmes paramètres, même gestion des trailing slashes (avec ou sans / final, mais cohérent avec l’ancien comportement).

Si le nouvel hébergeur impose une réécriture d’URL différente (changement de CMS, de structure de permaliens, ou passage d’un .php visible à une URL propre), il ne s’agit plus d’une simple migration d’hébergement mais d’un changement structurel qui nécessite un plan de redirections 301 complet, testé un par un sur les pages à fort trafic. Dans ce cas, référence-toi à la checklist de changement d’agence sans tout casser, qui couvre ce cas de figure plus large.

Pour une migration d’hébergeur pure (même CMS, même structure, serveur différent), aucune redirection ne devrait être nécessaire puisque les URLs ne changent pas. Si une redirection existante était déjà en place (ancien domaine, ancien www vs non-www), elle doit être reproduite à l’identique sur le nouveau serveur — pas oubliée dans la copie.

4. Basculer le DNS et surveiller la propagation

Une fois le TTL abaissé et le nouvel environnement validé, modifie l’enregistrement A (ou CNAME) pour pointer vers la nouvelle IP. Utilise un outil de vérification de propagation DNS pour observer, région par région, quand chaque résolveur a bien pris en compte le changement.

Pendant cette fenêtre (généralement 15 minutes à quelques heures grâce au TTL bas), garde les deux hébergements actifs et synchronisés. Ne coupe l’ancien serveur que lorsque :

• La propagation DNS est confirmée à 100 % sur plusieurs outils de vérification
• Le nouveau site répond correctement en HTTPS, sans avertissement de certificat
• Un test depuis plusieurs réseaux (mobile 4G, wifi, VPN dans un autre pays) confirme que tout le monde atterrit sur le nouveau serveur

Si un DNS ne se propage pas correctement après plusieurs heures, vérifie les enregistrements NS, la présence de doublons ou de conflits dans la zone, et l’absence de cache résiduel côté Cloudflare si un proxy est utilisé.

5. Vérifier robots.txt et sitemap.xml immédiatement après bascule

C’est l’étape la plus fréquemment oubliée — et la plus dangereuse pour le SEO. Beaucoup d’hébergeurs et de configurations serveur livrent un robots.txt par défaut qui bloque tout crawl (Disallow: /), notamment sur les environnements de staging copiés tels quels en production.

Juste après la bascule :

• Ouvre https://tondomaine.fr/robots.txt et vérifie qu’aucune ligne Disallow: / généralisée ne subsiste
• Ouvre https://tondomaine.fr/sitemap.xml et confirme qu’il liste bien les mêmes URLs qu’avant, avec les bonnes dates de dernière modification
• Vérifie que le sitemap est déclaré dans le robots.txt avec la bonne URL absolue
• Contrôle les balises meta robots sur un échantillon de pages stratégiques (page d’accueil, pages produits ou services principales) pour t’assurer qu’aucune balise noindex n’a été introduite par erreur lors du déploiement

Un robots.txt mal configuré pendant même quelques heures peut suffire à ce que Googlebot enregistre une baisse de crawl budget, avec un effet différé sur les positions dans les semaines suivantes.

6. Resoumettre le sitemap et surveiller Google Search Console

Une fois la bascule confirmée stable, connecte-toi à Search Console et :

• Resoumets le sitemap manuellement (même s’il n’a pas changé d’URL), pour forcer un nouveau crawl de confirmation
• Utilise l’outil d’inspection d’URL sur 5 à 10 pages stratégiques pour demander une nouvelle indexation
• Surveille quotidiennement, pendant les deux semaines suivant la migration, le rapport Couverture (erreurs de crawl, pages exclues) et le rapport Performances (impressions, clics, position moyenne)

Une chute brutale des impressions dans les 48h suivant la bascule est presque toujours le signe d’un problème technique (robots.txt, SSL, erreur 500 intermittente) et non d’une pénalité — elle doit être investiguée immédiatement, pas attendue. Si le serveur renvoie des erreurs par intermittence pendant la montée en charge, les guides sur l’erreur 500 et l’erreur 502 aident à diagnostiquer vite.

Pièges courants

Une migration d’hébergeur réussie, du point de vue SEO, se reconnaît à son absence totale de bruit dans Search Console : aucun pic d’erreurs, aucune chute d’impressions, aucune alerte de couverture. Si ces indicateurs bougent dans les deux semaines suivant la bascule, le problème est presque toujours technique et réversible rapidement — à condition de le détecter tôt.