Une migration SEO de site web ne se limite pas à changer sa technologie. Passer à un autre CMS, framework frontend, hébergeur ou nom de domaine peut modifier le HTML, les métadonnées, les liens internes, les URL et la manière dont les robots d’exploration accèdent au contenu, même lorsque le design semble inchangé.
Les moteurs de recherche ont besoin de temps pour explorer à nouveau les pages et traiter les changements. Le rôle de l’équipe est de préserver les signaux importants, de tester la nouvelle version en amont et d’éviter que des erreurs techniques transforment une perturbation temporaire en baisse durable de visibilité.
Une migration peut aller d’une modification des URL ou de la structure des liens à un changement de CMS, à l’adoption d’un nouveau framework ou à un transfert d’hébergement. Plusieurs de ces changements peuvent intervenir simultanément.
Un robot d’exploration peut recevoir un résultat différent même si les URL restent identiques. Un nouveau frontend peut modifier l’ordre des éléments HTML, la génération des titres et des URL canoniques, le maillage interne ou le moment où le contenu principal apparaît. Un changement d’hébergement affecte la disponibilité et les temps de réponse. Un nouveau CMS peut ajouter automatiquement une directive « noindex », modifier les slugs ou recréer le sitemap.
Avant de commencer le développement, répertoriez chaque changement et ses conséquences possibles. Si le domaine, le design, le contenu et l’architecture du site évoluent tous en même temps, il sera difficile d’identifier la cause d’une éventuelle baisse de visibilité. Dans la mesure du possible, répartissez les changements majeurs en plusieurs étapes. Sinon, prévoyez des contrôles pour chaque niveau et désignez un responsable.
Définissez également à l’avance les critères de réussite : les URL prioritaires à conserver, l’absence d’erreurs d’indexation critiques, le bon fonctionnement des outils d’analyse, une plage de trafic acceptable et la durée du suivi après la mise en ligne.
Commencez par effectuer un crawl complet du site en production. Vous obtiendrez une photographie de son état actuel : URL, codes de réponse, titres, descriptions, balises de titre, URL canoniques, directives robots, liens internes et profondeur des pages.
Le crawl constitue la base de l’inventaire des URL, mais il ne couvre pas tout. Certaines pages peuvent ne recevoir aucun lien interne tout en générant du trafic organique ou en bénéficiant de backlinks. Complétez la liste avec les données du sitemap XML, du CMS, des outils d’analyse, de Search Console, des outils de backlinks et des journaux serveur. Recensez séparément les PDF, les images liées depuis des sites externes, les landing pages de campagnes, les flux et les pages avec paramètres d’URL.
L’état de référence doit inclure le trafic organique, les impressions, les clics, les conversions, les pages indexables, les erreurs d’exploration et les Core Web Vitals. Comparez les différentes sections et les différents templates, et pas uniquement les statistiques globales. Une perte de visibilité dans une catégorie peut facilement passer inaperçue si les indicateurs de la page d’accueil restent stables.
Identifiez ensuite les URL prioritaires : les pages qui génèrent du trafic, des prospects, des backlinks ou une forte valeur commerciale. Elles méritent des contrôles qualité renforcés et une vérification manuelle immédiatement après la bascule.
Avant toute intervention, sauvegardez le contenu, les médias, les configurations et les règles de redirection existantes. Les anciennes redirections sont particulièrement faciles à perdre lors d’un changement de plateforme, alors que des sites externes et des favoris continuent d’utiliser les anciennes adresses.
Définissez une action pour chaque URL : conserver, mettre à jour, fusionner, rediriger ou supprimer. Appuyez-vous sur les données et sur l’utilité de la page. Migrer tout le contenu accumulé, même inutile, n’a guère de sens, mais supprimer une page uniquement parce qu’elle semble ancienne comporte aussi des risques.
Conservez une URL fonctionnelle lorsqu’aucune raison sérieuse ne justifie de la modifier. Un slug plus court compense rarement le risque supplémentaire. Si l’adresse change, l’ancienne URL doit rediriger vers le contenu le plus pertinent sur le nouveau site.
Consignez chaque correspondance dans une table de redirection. Pour chaque ligne, indiquez l’ancienne et la nouvelle adresse, le type de page, la décision prise, la priorité, le statut de validation et le responsable. Cette table devient une référence commune pour le spécialiste SEO, les développeurs et l’équipe éditoriale.
Utilisez des redirections côté serveur avec un code 301 ou 308 pour les déplacements permanents. Elles doivent pointer directement vers l’URL finale. Une chaîne de plusieurs redirections ralentit les requêtes et complique le diagnostic. Éliminez les boucles de redirection avant la mise en ligne.
Ne redirigez pas systématiquement toutes les pages supprimées vers la page d’accueil. Si aucun contenu équivalent n’existe, un véritable code 404 ou 410 décrit mieux la situation. Intégrez les anciennes règles de redirection à la nouvelle table et testez-les avec les autres.
Une page peut conserver son adresse tout en perdant de sa valeur à cause d’une modification discrète de son template. Comparez les versions ancienne et nouvelle : titre SEO, description, titres H1 à H6, contenu principal, textes alternatifs, URL canonique et directives robots. Vérifiez les données structurées et assurez-vous qu’elles correspondent au contenu visible.
Examinez les métadonnées en même temps que l’architecture interne. La navigation, le fil d’Ariane, les contenus associés et les liens contextuels aident les robots à comprendre la structure du site. Si une page prioritaire se retrouve plus profondément dans l’arborescence ou perd des liens internes entrants, son URL peut rester inchangée alors que son rôle dans le site a évolué.
Lors d’une migration vers une stack JavaScript, vérifiez séparément le HTML rendu. Pour les projets nécessitant une refonte plus large ou un changement de plateforme, nos services de développement web couvrent l’implémentation technique, l’architecture CMS, les intégrations et les aspects de performance à préserver pendant la migration. Le contenu principal, les titres, les liens et les métadonnées importantes doivent être accessibles après le rendu. Un lien classique doit posséder un véritable attribut « href » pour qu’un robot puisse découvrir l’URL suivante. Une route côté client accessible uniquement par un gestionnaire de clics crée un risque inutile.
Mettez également à jour le sitemap, les balises hreflang, les données Open Graph et les liens vers les médias. Chaque nouvelle page doit disposer d’une URL canonique correcte pointant vers elle-même. Le site en production ne doit conserver ni blocage dans « robots.txt », ni URL canonique de préproduction, ni directive « noindex » utilisée pendant le développement.
Protégez l’environnement de préproduction contre une indexation accidentelle, tout en le laissant accessible à l’équipe et aux outils de contrôle qualité. Choisissez une méthode de protection qui pourra être retirée en une seule opération maîtrisée avant le lancement.
Le contrôle principal consiste à comparer deux crawls : celui du site en production et celui de la préproduction. Recherchez les différences de codes de réponse, de métadonnées, de titres, d’URL canoniques, de directives robots, de liens internes et de profondeur d’exploration. Toutes les différences ne sont pas des erreurs, mais l’équipe doit pouvoir expliquer chacune d’elles.
Testez la table de redirection dans le futur environnement ou à l’aide des règles serveur préparées. Pour chaque ancienne URL, vérifiez le code de réponse final, la destination et l’absence de boucles ou de chaînes de redirections. Une liste importante d’URL ne peut pas être contrôlée manuellement : automatisez les tests et vérifiez séparément les pages prioritaires.
Les tests de préproduction doivent couvrir les formulaires, la recherche, les outils d’analyse, le consentement, la localisation et les intégrations externes. Vérifiez aussi les performances et l’accessibilité. Si l’équipe modifie un template essentiel après ces contrôles, relancez les tests et le crawl concernés.
Définissez les critères de retour arrière avant le lancement. Des erreurs 5xx généralisées, des templates principaux indisponibles ou une perte des données d’analyse peuvent justifier le rétablissement de l’ancienne version. La décision de revenir en arrière doit appartenir à un responsable désigné, et non à une personne choisie au hasard dans une conversation d’équipe.
Juste avant le lancement, synchronisez les dernières modifications de contenu et effectuez un dernier crawl de l’ancien site. Basculez ensuite le déploiement ou les DNS, activez les redirections et supprimez les blocages temporaires sur la nouvelle version.
Lancez immédiatement les premières vérifications. Ouvrez la page d’accueil et les principaux templates, puis contrôlez « robots.txt », le sitemap, les URL canoniques, les formulaires et les outils d’analyse. Testez ensuite la liste complète des anciennes URL et examinez leurs réponses finales. Parallèlement, les journaux serveur peuvent révéler des erreurs 5xx, une hausse inhabituelle des erreurs 404 ou des problèmes de chargement des ressources.
Une migration peut temporairement augmenter l’activité des robots d’exploration : les moteurs de recherche demandent les nouvelles URL tout en suivant les redirections depuis les anciennes. Assurez-vous que la capacité d’hébergement, le cache et les services essentiels peuvent absorber cette charge supplémentaire sans ralentir les pages prioritaires ni renvoyer d’erreurs 5xx.
En cas de changement de domaine, vérifiez les deux versions dans Search Console, y compris les variantes et sous-domaines concernés. Après la bascule, soumettez le nouveau sitemap et effectuez la procédure de changement d’adresse. Cette étape est inutile si seul le CMS change et que le domaine reste identique.
Planifiez le lancement à une période où le trafic commercial est généralement faible. Évitez les créneaux où les développeurs, le spécialiste SEO ou le responsable des décisions ne sont pas disponibles. Pouvoir corriger rapidement un problème est plus important que choisir une date simplement pratique sur le papier.
Dans les premières heures, surveillez la disponibilité, les réponses 5xx et 404, le trafic en temps réel, les conversions et les outils d’analyse. Au cours des premiers jours, vérifiez l’exploration des URL prioritaires et le fonctionnement des principaux templates. Dans les semaines suivantes, comparez les impressions, les clics, les pages indexées et le trafic des pages de destination aux valeurs de référence.
Analysez les variations importantes par section et par type de page. Elles peuvent provenir d’une directive « noindex » oubliée, d’une URL canonique incorrecte, d’un contenu manquant, d’un changement de maillage interne, d’une erreur de rendu ou d’une table de redirection incomplète. La courbe globale des positions ne montre que le symptôme.
Checklist SEO pour la migration d’un site web :
Conservez les redirections permanentes pendant au moins un an, et plus longtemps si possible. La mise en ligne marque le début de la phase de suivi. Le travail est terminé lorsque les moteurs de recherche ont traité les nouvelles adresses, que les indicateurs se sont stabilisés et que l’équipe a résolu les écarts constatés pendant le suivi.
