Migration SEO et refonte CMS : sécuriser trafic et indexation

Une équipe change de CMS et conserve ses URL les plus connues. Le nouveau catalogue répond en 200, mais les anciens liens vers deux catégories renvoient vers l’accueil. Le formulaire de devis s’ouvre encore sur mobile, alors que sa nouvelle variante envoie un code de service inconnu au CRM. Ces deux défauts exigent des vérifications différentes avant de donner le feu vert.

Une migration SEO se prépare avec un inventaire des pages et des parcours à protéger. Pour chaque famille, le plan associe une ancienne URL, une destination, un résultat attendu et la preuve qui autorise l’ouverture. Ce dossier sert aussi à décider quoi réparer lorsque les premiers signaux divergent.

Le scénario fictif suit un changement de CMS et de chemins pour des catégories, des fiches et des pages de service. Il permet de répartir les contrôles entre SEO, développement et équipe commerciale.

Si votre équipe a besoin de faire préparer ou exécuter la bascule, notre accompagnement à la migration et à la refonte SEO couvre le mapping, les tests et le suivi après publication. Pour intégrer la bascule à un chantier plus large, notre expertise en SEO technique couvre aussi le crawl, le rendu et la performance.

Quand préparer un plan de migration SEO

Utilisez ce plan pour un changement de domaine, une refonte de CMS, une nouvelle taxonomie ou un changement de rendu qui affecte des pages d’entrée. Même avec les mêmes URL, un nouveau template peut perdre son contenu principal, ses liens ou sa balise canonique. Repérez les familles exposées avant de définir la recette.

Si le calendrier le permet, séparez le changement de domaine du changement de CMS ou de navigation. Des dates distinctes facilitent le diagnostic et permettent de rétablir une couche sans annuler les autres. Lorsque les changements doivent coïncider, notez précisément les versions, les lots et les heures de mise en ligne.

Checklist de migration SEO, avant et après la bascule

Pour chaque contrôle, notez l’URL témoin, le résultat attendu, le résultat obtenu et la personne qui traite l’écart. Dans l’exemple, l’équipe peut vérifier le catalogue et le parcours de devis dès les premiers essais.

1. Avant la refonte, repérez les pages et les parcours à protéger. Exportez les anciennes URL depuis le crawl, les sitemaps, les liens externes, les logs et Search Console. Repérez les pages qui concentrent les clics et celles qui apportent des demandes.
2. Avant la recette, décidez du sort de chaque URL. Conservez son adresse, reliez-la à une destination équivalente ou consignez son retrait. Le guide de correspondance des URL aide à traiter les fusions et les exceptions. Une fois les destinations validées, le guide de test des redirections 301 aide à vérifier les règles sur les anciennes adresses.
3. Avant le feu vert, testez les cas qui bloquent le lot. Dans l’exemple, une catégorie active renvoyée vers l’accueil ou un devis témoin absent du CRM suffit à suspendre le lot concerné. Le dossier de décision de bascule aide à attribuer ces écarts et à consigner les risques acceptés.
4. À l’ouverture, refaites les tests depuis le site public. Suivez l’ancienne URL jusqu’à la destination finale. Comparez le HTML, les directives d’indexation et le sitemap au résultat attendu. Vérifiez la demande témoin dans le CRM.
5. Après l’ouverture, séparez les incidents des variations de visibilité. Corrigez les défauts reproductibles, puis comparez les clics sur des périodes consolidées et par famille de pages. Reliez chaque correction à sa date et à son résultat dans le dossier de preuves de la migration.

Définir ce que la bascule doit préserver

Commencez par les destinations qui ont un rôle identifiable. Une catégorie peut concentrer les visites génériques, un article peut recevoir des liens externes et une page de service peut générer peu de visites mais beaucoup de demandes. La priorité de recette dépend du rôle de la page et de la gravité d’un défaut.

Pour chaque famille, choisissez une URL nominale et des exceptions. Pour les catégories, prenez par exemple une catégorie active, une catégorie fusionnée et un ancien filtre indexé. Pour les pages de service, testez le chemin depuis une ancienne URL jusqu’à la réception du formulaire dans la file attendue.

Figer les données avant le changement

