Migration de site : ne pas perdre son référencement

Une migration de site déplace un site web vers un nouveau nom de domaine, une nouvelle structure d'URL, une nouvelle plateforme ou un nouvel hébergement. Le référencement ne se perd pas pendant le changement lui-même : il se perd sur les adresses d'origine laissées sans redirection 301, que Google traite alors comme des pages introuvables.

Toutes les migrations ne touchent pas au référencement

Le mot recouvre des opérations très différentes, et seules certaines déplacent des adresses. Identifier le cas exact est l'élément qui commande tout le reste : le travail nécessaire n'a rien de commun entre un changement d'hébergement et un changement de nom de domaine, et annoncer à un client une refonte sans distinguer les deux mène droit à la mauvaise estimation.

• Changement de nom de domaine : toutes les URL changent. C'est le cas le plus lourd, et le seul qui justifie l'outil de changement d'adresse de la Search Console.
• Passage de HTTP à HTTPS : toutes les URL changent aussi, même si le chemin reste identique. Google traite les deux protocoles comme deux sites web distincts.
• Réorganisation de l'arborescence : le domaine ne bouge pas, les chemins oui. Une refonte s'accompagne presque toujours de ce changement.
• Changement de plateforme : passer de WordPress à PrestaShop, ou l'inverse, réécrit les adresses selon les conventions du nouveau logiciel, avec ou sans barre finale, avec ou sans identifiant numérique.
• Changement d'hébergement seul : les adresses restent les mêmes. Le risque est ailleurs, dans la coupure de service et dans la perte de performance si le nouvel hébergeur est moins rapide que le précédent.
• Refonte graphique seule : rien ne bouge côté adresses, mais le contenu textuel et le maillage interne peuvent disparaître sans que personne s'en aperçoive.

Un projet réel combine souvent plusieurs de ces cas. Une entreprise qui refait son site change en général de plateforme, d'arborescence et parfois de nom de domaine dans la même opération, ce qui multiplie les points de contrôle plutôt que de les additionner. Chaque cas se traite séparément, avec sa propre liste de vérifications, et l'impact sur la visibilité n'est pas du tout le même selon la combinaison retenue.

Un inventaire complet des adresses, avant toute chose

Le travail commence sur le site actuel, tant qu'il répond. Une seule source d'URL ne suffit jamais : chacune a son angle mort, et les adresses oubliées sont exactement celles qui répondront en erreur après la migration.

Cinq sources à croiser

• Un crawl complet avec Screaming Frog, Sitebulb ou l'équivalent. Il donne ce qui est atteignable depuis la navigation, donc pas les contenus orphelins.
• L'export de la Search Console, onglet Performances puis Pages, sur seize mois. Il donne les adresses que Google montre réellement, orphelines comprises.
• Le sitemap XML actuel, qui contient parfois des URL que le crawl ne trouve plus.
• Les journaux du serveur sur trois mois. Ils révèlent les adresses que les robots d'exploration visitent encore et celles qui reçoivent des visiteurs depuis des liens externes anciens.
• L'export des liens entrants depuis un outil comme Ahrefs, Majestic ou la Search Console. Une URL qui reçoit des liens vaut bien plus qu'un contenu interne quelconque.

La fusion de ces cinq listes donne systématiquement plus d'adresses que prévu. Sur un site d'une centaine de pages visibles, il n'est pas rare d'aboutir à trois ou quatre cents URL réellement connues des moteurs de recherche, entre la pagination, les fichiers PDF, les images indexées, les versions archivées d'articles et les paramètres de suivi.

Trois colonnes qui décident des priorités

Toutes ces adresses ne méritent pas la même attention. Trois chiffres suffisent à les classer : le nombre de clics sur douze mois, le nombre de domaines qui pointent vers elles, et le classement moyen sur leur requête principale. Les vingt ou trente premières lignes de ce tableau concentrent en général l'essentiel de la valeur du site, et leur correspondance doit être irréprochable. Le reste se traite par lots, avec des règles générales plutôt qu'une décision unitaire.

La table de correspondance, une adresse par ligne

Le livrable central d'une migration réussie tient dans un tableur : ancienne adresse, nouvelle adresse, code de redirection prévu, motif du choix. Ce document se relit, se corrige et se rejoue ; une règle posée directement dans la configuration du serveur sans trace écrite ne se vérifie plus.

