Migration de site web : erreurs à éviter et bonnes pratiques

Une migration de site crée un risque simple : perdre la correspondance entre ce qui existe aujourd’hui et ce qui doit fonctionner demain. Les erreurs les plus coûteuses apparaissent lorsque les URL, les contenus, les fonctions ou les données de mesure sont traités trop tard.

Ce guide couvre les contrôles utiles avant, pendant et après une migration, indépendamment du CMS choisi. Il ne suppose ni changement de design, ni changement de domaine.

Migration de site : les risques à maîtriser

Risque éditorial. Des pages, champs CMS, médias ou relations disparaissent pendant la reprise.

Risque SEO. Les anciennes URL ne rejoignent pas les bonnes destinations, les balises changent sans décision ou le site devient difficile à explorer.

Risque fonctionnel. Formulaires, recherches, filtres, paiements, scripts ou intégrations ne produisent plus le résultat attendu.

Risque de mesure. Le tracking, les consentements ou les événements changent au moment même où il faudrait comparer avant et après.

Risque opérationnel. Les responsabilités, validations et conditions de retour arrière ne sont pas définies.

Avant la migration : construire une référence fiable

Les contrôles préparatoires établissent ce qui doit être conservé, transformé et mesuré. Ils réduisent les décisions improvisées pendant la bascule.

Erreur 1 — Commencer sans inventaire d’URL

Un sitemap seul ne suffit pas toujours. Croisez les URL du CMS, du site public, des outils de mesure et des données de recherche disponibles. Pour chaque URL, notez son statut, son rôle, sa destination cible et la décision prise.

Sans cet inventaire, des pages encore utiles peuvent devenir introuvables ou être redirigées vers une destination trop générale.

Erreur 2 — Copier les contenus sans leur structure

Un contenu ne se résume pas à son texte. Il peut dépendre d’un auteur, d’une catégorie, d’une date, de champs SEO, de relations, de médias ou d’un gabarit. Définissez le modèle cible avant l’import et testez les cas complexes sur un échantillon.

Erreur 3 — Oublier les fonctions invisibles

Inventoriez les formulaires, notifications, moteurs de recherche, filtres, scripts, webhooks, pixels, consentements, téléchargements et processus internes. Une page peut sembler identique tout en ayant perdu une fonction essentielle.

Erreur 4 — Modifier les URL sans raison

Conservez une URL lorsqu’elle reste cohérente avec le contenu et l’architecture cible. Lorsqu’elle doit changer, définissez une destination sémantiquement proche et documentez la redirection avant le lancement.

Erreur 5 — Ne pas conserver de valeurs de départ

Enregistrez les indicateurs utiles avant la migration : pages visibles, requêtes, clics, trafic, conversions, erreurs, performances et fonctionnement des formulaires. Sans référence, il devient difficile de distinguer une anomalie d’une variation normale.

Pendant la migration : contrôler la transformation

La phase de construction doit comparer la source et la cible à chaque lot. Une apparence correcte ne suffit pas si les contenus ou les fonctions ne produisent plus le même résultat.

Erreur 6 — Importer tout le contenu en une seule fois

Commencez par un petit lot représentatif : contenu simple, Rich Text, relations, médias et cas particuliers. Comparez la source et la cible champ par champ avant d’étendre l’import.

Un import techniquement réussi ne prouve pas que les titres, paragraphes, liens, tableaux ou contenus imbriqués sont complets.

Erreur 7 — Reproduire une fonction sans tester son usage réel

Vérifiez le résultat attendu, les états d’erreur et les notifications. Un formulaire doit être soumis et reçu ; une recherche doit retourner les bons contenus ; un filtre doit fonctionner avec des données réelles.

Erreur 8 — Préparer les redirections après la construction

Le mapping des URL doit évoluer avec l’arborescence et les décisions de contenu. Une redirection vers la page d’accueil n’est pas une réponse par défaut : la destination doit reprendre l’intention de l’ancienne page.

Erreur 9 — Mélanger migration et nettoyage sans journal de décision

Une migration peut être l’occasion de fusionner des contenus, mais chaque retrait doit être explicite. Conservez la source, la décision, la destination éventuelle et la personne qui a validé le changement.

