La migration de sites Web est une étape sérieuse pour toute entreprise. C’est pourquoi, avant de faire d’autres recommandations, je m’assure toujours qu’elles sont justifiées. Et si c’est le cas, l’étape suivante consiste à rendre le processus de migration optimisé pour le référencement.
Il existe de nombreux types de migrations, notamment:
- Passer de HTTP à HTTPS
- Passer d’un sous-domaine à un sous-dossier ou vice versa
- Passer d’un domaine à un autre
- Passer d’un système de gestion de contenu à un autre système
Voici une liste de contrôle SEMrush publiée précédemment pour donner une vue d’ensemble de tous les différents types de migrations.
Dans cet article, je me concentrerai sur un type de migration particulier, la commutation de systèmes de gestion de contenu – car ce type spécifique a ses propres défis. Je vais vous montrer ce que vous devez savoir avant de passer à un autre CMS, quels problèmes vous rencontrerez et les étapes exactes pour surmonter ces problèmes.
Pourquoi vous pourriez vouloir migrer vers un autre CMS
Il n’y a pas beaucoup de raisons, pour être honnête. Tous les clients avec qui j’ai travaillé n’en avaient qu’un – ils voulaient tenir compte de la croissance de l’entreprise. Et c’est une raison valable.
Par exemple, une entreprise ouvre une boutique en ligne. Ils ne savent pas comment les choses vont se passer et à quoi ressemblera l’entreprise cinq ans plus tard.
Au début, ils n’ont pas besoin de fonctionnalités CMS sophistiquées comme la gestion des stocks en vrac, les options d’expédition dans le monde entier, etc. Mais à mesure que le magasin se développe, les limites du système de gestion de contenu initial pourraient devenir plus évidentes et, à un moment donné, cela pourrait rendre sens de tout déplacer de l’ancien CMS vers un nouveau CMS.
Cela nécessite beaucoup de travail à l’avance, mais permet également de réaliser d’énormes économies de temps et d’argent à long terme, à condition que la partie SEO soit effectuée correctement. Et c’est exactement ce que je couvrirai ici.
L’idée d’une migration CMS
Je suis une personne visuelle, j’ai donc imaginé cette image pour illustrer l’idée de migration CMS:
C’est un arc-en-ciel entre 2 points: l’ancien CMS et le CMS cible. Les couleurs arc-en-ciel comblent l’écart entre les 2 systèmes. Chaque couleur est une étape particulière que vous devez effectuer pour passer de l’ancien CMS au CMS cible sans aucune perte.
Je couvrirai chacune de ces étapes en détail ci-dessous.
Les principaux problèmes que vous pourriez rencontrer lors d’une migration CMS
Il est évident que l’ancien CMS et les nouvelles fonctionnalités du CMS ne correspondent pas en tant que blocs Lego. Voici quelques problèmes que vous pourriez découvrir lors du changement de votre CMS:
Incapacité à conserver l’ancienne structure des URL
- Exemple: dans Magento 2, le chemin de catégorie est inclus dans l’URL du produit par défaut. Donc, si les URL de vos produits actuels n’incluent pas le chemin de catégorie, vous devrez utiliser une personnalisation ou une extension pour y parvenir.
Différents modèles ou règles pour générer des balises META et des balises H1
- Exemple: HubSpot ne permet pas d’avoir différentes balises H1 et de titre sur une page (même si elles semblent être en train de la changer).
Approche différente des fichiers de service (robots.txt, plan du site XML)
- Exemple: Shopify n’autorise pas la modification du plan du site robots.txt et XML. Donc, si vous y migrez, vous devez en tenir compte.
Données structurées
Conseil de pro: Les codes de suivi sont souvent ignorés. Avant le début de la migration, vous devez dresser une liste de tous les codes de suivi et personnalisations pour les transférer vers le nouveau CMS.
Combler l’écart: RAINBOW étapes pour rendre une migration CMS aussi transparente que possible
Voici un résumé de toutes les étapes. Comme je l’ai mentionné ci-dessus, chacun d’eux doit être complété pour passer correctement de l’ancien CMS au CMS cible:
R. Lancer une exploration
Avant même de commencer à planifier la migration, vous devez comprendre la portée – existe-t-il 100, 1 000 ou 10 000 URL? Vous souhaitez également rechercher les problèmes techniques qui ne doivent pas être transférés vers le nouveau CMS. Par exemple, vous pouvez trouver des pages avec des canoniques auto-référencés, alors que ces canoniques devraient plutôt pointer vers d’autres URL.
Après l’exploration, vous aurez une liste des pages du site Web. Je recommande toujours d’utiliser quelques sources pour obtenir une liste complète, notamment:
Par exemple, vous pouvez exporter des pages analysées à partir de SEMrush Site Audit:
Exportez toutes les URL de chaque outil, combinez-les en un seul document et supprimez les doublons. Vous aurez besoin de ces URL pour les analyser et prendre des décisions stratégiques (voir l’étape «I» ci-dessous).
De plus, avant d’apporter des modifications au site Web actuel, vous devez créer une sauvegarde (ou vous assurer qu’elle est effectuée du côté des développeurs). Bien sûr, après la migration du CMS, la structure des dossiers sur le serveur sera différente. Mais vous aurez au moins des données brutes et du contenu sur lesquels vous pourrez revenir en cas de problème ou de suppression.
Le résultat de l’étape R:
-
Vous disposez d’une liste complète de toutes les URL de sites Web.
-
Vous disposez d’une liste des problèmes techniques de référencement que vous souhaitez résoudre lors de la migration vers un autre CMS.
-
Une sauvegarde du site Web actuel.
A. Analyser les fonctionnalités du CMS
Il est maintenant temps de voir comment les fonctionnalités de votre CMS actuel sont traduites en fonctionnalités du Nouveau CMS.
Faites une liste des éléments à prendre en compte lors de la migration. Ce seront des aspects SEO absolument importants que vous souhaitez contrôler autant que possible. Ils incluent:
-
Structure d’URL – Vous souhaitez laisser la même structure si cela est possible. Sinon, vous devez le savoir à ce stade avant de créer la carte de redirection.
-
Méta-information – Vous souhaitez laisser les mêmes balises ou imiter les modèles de balises META. Si ce n’est pas possible, créez de nouveaux modèles qui seront pris en charge par le CMS vers lequel vous migrez.
-
Architecture de site Web – Assurez-vous que rien ne sera perdu pendant le processus de migration, par exemple, le fil d’Ariane restera, la navigation principale aura les mêmes catégories, etc.
-
Directives sur les étiquettes canoniques et les méta-robots – Le nouveau CMS devrait donner une option pour modifier ces paramètres au niveau de la page.
-
Plan du site Robots.txt et XML.
-
Données structurées.
-
Hreflang (pour les sites Web internationaux).
-
Toutes les fonctionnalités personnalisées importantes – Règles automatiques pour créer de nouvelles pages, rediriger les anciennes pages, etc. Par exemple, si vous migrez une boutique en ligne et que l’ancien CMS a une fonctionnalité pour rediriger automatiquement un produit abandonné vers la page de catégorie, votre plan de migration doit l’inclure comme bien.
Cette étape est difficile et nécessite beaucoup de recherche et de communication entre les équipes, mais elle est l’épine dorsale de l’ensemble du processus de migration.
Le résultat de l’étape A:
-
Une liste des fonctionnalités SEO les plus importantes et idéalement une indication si chaque fonctionnalité est disponible dans le nouveau CMS. Plus vous en savez, à ce stade, mieux c’est.
Remarque: Si le CMS vers lequel vous migrez est construit sur mesure, vous n’aurez probablement aucune information sur les fonctionnalités disponibles. Vous avez toujours besoin d’une liste des fonctionnalités qui sont absolument nécessaires pour le référencement afin qu’elles puissent être créées ou ajoutées au système personnalisé.
I. Indiquez les URL à rediriger
À cette étape, vous avez déjà une liste de toutes les pages du site Web et savez si des changements dans la structure de l’URL seront nécessaires. Alors maintenant, il est temps de créer une carte URL.
Gardez la carte simple. J’inclus généralement 3 colonnes: ancienne URL, action et URL finale:
Créez ensuite une carte supplémentaire qui n’aura que les URL à rediriger. Cette carte de redirection est destinée aux développeurs.
La raison pour laquelle je préfère avoir 2 cartes est simple: je veux m’assurer que chaque URL est gérée correctement. Si vous créez uniquement la carte de redirection, vous risquez de manquer que les autres URL renvoient 404. Je garde donc la carte avec toutes les pages pour moi et envoie la carte de redirection aux développeurs.
Le résultat de l’étape I:
N. Notez les histoires d’utilisateurs et les critères d’acceptation
Lorsqu’il s’agit de choses techniques compliquées comme le changement d’un système de gestion de contenu, il est important de communiquer correctement vos exigences et recommandations (et même de trop communiquer).
C’est là qu’interviennent les user stories. Une user story indique le résultat que vous souhaitez atteindre. Il suit cette structure:
En tant que {type d’utilisateur}, je veux {résultat} pour que {la raison}
Par exemple:
En tant que SEO, je veux que les URL des produits soient les mêmes, même si les utilisateurs accèdent à la page du produit à partir de différentes catégories afin que nous n’ayons pas de pages de produit en double.
Chaque user story doit avoir des critères d’acceptation. Ils clarifient le résultat que vous souhaitez atteindre. Voici un exemple de critères d’acceptation pour la user story ci-dessus:
-
Les pages produits se trouvent dans le sous-dossier / products /.
-
Les pages produits ne se trouvent pas dans les sous-dossiers / categories /.
-
Les pages produits contiennent des balises canoniques qui pointent vers elles-mêmes.
-
Le lien vers les produits qui font partie de plusieurs catégories est la même URL, quelle que soit la catégorie dans laquelle il se trouve.
-
Les liens internes pointent vers les versions canoniques des URL des produits.
Le résultat de l’étape N:
Vous avez des user stories et des critères d’acceptation pour chaque user story prêts à être téléchargés dans le système de gestion des tâches (par exemple, JIRA).
B. Devenez enquêteur
Une fois que vous avez l’environnement de préparation (ou site de test, ou UAT – il y a beaucoup de noms pour cela) prêt, il est temps de mettre votre chapeau d’enquêteur (chaque SEO l’a!) Et de tester si tout fonctionne correctement et répond à vos critères d’acceptation .
Il s’agit d’une étape très importante et vous devez résoudre tous les problèmes de référencement avant que le site Web ne soit mis en ligne sur le nouveau CMS.
Le résultat de l’étape B:
Il y aura très probablement quelques séries de tests car après la résolution de chaque problème; vous devrez le tester à nouveau. Une fois terminé, le site Web de test devrait être prêt à être mis en ligne.
O. Une fois terminé
Après la mise en ligne du site Web, il est temps de faire des vérifications finales mais cruciales.
Vous pouvez le faire en utilisant le mode liste dans Screaming Frog:
La source: Comment auditer les redirections
-
Vérifiez votre fichier robots.txt pour vous assurer que le site Web est autorisé à explorer.
-
Vérifiez les méta robots pour vous assurer que l’indexation est autorisée.
-
Vérifiez si les codes de suivi sont installés.
-
Faites une annotation dans Google Analytics pour marquer la date de migration afin que vous ayez une meilleure façon d’analyser le trafic post-migration:
Ajoutez également une note à vos rapports SEMrush:
Voici quelques vérifications plus immédiates que vous voulez faire après la migration du CMS.
Cette étape est importante car elle vous aide à détecter rapidement tous les problèmes de référencement et à les résoudre avant qu’ils ne provoquent une baisse de visibilité ou de trafic.
Le résultat de l’étape O:
Vous êtes sûr que toutes les informations ont été transférées correctement, et le site Web du nouveau CMS est «SEO sain».
W. Quand c’est fini, ce n’est pas fini
Toute migration de site Web n’est pas une chose « définissez et oubliez ». Même si tout semble parfait, vous devez toujours surveiller de près le trafic après la migration.
Une chose à noter ici: vous pourriez voir une diminution temporaire du trafic même si tout a été fait correctement. La raison en est que Google a besoin de temps pour réévaluer votre nouveau site, et plus il y a de changements structurels, plus cela peut prendre.
Mais néanmoins, il ne devrait pas y avoir de baisses énormes si toutes les étapes RAINBOW sont correctement gérées.
Le résultat de l’étape W:
- Tranquillité d’esprit.
- Des correctifs post-migration sont effectués si des problèmes sont découverts.
Dernières pensées
Une migration CMS est une tâche complexe où toutes les équipes doivent travailler en synchronisation. En tant que SEO, votre rôle est de diriger le processus en termes de présence organique sur le site Web, d’éduquer les autres équipes sur le SEO en cours de route et de mettre en place tous les contrôles.