Migration de site sans vous coûter votre SEO

J'ai vu des migrations à cinq chiffres se transformer en désastres SEO à six chiffres parce que l'équipe traitait la migration comme un problème technique au lieu d'un problème de continuité. Le schéma est toujours le même. Construire le nouveau site. Basculer l'interrupteur. Regarder le trafic organique chuter de quarante à soixante-dix pour cent au cours des huit semaines suivantes. Passer le trimestre suivant à essayer de récupérer ce qui a été perdu le jour du basculement.

Le déplacement technique tue rarement. Les cartes de redirection à quatre-vingts pour cent complètes tuent. Les balises canonical pointant vers des domaines de staging tuent. Les liens internes qui pointent encore vers l'ancienne structure tuent. Les changements d'URL faits « pendant qu'on y est » tuent. La construction elle-même est la partie facile ; le travail de continuité est celui où chaque migration que j'ai déployée à grande échelle réussit ou échoue.

Cinq choses, apprises à la dure sur douze mille sites chez Seahawk Media. Chacune est non-négociable sur chaque migration que nous déployons.

D'abord, la carte de redirection est construite avant tout code. Chaque ancienne URL reçoit une redirection 301 vers son nouvel équivalent. On exporte la liste des URL sources de Search Console, Ahrefs et du sitemap existant, puis on construit le mapping dans un tableur qui devient la source de vérité pour le basculement. Le linter de build échoue le déploiement si une URL pré-migration est absente de la carte.

Deuxièmement, la structure des URL est préservée partout où la nouvelle plateforme le permet. Chaque changement d'URL est un risque de classement. On change les URL seulement quand il y a une vraie raison de contenu — un doublon, une faute de frappe, une canonique qu'on consolide — jamais parce que la nouvelle plateforme suggère une convention différente. La tentation de « ranger pendant qu'on y est » a coûté plus de classements que n'importe quelle autre décision dans notre pratique de migration.

Troisièmement, les sites de plus de dix mille pages reçoivent un déploiement par phases. Migrer d'abord le contenu à plus faible trafic, valider que les classements se maintiennent, puis élargir. Une migration par étapes limite le rayon de blast si quelque chose se passe mal sur un template ou type de contenu particulier, et donne à l'équipe une chance de corriger le problème avant que les pages à fort trafic soient affectées.

Quatrièmement, une période de fonctionnement parallèle. L'ancien site reste en ligne en mode lecture seule pendant trente jours après le lancement. Si le nouveau site a un problème, le trafic est redirigé en arrière instantanément. Le coût de faire tourner deux stacks pendant un mois est faible comparé au coût d'un cycle de récupération de trafic de quatre semaines.

Cinquièmement, quatre-vingt-dix jours de monitoring post-lancement. Statistiques de crawl Search Console, couverture d'indexation, impressions, analyse de fichiers journaux, validateur de schéma, données de champ Core Web Vitals. Corriger les régressions en jours, pas en trimestres. Au jour quatre-vingt-dix le site est stable et on transfère proprement ou on passe à un plan de maintenance continu.

Une poignée de formes de migration représente presque tout notre travail de projets. Chacune a son propre playbook et ses propres modes de défaillance habituels.

WordPress vers Next.js ou Astro est l'engagement le plus courant. Le brief est généralement un site marketing ou de contenu qui a atteint le plafond de performance du WordPress classique et une équipe qui veut une DX front-end moderne sans perdre wp-admin pour l'équipe éditoriale. WordPress headless avec WPGraphQL plus un front-end Next.js ou Astro satisfait les deux côtés.

Drupal, Sitecore ou Typo3 vers WordPress est le deuxième schéma. Se déplacer hors d'une CMS d'entreprise héritée sans casser les classements SEO que l'équipe héritée a construits au fil d'une décennie. Migrations plus lentes, modélisation de contenu plus complexe, mais le playbook est le même — carte de redirection complète, URL préservées où possible, fonctionnement parallèle, déploiement par phases.

Shopify vers commerce headless est le troisième. Vitrine Shopify Plus avec un front-end Next.js ou Hydrogen, design entièrement personnalisé, Core Web Vitals plus rapides, moteur de commerce conservé. Shopify reste la source de vérité pour le catalogue, l'inventaire et le checkout ; le front-end devient personnalisé.

Les autres modèles que nous voyons régulièrement sont la consolidation de domaines (plusieurs domaines historiques fusionnés en un seul avec une stratégie canonique et de redirection appropriée), la consolidation sous-domaine vers sous-répertoire (déplacer blog.example.com vers example.com/blog/ pour consolider l'équité des liens), et les migrations d'hébergement et de plateforme (déplacer WordPress géré entre Kinsta, WP Engine, Pressable, ou vers une infrastructure bare-metal).

Les sites de moins de mille pages s'exécutent de quatre à huit semaines de bout en bout, incluant la planification, la cartographie des redirections, la migration du contenu, l'assurance qualité et la surveillance post-lancement. Les sites de dix mille à vingt mille pages s'exécutent de douze à vingt semaines. Les migrations d'entreprise de cinquante mille pages ou plus s'exécutent six à neuf mois minimum, avec des déploiements par étapes et des périodes de fonctionnement en parallèle intégrées à la chronologie.

La plus grande variable est la qualité du contenu à la source. Les taxonomies désordonnées, les URL en double et les métadonnées incohérentes ajoutent des semaines à la phase de planification. Nous vous dirons honnêtement lors de l'audit si votre site source est prêt pour la migration ou s'il a besoin d'une phase de nettoyage du contenu au préalable. Prétendre que la source est propre alors qu'elle ne l'est pas, c'est comment les migrations glissent d'un trimestre à une demi-année.

Des fourchettes honnêtes basées sur des engagements récents réels. Une migration de petite entreprise de moins de cinq cents pages coûte de quatre mille à douze mille livres. Une migration de marché intermédiaire de mille à dix mille pages coûte de quinze mille à soixante mille. Une migration d'entreprise de dix mille à cent mille pages coûte de soixante mille à trois cent mille livres, incluant le support SEO continu post-lancement pour le premier trimestre.

Environ trente à quarante pour cent du coût va à la planification et à l'assurance qualité, pas au développement technique. Les équipes qui vous citent bon marché sont celles qui ignorent la planification. Vous le payez plus tard par des pertes de classement, et le coût de reconstruction des classements est toujours plus élevé que le coût de leur préservation en premier lieu.