Migration de site internet : comment déménager sans perdre son trafic

La migration d'un site internet est tout projet qui déplace un site vers une nouvelle adresse, une nouvelle plateforme ou une nouvelle structure : changement de CMS, changement de nom de domaine, passage de HTTP à HTTPS, ou refonte qui renomme toutes les URL. Les contenus survivent au déménagement. Les adresses vers lesquelles pointent Google, les autres sites et vos propres campagnes e-mail, souvent non.

C'est dans cet écart que naissent les dégâts. Selon Google Search Central, un déplacement avec changement d'URL impose de conserver les redirections pendant au moins un an, et les positions bougent tant que le changement est digéré. Tout ce qui est oublié dans cette fenêtre coûte du trafic déjà payé : une URL sans destination, un robots.txt de préproduction parti en ligne, une balise de mesure jamais reportée sur les nouveaux gabarits.

Ce guide s'adresse à la personne qui valide le projet, pas à celle qui exécute le déploiement. Il couvre les quatre types de migration et le risque de chacun, le cadrage en amont, le plan de redirections, les tests avant la mise en ligne, l'ordre des opérations le jour J, la surveillance des 30 premiers jours et ce qui doit figurer au contrat.

Migration désigne quatre projets différents, et ils ne portent pas le même risque. La première question est donc : qu'est-ce qui change vraiment ? L'endroit d'où les fichiers sont servis, le système qui fabrique les pages, le nom de domaine dans la barre d'adresse, ou les chemins des URL. Un changement de plateforme qui conserve chaque URL est un week-end tranquille. Un changement de domaine qui renomme en plus chaque page finit en analyse d'incident.

Dans la réalité, la plupart des projets sont un mélange. Une entreprise remplace un CMS vieillissant, le marketing en profite pour demander une nouvelle navigation, le juridique demande d'abandonner le domaine national. Trois migrations sont empaquetées dans une seule mise en ligne, et quand le trafic baisse, personne ne sait laquelle des trois est en cause.

Si vous ne retenez qu'une décision de ce guide, retenez celle-ci : changez une variable à la fois quand le calendrier le permet. D'abord la plateforme, URL inchangées, on vérifie que les chiffres tiennent, puis la nouvelle structure dans une deuxième livraison. Cela coûte un déploiement de plus et vous donne une réponse le jour où quelque chose se passe mal.

Le trafic ne disparaît pas parce qu'un site a déménagé. Il disparaît parce que quelques liaisons ont cassé et que personne n'a vérifié. Dans la pratique, cinq défauts reviennent sur des projets de toutes tailles, et quatre d'entre eux se voient dans un crawl d'un après-midi.

Des URL sans destination. Chaque ancienne adresse qui renvoie 404 perd son positionnement, ses liens entrants et le trafic de campagne qu'elle portait. Le remède est peu spectaculaire : une ligne par ancienne URL dans un fichier de correspondance, relue par un humain.

Des redirections qui convergent vers une seule page. Une règle globale qui envoie 400 fiches produit retirées vers l'accueil évite les 404 sur le papier et détruit la pertinence en même temps. Google traite une redirection vers une page sans rapport à peu près comme un soft 404.

Des chaînes et des boucles. Ancienne URL vers URL intermédiaire vers URL finale gaspille le budget d'exploration et ralentit chaque visiteur venu d'un vieux lien. La cible est un seul saut, et les chaînes s'auditent avant la mise en ligne, pas après.

Des blocages venus de la préproduction. Les environnements de test sont fermés aux robots volontairement. La ligne Disallow: / et la balise noindex sont les deux morceaux de la préproduction qui ne doivent jamais atteindre la production, et ils expliquent les chutes les plus violentes.

Des liens internes qui pointent encore vers l'ancien arbre. Menus, pieds de page, liens dans le texte et sitemaps XML avec d'anciens chemins forcent chaque robot à passer par la couche de redirections et diluent le maillage interne construit pendant des années.

Une migration vaut son risque quand la solution actuelle bloque quelque chose dont l'entreprise a besoin, pas quand le site fait daté. Trois déclencheurs justifient le projet à eux seuls : la plateforme ne sait plus porter ce que vous vendez, la maintenir coûte plus cher que la remplacer, ou un changement juridique ou de marque impose de déplacer l'adresse.

L'argument de la plateforme arrive presque toujours trop tard. Sur le terrain, il ressemble à ceci : ajouter un type de page demande un développeur au lieu d'une rédactrice, chaque connexion dépend d'une extension qui casse à la mise à jour suivante, le temps de chargement s'effondre sous le trafic de campagne, et une deuxième langue devient un deuxième site. Ce sont les symptômes d'un site devenu trop grand pour ses fondations, et aucun budget de design ne les répare.