Quatre situations se présentent. La correspondance un pour un couvre la majorité des cas : le contenu existe des deux côtés, seule son adresse change. La correspondance plusieurs vers une intervient quand la refonte fusionne des contenus trop courts ; les adresses d'origine pointent alors toutes vers celle qui les remplace. Le cas sans équivalent demande un arbitrage : on vise la rubrique parente, jamais la page d'accueil, car une redirection vers une destination hors sujet vaut une erreur 404 déguisée, et l'utilisateur venu chercher une information précise quitte le site dans la seconde.

Le quatrième cas est celui des contenus qu'il faut assumer de supprimer. Une fiche produit définitivement retirée, une opération commerciale périmée ou un texte que l'on ne veut plus servir ne se redirigent pas : ils répondent 410, ce qui indique une suppression volontaire et accélère leur sortie de l'index par rapport à une erreur 404 ordinaire.

Choisir le bon code de redirection

Le réflexe consiste à tout basculer en 301 sans se poser de question. C'est le bon choix dans neuf cas sur dix, mais les autres codes existent et se justifient dans des situations précises.

La redirection par balise meta refresh et celle réalisée en JavaScript fonctionnent visuellement mais dépendent du rendu de la page. Sur une opération de cette importance, la règle se configure au niveau du serveur, où elle s'applique avant même que le navigateur reçoive quoi que ce soit.

Poser les règles sans fabriquer de chaînes

Sur Apache, les règles vivent dans le fichier .htaccess ou dans la configuration du site. Sur Nginx, elles prennent la forme de directives return ou rewrite. Les hébergements mutualisés et les extensions de CMS proposent des interfaces de gestion plus simples, au prix d'un temps de chargement supplémentaire à chaque requête, puisque la règle est alors évaluée par le logiciel et non par le serveur web.

Trois défauts reviennent dans presque tous les projets. La chaîne de redirections apparaît quand une adresse renvoie vers une deuxième, elle-même redirigée vers une troisième, souvent parce qu'une opération précédente n'a jamais été nettoyée. Chaque saut ralentit l'affichage et complique l'exploration. La table de correspondance doit donc viser la destination finale, pas l'étape intermédiaire.

La boucle survient lorsque deux règles se contredisent, typiquement l'une qui ajoute la barre finale et l'autre qui la retire. Le navigateur abandonne après une vingtaine d'allers-retours et le contenu devient inaccessible. Le test se fait avec la commande curl en refusant de suivre les redirections, ce qui rend le code brut et la destination annoncée.

La règle trop large est la plus sournoise. Une expression régulière écrite pour un lot d'adresses attrape parfois des URL qui n'ont rien à y faire, y compris les fichiers du nouveau site. Une règle qui redirige tout un répertoire doit être vérifiée sur une dizaine d'adresses réelles avant d'être considérée comme acquise, et non sur le seul exemple qui a servi à l'écrire.

Deux détails achèvent la liste : la casse des adresses, souvent significative sur les serveurs Linux, et la présence ou l'absence de barre finale, qui fait de /contact et /contact/ deux URL différentes tant qu'aucune règle ne les réunit.

Préparer le nouveau site avant la bascule

Le nouveau site se construit sur un environnement de préproduction fermé, protégé par une authentification plutôt que par un simple fichier robots.txt : une adresse de test qui fuite et se retrouve indexée crée un doublon exact du site à venir. Cet environnement sert à jouer l'intégralité de la table de correspondance avant la bascule, et non à les découvrir alors que le site est déjà public.

La vérification la plus rentable ne prend que quelques secondes : chercher les balises noindex laissées par l'environnement de test. Un site fraîchement mis en production avec cette balise reste invisible, et le problème passe souvent inaperçu pendant deux ou trois semaines parce que rien d'autre ne semble anormal.

Le contenu qui se positionne déjà se reprend tel quel plutôt que d'être réécrit dans la foulée. Une migration modifie l'adresse, pas le texte ; mener les deux chantiers en même temps rend impossible d'attribuer une baisse de trafic à l'un ou à l'autre. La réécriture éditoriale se planifie plusieurs semaines après, une fois le classement stabilisé, et c'est aussi le bon moment pour retravailler les contenus les plus faibles.

