Migration de site : les étapes essentielles et les erreurs à éviter

Une migration de site ne se résume jamais à déplacer des fichiers vers un autre serveur. Selon le projet, elle peut toucher les URLs, le CMS, les données clients, le tunnel de conversion, les outils de mesure, les performances ou encore la manière dont Google explore et indexe les pages.

C’est précisément pour cette raison qu’une migration peut très bien sembler réussie le jour de la mise en ligne, puis révéler ses problèmes quelques jours plus tard : formulaires qui n’arrivent plus dans le CRM, erreurs 404 sur d’anciennes pages rentables, baisse de visibilité sur une catégorie stratégique, suivi GA4 incomplet ou produits qui ne remontent plus correctement dans un flux.

L’enjeu n’est pas de garantir qu’aucune fluctuation ne surviendra. L’objectif est plutôt de préserver ce qui fonctionne, de limiter le nombre de variables modifiées le jour J et de disposer de contrôles assez précis pour détecter rapidement une anomalie.

Avant toute chose : quel type de migration préparez-vous ?

Le terme « migration de site » recouvre des réalités très différentes. Or le niveau de risque, les actions SEO à prévoir et les tests à mener ne sont pas les mêmes selon le projet.

Projet	Ce qui change réellement	Risque dominant	Ce qu’il faut sécuriser en priorité
Changement d’hébergement	Serveur, IP, configuration technique	Coupure, SSL, DNS, lenteur, erreurs serveur	Sauvegarde, DNS, cache, disponibilité, performances
Passage HTTP vers HTTPS	Protocole des URLs	Versions concurrentes, contenu mixte, indexation	Redirections, canonical, ressources HTTPS
Changement de CMS	Back-office, thèmes, plugins, base, gabarits	Perte de données, fonctions ou contenus	Import, recette, tracking, SEO, parcours métier
Refonte graphique	Design, UX, navigation, templates	Contenu retiré, maillage cassé, conversion en baisse	Parité des pages, mobile, performance, parcours utilisateurs
Changement de domaine	Domaine ou sous-domaine	Perte de signaux, backlinks cassés, visibilité	Mapping, redirections 301, suivi Search Console
Refonte avec nouvelles URLs	Arborescence, catégories, slugs	404, redirections incohérentes, désindexation	Inventaire complet et mapping URL par URL
Fusion de sites	Plusieurs domaines ou sections	Cannibalisation, suppressions abusives, duplication	Arbitrage sémantique, consolidation, redirections pertinentes
Migration e-commerce	Produits, comptes, commandes, paiement, stock	Perte de CA, erreurs catalogue, checkout défaillant	Synchronisation des données et recette métier
Site international	Pays, langues, répertoires ou sous-domaines	Hreflang cassé, mauvaise version servie	Hreflang, canonical, sélecteur de marché, URLs

Cette distinction a une conséquence pratique : il ne faut pas appliquer une checklist identique à tous les projets. Un changement d’hébergeur sans modification d’URL n’exige pas le même travail qu’une migration de domaine avec changement de CMS et fusion d’un catalogue e-commerce.

Le Change of Address : utile, mais seulement dans certains cas

L’outil Change of Address de Google Search Console concerne les changements de domaine ou de sous-domaine. Il ne sert pas pour un passage HTTP vers HTTPS, un basculement entre www et non-www, un changement de CMS ou une restructuration d’URLs au sein du même domaine.

Dans ces derniers cas, il faut toujours travailler les redirections, les balises canonical, les sitemaps et l’indexation, mais le Change of Address n’est pas l’action appropriée.

Avant migration : réduire les risques avant de les tester

Une erreur fréquente consiste à démarrer par les redirections. Elles sont importantes, mais elles n’arrivent qu’après une étape plus fondamentale : définir ce qui change, ce qui ne doit pas changer et ce qui sera considéré comme un succès.

Évitez de tout modifier en même temps