L'argument du coût, lui, se calcule. Additionnez licences, abonnements d'extensions, hébergement et les heures que votre équipe passe à contourner le système. Comparez à une reconstruction étalée sur trois ans. Dès que le total des contournements dépasse, la décision s'est prise toute seule.

Il existe aussi de mauvaises raisons, et elles coûtent cher : une nouvelle direction marketing qui préfère une autre technologie, une agence qui ne sait construire que sur un système, ou une envie de design réalisable en mise à jour de gabarits. Si seule l'apparence change, ce qu'il vous faut est une refonte, et la préparation d'une refonte est le chemin le plus court et le moins cher.

Cadrer, ici, c'est faire un inventaire, et cela se passe avant le design, avant le développement et avant le choix de la plateforme. Vous répondez à une seule question : qu'est-ce qui existe aujourd'hui, et combien vaut chaque ligne ? Sauter l'inventaire revient à laisser l'équipe décider par accident, en migrant ce qui s'exportait facilement.

Commencez par quatre exports. Un crawl complet du site en ligne donne chaque URL avec son code de statut, son titre et sa canonique. La Search Console donne chaque page ayant obtenu des impressions sur douze mois. L'analytique donne les pages d'entrée et les conversions par page. Un export de liens entrants donne les pages vers lesquelles d'autres sites pointent, et ce sont précisément celles qui ne doivent jamais renvoyer 404.

Croisez les quatre listes dans un tableau, puis marquez chaque URL d'une décision : garder, fusionner, renommer ou retirer. Une page sans trafic, sans position et sans lien peut disparaître. Une page avec deux liens entrants et zéro trafic a quand même besoin d'une destination. Ce tableau devient à la fois le plan de redirections, le plan de contenus et la liste de recette.

Le même passage répond aux questions qui surprennent tard : combien de formulaires existent et où partent les envois, quels outils écrivent dans le site, combien de langues sont servies, quelles pages portent des mentions juridiques, et qui gère les enregistrements DNS.

Le plan de redirections est un tableau avec une ligne par ancienne URL et une seule destination par ligne. C'est le livrable à demander par son nom, à relire avant la mise en ligne et à conserver après la clôture du projet. Une agence incapable de le montrer migre au jugé.

Trois règles le gardent honnête. Chaque destination doit être la page équivalente la plus proche, pas une catégorie ni l'accueil. Chaque redirection est permanente, une 301, pour que les moteurs transmettent les signaux acquis. Et chaque ancienne URL sans équivalent renvoie 410, ce qui dit aux robots que la page a été retirée volontairement au lieu de faire semblant d'un déménagement.

Relisez-le vous-même, dans un tableur, sur les lignes qui comptent : vos 50 pages les plus visitées, vos 50 pages les plus liées, et toute page présente dans une campagne en cours ou dans une signature e-mail. C'est une heure de votre temps contre le prix de découvrir l'erreur dans vos statistiques trois mois plus tard.

La visibilité dans les moteurs capte l'attention parce qu'elle se mesure en public. Les pannes qui coûtent le plus cher restent souvent invisibles pendant des semaines : un formulaire de contact qui envoie dans le vide, un bandeau de consentement qui bloque toute la mesure, ou des e-mails transactionnels qui n'arrivent plus parce que les enregistrements DNS ont suivi l'hébergement.

Le consentement mérite sa ligne. Reconstruire un site veut dire reconstruire le bandeau cookies, et selon le RGPD et les règles de la CNIL, les traceurs non nécessaires ne peuvent pas se déclencher avant l'accord de la personne. Les équipes qui refont la mesure dans l'urgence livrent souvent un bandeau qui bloque tout, ce qui fait ressembler le rapport à un effondrement de trafic, ou qui ne bloque rien, ce qui n'est plus un problème de rapport.

Le tableau ci-dessous est la version courte de la réunion de passation. Chaque ligne a besoin d'un responsable et d'un test en préproduction, pas d'une promesse de vérifier après la mise en ligne.

Tester avant la mise en ligne, c'est comparer, pas donner un avis. Vous crawlez la préproduction avec l'outil qui a servi sur le site en ligne et vous mettez les deux inventaires côte à côte. Tout ce qui figure dans l'ancien crawl et manque dans le nouveau est soit un retrait volontaire avec 410, soit un défaut, et il n'y a pas de troisième possibilité.