Conservez les clics et impressions par page et, quand les données le permettent, par requête. Archivez aussi les entrées organiques et les demandes reçues avec leur fenêtre de mesure. Pour chaque export, notez la propriété, le pays, l’appareil, les filtres et la date de consolidation. Ces éléments permettent de comparer la même population après la bascule.

Inscrivez les événements susceptibles de brouiller la lecture. Une campagne de marque qui se termine, une rupture de stock ou un changement de formulaire peut déplacer les chiffres le même jour que le lancement. Une courbe globale permet d’ouvrir une enquête. L’interprétation dépend ensuite des cohortes et des preuves techniques.

Décider du sort de chaque ancienne URL

Une URL conservée doit répondre directement. Si elle change de chemin et dispose d’un équivalent, utilisez une redirection permanente côté serveur vers la nouvelle URL. Lorsqu’un contenu disparaît sans équivalent pertinent, prévoyez le statut de retrait approprié. Une redirection générale vers l’accueil ne préserve pas l’intention de recherche d’une page supprimée.

Contrôlez que les liens du nouveau site pointent directement vers les cibles finales. La balise canonique, le sitemap et les liens doivent rester cohérents. Pour une migration de domaine, vérifiez les propriétés Search Console concernées et les conditions d’utilisation de l’outil Changement d’adresse. Le guide des migrations de Google détaille ces étapes et recommande de conserver les redirections au moins un an.

Prioriser les familles et les exceptions

Testez toutes les anciennes URL critiques et toutes les règles de réécriture utilisées. Sur un grand catalogue, complétez par des échantillons par gabarit et par règle, y compris les exceptions de casse, de langue et de paramètres qui ont une valeur commerciale. Une couverture élevée en nombre d’URL peut masquer une famille entière envoyée vers la mauvaise catégorie.

Dans la matrice, une exception doit avoir un motif, une personne responsable et une échéance de revue. Si deux anciennes pages se ressemblent, relisez leur contenu et leurs requêtes avant de décider qu’une seule cible peut reprendre les deux intentions.

Préparer l’environnement de recette

Protégez la préproduction avec un contrôle d’accès. Au moment de publier, vérifiez depuis l’extérieur les en-têtes, les directives robots, la balise canonique et le sitemap public. Contrôlez le HTML reçu et le DOM rendu pour les gabarits qui dépendent du JavaScript. Une URL peut répondre 200 et perdre son texte principal ou ses liens.

Préparez une recette pour les caches. Une demande sur le CDN, une réponse directe de l’origine et un rechargement sur mobile doivent servir la version attendue. Documentez la purge ou la clé de cache à changer si une couche sert encore l’ancien gabarit.

Définir qui décide et quand ouvrir

Pour chaque lot, nommez la personne qui valide le mapping, celle qui déploie et celle qui peut suspendre l’ouverture. Une erreur reproductible sur une page de devis, une boucle de redirection ou une famille de nouvelles pages en noindex justifie de bloquer le lot concerné. Définissez ces critères avec les équipes qui devront agir.

Figez une version restaurable de chaque composant. Une règle de redirection peut être rétablie seule. Un retour complet exige aussi de savoir ce que deviennent les commandes, demandes et contenus écrits depuis la bascule. Le plan de retour arrière d’une migration détaille les critères de décision et de restauration.

Reconnaître les défauts qui se cachent dans une moyenne

Un crawl global peut réussir alors que les pages d’une langue pointent vers la mauvaise version. Un dashboard peut rester stable alors qu’une variante mobile ne crée plus de dossier CRM. Les seuils s’appliquent aux groupes qui partagent le même gabarit ou la même règle, puis aux parcours critiques pris individuellement.

Séparez les contrôles instantanés des observations différées. Une boucle ou un 5xx est visible dès la bascule. Une variation de clics peut demander plusieurs jours consolidés et une comparaison avec des pages témoins. Consignez le premier fait observé et l’action qu’il justifie.

Vérifier la publication depuis l’extérieur

Rejouez les anciennes URL et notez la chaîne jusqu’à la cible finale. Ouvrez le sitemap actif et vérifiez son contenu, pas seulement sa réponse HTTP. Comparez la balise canonique, le contenu et les liens de la cible au résultat prévu. Envoyez des demandes de test identifiées comme telles sur les gabarits critiques, puis vérifiez leur réception.

