Migration de site web — hébergement, domaine et redirections 301

Une migration de site web ne se termine pas le jour où le site tourne sur le nouveau serveur ou à la nouvelle adresse. Elle se termine quand Google s’en aperçoit — et cela peut prendre des semaines. Nous le savons par notre propre site : l’édition polonaise de cet article a elle-même été migrée.

Jusqu’au 14 septembre, elle se trouvait à une adresse dans une rubrique de guides de notre site polonais, que nous avons supprimée. Ce jour-là, elle a reçu une redirection permanente vers son adresse actuelle. Cinq jours plus tard, la Search Console affichait ceci :

Un lecteur qui clique sur l’ancien lien arrive sur la nouvelle adresse dès la première seconde. Mais Google n’apprend la redirection qu’à sa prochaine visite sur l’ancienne adresse — et sa dernière visite remontait à juillet. D’ici là, l’index contient une adresse qui n’existe plus, tandis que la nouvelle attend son tour. La documentation de Google le dit clairement : pour un site petit ou moyen, le déplacement de la plupart des adresses prend « a few weeks », et les fluctuations de visibilité pendant cette période sont « normal ».

Ce n’est pas un argument contre la migration. C’est un argument pour la planifier comme si Google devait l’apprendre tard — car ce sera le cas.

Trois migrations sous un seul nom

La « migration de site » désigne trois opérations différentes. Elles se distinguent par ce qui change du point de vue du moteur de recherche — et c’est cela qui détermine ce qui peut mal tourner.

Changement d’hébergement — le même site, les mêmes adresses, un autre serveur. Pour Google, il ne se passe rien, sinon qu’une autre machine répond à une adresse connue. C’est la plus sûre des trois, à condition que tout ait été déplacé.

Changement de domaine — chaque adresse du site devient nouvelle. Pour Google, c’est le déménagement du site entier, qu’il faut signaler et réaliser par des redirections, adresse par adresse.

Changement de structure ou de plateforme — un nouveau système de gestion de contenu, une nouvelle boutique, une réorganisation des rubriques. Le domaine reste, mais une partie des adresses change. C’est la source de pertes la plus fréquente, car cela ressemble à un changement « purement technique », alors que pour le moteur de recherche, chaque adresse modifiée sans redirection est une nouvelle page, vide.

En pratique, ces opérations vont souvent ensemble — une nouvelle plateforme sur un nouvel hébergement, parfois sous un nouveau domaine. Il vaut alors la peine de les séparer dans le temps si possible. Google admet que les grands sites soient déplacés section par section et recommande de déplacer toutes les adresses d’un coup pour les plus petits ; dans les deux cas, il est plus facile de trouver la cause d’une baisse quand une seule chose a changé dans la semaine, et non trois.

Déménager un site vers un nouvel hébergement

Google décrit le déménagement d’un site vers un nouvel hébergement sans changement d’adresses dans un document distinct, qui contient trois recommandations à prendre au pied de la lettre.

Réduisez le TTL au moins une semaine à l’avance. Google propose une valeur de « a few hours » fixée « at least a week in advance ». Pourquoi si tôt, la section suivante l’explique ; en bref, la réduction ne prend effet qu’une fois expirée l’ancienne valeur, plus longue, mémorisée par les serveurs en chemin.

N’éteignez pas l’ancien hébergement le jour du déménagement. Google conseille de surveiller les journaux de l’ancien serveur et de ne l’éteindre que lorsque le trafic y est tombé à zéro. Pendant plusieurs jours, une partie des visiteurs — et une partie des robots — atteindra encore l’ancienne adresse IP. Si l’ancien serveur ne répond plus, ce sont des visites perdues. Au passage, c’est un argument pour ne pas résilier l’ancien contrat d’hébergement de façon qu’il se termine le jour de la migration.

Une baisse d’activité de Googlebot après le déménagement est normale. Selon la documentation, juste après le lancement sur le nouveau serveur, Google ralentit généralement l’exploration pour un temps, puis accélère progressivement au cours des jours suivants. Inutile de réagir.

Ce que la documentation de Google ne dit pas, car ce n’est pas son rôle : ce qu’il faut déplacer. Les fichiers du site ne sont qu’une partie. S’y ajoutent la base de données, les fichiers envoyés par les utilisateurs, les tâches planifiées, la configuration du serveur, le certificat et l’e-mail — s’il se trouvait sur le même hébergement, son déplacement est une opération à part, facile à oublier, parce que « le site fonctionne ». Et la version de PHP : si le nouveau serveur en a une plus récente que l’ancien, une extension plus ancienne peut cesser de fonctionner le jour du déménagement. Avant de basculer quoi que ce soit, il faut une sauvegarde qui se restaure réellement — idéalement sur le nouveau serveur lui-même, car le test de la sauvegarde et la répétition de la migration ne font alors qu’une seule tâche.