Une migration devient difficile à diagnostiquer lorsque l’on change simultanément de domaine, de CMS, de navigation, de structure d’URL, de contenus, d’outils de tracking, de CDN et de charte graphique.

Dans la pratique, les pertes de visibilité ne proviennent pas toujours d’une seule redirection absente. Elles viennent souvent d’une accumulation de détails : un bloc de texte SEO retiré pendant la refonte, une canonical pointant vers la préproduction, un maillage interne qui renvoie encore vers les anciennes URLs, une règle de cache trop agressive ou un événement de conversion qui n’est plus transmis à GA4.

Si vous le pouvez, gardez stables les éléments suivants pendant la bascule :

• Les contenus qui génèrent du trafic, des leads ou des ventes.
• Les titles, H1 et intentions de recherche des pages prioritaires.
• Les URLs qui n’ont aucune raison claire de changer.
• Les règles de navigation et de maillage les plus importantes.
• Le plan de tracking et les noms d’événements existants.
• Les mécanismes critiques de panier, paiement, livraison, compte client ou formulaires.

Les évolutions plus ambitieuses — réécriture éditoriale massive, nouvelle taxonomie, changement de ton de marque, ajout de fonctionnalités secondaires — peuvent souvent attendre la phase de stabilisation.

Nommer les responsables et verrouiller les accès

Une migration ne devrait jamais reposer sur une seule personne, ni sur un prestataire impossible à joindre au moment critique. Avant le lancement, listez les personnes capables d’intervenir et les accès réellement disponibles.

Le chef de projet pilote les arbitrages. Le développeur ou responsable technique gère le déploiement, les serveurs, le DNS, le cache, la sécurité et le retour arrière. Le SEO valide l’inventaire, le mapping, les redirections, l’indexabilité et le suivi post-lancement. Les responsables data et e-commerce, eux, doivent pouvoir confirmer que les conversions, les paiements, les commandes, le stock et les données remontent correctement.

Cela peut sembler administratif. Pourtant, le jour J, savoir qui peut modifier une zone DNS, purger un CDN, réactiver une ancienne version ou vérifier un webhooks de paiement fait souvent la différence entre un incident de dix minutes et une panne qui s’étire.

Sauvegarder, puis tester la restauration

Une sauvegarde non testée est une précaution incomplète. Elle peut être corrompue, trop ancienne, impossible à restaurer rapidement ou incapable de remettre en place certains réglages critiques.

Conservez au minimum :

• Les fichiers et la base de données.
• Les réglages serveur et variables d’environnement.
• Les règles de redirection.
• La configuration du CDN, du cache et du WAF.
• La zone DNS et les certificats SSL.
• Les médias, fichiers téléchargeables et PDF.
• Les données clients, produits, commandes, stocks et avis si le site est marchand.
• Les réglages des extensions, services tiers et clés API nécessaires au fonctionnement.

Le point à tester n’est pas seulement « peut-on récupérer un export SQL ? ». Il faut vérifier qu’une restauration redonne bien un site accessible, ses médias, ses comptes, ses réglages techniques et ses fonctions métiers.

À mon sens, c’est l’étape la plus sous-estimée du projet. Beaucoup d’équipes ont une sauvegarde ; peu ont vérifié qu’elles peuvent réellement revenir à un état fonctionnel dans un délai acceptable.

Faire l’inventaire des URLs avec plusieurs sources

Un crawl est indispensable, mais il ne suffit pas. Il ne trouve pas toujours les pages orphelines, les anciennes landing pages encore utilisées en publicité, les PDF indexés, les URLs qui reçoivent des backlinks ou les pages retirées du menu mais toujours actives.

Construisez donc votre inventaire à partir de plusieurs sources :