Cinq vérifications attrapent l'essentiel. Comparer le nombre de pages et les titres entre ancien et nouveau. Confirmer que chaque canonique pointe vers le domaine de production et non vers la préproduction. Vérifier que le hreflang est réciproque, puisque Google demande à chaque version linguistique de citer toutes les autres et elle-même. Confirmer qu'aucune balise noindex ne traîne sur des pages à indexer. Et passer le plan de redirections en lot : donner les anciennes URL au crawler et confirmer que chacune répond par une seule 301 vers une page vivante.

La performance appartient au même passage. Les Core Web Vitals sont évalués au 75e centile des chargements réels, un gabarit peut donc être bon sur votre portable et échouer sur le terrain. Mesurez les nouveaux gabarits face aux seuils publiés sur web.dev et traitez une régression comme un point bloquant, pas comme une optimisation pour plus tard. Nos notes sur le temps de chargement expliquent quoi corriger en premier quand le nouveau site part plus lent que celui qu'il remplace.

L'accessibilité fait partie de la même conversation depuis 2025. La directive (UE) 2019/882 s'applique depuis le 28 juin 2025, et un service reconstruit ou modifié en profondeur compte comme nouveau, pas comme existant. Si vous vendez à des particuliers, la migration est le moment d'intégrer l'accessibilité, pas celui de la repousser.

Le jour J échoue plus souvent sur l'ordre que sur le code. La liste ci-dessous suppose que le nouveau site est validé en préproduction et que le plan de redirections a été vérifié en lot, si bien que la journée elle-même est mécanique.

1. Geler les modifications de contenu sur l'ancien site, en annonçant l'heure de début à l'équipe.
2. Lancer un dernier crawl du site en ligne. C'est la dernière photo comparable.
3. Baisser le TTL DNS 48 heures à l'avance pour que la bascule se propage en minutes et non en un jour.
4. Déployer le nouveau site, encore fermé aux robots, et parcourir les chemins critiques.
5. Retirer les blocages : robots.txt d'abord, puis toute balise noindex restée dans les gabarits.
6. Activer les redirections et tester 20 URL à la main, choisies sur le trafic et sur les liens.
7. Publier le nouveau sitemap XML et le soumettre dans la Search Console.
8. Confirmer que mesure, consentement et formulaires enregistrent en production, pas seulement en test.
9. Surveiller les logs serveur pour les 404 le reste de la journée et corriger ce qui apparaît.

Gardez l'ancien environnement accessible quelque temps après la bascule. Pas en ligne, mais récupérable. Un plan de retour arrière qui n'existe que sous forme de phrase dans une proposition n'est pas un plan de retour arrière.

Le premier mois décide si la migration fut un projet ou un incident. Les moteurs ont besoin de temps pour réexplorer et retraiter les nouvelles adresses : un creux les deux premières semaines est normal, un creux qui s'aggrave en semaine quatre ne l'est pas. Surveillez des groupes de pages plutôt que le total du site, parce qu'une moyenne masque exactement la section qui a cassé.

Fixez le rythme de revue avant la mise en ligne : quotidien la première semaine, deux fois la deuxième, hebdomadaire ensuite. Confiez le compte rendu à une personne. Les migrations échouent rarement bruyamment, elles échouent en pente douce, celle que chacun croit surveillée par quelqu'un d'autre.

Le coût suit le type de déménagement, pas le nombre de pages. Changer d'hébergement est une journée de travail. Changer de plateforme en conservant les URL, c'est refaire les gabarits plus un export de données. Changer de domaine et renommer toutes les URL ajoute la correspondance, les tests et la fenêtre de surveillance par-dessus.

Les prix publiés donnent un repère. Nos tarifs démarrent à €1 500 pour une landing page livrée en deux à trois jours, €4 500 pour un site corporate de 10 à 30 pages livré en une à trois semaines, et €9 000 pour un portail de 50 pages et plus livré en un à trois mois. La migration d'un site existant de taille équivalente tombe dans la même fourchette, avec la correspondance et la vérification en plus, puisque la reconstruction est identique et que l'inventaire s'ajoute. Chiffres en vigueur en août 2026.

Ce qui surprend n'est pas la construction, ce sont les deux extrémités. L'inventaire et la correspondance prennent une à trois semaines de calendrier sur un site moyen, parce qu'ils réclament des arbitrages du marketing, du commerce et du juridique, pas davantage d'heures de développement. La fenêtre de surveillance après la mise en ligne dure quatre à huit semaines et doit figurer au contrat comme prestation payée, pas comme geste commercial.