Propagation DNS : c’est le TTL, pas 48 heures

Une phrase circule à propos des changements DNS : « la propagation prend jusqu’à 48 heures ». On dirait que l’information sur la nouvelle adresse se répand sur Internet comme une vague. Ce n’est pas le cas. Rien ne se répand — ce sont les copies mémorisées par les serveurs en chemin qui expirent, et leur durée de conservation est fixée par le propriétaire de l’enregistrement. C’est le TTL, la durée de vie de l’enregistrement, exprimée en secondes.

Si l’enregistrement qui pointe vers l’adresse du serveur a un TTL de 86 400 secondes, soit un jour, un serveur qui l’a demandé juste avant le changement enverra les visiteurs vers l’ancienne adresse pendant toute la journée suivante. S’il est de 300 secondes, pendant cinq minutes. C’est pourquoi on réduit le TTL à l’avance : d’abord, l’ancienne valeur longue doit expirer, et seulement ensuite le changement d’adresse se propagera dans le délai de la nouvelle valeur, courte.

Nous avons vérifié les deux valeurs sur notre propre domaine .ch. Les enregistrements qui pointent vers l’adresse de notre serveur ont un TTL de 300 secondes. Le registre .ch publie l’information sur les serveurs de noms qui gèrent le domaine avec un TTL de 3 600 secondes — une heure. C’est bien plus court que sur d’autres extensions : pour notre domaine .eu, la même information porte 86 400 secondes, un jour entier. Il en découle une différence pratique entre deux opérations qui portent des noms proches dans les interfaces de gestion :

• Modifier des enregistrements (adresse du serveur, e-mail) — un changement DNS chez votre fournisseur actuel. Il prend effet dans le délai du TTL que vous avez vous-même fixé.
• Changer de serveurs de noms (confier la gestion DNS à une autre entreprise) — s’y ajoute alors le TTL du registre, que vous ne pouvez pas raccourcir. Pour un domaine .ch, c’est une heure ; pour beaucoup d’autres extensions, c’est un jour, d’où les fameuses « 24 à 48 heures ».

Il en va de même pour le déplacement de la messagerie, même si l’e-mail ne change pas d’endroit. Lorsque vous changez de serveurs de noms, le nouveau fournisseur DNS ne connaît pas vos enregistrements existants — il faut les recréer, y compris les enregistrements de messagerie (MX) et ceux qui confirment que vous êtes autorisé à envoyer des e-mails depuis le domaine (SPF, DKIM). S’ils sont oubliés, le site commencera à fonctionner sur le nouveau serveur au moment précis où l’e-mail cessera d’arriver. Avant de changer de serveurs de noms, il vaut donc la peine d’exporter toute la zone, et pas seulement de noter l’adresse du serveur.

La conclusion pour le jour de la migration : lors d’un changement d’hébergement, mieux vaut modifier les enregistrements chez votre fournisseur DNS actuel que de déplacer la gestion DNS ailleurs le même jour. Deux changements simultanés, ce sont deux horloges différentes.

Transférer un domaine .ch — l’Auth-Code

Un transfert de domaine est le changement de l’entreprise qui gère votre domaine — le registraire. Il ne change pas le titulaire, ne change pas l’adresse du site et n’affecte pas, à lui seul, son fonctionnement. Mais c’est là que la plupart des migrations se bloquent, et presque jamais pour des raisons techniques.

Pour les domaines .ch, les règles sont fixées par Switch, qui gère le registre pour la Suisse et le Liechtenstein. On ne peut pas enregistrer ni gérer un domaine .ch directement auprès de Switch — seulement par un registraire accrédité, et le transfert se déroule ainsi :

1. L’Auth-Code. Pour déplacer un domaine vers un autre registraire, il faut un code de transfert. C’est votre registraire actuel qui le fournit.
2. La transmission. Vous transmettez ce code au nouveau registraire, qui reprend la gestion du domaine.
3. Un blocage ensuite. Après un transfert réussi, le registre attribue un statut qui empêche tout nouveau transfert pendant 60 jours (selon le manuel EPP de Switch). Deux changements de registraire d’affilée, en pleine migration, ne sont donc pas possibles.

