Migration web : comment migrer un site sans perdre son référencement ?

Migrer un site web, c’est le transférer vers un autre environnement technique en reprenant ses contenus, ses données et ses fonctionnalités. Le changement peut porter sur le CMS, l’hébergement ou le nom de domaine, et chaque scénario fait courir des risques différents aux visiteurs, aux équipes éditoriales et au référencement. Avant de commencer, il faut savoir ce qui reste identique, ce qui change et comment on vérifiera le résultat. On passe ici en revue le périmètre, les contrôles et la répartition des rôles, pour limiter les pertes puis les mesurer.

Ce sont le périmètre technique et les critères de validation qui dictent la préparation, bien plus que le nom de l’outil d’arrivée.

Quels changements recouvre une migration web ?

Changer de plateforme, d’hébergement web ou de domaine ne touche pas les mêmes parties du site. Le périmètre doit nommer ce qui bouge et ce qui reste en service : quand plusieurs changements tombent en même temps, une anomalie devient difficile à rattacher à sa cause.

Le terme de migration informatique couvre aussi des chantiers plus larges, comme le passage d’applications internes vers le cloud. Pour un site, demandez la carte des pages, des données et des services réellement concernés, plutôt qu’une description générale de l’infrastructure.

Pourquoi déplacer un site, et quand associer une refonte ?

Un CMS devenu pénible pour publier, des fonctionnalités à reprendre ou un hébergement à remplacer justifient d’étudier un transfert. Changer de plateforme n’est pas toujours la réponse : un site WordPress qui remplit encore ses fonctions peut souvent changer d’hébergement ou de thème sans quitter son CMS, à condition d’en évaluer le coût de maintenance sur la durée.

La migration touche le socle, la refonte les interfaces et les parcours. On peut garder le design pendant un changement technique, ou revoir les parcours sans changer de plateforme. Si l’on fait les deux, les validations restent séparées : la reprise des données d’un côté, le fonctionnement des interfaces de l’autre.

Dans ce cas, faites travailler les concepteurs avec les développeurs dès les arbitrages de contenu, sans attendre l’approbation des maquettes. Un gabarit dessiné sans connaître le modèle de contenu cible oblige à revoir la reprise des données.

Notre article sur les décisions liées à une refonte revient sur cette distinction. Le passage de WordPress à Webflow est un cas à part, avec ses propres choix de reprise.

Préparer le transfert avant de toucher au site

La bascule suppose un inventaire validé, des données récupérables et des responsables de recette nommés. Tout commence donc sur le site existant : l’équipe doit savoir ce qu’elle garde avant de construire la destination.

Cartographier le site et définir le périmètre

L’audit de départ rattache chaque contenu à son adresse, à son gabarit et aux fonctions dont il dépend. Le responsable éditorial confirme les pages à reprendre, le responsable technique les dépendances et les contraintes d’accès. Ils livrent ensemble un inventaire approuvé, qui dit pour chaque élément s’il est conservé, transformé ou retiré.

• Pages, URL et contenus prioritaires.
• Gabarits et composants réutilisés.
• Formulaires, réservation et autres fonctionnalités.
• Liens internes et documents téléchargeables.
• Services connectés et accès nécessaires.

Sécuriser les contenus et les données

Récupérer les textes, les médias, les métadonnées et les données utiles ne suffit pas : il faut ensuite vérifier qu’ils ont bien été repris. Sur WordPress, les fichiers et la base de données sont deux choses distinctes, et avoir les images ne prouve pas que les contenus et leurs relations sont récupérables. Le responsable technique documente les exports, l’équipe éditoriale valide les contenus transférés.

Une sauvegarde n’est exploitable que si l’on connaît son périmètre, que les accès sont disponibles et que la restauration a été testée dans un environnement adapté. Le guide de l’ANSSI sur les fondamentaux de la sauvegarde des systèmes d’information donne des repères pour cette préparation, sans remplacer les choix propres au site. Les exports sensibles demandent en plus des accès restreints et une protection pendant leur transfert.

Attribuer les validations et préparer la préproduction

Marque, contenu, produit, développement : chaque équipe reçoit sa liste de points à vérifier et le pouvoir de les valider. La marque examine les interfaces, le contenu contrôle la reprise, le produit teste les parcours et le développement vérifie le fonctionnement technique. Les réserves et leur responsable sont consignés dans un document partagé.

Les essais avant publication se font sur un environnement de staging. Précisez qui y a accès, comment les modifications y sont suivies et comment on évite d’y exposer des données sensibles. On y valide les interfaces développées, au-delà des maquettes : un formulaire ou un composant éditorial se teste en fonctionnement réel.

Transférer le site sans perdre le fil

On contrôle la copie sur l’environnement cible avant de toucher à l’adresse publique. Le développement reprend fichiers, contenus et données, puis note les écarts dans un compte rendu ; l’équipe éditoriale valide ce qui sera publié.

Une fois la recette passée, le responsable de publication confirme le gel des contenus et la dernière sauvegarde. Le responsable technique prépare les paramètres DNS, vérifie le TTL DNS en place et prévoit la purge du cache si un CDN diffuse le site. Il en sort une procédure de bascule, avec chaque vérification et son responsable.

Le plan de rollback précise quand revenir en arrière, avec quels accès, et prévoit le traitement des données créées après le lancement. Restaurer l’ancien site n’est pas toujours la bonne réponse : des réservations ou des demandes reçues sur le nouvel environnement peuvent devoir être conservées. Leur sort se décide avant d’autoriser tout retour vers l’ancien site.

Protéger le référencement pendant le changement