Le maillage interne, lui, se reconstruit intégralement. Les liens qu'un site tisse entre ses contenus au fil des années portent une partie de son positionnement, et une refonte partant d'une navigation vierge les efface d'un coup. Les mêmes vérifications s'appliquent à la hiérarchie des titres, aux balises title et aux métadonnées de description, aux données structurées et aux attributs hreflang si le site existe en plusieurs versions linguistiques.

Deux éléments techniques méritent une attention particulière. Les images changent souvent d'adresse lors d'un changement de plateforme, et celles qui apparaissent dans la recherche par images perdent alors leur historique si aucune règle ne les couvre. Le temps de chargement, ensuite, se mesure avant et après : une plateforme plus moderne n'est pas mécaniquement plus rapide, et il serait dommage de perdre en performance ce que la refonte devait améliorer. La mesure des Core Web Vitals sur les deux versions donne un point de comparaison objectif.

Le cas particulier d'une boutique en commerce électronique

La migration d'un site marchand ajoute une couche de difficulté que les guides généralistes passent sous silence. Les URL de fiches produit portent souvent un identifiant technique généré par la plateforme, qui ne se retrouve pas à l'identique sur la nouvelle : la correspondance ne peut donc pas se déduire du chemin, elle se construit à partir de la référence du produit exportée depuis la base.

Trois éléments propres au commerce demandent une décision explicite. Les pages de catégorie filtrées, qui multiplient les adresses par les couleurs et les tailles, se traitent par une règle générale plutôt qu'une par une. Les produits épuisés ne se suppriment pas : tant qu'ils reçoivent des visites, ils redirigent vers un article équivalent ou restent en place avec une mention de rupture. Les avis clients, enfin, se migrent avec leurs dates et leurs auteurs, faute de quoi les étoiles affichées dans les résultats de recherche disparaissent sans préavis.

Le flux marchand envoyé aux comparateurs et aux régies publicitaires contient les adresses d'origine. Il se régénère le jour de la bascule, sans quoi chaque clic acheté passe par une redirection, ce qui dégrade le suivi des conversions et l'expérience d'achat. Le même contrôle vaut pour les campagnes en cours et pour les liens présents dans les messages automatiques envoyés à la clientèle.

Ce que la migration change pour l'exploration

Google n'explore pas un site d'un bloc. Il répartit ses visites selon un rythme qu'il ajuste en fonction de la fréquence de modification et de la capacité du serveur à répondre. Une migration lui impose de redécouvrir l'ensemble des adresses, ce qui consomme ce budget d'exploration bien plus vite que d'ordinaire.

Trois actions accélèrent l'indexation des nouvelles URL. Le sitemap XML se régénère et se soumet dès la bascule, en n'y déclarant que les adresses finales, jamais celles qui redirigent. Le fichier robots.txt se relit ligne par ligne : une directive de blocage héritée de la préproduction annule tout le reste du travail. Les données structurées, enfin, se vérifient avec l'outil de test des résultats enrichis, car un changement de plateforme les réécrit systématiquement.

Un sitemap temporaire contenant les adresses d'origine est parfois recommandé pour hâter la découverte des redirections. La méthode fonctionne, à condition de le retirer une fois le transfert effectué : le laisser en place revient ensuite à déclarer comme valides des URL qui n'existent plus. Nos repères sur le référencement naturel détaillent la façon dont ces signaux se combinent une fois le site stabilisé.

Le suivi et les services connectés au site

Un site web moderne ne vit pas seul : il dialogue avec un outil de mesure d'audience, une régie publicitaire, un service d'envoi de messages, parfois une fiche d'établissement et un module de paiement. Chacun de ces services connaît le site par son adresse, et chacun demande donc à être vérifié après le changement.

La liste est courte mais elle s'oublie facilement. L'outil d'analyse d'audience doit être reconfiguré si le domaine change, faute de quoi la mesure s'arrête sans aucun message d'erreur. Les objectifs et les conversions déclarés sur des adresses précises se réécrivent une à une. Le bandeau de consentement, souvent lié au domaine, se paramètre à nouveau. Dans la Search Console, une propriété correspondant au nouveau nom de domaine se crée et se valide avant la bascule, pas après, pour ne pas perdre les premiers relevés.