Switch ajoute une phrase qui compte plus qu’il n’y paraît : le contrat avec le registraire est privé, et tout litige qui en découle doit être tranché par les tribunaux civils. Il n’existe pas de procédure de réclamation auprès du registre sur laquelle se rabattre. Si le registraire ne remet pas le code, ou si le compte chez le registraire appartient à quelqu’un d’autre, vous avez affaire à un problème contractuel, pas technique.

Et c’est justement là que les transferts se bloquent le plus souvent : au nom de qui, et sur le compte de qui, le domaine est enregistré. Si le domaine a été enregistré il y a des années par une agence ou par un employé qui a quitté l’entreprise, le compte chez le registraire et l’adresse de contact peuvent leur appartenir — et obtenir le code devient une négociation.

C’est le même problème que nous décrivons dans l’article sur le contrat de maintenance : le domaine doit être enregistré au nom de l’entreprise, avec une adresse e-mail que quelqu’un lit. Lors d’un transfert, cela cesse d’être une bonne pratique et devient une condition.

Changer de domaine

Un changement de domaine — nouveau nom d’entreprise, passage d’un .com à un .ch, fusion de deux sites — est la seule des trois migrations pour laquelle Google fournit un outil dédié. La Search Console dispose d’une fonction de changement d’adresse ; selon la documentation, elle s’utilise lors d’un déménagement d’un domaine ou sous-domaine vers un autre, pas lors du passage à HTTPS, du changement entre www et sans www, ni du déplacement de pages au sein du même domaine.

Trois règles de la documentation de Google décident du résultat :

• Chaque ancienne adresse redirigée vers son équivalent, pas vers la page d’accueil du nouveau domaine. Tout rediriger vers la page d’accueil indique au moteur de recherche que les sous-pages n’existent plus.
• Des redirections permanentes côté serveur — 301 ou 308.
• Conservez-les « for as long as possible, generally at least 1 year ». L’ancien domaine doit donc être payé pendant au moins un an après le changement — un coût à inscrire au budget du déménagement avant que quelqu’un décide qu'« on ne renouvelle pas l’ancien ».

Redirection 301 — le plan des anciennes adresses

Une redirection 301 est la réponse du serveur « cette adresse a déménagé définitivement, là-bas ». C’est le cœur de toute migration où les adresses changent, et l’endroit où une migration se casse le plus souvent.

Google distingue deux groupes. Les redirections permanentes — 301 et 308 — sont considérées par Google comme un signal que l’adresse cible doit être l’adresse correcte, canonique. Avec les temporaires — 302, 303, 307 — il suit la redirection, mais ne transmet pas ce signal à la cible. Une redirection 302 posée par erreur lors d’une migration est donc une redirection qui fonctionne pour les personnes et pas pour le moteur de recherche. Google traite un meta refresh instantané dans le code de la page comme permanent, et un meta refresh différé comme temporaire. Une redirection en JavaScript, seulement si rien d’autre n’est possible, car Google risque de ne pas l’exécuter.

Un plan de redirection est un tableau à deux colonnes : ancienne adresse, nouvelle adresse. La liste des anciennes adresses se compose de préférence à partir de trois sources, car chacune montre autre chose : le sitemap actuel, le rapport sur les pages de la Search Console et la liste des adresses vers lesquelles pointent des liens externes. Chaque ligne a une cible — même si une page disparaît, la redirection mène vers la page la plus proche par le sujet, pas vers la page d’accueil.

Où l’on pose une redirection 301. Sur les serveurs Apache, cela se fait dans le fichier .htaccess du répertoire du site — une ligne par adresse, par exemple Redirect 301 /ancienne-adresse/ https://www.exemple.ch/nouvelle-adresse/. Pour des dizaines d’adresses suivant un même modèle, on utilise des règles avec expressions régulières, mais chacune comporte le risque de rediriger plus que prévu — il faut donc, après l’ajout, vérifier aussi les adresses censées rester intactes. Les serveurs nginx ne lisent pas du tout le fichier .htaccess ; les redirections se trouvent dans la configuration du serveur, généralement du côté de l’hébergeur. Dans WordPress, des extensions s’en chargent. Dans des systèmes comme le nôtre, les règles font partie du code et passent par la même relecture que toute autre modification. Où qu’elle soit posée, une règle s’applique : la redirection doit être donnée par le serveur avant que la page ne démarre — pas par un script sur la page.

Deux points à vérifier après le déploiement :

