Un plan de migration SEO répond à une question simple : qui décide quoi, sur quelle preuve, et à quel moment. Les guides en ligne le présentent comme une liste d'étapes ; je le traite comme un document qui fixe ce qu'on mesure avant, ce qu'on surveille pendant la bascule, et ce qu'on contrôle après, avec un nom en face de chaque ligne. Le plan de redirection, celui qui associe chaque ancienne adresse à sa nouvelle destination, n'en est qu'une pièce parmi d'autres. Si vous préparez un changement de domaine, de CMS ou d'hébergeur, la définition de chaque cas et ses pièges figurent dans l'article sur la migration de site web. Ici, je vous montre comment structurer la décision elle-même, avant, pendant et après.
Ce que contient un plan de migration SEO
| Rubrique | Ce qu'elle fixe | Qui la tient |
|---|---|---|
| Mesure de référence | Photo datée avant bascule | Les deux |
| Inventaire des adresses | Toutes les pages à traiter | Moi |
| Plan de redirection | Ancienne adresse vers nouvelle | Moi |
| Gel des contenus | Plus aucune publication | Vous |
| Critères de bascule | Conditions du feu vert | Les deux |
| Retour arrière | Quand revenir, quand corriger | Les deux |
| Rendez-vous de contrôle | Lendemain, J+7, J+30 | Les deux |
Confondre le plan de migration et le plan de redirection fait rater des migrations pourtant bien redirigées techniquement. Les 301 sont posées, tout semble propre ; mais la décision de basculer n'a jamais eu de critère écrit, personne ne sait dans quelles conditions revenir en arrière, et personne n'a de référence pour juger si le trafic d'après ressemble au trafic d'avant. Le plan de redirection règle le trajet des pages. Le plan de migration règle la décision.
Avant la bascule : mesurer, inventorier, geler
Relever la mesure de référence
Avant toute bascule, je prends une photo datée du site en place : pages indexées, requêtes principales, clics et impressions, exportée hors de l'outil pour qu'elle ne bouge plus. J'y ajoute une courte liste de pages témoins, celles qui amènent réellement des contacts ou des ventes, quel que soit leur rang dans les statistiques de visites. Si le domaine change, la propriété Search Console du nouveau domaine se crée avant la bascule : sans elle, impossible d'envoyer le sitemap ni de déclarer le changement d'adresse le jour J.
Inventorier toutes les adresses, y compris hors du menu
Le menu du site ne montre jamais toutes les pages qui comptent. L'inventaire croise trois sources : un crawl complet de l'ancien site, les pages connues de Search Console, et celles qui reçoivent des liens externes ou internes utiles. La méthode du fichier de correspondance, colonne par colonne, est détaillée dans ma checklist de migration de site web ; je ne la redéveloppe pas ici. Sur la migration WooCommerce d'Ad Majoris, cet inventaire a couvert plus de mille pages, sans perte de référencement à l'arrivée : c'est ce travail en amont qui l'a permis ; les redirections n'ont fait qu'exécuter l'inventaire. Voir le cas Ad Majoris.
Geler les contenus jusqu'à la bascule
Entre le dernier inventaire et la mise en ligne, personne ne publie ni ne renomme de page sur l'ancien site. Si une page doit sortir malgré tout, elle entre d'abord dans le plan de redirection, jamais en dehors. Sans ce gel, des adresses nées après l'inventaire tombent en 404 le jour de la bascule ; et c'est souvent là que naissent les pertes qu'on attribue ensuite, à tort, à la technique.
Pendant : la veille et le jour de la bascule
Les critères qui autorisent la bascule
La veille, je vérifie une liste courte. Chaque ligne se répond par oui ou non, rien d'intermédiaire :
- chaque adresse du plan de redirection testée, un seul saut vers une page qui répond ;
- aucun blocage d'indexation sur le nouveau site ;
- robots.txt et sitemap prêts à être envoyés ;
- formulaires et paiement testés en conditions réelles ;
- sauvegarde complète de l'ancien site faite et vérifiée.
Une seule condition à non, et la date se décale. Décaler d'un jour coûte moins cher qu'une semaine de pages introuvables qui font fuir des visiteurs qui cherchaient un produit ou un rendez-vous. Le plan nomme aussi qui prononce le go : vous, sur la base de ma vérification. Cette ligne évite l'ambiguïté du soir où tout le monde attend que quelqu'un d'autre décide.
L'ordre des opérations le jour J
Le jour de la bascule suit un ordre fixe, celui de ma checklist de mise en ligne :
- sauvegarde de l'ancien site, horodatée ;
- redirections 301 activées et rejouées une par une ;
- certificat SSL actif sur le nouveau domaine ;
- robots.txt ouvert à l'exploration ;
- sitemap envoyé dans Search Console ;
- contrôle de la liste des anciennes adresses, dès le soir de la bascule.
Le choix du jour compte autant que l'ordre. Pas la veille d'un week-end, pas en haute saison commerciale : le pire moment pour découvrir un problème, c'est quand personne ne peut le corriger avant deux jours. Choisissez un jour où l'équipe est présente le lendemain matin, prête à reprendre la liste dès l'ouverture.
Le plan de retour arrière : quand revenir à l'ancien site
L'ancien site reste intact et restaurable pendant les premiers jours ; c'est écrit dans le plan. Mais tout ne mérite pas un retour en arrière. Deux cas, et deux seulement.
On revient en arrière pour une panne qui coupe l'activité : site injoignable, formulaires ou commandes qui ne partent plus, paiement cassé. Là, chaque heure compte en chiffre d'affaires perdu ; le retour arrière est la décision la plus rapide.
On ne revient jamais en arrière pour une baisse de positions. Aller et venir entre deux versions du site envoie à Google des signaux contradictoires, ce qui retarde la stabilisation. Dans ce cas, on corrige donc sur le nouveau site : redirection manquante, contenu tronqué, maillage cassé. Écrire cette règle avant la bascule évite de la décider sous stress, un soir, avec une courbe qui baisse et l'envie de tout annuler.
Après : trois rendez-vous de contrôle
Le lendemain
Je vérifie qu'aucune page n'est introuvable, qu'aucun blocage d'indexation ne traîne, que le sitemap a été lu par Search Console. Les pages témoins répondent, et j'envoie un vrai formulaire, comme le ferait un client : je veux voir le mail arriver.
À J+7
Dans Search Console, trois signaux : les nouvelles adresses entrent dans l'index, les anciennes sont vues comme redirigées, les erreurs d'exploration restent à zéro ou proches. Un site qui migre bien se lit dans ces trois courbes avant de se lire dans le trafic.
À J+30
Comparaison page par page avec la mesure de référence, en commençant par les pages témoins, celles qui rapportent des contacts ou des ventes. Deux décisions possibles : on clôt la migration, ou on corrige ce qui traîne. Les 301, elles, restent en place au moins un an, quelle que soit la décision.
La migration WordPress de Skinobs, plus de 5000 articles en français et en anglais, s'est faite sans perte de référencement. Sur un tel volume, la mise en ligne n'est qu'une étape : c'est la comparaison avec la mesure de référence qui dit si la migration est terminée.
La checklist du plan de migration SEO, phase par phase
| Quand | Action | Preuve attendue |
|---|---|---|
| Avant | Mesure de référence | Export daté |
| Avant | Inventaire des adresses | Fichier de correspondance |
| Veille | Test des redirections | Rapport de test |
| Veille | Contrôle indexation | Capture robots.txt |
| Jour J | Sauvegarde ancien site | Fichier horodaté |
| Jour J | Activation 301 | Liste rejouée |
| Jour J | Sitemap envoyé | Capture Search Console |
| Lendemain | Pages témoins vérifiées | Captures pages ouvertes |
| Lendemain | Formulaire testé | Mail reçu |
| J+7 | Index des nouvelles pages | Capture Search Console |
| J+7 | Erreurs d'exploration | Rapport d'erreurs |
| J+30 | Comparaison page par page | Tableau avant après |
Ce plan fait partie de toute refonte de site web que je pilote ; il s'écrit dès les premières semaines du planning de refonte, bien avant la mise en ligne. Si vous préparez une bascule et voulez le poser sur votre projet, c'est le bon moment pour en parler.