Les fonctionnalités qui reposent sur une extension du CMS méritent la même vigilance : formulaire de contact, moteur de recherche interne, espace client, connexion à un logiciel de gestion. Elles se testent une par une sur le nouvel environnement, en conditions réelles, avec un envoi effectif et non une simple ouverture de la page. Un formulaire qui ne délivre plus les messages est un dégât commercial immédiat, sans rapport avec le référencement mais bien plus coûteux à court terme.

Une équipe qui prépare cette liste avant la bascule y consacre une demi-journée. La même liste reconstituée après coup, service par service, à mesure que les défauts se signalent, prend plusieurs semaines et laisse des trous. C'est un avantage évident à la planification, et probablement le seul point du projet où l'ordre des tâches change réellement le résultat final.

Le jour de la bascule

Quarante-huit heures avant, la durée de vie des enregistrements DNS se réduit à cinq minutes. Sans cette précaution, un changement de serveur met parfois vingt-quatre heures à se propager, avec des visiteurs envoyés vers le serveur d'origine et d'autres vers la nouvelle, sans moyen de savoir qui voit quoi.

L'ordre des opérations compte. On retire la protection de la préproduction et les balises noindex, on vérifie que le fichier robots.txt du nouveau site n'interdit rien d'important, on bascule les enregistrements DNS, puis on active les règles de redirection. Une sauvegarde complète du site actuel, base de données comprise, se prend juste avant : c'est le seul moyen de revenir en arrière si un défaut majeur apparaît, et une raison de plus de connaître ce que la sauvegarde de l'hébergeur couvre réellement.

L'ancien serveur reste allumé. Tant qu'il porte les règles de redirection, il transmet ce qu'il doit transmettre ; l'éteindre trop tôt transforme l'ensemble du travail en erreurs 404. La recommandation courante est de le conserver un an au minimum, et davantage si le site a une longue histoire.

Dans le seul cas d'un changement de nom de domaine, la Search Console propose un outil dédié qui accélère le transfert. Il exige que les deux propriétés soient vérifiées et que les redirections soient déjà en place. Il ne dispense d'aucune des étapes précédentes et n'a aucun effet lors d'une simple réorganisation de l'arborescence, où il n'est d'ailleurs pas proposé.

Les trente jours qui suivent

La surveillance des premières heures porte sur trois indicateurs simples : le code renvoyé par les vingt adresses les plus importantes, le nombre d'erreurs dans les journaux du serveur, et la proportion de contenus servis correctement aux robots. Un contrôle par lot de la table de correspondance entière se relance chaque soir de la première semaine.

Le rapport d'indexation de la Search Console met une bonne semaine à refléter la nouvelle situation. Les adresses d'origine y apparaissent progressivement comme redirigées, et les nouvelles comme explorées puis indexées. Ce basculement s'étale sur trois à six semaines pour un site de taille moyenne, plus longtemps pour un site de plusieurs milliers d'URL.

Une baisse de trafic pendant deux à quatre semaines est fréquente, même sur une opération correctement menée. Ce qui doit alerter tient en trois signaux : une chute qui dépasse nettement ce délai, une chute concentrée sur les contenus historiquement les mieux placés plutôt que répartie, ou l'apparition d'adresses d'origine en erreur dans le rapport d'indexation. Dans les trois cas, la table de correspondance est le premier document à relire.

Une annotation datée dans l'outil de mesure d'audience évite bien des malentendus six mois plus tard, quand personne ne se souvient de la date exacte du changement. Le suivi des positions sur les requêtes principales, relevé chaque semaine, complète utilement les données de fréquentation : le trafic peut baisser pour des raisons saisonnières sans qu'aucun classement ne bouge.

Qui fait quoi, et selon quel calendrier

Une migration de site web se pilote à trois ou quatre personnes au maximum, avec des responsabilités écrites. Le développement du nouveau site, la gestion des redirections et le suivi de la visibilité relèvent rarement de la même personne, et le défaut le plus courant d'organisation consiste à supposer que quelqu'un d'autre s'occupe de l'inventaire des adresses.