• Un crawl de l’ancien site.
• Le sitemap XML existant.
• Google Search Console : clics, impressions, pages indexées et pages exclues.
• GA4, Matomo ou un autre outil analytics : landing pages, conversions et revenus.
• Les logs serveur, particulièrement utiles pour voir les URLs réellement demandées.
• Un export du CMS ou de la base de données.
• Les outils de backlinks : Ahrefs, Semrush, Majestic ou équivalent.
• Les anciennes règles de redirection.
• Les flux produits, campagnes, newsletters, liens partenaires et catalogues publicitaires.
• Les sous-domaines, documents PDF, pages de téléchargement et versions linguistiques.

Pour chaque URL importante, ajoutez si possible le type de page, le trafic organique, les conversions, le chiffre d’affaires, les backlinks et la décision attendue après migration. Ce n’est pas nécessairement le plus élégant des fichiers ; c’est l’un des livrables les plus rentables d’une migration.

Construire le plan SEO, technique et data

Mapper les URLs selon l’intention, pas seulement selon leur forme

Le mapping ne consiste pas à remplacer mécaniquement une ancienne URL par une nouvelle. Il faut déterminer ce que l’utilisateur cherchait, ce que la page apportait et quelle destination répond le mieux à ce besoin après migration.

Situation	Décision généralement adaptée
Une page a un équivalent direct	Redirection 301 vers la nouvelle page équivalente
Plusieurs anciennes pages deviennent un guide complet	Redirection 301 vers la page de consolidation, si elle répond bien à l’intention
Un produit est remplacé	Redirection 301 vers le produit successeur
Un produit est arrêté sans successeur	Page informative, catégorie pertinente ou 410 selon le contexte
Une page est définitivement supprimée sans valeur résiduelle	410 ou 404 assumée après validation
Une URL reçoit des backlinks mais son contenu disparaît	Créer ou conserver une destination éditoriale pertinente
Une URL est sans trafic, lien ou équivalent	Ne pas forcer une redirection artificielle

Le réflexe de tout rediriger vers la page d’accueil est compréhensible : il évite de voir des 404 dans un rapport. Mais une redirection ne devient pas utile parce qu’elle existe. Si elle envoie l’utilisateur vers une page sans rapport, elle ne répond pas à son besoin et peut être interprétée comme une destination peu pertinente.

Les redirections doivent être mises en œuvre côté serveur autant que possible. Évitez les redirections JavaScript ou meta refresh pour une migration structurante, et éliminez les chaînes inutiles : une ancienne URL doit idéalement atteindre la nouvelle page finale en un seul saut.

Contrôler les fondamentaux SEO

Sur l’environnement de préproduction, vérifiez que :

• Les pages importantes répondent en 200.
• Les anciennes URLs prévues dans le mapping redirigent vers leur destination finale.
• Les pages qui doivent être indexées ne portent pas de noindex.
• Le fichier robots.txt n’empêche pas le crawl du futur site.
• Les canonical pointent vers les URLs finales de production.
• Les sitemaps XML contiennent uniquement des URLs canoniques, indexables et répondant en 200.
• Les liens internes utilisent directement les nouvelles URLs.
• Les breadcrumbs, menus, filtres et blocs de contenus liés n’envoient pas vers d’anciennes adresses.
• Les données structurées sont conservées sur les gabarits concernés.
• Les annotations hreflang sont cohérentes, réciproques et alignées avec les canonical pour un site international.

Pour un e-commerce, contrôlez les données structurées produit avec la même attention que les redirections. Lors d’un changement de thème ou de CMS, les données Product disparaissent parfois sans alerte visible. Lorsque les fiches regroupent des variantes de taille, couleur, matière ou capacité, le balisage ProductGroup doit rester cohérent avec les variantes effectivement disponibles.

Tester ce qui ne se voit pas

Une page peut renvoyer un code 200, être jolie sur ordinateur et rester défaillante pour le business.

Le test doit couvrir les intégrations : formulaires, CRM, emails transactionnels, paiement, webhooks, ERP, PIM, stock, moteur de recherche interne, scripts publicitaires, CMP, pixels, API, plugins anti-spam, cache, CDN et règles WAF.