• Les chaînes. Si l’adresse A redirige vers B, et B — d’une migration précédente — vers C, chaque nouveau changement ajoute un maillon. Les anciennes règles doivent être réorientées pour mener directement à la cible.
• La redirection fonctionne-t-elle vraiment en production ? Cela paraît évident, mais nous avons une preuve toute récente que non. Notre site gère 318 règles de redirection. Le 9 septembre, l’une d’elles a été écrite, validée et déployée — et l’ancienne adresse répondait toujours 200 avec l’ancien contenu, parce que la règle avait été ajoutée au code source, mais pas au fichier que le serveur lit réellement. Rien ne le signalait. Le seul test qui l’a détecté a été de vérifier la réponse de l’ancienne adresse après le déploiement.

Ce test tient en une commande ou un outil en ligne : pour chaque ancienne adresse du plan — répond-elle 301 ou 308, et aboutit-elle, après la redirection, sur une page qui répond 200. Pour quelques dizaines d’adresses, c’est un quart d’heure. Après une migration où « tout fonctionne », ce quart d’heure est la seule preuve.

Migration WordPress — l’adresse est dans la base de données

WordPress a une particularité qui change la façon de migrer en cas de changement de domaine : l’adresse du site est enregistrée dans la base de données, et à de nombreux endroits — dans les réglages, dans les contenus, dans la configuration du thème et des widgets. Déplacer les fichiers et la base vers un nouveau serveur sous le même domaine n’y touche pas. Changer de domaine touche à tout.

La solution intuitive consiste à chercher l’ancienne adresse dans toute la base et à la remplacer par la nouvelle. La documentation de WordPress met précisément en garde contre cela : un tel remplacement « can cause issues with data serialization », car certains thèmes et widgets enregistrent des valeurs avec leur longueur. La nouvelle adresse n’a pas le même nombre de caractères que l’ancienne, la longueur enregistrée ne correspond plus, et des réglages disparaissent sans bruit. Pour changer l’adresse dans une base WordPress, on utilise des outils qui comprennent ce format — pas un simple « rechercher et remplacer ».

La seconde règle de la même documentation est formulée encore plus fermement : la colonne GUID de la table des articles ne se modifie « never, ever ». C’est l’identifiant de l’article, pas son adresse — si on la change, les lecteurs de flux RSS afficheront à nouveau tous les articles comme nouveaux.

La première semaine après une migration

Pendant la première semaine après une migration, on ne vérifie pas si le site fonctionne, mais si ce que l’on ne voit pas sur la page d’accueil fonctionne :

• Les formulaires — les messages arrivent-ils ? Un nouveau serveur envoie souvent les e-mails autrement que l’ancien.
• La messagerie du domaine — envoi et réception, si elle a été déplacée.
• Les paiements et les comptes clients — une vraie transaction plutôt qu’une supposition.
• La Search Console — le rapport sur les pages et la liste des erreurs 404. Chaque nouvelle 404 est une adresse tombée hors du plan de redirection ; comment la lire et la corriger, nous l’expliquons dans l’article sur l'erreur 404.
• Le monitoring de disponibilité — dirigé vers le nouveau serveur, pas vers l’ancien ; à part, ce qu’il doit vérifier.

Si la vitesse du site a changé après la migration, comparez des données de même source. Un score de test en laboratoire et les données d’utilisateurs réels mesurent des choses différentes, et ces dernières sont collectées sur 28 jours — nous l’expliquons dans l’article sur les Core Web Vitals.

Ce que cet article laisse volontairement de côté

• La migration d’une boutique — déplacer une boutique d’une plateforme à une autre comporte ses propres risques (produits, variantes, comptes clients, historique des commandes) ; il existe une checklist dédiée.
• La décision de reconstruire ou non le site — c’est une question de refonte ou d’optimisation, pas de migration.
• Le choix du nouvel hébergement — comment choisir un hébergement ; et son coût avec le domaine — nom de domaine et hébergement.
• Qui a accès au domaine et au serveur — le contrat de maintenance, avec la liste des accès qui doivent appartenir à l’entreprise.

Le résumé le plus court : nommez laquelle des trois migrations vous réalisez, et séparez-les dans le temps si elles vont ensemble. Lors d’un changement d’hébergement, surveillez le TTL et l’ancien serveur. Lors d’un changement d’adresses — le plan de redirection et la vérification qu’il fonctionne. Ensuite, laissez à Google des semaines, pas des jours : notre propre adresse déplacée figurait encore dans l’index cinq jours après la redirection, et ce n’était pas une panne, seulement le calendrier du robot.