Budgétez à part ce qui est toujours oublié : refaire le dispositif de consentement, retester chaque formulaire et chaque connexion, mettre à jour les URL de campagne dans les régies et les outils d'e-mailing, et corriger les liens internes des anciens articles qui pointent vers des pages renommées.

Un contrat de migration qui promet seulement que le nouveau site ressemblera aux maquettes laisse dehors tout ce qui peut mal tourner. Les critères de recette doivent être vérifiables par quelqu'un qui ne développe pas, donc écrits comme des contrôles avec un résultat conforme ou non conforme.

Demandez ces sept points par écrit. Un plan de redirections couvrant toute URL ayant eu du trafic ou un lien entrant sur douze mois, livré pour relecture avant la mise en ligne. La confirmation que les anciennes URL répondent par une seule 301 vers une page pertinente et que les pages retirées renvoient 410. La conservation des titres, méta-descriptions, canoniques et hreflang, ou une justification documentée là où ils changent. Un plan de test de la mesure listant chaque événement, objectif et formulaire devant fonctionner le jour J. Une prise de position sur les obligations d'accessibilité issues de la directive européenne quand le site entre dans son champ. Des objectifs de performance mesurés sur le terrain pour les gabarits principaux. Et une fenêtre de surveillance nommée, de quatre à huit semaines, avec des délais de réaction sur les défauts qui y sont trouvés.

Ajoutez une clause qui ne coûte rien et évite les disputes : le plan de redirections, les exports de crawl et le plan de mesure sont remis sous forme de fichiers à la clôture. Ce sont vos documents. La prochaine agence les demandera, et vous aussi.

Voici la version courte de tout ce qui précède, dans l'ordre où le travail se fait. Recopiez-la dans votre outil de suivi et donnez à chaque ligne un responsable et une date.

Avant la construction

• Crawler le site en ligne et exporter chaque URL avec son statut, son titre et sa canonique.
• Exporter douze mois de Search Console, les pages d'entrée de l'analytique et les domaines référents.
• Marquer chaque URL : garder, fusionner, renommer ou retirer.
• Lister formulaires, connexions, balises de mesure, flux et pages juridiques avec leurs responsables.
• Décider si plateforme, structure et domaine changent en une livraison ou en plusieurs.

Avant la mise en ligne

• Plan de redirections relu à la main sur les 50 pages les plus visitées et les 50 plus liées.
• Préproduction crawlée et comparée à l'inventaire du site en ligne.
• Canoniques vers la production, hreflang réciproque, aucun noindex égaré.
• Formulaires, parcours de consentement et événements analytiques testés en préproduction.
• Core Web Vitals mesurés sur les nouveaux gabarits, les régressions sont bloquantes.
• Plan de retour arrière écrit, TTL DNS abaissé.

Jour J et après

• Blocage retiré, redirections actives, sitemap soumis.
• Vingt redirections testées à la main, logs serveur surveillés pour les 404.
• URL de destination des publicités et des e-mails repointées vers les nouvelles adresses.
• Rythme de surveillance acté : quotidien une semaine, puis hebdomadaire un mois.
• Redirections maintenues au moins un an et plan archivé avec les documents du projet.

Ce cas-là, nous pouvons le raconter de l'intérieur, puisque c'est notre site. Vezert existe en anglais, allemand, espagnol, français et néerlandais, et chaque langue a son propre slug d'URL au lieu d'une page traduite posée sur une adresse anglaise. À chaque changement de slug, l'ancienne adresse reçoit une redirection permanente, et le fichier qui les rassemble en contient aujourd'hui 329.

Deux décisions ont fait le travail. Chaque article porte un identifiant stable qui ne change jamais, si bien que le hreflang est généré depuis cet identifiant et non depuis un nom de fichier : renommer une page dans une langue ne peut pas couper le lien avec les quatre autres. Et le changement de slug produit sa redirection automatiquement, dans le même script qui renomme le fichier, ce qui supprime l'étape que les gens oublient.

La leçon vaut pour toute migration : la redirection fait partie du renommage, ce n'est pas une tâche qui vient après. Quand les deux sont séparés, quelqu'un finit par renommer une page un vendredi et la redirection arrive le lundi, si elle arrive. Si votre déménagement ajoute aussi des langues, notre guide des sites multilingues couvre les choix de structure d'URL difficiles à défaire ensuite, et l'arborescence couvre l'arbre de pages que le plan de redirections doit suivre.