Prenons un cas simple, volontairement fictif : un e-commerce migre vers un nouveau CMS et conserve son trafic organique le lendemain. L’équipe considère la migration comme réussie. Pourtant, l’événement purchase n’est plus transmis au data layer : GA4 ne remonte plus les achats alors que les commandes existent. Deux jours plus tard, les campagnes publicitaires automatisées commencent à se dégrader parce qu’elles s’appuient sur des données de conversion incomplètes. Le site n’était pas réellement « fonctionnel » ; il était seulement accessible.

Testez donc un parcours complet : recherche d’un produit, ajout au panier, code promotionnel, livraison, paiement, confirmation, email transactionnel, décrémentation du stock et remontée de la conversion dans l’outil de mesure.

Mettre en place une vraie recette comparée

Un contrôle utile ne se limite pas à cocher « testé ». Il compare l’état avant et après.

Zone contrôlée	Ce qu’il faut comparer	Exemple de signal d’alerte
URLs indexables	Volumes par type de page	40 % de fiches produit devenues non indexables
Codes HTTP	200, 3xx, 4xx, 5xx	Hausse de 404 ou erreurs serveur après déploiement
Redirections	Ancienne URL vers destination finale	Chaîne de redirections ou renvoi vers la home
Contenus	Texte, images, blocs SEO, liens	Intro de catégorie supprimée lors de la refonte
Balises	Title, H1, canonical, robots, hreflang	Canonical vers le domaine de préproduction
Performance	TTFB, LCP, INP, CLS	Nouveau thème beaucoup plus lourd sur mobile
Tracking	Événements, consentement, ventes	purchase ou formulaire absent de GA4
Conversion	Compte, panier, paiement, formulaires	Code promo ou mode de livraison inutilisable

Sur les pages générant réellement des revenus ou des leads, complétez le crawl par une recette humaine. Les outils détectent des signaux techniques ; ils ne savent pas toujours déterminer si un prix, une promesse, un configurateur ou un tunnel de commande reste compréhensible et utilisable.

Jour J : basculer sans improviser

Le lancement doit s’appuyer sur un déroulé connu à l’avance. Une migration technique peut toujours réserver une surprise ; l’improvisation, elle, n’a aucune raison de faire partie du plan.

Préparer des critères go/no-go

Décidez avant la bascule des problèmes qui justifient un report ou un retour arrière.

Vous pouvez envisager un lancement si les sauvegardes ont été testées, si les redirections critiques sont en place, si le SSL est valide, si les outils de mesure remontent les données attendues et si les principaux parcours métiers ont été validés.

À l’inverse, un noindex encore présent, un paiement non testé, une liste de redirections incomplète sur les pages à forte valeur, une absence d’accès au DNS ou aucun plan de rollback doivent être considérés comme des signaux de non-départ.

Le jour J, je préfère une bascule moins ambitieuse, mais contrôlable, à une refonte parfaite sur le papier dont personne ne peut expliquer les conséquences après mise en ligne.

Déroulé de bascule recommandé

1. Geler les modifications de contenu et les changements non indispensables.
2. Réaliser la synchronisation finale des données : commandes, comptes, stocks, leads ou formulaires selon le projet.
3. Déployer la nouvelle version.
4. Activer les redirections et vérifier leur comportement.
5. Mettre à jour le DNS si nécessaire.
6. Contrôler le SSL, le CDN, le cache et les règles de sécurité.
7. Tester les pages prioritaires en navigation privée, sur mobile et desktop.
8. Valider les formulaires, comptes clients, panier, paiement et emails transactionnels.
9. Vérifier GTM, GA4, CMP, pixels et événements clés.
10. Mettre à jour ou soumettre le sitemap XML de production.
11. Démarrer le suivi des erreurs techniques et des logs.

