Une migration CMS fait partie des rares projets où le travail technique peut se dérouler parfaitement et le résultat rester un désastre. Le site sort dans les temps, il est plus beau, il charge plus vite, et le trafic chute de moitié, parce que quelques centaines d’URL ont changé de forme et que personne n’a construit le plan de redirection.

La perte ne vient pas de la nouvelle plateforme. Elle vient de la rupture : des adresses qui répondaient ne répondent plus, des pages qui étaient identifiables ont l’air neuves, et l’historique accumulé sur les anciennes URL n’a plus nulle part où aller.

La seule décision qui détermine le résultat : gardez-vous la structure d’URL ? Si oui, la migration se réduit pour l’essentiel à un exercice de contenu et de gabarits, et le risque reste modéré. Si non, chaque adresse modifiée réclame une redirection vers son équivalent précis, et c’est l’exhaustivité de ce plan qui décide si la migration passe inaperçue ou coûte cher. Il n’existe pas de troisième cas où les URL changent et où tout se passe bien quand même.

Ce qu’une migration CMS casse vraiment

Les URL, et c’est le point majeur. Chaque plateforme a ses propres conventions pour les chemins, la pagination, les catégories et les dates, et adopter les réglages par défaut de la nouvelle réécrit silencieusement toutes les adresses du site.

Les métadonnées. Les titres et descriptions rédigés au fil des années survivent rarement à un export, et la nouvelle plateforme les regénère à partir de gabarits. L’oubli est facile, parce que les pages ont parfaitement bonne allure.

Les données structurées. Le balisage produit par une extension sur l’ancienne plateforme disparaît avec elle, et les équivalents rendent rarement une sortie identique. Notre guide sur la façon dont les moteurs de recherche IA lisent le balisage Schema détaille ce qui doit survivre.

Les liens internes. Un contenu truffé de liens absolus vers les anciens chemins continuera de pointer vers eux, ce qui, après un changement d’URL, signifie que chacun d’eux passe au mieux par une redirection.

Les images et médias. Chemins de stockage différents, noms de fichiers différents, et textes alternatifs qui vivaient dans l’ancienne base de données sans figurer dans l’export.

Tout ce qu’une extension faisait pour vous. Des redirections configurées au fil des ans, des règles canoniques, des formats de flux et des fonctions que personne n’a documentées parce qu’elles tenaient dans une case à cocher.

Inventoriez tout cela avant la migration, pas après. La liste de ce que l’ancienne plateforme fait discrètement à votre place est toujours plus longue que prévu.

Le plan de redirection décide de tout

Si les URL changent, c’est le livrable qui compte, et il doit être complet plutôt que presque complet.

Construisez la liste de départ à partir de plusieurs sources. Un crawl du site en ligne trouve ce qui est lié. Vos statistiques et la Search Console trouvent les pages qui reçoivent du trafic mais peuvent être orphelines. Les journaux serveur trouvent ce qui est réellement demandé, y compris par les autres sites qui pointent vers vous. Chaque source prise seule laisse passer des choses, et les pages oubliées sont surtout les anciennes, celles qui portent des liens.

Associez chaque ancienne URL à son équivalent précis. Pas à la page d’accueil, pas à une page de catégorie : une redirection vers quelque chose qui ne répond pas à la demande initiale est traitée comme une erreur douce et ne transmet presque aucune valeur. La documentation de Google sur le déménagement de site décrit la correspondance attendue. Si vraiment rien ne correspond, renvoyer une réponse « page introuvable » est la solution honnête, et elle vaut mieux qu’une redirection trompeuse.

Utilisez des redirections permanentes, limitez les chaînes à un seul saut en faisant pointer les anciennes adresses directement vers les destinations finales, et rappelez-vous que les règles sont évaluées dans l’ordre : un motif large placé au-dessus d’une règle précise l’avale.

Testez ensuite le plan avant la mise en ligne, sur la liste complète et non sur un échantillon.

Avant de basculer

Crawlez et archivez l’ancien site. Un relevé complet de chaque URL avec son titre, sa description, sa canonique, son code de statut et son nombre de mots. C’est votre référence de comparaison, et vous ne pourrez pas la produire après coup.