La planification tient en quatre jalons. Un mois avant l'échéance, l'inventaire et la table de correspondance sont terminés. Une semaine avant, les redirections sont configurées et vérifiées sur la préproduction. Le jour J, la bascule suit l'ordre défini plus haut. Un mois après, un bilan compare le trafic, le classement et les erreurs relevées avec la situation de départ.

Le recours à une agence ou à un expert externe se justifie surtout sur l'inventaire et sur la relecture du plan de redirections, deux tâches où l'expérience évite les oublis coûteux. Le reste, y compris la création du nouveau site, peut parfaitement être mené par une équipe interne dès lors que la table de correspondance existe et qu'elle est maintenue.

Une dernière tâche est presque toujours oubliée : informer. Les liens présents dans les profils de réseaux sociaux, les signatures de messagerie, les documents commerciaux et les annuaires professionnels pointent vers les adresses d'origine. Les redirections les couvrent, mais un lien corrigé vaut mieux qu'un lien redirigé, et la correction ne demande que quelques minutes par support.

Six questions fréquentes sur la migration d'un site

Comment migrer un site sans perdre son référencement ?

En relevant toutes les URL du site actuel avant la bascule, en posant une redirection 301 par adresse vers le contenu qui la remplace le mieux, en conservant le contenu et le maillage interne des pages qui se positionnent, et en laissant les règles actives pendant au moins un an.

Quelles étapes suivre pour une migration réussie ?

Six étapes : identifier le type de changement, inventorier les adresses à partir de cinq sources, construire la table de correspondance, tester les redirections sur un environnement fermé, basculer dans un ordre défini, puis surveiller pendant un mois.

Quels sont les risques d'une migration de site ?

Les adresses oubliées qui répondent en erreur, les redirections envoyées vers la page d'accueil, les chaînes et les boucles de redirection, la balise noindex de la préproduction laissée en place, la perte du maillage interne et l'extinction trop rapide du serveur d'origine.

Combien de temps dure la perte de trafic après une migration ?

De deux à quatre semaines dans un cas normal, le temps que Google réexplore le site et transfère les signaux vers les nouvelles adresses. Au delà de six à huit semaines sans retour, il faut chercher un défaut technique plutôt qu'attendre.

Faut-il utiliser l'outil de changement d'adresse de la Search Console ?

Uniquement lors d'un changement de nom de domaine, et après avoir posé les redirections. Il n'est ni proposé ni utile pour une réorganisation de l'arborescence sur le même domaine.

Quels outils sont nécessaires pour préparer une migration ?

Un logiciel de crawl comme Screaming Frog, la Search Console pour l'export des adresses, un tableur pour la table de correspondance, la commande curl pour tester les codes renvoyés, et un accès aux journaux du serveur.

Les erreurs qui coûtent le plus cher

Après plusieurs projets, les mêmes fautes reviennent, et aucune n'est difficile à éviter. Elles coûtent cher parce qu'elles se découvrent tard, souvent quand la baisse de trafic devient visible dans les chiffres du mois.

• Tout renvoyer vers la racine du site. C'est la faute la plus répandue et la plus chère : les signaux ne se transmettent pas, et l'expérience de l'utilisateur qui cherchait un contenu précis est mauvaise.
• Lancer la migration et la refonte éditoriale le même jour. Aucune analyse ultérieure ne pourra plus distinguer les effets de l'une et de l'autre.
• Oublier les sous-domaines, les fichiers PDF et les images. Ils sont indexés au même titre que le reste et disparaissent silencieusement de la liste.
• Ne pas prévenir les sites qui font un lien vers vous. Une redirection fonctionne, mais un lien corrigé vers la nouvelle adresse vaut mieux, au moins pour les dix domaines les plus importants.
• Considérer la migration comme terminée au moment de la bascule. Le vrai travail commence là, et il occupe encore quelques heures par semaine pendant un mois.

Une migration de site bien préparée n'est pas un pari. Elle demande un inventaire honnête, un document de correspondance tenu à jour et une période de surveillance, soit un travail de quelques jours réparti sur deux mois. Les projets qui échouent sont presque toujours ceux où cette préparation a été compressée pour tenir une date de mise en production annoncée trop tôt.