Scénario classique : un samedi de juillet, le site d’une chambre d’hôtes du Luberon tombe et les e-mails de réservation se perdent, parce que les DNS ont été modifiés à la hâte pour changer d’hébergeur. Ce scénario s’évite avec un inventaire complet, une date hors saison, un TTL abaissé une semaine avant et une recette méthodique après la bascule.
Changer d’hébergeur, de bureau d’enregistrement ou de domaine
Trois opérations se cachent derrière l’envie de déménager son site, avec des risques différents. Techniquement, changer d’hébergeur sans toucher à l’adresse revient à copier fichiers et base de données sur un nouveau serveur, puis à y pointer le domaine : si la copie est fidèle, les URL restent identiques et Google ne voit qu’un changement de serveur. Changer de nom de domaine crée au contraire des adresses nouvelles, que le moteur doit découvrir, relier aux anciennes et réindexer.
La troisième passe souvent inaperçue : transférer le domaine chez un autre bureau d’enregistrement. Aucun fichier ne bouge, mais la zone DNS change de mains si le bureau sortant la gérait, et c’est là que disparaissent les enregistrements de messagerie que personne n’avait notés.
Le transfert d’un .fr, en pratique
Selon l’Afnic, le titulaire d’un .fr peut changer de bureau d’enregistrement à tout moment. Le code d’autorisation, appelé AUTH_INFO, figure généralement dans l’interface du bureau sortant, qui doit le fournir s’il n’y est pas accessible ; passé huit jours sans réponse de sa part, le domaine part automatiquement chez le nouveau bureau. Vérifiez d’abord que le domaine est au nom de l’exploitation : un gîte dont l’adresse appartient à un ancien webmaster commence par la transmission du domaine à son nom, procédure distincte que l’actuel titulaire doit valider. Et jamais de transfert la même semaine qu’un changement d’hébergement : une modification à la fois, sinon une panne devient impossible à attribuer.
L’inventaire, ou tout ce que le site emporte avec lui
L’inventaire se rédige avant de commander le nouvel hébergement, parce qu’il dit ce que l’offre doit savoir accueillir. Pour un gîte, un camping ou un domaine viticole, il tient sur une page :
- les fichiers : thème, extensions, médias, configuration, version du langage serveur ;
- la base de données : export complet, encodage, identifiants à reporter ;
- les adresses e-mail : boîtes, alias, transferts, et l’historique si la messagerie déménage aussi ;
- la zone DNS entière : A, AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC, validations de services), relevée telle quelle ;
- le certificat HTTPS : émetteur, mode de renouvellement, couverture de la variante www ;
- les accès : bureau d’enregistrement, hébergeur, administration du site, Search Console, fiche d’établissement, statistiques ;
- le module de réservation : moteur, calendrier synchronisé, paiement, notifications aux clients.
Réservation et messagerie, les deux pièces qui cassent sans bruit
Un site qui s’affiche peut très bien ne plus rien vendre. Le calendrier d’un gîte se synchronise souvent avec des plateformes de location par des flux iCal ; le paiement renvoie le client vers des URL de retour et prévient le site par des webhooks ; les confirmations partent par un serveur d’envoi que le SPF du domaine doit autoriser. Oubliez une clé d’API dans la copie, ou le nouveau serveur d’envoi dans le SPF, et les séjours restent payés sans apparaître au calendrier, ou les confirmations finissent en indésirables.
Site prisonnier d’une plateforme fermée : le déménagement tourne à la refonte
L’inventaire réserve parfois une mauvaise surprise : il n’y a rien à copier. Un site bâti sur un créateur en ligne à abonnement, ou sur un outil propriétaire installé par un ancien prestataire, ne livre généralement ni les fichiers, ni la base de données, ni le code. L’export se limite au mieux aux textes et aux images. Le domaine se transfère ; le site, non.
Dans ce cas, le déménagement du site change de nature. Les pages se reconstruisent sur un socle que l’exploitation contrôle, les versions étrangères se refont, le module de réservation se rebranche. C’est une refonte, avec son budget et son calendrier, et les redirections décrites plus bas deviennent obligatoires dès que la structure des adresses change. Notre guide de la création de site web à Aix-en-Provence détaille ce qui sépare une plateforme fermée d’un socle ouvert.
La reprise des textes sert aussi de tri, selon la logique de notre dossier sur la stratégie éditoriale d’une PME : les pages sans visite ni lien entrant se fusionnent, celles qui répondent aux voyageurs se réécrivent.
Le choix du prestataire de cette refonte décide du prochain déménagement. Un studio qui remet l’intégralité du code source et traite design, intégration et référencement local en interne ne recrée pas le verrou dont l’exploitation sort. C’est le parti pris de ce studio web à 45 minutes d'Avignon, installé entre Nîmes et Uzès : il conçoit des sites pour les hébergeurs touristiques et les domaines viticoles du Vaucluse, livre le code source à 100 % et inclut le français, l’anglais, l’allemand et l’italien dans ses packs tourisme, ce qui laisse le site libre de changer d’hébergeur le jour venu.
Choisir la date, puis basculer sans coupure
Une bascule bien préparée tient en quelques heures, à condition de tomber au bon moment.
Un calendrier dicté par la saison
Pour un hébergement touristique, la période où les clients réservent compte autant que celle où ils séjournent. Quatre fenêtres sont à exclure :
- la haute saison et les semaines où arrivent les réservations d’été ;
- le Festival d’Avignon, en juillet, qui remplit les hébergements de la région ;
- les vendanges, pour un domaine viticole, quand personne ne surveille la boîte de réception ;
- les veilles de week-end et de jours fériés, quand les supports techniques répondent moins vite.
Reste une fenêtre confortable : la fin de l’automne ou l’hiver, un mardi ou un mercredi matin, avec deux jours de disponibilité de la personne qui pilote l’opération.
TTL, DNS, MX, certificat : l’ordre du jour J
Google Search Central conseille de régler le TTL des enregistrements DNS sur une valeur faible, de l’ordre de quelques heures, au moins une semaine avant la migration. Abaissé tôt, il réduit la période où des résolveurs servent encore l’ancienne réponse en cache. Il ne vaut que pour les enregistrements de la zone : un changement de serveurs de noms dépend aussi du TTL de délégation fixé par le registre. Le jour J suit ensuite cet ordre :
- Tester la copie du site via une adresse provisoire ou le fichier hosts.
- Préparer le certificat : la validation HTTP suppose que le domaine pointe déjà vers le nouveau serveur, la validation DNS par enregistrement TXT autorise son émission avant la bascule.
- Suspendre les réservations en ligne le temps de la dernière copie de la base.
- Modifier les enregistrements A et AAAA, et eux seuls.
- Garder l’ancien hébergement actif : Google recommande d’attendre que ses journaux ne montrent plus aucun trafic avant de le résilier.
Côté messagerie, quand le domaine change de serveurs de noms, la nouvelle zone démarre souvent vide ou avec des valeurs par défaut : sans MX recopiés à l’identique, les e-mails de réservation sont refusés ou livrés ailleurs, sans alerte. Recopier la zone complète, SPF et DKIM compris, avant le changement règle la question.
Nouveau nom de domaine : redirections 301 et changement d’adresse
Situation type : un domaine de Gigondas reprend le nom de la famille et veut changer de domaine en même temps que d’étiquette. Chaque ancienne adresse renvoie alors, par une redirection permanente côté serveur, vers son équivalent exact : la cuvée vers la même cuvée, la version allemande vers la version allemande. Google Search Central déconseille de tout renvoyer vers une seule page, ce qui déroute les internautes. Quand le nouveau nom accompagne une nouvelle identité, sa disponibilité se vérifie avant le dessin, comme le rappelle notre dossier sur l’identité visuelle et le branding.
Le plan de correspondance, page à page
Le plan croise l’arborescence actuelle, les pages qui reçoivent des visites et celles qui reçoivent des liens d’offices de tourisme, de guides ou de cavistes. Google recommande de garder les redirections aussi longtemps que possible, généralement au moins un an, sans chaînes : trois sauts au maximum dans l’idéal. Canoniques, hreflang et sitemap passent au nouveau domaine le jour même. L’ancien nom reste à renouveler : expiré, il peut être racheté par un tiers, et les redirections tombent avec lui.
L’outil de changement d’adresse de la Search Console
Les redirections en place, l’outil de changement d’adresse de la Google Search Console signale le déplacement au moteur. Ses conditions sont précises : être propriétaire des deux propriétés avec le même compte Google, travailler au niveau du domaine et non d’un sous-répertoire, rediriger en 301 l’ancienne page d’accueil vers la nouvelle. D’après l’aide de la Search Console, Google privilégie ensuite pendant 180 jours l’exploration du nouveau site et lui transmet divers signaux de l’ancien. L’outil ne sert ni pour un simple changement d’hébergeur, ni pour un passage en HTTPS.
Reste une limite qu’aucune méthode ne lève : un nouveau nom de domaine traverse toujours une période de réindexation. Google Search Central parle de quelques semaines ou plus, pour un site de taille moyenne, avant que les nouvelles URL apparaissent progressivement, avec des fluctuations de visibilité qu’il juge normales. Des redirections 301 complètes ne suppriment pas cette phase ; elles la raccourcissent.
La recette des deux jours qui suivent
La réussite d’une migration de site se juge sur ce que les visiteurs utilisent, pas sur la page d’accueil. La recette suit une liste écrite :
- envoyer une demande depuis chaque formulaire et vérifier sa réception dans la vraie boîte ;
- simuler une réservation complète, paiement en mode test, puis contrôler le calendrier et les plateformes synchronisées ;
- écrire depuis l’extérieur à chaque adresse du domaine, et répondre depuis chacune ;
- parcourir les versions anglaise, allemande ou italienne : sélecteur de langue, formulaires traduits, hreflang ;
- tester un échantillon d’anciennes adresses et constater un seul saut 301 vers la bonne page ;
- vérifier le HTTPS sur les variantes avec et sans www.
L’adresse du site se corrige enfin sur la fiche d’établissement, les plateformes de location et les annuaires touristiques. Ce relais local pèse lourd pour un gîte, comme le montre notre panorama de la visibilité web en Provence. La Search Console, suivie chaque semaine, signale ensuite les pages en erreur que la recette aurait manquées.
Le studio qui s’en charge : quatre vérifications
Confier la migration du site à un prestataire suppose quatre questions précises, toutes liées au déménagement :
- le code source, la base et les identifiants reviennent-ils à l’exploitation, avec domaine et hébergement à son nom ?
- le plan de redirections est-il écrit, testé avant la mise en ligne et remis avec le site ?
- les versions étrangères sont-elles migrées avec leurs balises hreflang, ou reconstruites dans les mêmes langues ?
- la mise à jour de la fiche d’établissement et le suivi de la Search Console après bascule figurent-ils au devis ?
Un devis qui répond noir sur blanc à ces quatre points protège la saison suivante. Prochaine étape : exporter dès aujourd’hui la zone DNS actuelle, la pièce la plus difficile à reconstituer après coup.