Pour garder vos positions, trois éléments doivent traverser le changement sans perte : les contenus que les internautes recherchent, les destinations d’URL et les signaux d’indexation. Même bien préparée, une migration ne garantit pas ces positions. D’où l’intérêt de contrôles qui produisent, avant comme après le lancement, des constats comparables.

Construire le mapping et traiter les redirections

Le mapping d’URL donne à chaque ancienne adresse une destination ou une décision. Commencez par les pages suivies dans Search Console et les contenus que vous voulez garder. Une adresse qui ne change pas se contrôle aussi, sur son contenu comme sur son accessibilité.

Un déplacement permanent appelle une redirection HTTP 301 vers la page correspondante, testée jusqu’à sa destination. Une page sans équivalent demande une décision claire : un contenu de remplacement pertinent ou un retrait assumé. Évitez les chaînes de redirections et les renvois systématiques vers l’accueil, qui ne répondent pas forcément au besoin de l’ancienne page.

Vérifier l’indexabilité et les signaux techniques

Les réglages d’indexation doivent désigner les versions publiques que vous voulez montrer à Google. Le responsable SEO valide les destinations attendues, le développement vérifie qu’elles sont en place sur le site publié, pour qu’aucune restriction de préproduction ne reste active par erreur.

• Balise canonique cohérente avec l’URL retenue.
• Fichier robots.txt adapté aux pages publiques.
• Directives d’indexation vérifiées sur les gabarits.
• Balises hreflang contrôlées pour les versions internationales.

Comparer les crawls avant et après le lancement

Un crawl lancé avant la migration, puis un autre après, mettent côte à côte les adresses explorées, les statuts HTTP, les liens internes et les pages accessibles. Gardez le même périmètre et annotez les changements décidés : une page supprimée volontairement n’a pas à passer pour une disparition inexpliquée.

Le guide de Google sur le déplacement d’un site avec changement d’URL recommande de s’appuyer sur Search Console pendant la migration pour suivre l’indexation des anciennes et des nouvelles adresses. Les deux outils se complètent : le crawl montre ce que le site expose au moment du test, Search Console ce que Google en fait.

Suivre les symptômes et rechercher leur cause

Une baisse de visibilité se diagnostique page par page et symptôme par symptôme, avant d’accuser la migration. Comparez les contenus concernés, les changements d’adresses et les erreurs techniques ; si vous avez accès aux logs serveur, leur analyse complète la recherche. Quand la destination est Webflow, l’agence SEO Webflow de mad.studio prend ce suivi en charge après la bascule.

• Page introuvable : vérifier l’adresse et sa destination.
• Baisse d’indexation : examiner les directives et les pages concernées.
• Redirection incorrecte : tester le chemin jusqu’à la destination finale.
• Exploration incohérente : confronter logs serveur et Google Search Console.

Recetter le nouveau site avant et après la bascule

La recette vérifie que les visiteurs vont au bout de leurs parcours, avec des critères proches de ceux d’un audit UX design, et que l’équipe retrouve les contenus attendus. La préproduction valide la reprise ; sur le site en ligne, on contrôle ensuite les adresses et les services réellement publiés.

Sur un site de commerce électronique, ajoutez les contrôles d’accessibilité applicables. La DGCCRF indique que depuis le 28 juin 2025, les exigences françaises issues de la directive européenne concernent certains produits et services, dont les services de commerce électronique. Un changement technique ne dispense pas de vérifier les parcours concernés.

La check-list de bascule, J-7, jour J, J+7

Ce découpage évite la panique du jour de mise en ligne : chaque contrôle a sa date, et rien ne dépend de la mémoire de l’équipe.

Piloter la mise en ligne et le suivi

La procédure de lancement confie à des personnes nommées le feu vert de publication, l’exécution de la bascule et la validation des parcours. Que la destination soit un CMS ou un site développé sur mesure, elle s’accompagne de contrôles écrits, sans promesse de résultat SEO.

Organiser la bascule

On lance une fois la recette approuvée et les accès techniques confirmés. L’équipe éditoriale applique le gel prévu ; le responsable technique déroule la procédure, contrôle les paramètres DNS et vérifie le TTL configuré, sans supposer un délai de propagation valable partout.

Avec un CDN, purgez le cache au moment de la publication pour vérifier la version réellement servie aux visiteurs. Les personnes chargées des parcours prioritaires restent disponibles pour tester les pages publiques, les formulaires et leurs destinations. En cas d’anomalie bloquante, on applique la décision prévue au plan de rollback, après examen des données déjà reçues.

Surveiller et corriger après le lancement

Après le lancement, les vérifications éditoriales, fonctionnelles et SEO continuent sur le site que les visiteurs utilisent. Ce qui empêche une demande, une réservation ou l’accès à un contenu prioritaire passe avant les écarts de présentation qui ne bloquent pas le parcours.

Chaque incident a une adresse, une description reproductible, un responsable et un test après correction. Google Search Console suit les pages et les positions concernées, mais pas le bon fonctionnement d’un formulaire : les contrôles de formulaires et de contenus continuent même sans alerte de référencement.

Pour choisir entre faire en interne et se faire accompagner, vérifiez que votre équipe couvre les accès techniques, la reprise éditoriale, les redirections et la disponibilité le jour du lancement, et parlez à la personne qui exécutera les opérations. Le devis doit séparer le transfert, les évolutions d’interface, la recette et le suivi, car le volume de travail varie avec les fonctionnalités à reprendre et la transformation des contenus.

Entre transfert technique et évolution des interfaces, tout dépend des limites du site actuel et des fonctions à conserver.