Exportez et vérifiez le contenu. Comptez, ne vous contentez pas de constater que l’export s’est terminé. Catégories manquantes, champs personnalisés perdus et articles tronqués sont fréquents, et tous silencieux.

Préparez la recette sur un environnement bloqué. Un site de préproduction qui se fait indexer crée des doublons de tout votre site, un problème pire que celui que vous cherchiez à résoudre.

Vérifiez que les nouveaux gabarits produisent ce que produisaient les anciens. Titres, descriptions, canoniques, données structurées, et hreflang si vous gérez plusieurs langues, comme le détaille notre guide du SEO multilingue.

Planifiez la date. Pas avant votre période la plus chargée, et pas un vendredi. Vous voulez plusieurs jours ouvrés d’attention pleine juste après.

Après la bascule

Les quarante-huit premières heures comptent plus que le mois qui suit, car c’est là qu’une erreur réparable reste bon marché.

Surveillez les réponses « page introuvable » dans les journaux serveur. C’est le moyen le plus rapide de trouver les URL oubliées par votre plan, et il les trouve à partir de demandes réelles plutôt que de vos hypothèses. Soumettez le nouveau sitemap, puis vérifiez que le crawl a bien lieu au lieu de le supposer.

Comparez avec le crawl de référence. Chaque URL indexable auparavant doit désormais soit répondre, soit rediriger vers une cible précise. Celle qui ne fait ni l’un ni l’autre est un trou.

Attendez-vous à un creux. Quelques semaines de fluctuation restent normales même sur une migration bien menée, le temps que les nouvelles adresses soient recrawlées et réévaluées. Ce qui n’est pas normal, c’est une baisse durable qui ne se rétablit pas, et elle vient presque toujours de redirections oubliées ou envoyées vers une cible générique.

Gardez les redirections indéfiniment. Ce n’est pas une mesure transitoire : c’est la seule chose qui relie des années de liens accumulés à vos pages actuelles, et les retirer un an plus tard reproduit la perte initiale.

Mecanik prend en charge ce type de migration dans le cadre de nos prestations de développement web. Le schéma se répète : le changement de plateforme est une routine, et tout l’écart entre un bon et un mauvais résultat tient à l’exhaustivité du plan.

Questions fréquentes

Pourquoi le trafic chute-t-il après une migration CMS ? Presque toujours parce que les URL ont changé et que le plan de redirection était incomplet. Les anciennes adresses cessent de répondre, donc des années de liens accumulés et d’historique de crawl n’ont plus nulle part où aller. La plateforme elle-même cause rarement la perte ; c’est la rupture entre anciennes et nouvelles adresses qui la cause.

Dois-je conserver ma structure d’URL en changeant de CMS ? Si vous le pouvez, oui. Conserver la structure réduit la migration à un exercice de contenu et de gabarits, avec un risque modéré. La changer implique que chaque adresse modifiée reçoive une redirection vers son équivalent précis, et l’exhaustivité de cette correspondance détermine si la migration passe inaperçue ou coûte cher.

Où trouver la liste des URL à rediriger ? Dans plusieurs sources, car chacune laisse passer des choses. Un crawl du site en ligne trouve les pages liées, les statistiques et la Search Console trouvent les pages qui reçoivent du trafic et peuvent être orphelines, et les journaux serveur trouvent ce qui est réellement demandé, y compris depuis des liens externes. Les pages oubliées par une source unique sont surtout les anciennes, celles qui portent des liens.

Puis-je rediriger les anciennes pages vers la page d’accueil ? Non. Une redirection vers quelque chose qui ne répond pas à la demande initiale est traitée comme une erreur douce et ne transmet presque aucune valeur. Associez chaque ancienne URL à son équivalent précis, et là où rien ne correspond vraiment, renvoyer une réponse « page introuvable » est plus honnête et plus utile qu’une redirection trompeuse.

Combien de temps faut-il garder les redirections de migration ? Indéfiniment. Ce n’est pas une mesure transitoire mais le seul lien entre des années de liens entrants accumulés et vos pages actuelles ; les retirer un an plus tard reproduit exactement la perte de trafic que la migration devait éviter.