Pour un changement de domaine, ajoutez le nouveau domaine à Google Search Console avant la mise en ligne. Une fois que le nouveau site est accessible et que les redirections sont actives, utilisez l’outil Change of Address. Cela ne remplace ni les redirections 301 ni le monitoring de l’ancienne et de la nouvelle propriété.

Après la mise en ligne : surveiller, corriger, ne pas casser l’ancien site

La migration ne se termine pas au moment où le nouveau site apparaît à l’écran. C’est le début de la période où les erreurs réelles deviennent visibles : utilisateurs qui suivent d’anciens liens, robots qui explorent les redirections, cache qui se comporte différemment en production ou données business qui remontent mal.

Les 72 premières heures

Surveillez les erreurs 404 et 5xx, la disponibilité, les temps de réponse, le SSL, les redirections, les formulaires, les commandes, les paiements et les événements de conversion.

Les logs serveur sont particulièrement précieux à ce stade. Ils montrent quelles anciennes URLs reçoivent encore des visites, comment Googlebot accède aux nouvelles pages et quels problèmes ne remontent pas immédiatement dans Analytics ou Search Console. Une hausse de codes 500 sur certaines URLs, des boucles de redirection ou des requêtes fréquentes vers une ressource JavaScript bloquée peuvent révéler une erreur avant qu’elle ne produise une baisse visible dans le trafic organique.

Suivre des indicateurs SEO et business

Ne pilotez pas la période post-migration avec les seules sessions organiques. Le trafic peut rester stable tandis que les conversions se dégradent ; à l’inverse, une variation temporaire d’impressions peut être sans conséquence commerciale.

Suivez plutôt un ensemble cohérent :

• Clics et impressions dans Search Console.
• Pages indexées, exclues ou affectées par un problème de canonicalisation.
• Erreurs d’exploration et 404.
• Landing pages organiques à forte valeur.
• Positions des requêtes commerciales importantes.
• Leads, transactions, chiffre d’affaires et taux de conversion.
• Événements GA4 et cohérence avec le back-office.
• Performance mobile et Core Web Vitals.
• Logs de crawl et comportement de Googlebot.

Conservez l’ancien domaine et ses redirections

Il faut distinguer deux durées souvent mélangées.

Lors d’un changement de domaine, l’outil Change of Address de Google Search Console reste actif pendant environ 180 jours. Cette période aide Google à traiter le déplacement entre l’ancien et le nouveau domaine.

Les redirections 301 ne doivent pas disparaître au bout de ces 180 jours. Google recommande de les maintenir au moins un an. Dans la pratique, conservez-les plus longtemps pour les URLs qui reçoivent encore du trafic, des backlinks, des visites issues de campagnes anciennes ou des clics depuis des favoris.

L’ancien domaine ne doit pas rester un second site actif et concurrent. En revanche, il doit continuer à répondre techniquement : DNS actif, HTTPS valide, serveur accessible et redirections URL par URL.

Ne sabotez pas les anciennes URLs pendant la transition

Après un changement de domaine, certaines équipes suppriment l’ancien site, placent des balises noindex sur les anciennes pages, bloquent tout dans robots.txt ou laissent les URLs historiques basculer en 404.

C’est une mauvaise idée lorsque ces URLs doivent rediriger. Si les robots ne peuvent plus accéder aux anciennes adresses ou si les redirections cessent de fonctionner, vous interrompez le chemin qui permet aux utilisateurs et aux moteurs de recherche de rejoindre les nouvelles pages.

Conservez donc les anciennes URLs redirigées, sans les bloquer avant que la transition soit réellement terminée. Avant toute désactivation définitive, vérifiez les logs, les backlinks, les données analytics et Search Console. Si certaines anciennes URLs reçoivent encore des visites ou sont régulièrement explorées, elles doivent rester couvertes par les redirections.

Les erreurs les plus coûteuses lors d’une migration

