Migrer son site vers un nouveau CMS sans perdre son référencement

Un client qui change de CMS ou relance une refonte me pose presque toujours la même question en premier : est-ce que le site va garder sa place sur Google. La réponse honnête, c'est que ça dépend entièrement de comment la migration est menée. J'ai vu des sites perdre la moitié de leur trafic organique en quelques semaines après un changement d'hébergeur ou de CMS, pas parce que le nouveau site était mauvais, mais parce que personne n'avait pensé à ce que Google allait voir le jour du basculement.

Le vrai risque, ce ne sont pas les nouvelles pages

On se concentre naturellement sur ce qu'on construit : le nouveau design, les nouvelles fonctionnalités, parfois un nouveau découpage des rubriques. Mais ce qui fait mal au référencement, c'est rarement ce qui est ajouté. C'est ce qui disparaît sans prévenir. Une page qui changeait d'URL sans redirection, un ancien article fusionné dans un autre sans qu'on y pense, une structure de catégories repensée qui casse tout le maillage existant : Google se retrouve avec des centaines de liens qui pointent vers du vide, et il met ça sur le compte d'un site qui s'est dégradé. C'est le même type de signal qu'on cherche à détecter lors d'un audit SEO technique, sauf qu'ici le problème est créé le jour même de la mise en ligne.

Les redirections 301, l'étape qu'on bâcle le plus souvent

La règle est simple à énoncer : chaque ancienne URL qui change d'adresse doit rediriger vers sa nouvelle version, une par une, pas vers la page d'accueil par défaut. Dans la pratique, c'est l'étape qu'on sacrifie le plus souvent quand le planning déborde, parce qu'elle demande de lister méthodiquement toutes les pages existantes avant de couper l'ancien site. Sans cette liste, la migration se fait dans le mauvais sens : on construit le nouveau site, on le publie, et on découvre les trous a posteriori, une fois que Google a déjà commencé à désindexer les pages manquantes. À ce stade, récupérer le positionnement perdu prend des mois.

Le sitemap XML et le fichier robots.txt méritent la même attention, et pourtant ce sont souvent les deux derniers éléments auxquels on pense. Un sitemap qui pointe encore vers l'ancienne structure, ou un robots.txt copié depuis l'ancien hébergement sans être relu, peut bloquer l'exploration du nouveau site sans que personne ne s&apos9en aperçoive avant plusieurs semaines. Ce sont des fichiers techniques, discrets, mais ils conditionnent directement ce que Google voit et comprend du site tout juste mis en ligne.

Ne pas tout réécrire par réflexe

Une refonte donne souvent envie de repartir d'une page blanche sur les textes aussi, pas seulement sur le design. C'est une erreur fréquente : un contenu qui positionne bien depuis des mois porte des signaux que Google a déjà appris à reconnaître, et le réécrire entièrement revient à repartir de zéro à ses yeux. Mieux vaut repérer ce qui fonctionne déjà, le garder tel quel ou l'améliorer par petites touches, et réserver l'effort de création aux pages qui en avaient vraiment besoin. C'est un des signes qui doit alerter avant même de lancer le projet, au même titre que les points listés dans notre article sur les signes qu'une refonte devient nécessaire: la refonte doit corriger un problème précis, pas tout remettre à plat par habitude.

Le nouveau CMS doit laisser la main, pas la reprendre

Beaucoup de migrations partent d'un bon réflexe : sortir d'un CMS devenu trop limité pour gérer un catalogue, des rôles utilisateurs ou des contenus qui bougent souvent. Le risque, c'est de troquer une limite contre une autre en choisissant un outil générique de plus, qui impose sa propre structure d'URLs et son propre fonctionnement de balisage. Sur les sites avec back-office sur-mesure qu'on construit, la structure des pages et des URLs reste pensée pour le référencement dès le départ, justement pour éviter ce genre de compromis au moment où le client veut faire évoluer son site lui-même.

Après la mise en ligne, surveiller plutôt qu'espérer

Les premières semaines qui suivent un basculement sont celles où tout se joue. Il faut vérifier que Google arrive bien à explorer le nouveau site, que le temps de chargement n'a pas régressé malgré le nouveau design — un sujet qu'on développe dans notre article sur la vitesse de chargement—, et que les positions sur les requêtes principales ne décrochent pas sans explication. Une migration réussie n'est pas celle qui se termine au moment de la mise en ligne, c'est celle qu'on continue à surveiller pendant les semaines suivantes, prêt à corriger vite si quelque chose a été oublié.

Si un changement de CMS ou une refonte est au programme chez vous, ça se prépare bien avant le premier écran de maquette.