Ce qui se perd vraiment quand on migre
Chaque année, je récupère deux ou trois sites qui ont fondu après une refonte. Le diagnostic est presque toujours le même : le nouveau site est plus joli, plus rapide, mieux fichu, mais ses adresses ont changé et personne n'a fait le pont avec les anciennes.
Il faut se rappeler ce que Google stocke. Pas « votre site » comme entité abstraite, mais une collection d'URL, chacune avec son historique : contenu indexé, liens externes reçus, positions acquises. Changez l'adresse sans prévenir, et cet historique reste accroché à une page qui répond 404, pendant que le contenu réapparaît ailleurs, vierge de tout passé.
D'où la seule vraie question d'une migration : comment transférer cet historique, URL par URL ? Une refonte graphique qui réécrit tous les slugs au passage est bien plus risquée qu'un changement de CMS à adresses constantes.
Étape 1 : la photo de l'existant, avant de toucher à quoi que ce soit
Cette étape se fait sur le site encore en ligne : une fois l'ancienne version débranchée, ces données sont irrécupérables.
Commencez par un crawl complet, avec Screaming Frog, Sitebulb ou un crawler en ligne : vous en tirez la liste exhaustive des URL en 200, avec leurs titles et leurs balises canonical. Exportez en tableur, c'est la colonne de gauche de votre plan de redirection. Si ces outils vous freinent, mon guide pour auditer vous-même la technique de votre site les détaille pas à pas.
Un crawl ne voit que les pages reliées par des liens. Complétez avec l'export des performances de la Search Console sur seize mois, celui des pages indexées (souvent plein d'URL orphelines) et vos logs serveur si vous y avez accès.
Dernier réflexe, trop négligé : notez votre point de départ. Trafic organique mensuel, pages indexées, positions sur vos vingt requêtes principales. Sans cette photo avant, impossible de dire si la baisse constatée trois semaines plus tard vient de la migration ou de la saisonnalité.
Étape 2 : le plan de redirection, le seul livrable non négociable
Un plan de redirection, c'est un tableau à deux colonnes : ancienne URL, nouvelle URL. Rien de plus, et c'est justement ce qui le rend pénible à produire quand le site compte quelques milliers de pages.
La règle : correspondance un pour un, chaque ancienne adresse vers la page qui répond à la même intention sur le nouveau site. Pas vers l'accueil, pas vers la catégorie parente en attendant mieux. Google traite les redirections vers une destination sans rapport comme des soft 404, et l'historique part à la poubelle.
Trois cas reviennent toujours. Les pages sans équivalent : si le contenu disparaît, assumez un 404, sauf si la page recevait des liens externes. Les regroupements, plusieurs pages fusionnées en une, légitimes tant que le nouveau contenu couvre les sujets absorbés. Les paginations et les filtres, à traiter par motif global.
On utilise des redirections permanentes, uniquement : la 302 dit à Google que l'ancienne adresse reste la bonne, l'inverse du message à faire passer. La distinction est détaillée dans mon guide sur la façon de mettre en place une redirection permanente. Vérifiez aussi qu'une URL atteint sa destination en un seul saut.
Enfin, testez le plan en préproduction : on passe les anciennes URL dans un crawler en mode liste, et on contrôle le code retourné et l'adresse d'arrivée. Une demi-journée fastidieuse, qui sépare une migration propre d'un sauvetage trois mois plus tard.
Refonte, changement de domaine, HTTPS : ce qui diffère
Les trois scénarios n'ont pas le même profil de risque. Le passage en HTTPS ou l'ajout du www sont les plus simples : les chemins ne bougent pas, une règle globale suffit.
La refonte à domaine constant est le cas le plus courant et le plus casse-gueule, parce que le changement d'URL y est souvent un effet de bord non décidé : le nouveau CMS génère ses slugs à sa façon et personne ne réalise que 800 adresses viennent de changer. Le réflexe qui sauve : demander en amont si les URL bougent, et exiger la liste.
Le changement de domaine ajoute une couche : conservez l'ancien domaine et son certificat au moins un an, créez la nouvelle propriété dans la Search Console, puis déclarez l'opération avec l'outil de changement d'adresse. La marche à suivre officielle figure dans la documentation Google sur les déplacements de site avec changement d'URL.
Le jour de la bascule : l'ordre des opérations
Migrez un mardi matin, jamais un vendredi soir : vous voulez être disponible les 48 heures suivantes, et l'équipe technique aussi. Évitez également vos pics d'activité annuels.
- Vérifier que le nouveau site n'est plus bloqué. C'est l'oubli n°1, la préproduction interdite aux robots qui part en ligne telle quelle : contrôlez le robots.txt et l'absence de noindex sur les modèles de page.
- Activer le plan de redirection en une fois, et le repasser au crawler dans la foulée.
- Mettre en ligne le nouveau sitemap XML, avec les nouvelles adresses uniquement, et le soumettre à la Search Console. Beaucoup laissent traîner l'ancien : le sujet est traité dans mon guide sur la manière de piloter l'exploration de son site.
- Corriger les liens internes en dur : la redirection fait le travail, mais le lien direct reste préférable.
- Contrôler que le suivi analytique et la balise de vérification Search Console ont survécu.
- Passer quelques URL importantes à l'inspection d'URL, pour voir ce que Googlebot constate.
Pour un changement de domaine, l'outil de changement d'adresse se déclare après l'activation des redirections : il a besoin de les constater.
Les semaines qui suivent : ce qu'on surveille, ce qu'on ignore
Une migration ne se juge pas le lendemain. Comptez six à huit semaines, le temps que Google recrawle l'ensemble et bascule ses URL canoniques. Les gros sites sont plus lents, le recrawl complet prenant plus de temps.
Ce qu'on regarde vraiment : le rapport d'indexation, où le volume de pages doit descendre côté ancien site et monter côté nouveau, en miroir. Les 404 nouvellement détectées, autant de lignes manquantes dans le plan. Et le trafic par groupe de pages, pas en global : une baisse concentrée sur une section signale un problème localisé.
Ce qu'on ignore : les fluctuations de positions des dix premiers jours. Elles poussent à des corrections précipitées. J'ai vu un site où l'on avait annulé les redirections au bout d'une semaine « parce que ça ne marchait pas ». C'est là que les vrais dégâts commencent.
La règle que je répète à chaque projet : on ne change rien d'autre pendant la migration. Ni les contenus, ni l'arborescence des catégories, ni la stratégie de mots-clés. Sinon, en cas de baisse, impossible d'isoler la cause parmi trois variables modifiées en même temps.
Les erreurs qui coûtent le plus cher
Par ordre de fréquence dans les audits post-migration : le noindex de préproduction laissé en ligne, qui désindexe le site en quelques jours. Les redirections en masse vers l'accueil. Les chaînes accumulées quand une migration s'empile sur une ancienne. Les redirections coupées trop tôt, à l'échéance d'un domaine que personne n'a renouvelé.
Une migration réussie, ce n'est pas de la magie : un tableur bien rempli et un peu de discipline sur l'ordre des opérations.