Oublier les URLs qui ne figurent pas dans le menu

Les anciennes landing pages, les PDF, les pages orphelines, les sous-domaines, les produits retirés, les contenus liés depuis des sites tiers et les URLs utilisées dans des campagnes sont les premières candidates à l’oubli.

Un inventaire multi-sources limite ce risque. Si vous dépendez uniquement d’un crawl, vous n’aurez qu’une vue partielle du site.

Supprimer du contenu stratégique pendant une refonte

Une refonte visuelle conduit parfois à simplifier les catégories, à retirer les paragraphes de texte, à réduire les liens contextuels ou à fusionner des pages qui répondaient à des intentions différentes.

Avant de supprimer, regardez le trafic, les requêtes, les backlinks, les conversions et la capacité de la nouvelle page à répondre à la même intention. Une mise en page plus épurée n’est pas automatiquement une meilleure page pour le SEO ou pour l’utilisateur.

Penser qu’une sauvegarde suffit

La restauration testée, les accès de secours et les critères de rollback sont bien plus importants qu’un simple dossier de sauvegarde stocké quelque part.

Demandez-vous : qui décide du retour arrière ? Quel est le délai maximal acceptable ? Comment réconcilier les commandes, leads ou données créées après la dernière sauvegarde ? Ces questions sont inconfortables, mais elles doivent être résolues avant l’incident, pas au milieu de celui-ci.

Oublier les intégrations

Les problèmes de migration les plus frustrants concernent souvent les éléments invisibles : emails qui ne partent plus, webhooks de paiement qui échouent, consentement qui ne déclenche plus les tags, recherche interne non réindexée, cache qui bloque le panier ou formulaires qui ne créent plus de fiche dans le CRM.

Faites tester chaque intégration par la personne qui utilise réellement le résultat. Le responsable CRM doit voir le lead arriver. L’équipe e-commerce doit voir la commande, le paiement et le stock. La personne en charge de l’acquisition doit vérifier la remontée des conversions.

Arrêter trop tôt les redirections

Les anciens liens continuent de circuler longtemps. Un backlink, une newsletter vieille de deux ans, un PDF ou un favori navigateur peuvent générer des visites bien après la migration. Garder les redirections est généralement bien moins coûteux que devoir réparer une perte de trafic ou de liens plusieurs mois plus tard.

Checklist finale

Avant migration : définissez le type de projet, réduisez les changements non essentiels, nommez les responsables, testez une restauration, inventoriez les URLs par plusieurs sources et préparez un mapping fondé sur l’intention.

En préproduction : comparez ancien et nouveau site, testez les redirections, les métadonnées, l’indexabilité, les liens internes, la performance, le rendu mobile, les données structurées, le tracking et les fonctions métiers.

Le jour J : effectuez une synchronisation finale des données, déployez, activez les redirections, contrôlez DNS, SSL, cache et CDN, puis testez les pages et parcours prioritaires en conditions réelles.

Après migration : surveillez les logs, Search Console, les erreurs, les performances, les conversions et le chiffre d’affaires. Maintenez les redirections, ne bloquez pas les anciennes URLs qui doivent rediriger et corrigez rapidement les écarts identifiés.

Conclusion

Une migration de site est un projet de continuité, pas seulement un projet technique. Les moteurs de recherche doivent retrouver les bonnes pages, les utilisateurs doivent conserver un accès fluide aux contenus et aux fonctionnalités, et les équipes doivent continuer à disposer de données fiables pour piloter leur activité.

Les redirections 301 sont essentielles, mais elles ne suffisent pas. Le résultat dépend aussi de la qualité de l’inventaire, du maintien des contenus stratégiques, de la recette des intégrations, de la préparation du rollback et du suivi mené après la bascule.

Si une seule règle devait guider le projet, ce serait celle-ci : ne mettez en production que ce que vous êtes capable de tester, de mesurer et, si nécessaire, de corriger rapidement.