Migration de CMS : déménager sans perdre de trafic
Une migration de CMS déplace du contenu d'un système vers un autre. Le risque n'est pas technique — exports et imports sont des problèmes résolus — c'est que la structure, les URL et les métadonnées changent en chemin, et les moteurs de recherche remarquent les trois.
Ce guide couvre la séquence qui préserve le trafic, l'audit qui devrait venir en premier, et ce qu'il faut surveiller ensuite.
Auditez avant de déplacer quoi que ce soit#
Tout migrer est le réflexe par défaut et généralement le mauvais choix. La plupart des sites traînent une longue queue de pages sans trafic, sans liens et sans utilité, et les déplacer importe le problème dans le nouveau système.
- Explorez le site existant pour obtenir toutes les URL qui existent réellement.
- Extrayez douze mois de trafic par URL, plus les liens entrants.
- Classez chaque page : migrer telle quelle, réécrire, fusionner avec une autre, ou abandonner.
- Tout ce qui a du trafic ou des liens doit avoir une destination. Le reste peut partir.
- Notez quelles pages portent des données structurées, des champs sur mesure ou des gabarits inhabituels.
- Exportez les métadonnées — titres et descriptions — séparément. C'est le bien le plus fréquemment perdu lors d'une migration.
Fusionner des pages pauvres dans des pages plus fortes pendant une migration est l'un des rares résultats SEO fiablement positifs de tout l'exercice. Redirigez les fusionnées vers la survivante.
Modélisez le contenu avant de l'importer#
La tentation est de recréer exactement l'ancienne structure. Cela importe d'anciens compromis. Modélisez le contenu tel qu'il devrait être, puis faites correspondre les anciennes données dessus.
| Étape | Ce qu'il faut décider |
|---|---|
| Types de contenu | Ce qui diffère réellement : page, article, produit, personne, événement |
| Champs | Des champs structurés plutôt qu'un bloc de HTML partout où c'est faisable |
| Taxonomies | Quelles catégories et étiquettes survivent ; la plupart des sites en ont trop |
| Médias | Où vivent les fichiers et si les chemins changent |
| Auteurs et dates | Conserver les vraies dates de publication ; ne pas toutes les remettre à aujourd'hui |
| Métadonnées | Titres, descriptions et canoniques cartographiés explicitement |
| Table de redirections | Ancienne URL vers nouvelle URL, une pour une, construite au fil de l'eau |
Réinitialiser les dates de publication à l'import est un accident fréquent et détruit d'un coup le signal de fraîcheur de toute votre archive.
Conservez les URL, et redirigez ce que vous ne pouvez pas#
Le facteur qui détermine le plus si une migration coûte du trafic.
- Conservez la structure d'URL existante sauf si elle est réellement cassée. « Le nouveau CMS préfère un autre motif » n'est pas une raison suffisante.
- Là où les URL doivent changer, cartographiez une pour une — jamais vers une page de catégorie ni vers l'accueil.
- Utilisez des redirections 301, et vérifiez que chacune est un saut unique.
- Redirigez aussi les fichiers médias. Les images accumulent des liens et apparaissent dans la recherche d'images.
- Conservez les redirections indéfiniment ; les liens externes ne sont jamais mis à jour.
- Testez la table de redirections en préproduction avec la liste complète avant le lancement, pas avec un échantillon.
Le lancement et les six semaines suivantes#
La migration n'est pas finie à la bascule. La plupart des problèmes deviennent visibles le mois suivant.
- Lancez quand vous pouvez surveiller. Pas un vendredi, pas avant un jour férié.
- Vérifiez immédiatement robots.txt, meta robots, canoniques et sitemap en production.
- Passez la liste complète de redirections contre la production et cherchez les 404 et les chaînes.
- Soumettez le nouveau sitemap dans la Search Console et surveillez la couverture quotidiennement pendant une semaine.
- Comparez les pages principales à la période précédente ; une page qui chute nettement a généralement une cause précise.
- Surveillez les journaux serveur pour les 404 des robots : ils trouvent les URL oubliées plus vite que les statistiques.
- Attendez-vous à des fluctuations pendant deux à six semaines ; enquêtez sur une baisse qui continue de s'aggraver après un mois.
- Gardez l'ancien système en lecture seule un temps, pour pouvoir vérifier ce que contenait une page.
Questions fréquentes
Vais-je perdre du trafic de recherche en migrant ?
Attendez-vous à une baisse de quelques semaines même quand tout est fait correctement : les moteurs doivent réexplorer et réévaluer. Avec des redirections propres et un contenu conservé, le trafic revient normalement au niveau précédent en deux à six semaines. Une perte permanente se ramène presque toujours à des redirections oubliées, du contenu modifié, ou des pages discrètement abandonnées.
Dois-je refondre en même temps ?
C'est tentant et cela rend le diagnostic bien plus difficile : quand le trafic bouge, vous ne pouvez pas dire si c'était la migration ou le design. Si vous pouvez les séparer, migrez d'abord avec les gabarits existants, confirmez la stabilité, puis refondez. Si cela doit se faire ensemble, soyez plus rigoureux encore sur la conservation des URL et du contenu.
Comment migrer du contenu qui ne se transpose pas proprement ?
Il y a toujours du contenu qui résiste à l'automatisation : mises en page sur mesure, widgets intégrés, tableaux faits à la main. Repérez-les pendant l'audit et budgétez du temps manuel. Vouloir automatiser les derniers 5 % coûte généralement plus cher que de le faire à la main, et produit un moins bon résultat.
Dois-je garder l'ancien CMS en fonctionnement ?
Gardez-le accessible mais non public pendant quelques mois : en lecture seule, bloqué aux moteurs, sur une adresse interne. C'est inestimable pour vérifier ce que disait une page quand quelque chose paraît faux. Ensuite mettez-le hors service proprement : une installation publique abandonnée est un risque de sécurité.
migration cmsmigration site webmigration de contenuchangement de plateformeredirections migrationmigrer wordpress
