Surveiller une migration, c’est tenir une carte d’URL et la rejouer après la bascule. Chaque ligne a l’ancienne adresse, la nouvelle, et le code attendu : 301 vers la nouvelle, qui elle-même répond 200. Sans cette carte, vous découvrez les oublis dans Search Console deux semaines plus tard, sous forme de 404. Le jour J n’est pas le moment de décider du plan d’adresses.
La carte, avant le jour J
Partez du sitemap de l’ancien site et des URL qui ont des liens externes si vous les connaissez. Vous n’êtes pas obligé de tester les dix mille fiches produit à la main. Vous êtes obligé d’avoir la règle (ancien chemin devient tel nouveau chemin) et un échantillon : accueil, une rubrique, une fiche, une URL avec et sans slash final, la variante http, la variante www.
| Ancienne URL | Nouvelle URL | Attendu |
|---|---|---|
| http://example.com/ | https://example.com/ | 301, une seule fois |
| https://www.example.com/offre/ | https://example.com/offre/ | 301 si le www n’est pas la canonique |
| /ancien-article/ | /journal/ancien-article/ | 301 puis 200 |
| /page-supprimee/ | / ou une page proche | 301, pas un 404 silencieux si la page avait des liens |
Une chaîne de deux 301 (http vers https vers www, ou slash ajouté en second saut) se corrige avant le jour J. Chaque saut est une occasion d’erreur et un délai pour le robot. La méthode pour auditer ces chaînes est dans auditer les redirections d’une migration.
Le jour J, dans cet ordre
- Sauvegarde de l’ancien et du nouveau, identifiables par l’heure. Vous ne migrez pas sans pouvoir revenir à l’ancien DNS.
- Bascule DNS ou mise en ligne des redirections sur l’ancien hébergement. L’ancien hébergement doit rester allumé : c’est lui qui sert les 301. Couper l’ancien serveur le soir même annule la carte.
- Échantillon :
curl -sIsur chaque URL témoin. Vous lisez le code et l’en-têteLocation. Le 301 doit viser l’URL finale en https, pas une étape intermédiaire. - Sur l’URL finale, un 200, la canonique égale à cette URL, pas de lien vers l’ancien hôte dans le HTML.
- Recherche dans la base des occurrences de l’ancien domaine. Sur WordPress,
wp search-replacegère les données sérialisées. Un remplacement SQL brut casse des options. - Sitemap du nouveau site régénéré, soumis dans la propriété Search Console du nouvel hôte. L’ancien sitemap ne doit plus lister que des URL qui redirigent, ou vous le retirez.
- Formulaire et page principale retestés sur le nouveau domaine. Les clés de captcha et le SMTP suivent le domaine.
Le contrôle http vers https, quand la migration n’est que ça, se détaille dans rediriger HTTP vers HTTPS.
Search Console, sans le mauvais outil
Le changement d’adresse, dans les paramètres de la propriété, s’utilise quand le nom de domaine change, et seulement si l’ancienne et la nouvelle propriété sont vérifiées. Il ne s’utilise pas pour passer de http à https sur le même nom. Dans ce cas, les 301 suffisent. Après un vrai changement de domaine, lancez l’Inspection de l’URL sur l’accueil du nouveau site, en test en direct, pour voir si Google peut le lire. Demander l’indexation de trois URL témoins a un sens. Le geste est décrit dans demander l’indexation. Le refaire en boucle ne remplace pas un 301 manquant.
Quarante-huit heures après
Rejouez l’échantillon. Un CDN ou un cache peut avoir servi un 200 sur l’ancienne URL juste après la bascule, puis un 301 le lendemain, ou l’inverse. Regardez le rapport Pages quelques jours plus tard : les 404 qui montent sont des lignes absentes de la carte, à ajouter en 301, pas à ignorer. Les redirections restent en place au moins un an. Écrivez cette date sur la carte, sinon quelqu’un résiliera l’ancien hébergement au prochain renouvellement.
Le livrable est la carte avec une colonne contrôlé le remplie le jour J et à 48 heures. Une migration sans cette colonne est un changement de DNS. Vous saurez qu’elle a marché le jour où un client trouvera un 404, ce qui est une méthode de contrôle un peu tardive.