Erreur 10 — Tester uniquement l’apparence

La recette doit couvrir le responsive, la navigation au clavier, les liens, les statuts HTTP, les métadonnées, les canonicals, les formulaires, le tracking, les scripts et les redirections. Testez aussi les gabarits CMS avec des contenus courts, longs et incomplets.

Au lancement : éviter une bascule aveugle

Le lancement réunit plusieurs opérations dépendantes. Leur ordre, leurs responsables et les conditions d’arrêt doivent être connus avant la publication.

Erreur 11 — Modifier plusieurs systèmes sans ordre de passage

Documentez les opérations : gel des contenus si nécessaire, sauvegarde, publication, DNS le cas échéant, activation des redirections, contrôles immédiats et communication. Attribuez un responsable à chaque étape.

Erreur 12 — Ne pas prévoir de retour arrière

Définissez les conditions qui imposent un arrêt ou un retour à l’état précédent : site indisponible, formulaires critiques hors service, redirections massivement incorrectes ou contenus essentiels manquants. Vérifiez que les sauvegardes et accès nécessaires sont disponibles.

Après la migration : contrôler avant d’optimiser

Les premiers contrôles recherchent les ruptures factuelles. Les optimisations éditoriales viennent ensuite, lorsque la continuité technique et la mesure sont établies.

Erreur 13 — Considérer la publication comme la fin du projet

Contrôlez immédiatement un échantillon représentatif d’anciennes URL, les pages prioritaires, les formulaires, le tracking et les fichiers importants. Vérifiez ensuite les erreurs d’exploration, l’indexation et les signaux par page.

Erreur 14 — Réécrire trop vite en réaction aux premières variations

Corrigez sans attendre les anomalies techniques démontrées. Pour les variations de visibilité, distinguez le délai de réexploration, le changement de requêtes et une baisse réelle avant de modifier à nouveau les contenus.

Erreur 15 — Arrêter le suivi sans bilan

Comparez les résultats aux valeurs de départ, consignez les incidents et fermez les tâches seulement lorsque les fonctions, les URL et la mesure sont vérifiées. Le bilan sert de référence aux évolutions suivantes.

Checklist robuste avant mise en ligne

☐ L’inventaire des URL possède une décision et une destination pour chaque page concernée.

☐ Les contenus et champs CMS ont été testés sur un échantillon représentatif.

☐ Les anciennes et nouvelles URL sont reliées dans un mapping validé.

☐ Les Titles, metas, canonicals, indexation et liens internes des pages prioritaires sont contrôlés.

☐ Les formulaires, notifications, recherches, filtres et intégrations ont été testés.

☐ Les scripts de mesure et les événements utiles produisent des données vérifiables.

☐ Les contenus longs, Rich Text, médias et relations CMS sont complets.

☐ Les redirections ont été testées sur leurs URL exactes et leurs destinations finales.

☐ Le domaine et les réglages DNS ne changent que si le projet l’exige.

☐ Les responsables du lancement et des contrôles immédiats sont identifiés.

☐ Une sauvegarde et une procédure de retour arrière sont disponibles.

☐ Les valeurs de départ et la fenêtre de suivi après lancement sont documentées.

Migration seule ou refonte avec migration ?

Si le contenu, l’arborescence et les parcours restent adaptés, le projet peut rester une migration. S’ils doivent être transformés, il devient une refonte avec migration. Le guide refonte ou migration de site aide à poser cette décision avant de chiffrer le projet.

Pour organiser le chantier complet, utilisez la méthode de refonte en 10 étapes. Pour le cas spécifique d’un changement de CMS, consultez la méthode pour migrer WordPress vers Webflow.

Conclusion

Une migration maîtrisée repose sur quatre continuités : les contenus, les URL, les fonctions et la mesure. L’inventaire fixe la référence, les tests valident la transformation et le suivi confirme que le site reste exploitable après le lancement.

Si la migration s’inscrit dans une transformation plus large, le service de refonte Webflow permet de cadrer ensemble contenu, plateforme et sécurisation du lancement.