À l’ouverture, comparez la sonde aux logs de l’origine pour repérer une divergence entre cache et serveur. Lorsqu’une règle partagée échoue, élargissez l’échantillon à toute la famille avant de déployer le lot suivant. Le contrôle des routes et des logs après migration indique quoi lire dans les premières heures.

Suivre la reprise par famille de pages

Ce que l’équipe doit pouvoir décider

Pour chaque famille, indiquez les URL encore bloquées, leur rôle, le résultat attendu, le responsable et le prochain contrôle. Montrez séparément les défauts déjà reproduits et les observations Search Console qui attendent leur consolidation.

Relier visibilité et résultat métier

Suivez les pages d’entrée et les demandes réellement reçues. Si les clics restent stables alors que les dossiers diminuent, vérifiez la réception serveur et les états CRM sur le même périmètre. Le diagnostic des demandes en baisse après une refonte détaille cette enquête.

Choisir le correctif le plus ciblé

Si la cause est une règle de routage isolée, corrigez ou rétablissez cette règle et rejouez la recette. Si le défaut touche plusieurs composants, suspendez l’extension et vérifiez les dépendances et les écritures récentes avant de décider du périmètre à restaurer.

Tenir un registre des exceptions

Documentez les anciennes URL qui doivent continuer à recevoir des visiteurs ou des liens, les destinations provisoires et les variantes retirées. Gardez la raison, la décision de recette et le moment prévu pour lever chaque exception.

Organiser les premières heures

À J0, testez les parcours bloquants depuis deux accès utiles. Dans les jours suivants, cherchez les redirections mal couvertes, les erreurs d’origine et les écarts entre le sitemap et les URL réellement servies. Ajustez la fréquence au trafic et au risque de chaque famille.

Archiver les décisions avec leurs preuves

Conservez le mapping versionné, les résultats de tests, le moment de la bascule et les écarts résolus. Dans le suivi Dawap, une activité rattache la modification à la page et aux requêtes à observer. Les relevés J+30 donnent une chronologie exploitable lorsque les données arrivent.

Comparer des périodes comparables

Examinez la marque et les requêtes génériques séparément. Si un groupe migré et son témoin baissent ensemble, examinez la demande et les autres changements avant d’attribuer tout l’écart à la refonte. Le guide pour mesurer l’effet d’une migration SEO détaille la comparaison par cohorte.

Fixer les conditions de sortie

Pour clore le contrôle technique, rejouez les défauts corrigés depuis l’ancienne URL et vérifiez leur absence sur les parcours témoins. Les écarts acceptés gardent une échéance. La reprise organique continue à être observée sur les périodes consolidées disponibles.

Préparer le dernier contrôle avant la bascule

Faites confirmer la version réellement servie, l’état des caches et le résultat du formulaire par une personne qui n’a pas publié le lot. Cette lecture indépendante protège contre la vérification involontaire de la préproduction ou d’une session déjà authentifiée.

Approfondir les quatre décisions de migration

• Préparer un rollback SEO pour restaurer une configuration et vérifier les écritures intervenues depuis la bascule.
• Contrôler une migration en production pour isoler la couche en défaut à partir des réponses, du rendu et des logs.
• Mesurer l’effet de la migration pour comparer les cohortes et séparer un défaut technique d’un changement de demande.
• Retrouver les demandes après la refonte pour suivre un formulaire du site jusqu’au CRM.

Projets liés à la migration SEO

La refonte du site Dawap

La refonte SEO technique du site Dawap illustre les contrôles à documenter dans un vrai chantier, du rendu des gabarits au sitemap, au maillage et aux vérifications de production.

Conclusion : autoriser la bascule sur des preuves

Une migration se décide à partir de l’URL et du parcours effectivement servis. Une matrice de destinations et quelques témoins métier rendent cette décision vérifiable par l’équipe qui publie et par celle qui exploite le site.

Avant l’ouverture, choisissez ce qui bloque le lot et la version que vous pouvez restaurer. Après l’ouverture, contrôlez les erreurs sur la couche concernée et comparez les résultats organiques sur des données consolidées.

Notre équipe SEO technique peut cadrer ces contrôles et les mettre en œuvre dans vos templates, votre serveur ou votre pipeline de déploiement, puis accompagner les premières corrections après la mise en ligne.