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

Le jour de la bascule, ce n’est pas le site qui casse. C’est ce qui pointait vers lui.

Une migration ratée ne se voit pas tout de suite. Le site est en ligne, il est plus beau, tout le monde se félicite. La perte apparaît deux à six semaines plus tard, quand les pages qui rapportaient des demandes ont disparu des résultats et que personne ne sait dire lesquelles, parce que personne n’avait noté ce qui existait avant.

Ce texte décrit ce qui se perd réellement, ce que la documentation de Google établit noir sur blanc, et la partie du travail qui se fait avant de toucher à quoi que ce soit.

Qu’est-ce qu’une migration de site ?

Une migration de site est toute opération qui modifie l’adresse, l’infrastructure ou la structure d’un site existant déjà connu des moteurs de recherche. À la différence d’une création, qui part de rien, elle hérite d’un capital : des positions acquises, des liens entrants, des adresses partagées dans des emails et des documents. C’est ce capital qu’elle met en jeu.

Le mot recouvre cinq opérations très différentes, qui n’appellent pas le même traitement. Les confondre est la première cause de travail inutile, et parfois de dégât.

Le passage de HTTP à HTTPS. Les URL changent techniquement, mais le chemin reste identique. Google demande une redirection permanente vers la version sécurisée, et précise qu’il ne faut pas utiliser l’outil de changement d’adresse dans ce cas.

Le changement de nom de domaine. Le cas le plus lourd, et le seul qui justifie l’outil de changement d’adresse. Tout change, y compris ce que Google sait de votre site.

La refonte de la structure des URL, à domaine constant. Le cas le plus fréquent lors d’une refonte de site : le domaine ne bouge pas, mais les adresses des pages sont réécrites. L’outil de changement d’adresse ne s’applique pas, la table de redirections fait tout le travail.

Le changement d’hébergeur ou la mise en place d’un CDN, sans modification des URL. Google traite ce cas à part : rien ne change pour l’utilisateur ni pour l’index, le risque se situe ailleurs, dans la bascule DNS et la disponibilité.

La fusion de plusieurs sites en un seul. Additionne les difficultés des précédents et ajoute la sienne : plusieurs pages anciennes veulent souvent la même page nouvelle, et il faut arbitrer.

Une refonte réelle en combine souvent deux ou trois. C’est légitime, mais Google formule ici un avertissement qui mérite d’être lu littéralement : sa documentation sur les migrations recommande de ne changer qu’une seule chose à la fois. Changer de domaine, de structure d’URL et de contenu le même jour ne rend pas la migration impossible, mais rend impossible de savoir ce qui a marché et ce qui a cassé.

Ce qui se perd, et ce qui ne se perd pas

Commençons par démonter une croyance tenace, parce qu’elle oriente de mauvaises décisions.

Une redirection permanente ne fait pas perdre de valeur. La documentation de Google l’écrit sans ambiguïté : les redirections 301 et les autres redirections permanentes n’entraînent pas de perte de PageRank. L’idée qu’un pourcentage se dissiperait à chaque saut a circulé pendant des années, elle n’est pas exacte, et elle pousse à éviter des redirections qu’il faudrait faire.

Ce qui se perd, c’est autre chose, et c’est presque toujours l’une de ces cinq choses.

Les URL qu’on avait oubliées. Elles ne sont pas redirigées, elles tombent en erreur. C’est la première cause de perte, et elle est entièrement évitable.

Les redirections paresseuses. Rediriger cinquante pages disparues vers la page d’accueil est plus rapide que de trouver l’équivalent de chacune. Google traite ces redirections vers une page sans rapport comme des pages introuvables déguisées, et le trafic ne se reporte pas.

Le contenu qui a changé en même temps. Une page dont l’adresse et le texte changent le même jour n’est plus la même page. La redirection fonctionne, mais la page d’arrivée ne répond plus à la question qui amenait les visiteurs.

Les liens entrants qui pointent dans le vide. Ils continuent de fonctionner tant que la redirection existe. Ils cessent le jour où elle est retirée, souvent des années plus tard, par quelqu’un qui ne sait pas pourquoi ces lignes sont là.

Ce qui n’a rien à voir avec le référencement. Les pages de destination de vos campagnes publicitaires, les liens dans vos signatures d’email, les QR codes imprimés sur vos plaquettes, les liens dans vos anciennes newsletters. Cette catégorie ne se voit dans aucun outil de référencement, et elle coûte immédiatement.

Ce que les études disent, et ce qu’elles ne disent pas

Vous lirez des chiffres alarmants sur les migrations. La plupart n’ont aucune source. Deux études publient leur méthodologie, et il vaut la peine de comprendre pourquoi elles semblent se contredire.

La première, publiée par Search Engine Journal en janvier 2025, porte sur 892 migrations de domaine, avec des données arrêtées au 22 octobre 2024. Son résultat le plus cité : il a fallu en moyenne 523 jours pour que le nouveau domaine retrouve le niveau de trafic organique de l’ancien, et 17 % des migrations de l’échantillon n’avaient toujours pas récupéré après mille jours. Les récupérations les plus rapides observées se comptent en revanche en semaines : 19, 22, 23 et 33 jours.

La seconde, publiée par SALT.agency en juin 2026, porte sur 1 052 migrations et raisonne autrement : elle mesure la part des migrations qui ont récupéré à chaque échéance. Environ 22,8 % récupèrent en 90 jours, la proportion continuant de monter au fil des mois.

Ces deux résultats ne se contredisent pas, ils décrivent deux choses différentes. La moyenne de 523 jours est tirée vers le haut par les migrations qui ne récupèrent jamais, tandis que la distribution cumulée montre qu’une part significative des cas se règle en quelques mois. Une moyenne calculée sur une distribution où une partie des cas ne converge pas n’est pas une prévision, c’est un indicateur de dispersion.

Il faut ajouter une limite que les deux études assument mais que leurs reprises omettent toujours : le trafic y est estimé par des outils tiers, pas mesuré. Un outil qui estime le trafic organique à partir de positions et de volumes de recherche modélisés ne voit pas la même chose qu’une Search Console. Ces travaux donnent un ordre de grandeur du risque, ils ne donnent pas le vôtre.

Ce qui est en revanche documenté par Google, et qui vous concerne directement : le traitement se fait URL par URL, et un site de petite ou moyenne taille demande quelques semaines pour que la majorité de ses pages bascule dans l’index. Une migration n’est considérée comme aboutie que lorsque Googlebot a visité chaque URL de l’ancien et du nouveau site au moins une fois.

L’inventaire, qui se fait avant de toucher au site

C’est l’étape que les projets sautent, et c’est la seule qui soit irréversible : une fois l’ancien site éteint, les informations qui n’ont pas été relevées sont perdues.

Il ne s’agit pas de lister les pages du menu. Il s’agit de recenser tout ce qui répond à une adresse, et les sources se complètent parce qu’aucune n’est exhaustive.

L’export de la Search Console sur douze mois. Il donne les pages qui reçoivent effectivement des visites depuis Google, avec leur volume. C’est la base de la hiérarchisation : toutes les pages ne méritent pas le même soin.

La liste des pages indexées. Elle contient des URL que vous avez oubliées, des versions paginées, des pages de filtres, d’anciennes campagnes.

Les pages qui reçoivent des liens entrants. Ce sont les plus précieuses et souvent les plus anciennes. La Search Console les liste, et cette liste sert deux fois : pour les redirections, puis pour écrire aux sites concernés.

Le fichier sitemap actuel, et l’ancien s’il en existe un.

Les journaux du serveur, si vous pouvez les obtenir. C’est la seule source qui montre les URL réellement demandées, y compris celles qu’aucun outil ne connaît.

Les fichiers. Documents à télécharger, images appelées par des sites tiers, tout ce qui n’est pas une page HTML mais possède une adresse.

Les redirections déjà en place. Un site refondu une fois l’a souvent été deux fois. Ces règles existantes doivent être reprises, sans quoi vous créerez des chaînes.

Les destinations hors référencement. Vos campagnes publicitaires actives, vos séquences d’emails, vos profils sur les annuaires, vos codes QR imprimés. Cette liste ne sort d’aucun outil, elle se constitue en interrogeant les personnes concernées.

Ce travail produit un tableau unique. Pour chaque adresse : son trafic, ses liens, sa destination future, et une décision. Car toutes les pages ne doivent pas survivre : une migration est aussi l’occasion de supprimer ce qui ne sert plus, à condition que ce soit une décision et non un oubli.

La table de redirections, et ses trois pannes mécaniques

Une table de redirections associe chaque ancienne adresse à sa nouvelle. La règle tient en une phrase : chaque URL rejoint la page qui répond à la même intention, et à défaut d’équivalent, la page de niveau supérieur la plus proche.

Trois pannes reviennent systématiquement, et leur particularité est d’être détectables mécaniquement. Aucune ne demande de jugement, ce qui veut dire qu’aucune ne devrait survivre à une vérification sérieuse.

La chaîne. L’ancienne page A redirige vers B, qui redirige vers C. Googlebot suit jusqu’à dix sauts dans une chaîne, mais Google recommande de rester idéalement sous trois et en tout cas sous cinq. Les chaînes naissent presque toujours d’une refonte antérieure dont les règles n’ont pas été reprises. La correction est simple : faire pointer A directement vers C.

La boucle. A redirige vers B, qui redirige vers A. La page devient inatteignable pour tout le monde. C’est rare mais radical, et cela se détecte en une formule.

La cible qui n’existe pas. La redirection fonctionne parfaitement et aboutit à une page introuvable. C’est la panne la plus fréquente des tables construites à la main, parce qu’elle survient quand la structure du nouveau site évolue après l’écriture de la table.

Une quatrième erreur n’est pas mécanique mais coûte autant : utiliser une redirection temporaire là où il fallait une permanente. La distinction n’est pas cosmétique. Google traite la redirection permanente comme un signal indiquant que la cible doit devenir l’adresse de référence ; la redirection temporaire ne porte pas ce signal. Dans une migration, sauf cas particulier, toutes les redirections sont permanentes.

Deux mécanismes sont à éviter, dans cet ordre. La redirection par balise meta refresh fonctionne, mais Google ne la considère comme permanente que si le délai est nul. La redirection en JavaScript ne doit être utilisée qu’en dernier recours, quand ni le serveur ni la balise ne sont accessibles.

La fenêtre de 180 jours que personne ne mentionne

Voici le point le plus mal connu, et il ne concerne qu’un seul cas : le changement de nom de domaine.

L’outil de changement d’adresse de la Search Console indique à Google de donner la priorité au crawl du nouveau site et transfère divers signaux de l’ancien vers le nouveau. Mais la documentation officielle précise une limite que presque aucun guide ne reprend : ces actions interviennent pendant une durée de 180 jours. Et au terme de cette période, Google ne reconnaîtra plus aucune relation entre l’ancien et le nouveau site, et considérera l’ancien comme un site à part entière.

Mettez ce fait à côté d’un second. Gary Illyes, chez Google, a recommandé publiquement de conserver les redirections au moins un an pour que l’ensemble des signaux soit transféré, tout en conseillant de les garder indéfiniment pour les visiteurs.

Les deux durées ne se contredisent pas, elles portent sur des objets différents : la première est la durée de vie d’un signal administratif, la seconde la durée nécessaire au transfert effectif. La conséquence pratique est simple. La déclaration expire, pas la redirection. Retirer les redirections au bout de six mois parce que la fenêtre de la Search Console est close revient à couper le pont pendant la traversée.

Notre position sur ce sujet est plus tranchée encore : une redirection ne se retire pas. Elle coûte quelques lignes de configuration, et des liens vers vos anciennes adresses existeront encore dans des documents, des emails et des sites tiers dans dix ans.

Rappelons enfin les quatre situations où cet outil ne doit pas être utilisé, parce que l’employer à tort fait perdre du temps : le passage de HTTP à HTTPS, le déplacement de pages à l’intérieur d’un même domaine, le passage de www à sans www, et la migration sans changement d’URL visible.

Tout d’un coup, ou par lots ?

Le conseil répandu est de migrer progressivement, section par section, pour limiter le risque. Pour un site de PME, c’est un mauvais conseil, et Google écrit l’inverse.

Sa documentation recommande, pour un site de petite ou moyenne taille, de déplacer toutes les URL simultanément plutôt qu’une section à la fois, parce que cela aide ses algorithmes à détecter la migration plus rapidement.

La raison est mécanique. Une migration progressive maintient pendant des semaines un état hybride où les deux structures coexistent, où les liens internes pointent tantôt vers l’ancienne tantôt vers la nouvelle, et où chaque anomalie constatée peut avoir trois causes. Le conseil de progressivité vient du monde des très grands sites, où le volume d’URL impose de composer avec la capacité de crawl. Appliqué à deux cents pages, il allonge la période d’incertitude sans réduire le risque.

Ce qui doit être progressif, en revanche, c’est la préparation. La table de redirections se construit et se teste des semaines à l’avance, sur une préproduction. La bascule, elle, est un moment court.

Le piège de la préproduction

Une erreur mérite d’être isolée parce qu’elle survient dans presque tous les projets, qu’elle est invisible et qu’elle a deux versions, symétriques et également graves.

Version un : le site de préproduction se retrouve indexé. L’équipe croit l’avoir protégé en le bloquant dans le fichier robots.txt. Or Google documente le fait suivant : si une page est bloquée par robots.txt, le robot ne peut jamais lire la directive noindex qu’elle contient, et la page peut donc apparaître dans les résultats si des liens externes pointent vers elle. Les deux mécanismes s’annulent. Pour protéger une préproduction, il faut une protection par mot de passe au niveau du serveur, pas une interdiction de crawl.

Version deux, plus coûteuse : le blocage part en production avec le site. Le nouveau site est en ligne, il est parfait, et il porte encore la directive qui interdit son indexation. Personne ne s’en aperçoit pendant deux semaines, parce que rien ne semble anormal : le trafic baisse, ce qu’on attendait d’une migration.

Ces deux erreurs partagent une cause : la configuration d’indexation n’est jamais dans la liste de ce qu’on vérifie, parce qu’elle n’est visible nulle part dans l’interface du site. Elle doit figurer explicitement dans la recette, en premier point.

Trois cas particuliers qui compliquent tout

Les principes ci-dessus couvrent la majorité des refontes. Trois situations demandent un traitement supplémentaire, et elles sont assez fréquentes pour mériter d’être nommées.

La fusion de deux sites. Elle survient après un rachat, ou quand une entreprise décide de réunir un site principal et un site satellite créé pour une gamme. La difficulté propre à ce cas est qu’il n’y a plus de correspondance page à page : deux pages différentes veulent souvent la même destination. Une seule règle tient : la page qui reçoit doit couvrir les deux sujets, sinon la moitié du trafic redirigé arrive sur un contenu qui ne répond pas à sa question. Concrètement, la fusion impose de réécrire les pages d’arrivée avant de rediriger, pas après. C’est du travail éditorial, pas du travail technique, et c’est presque toujours ce poste qui manque au devis.

Le passage d’un sous-domaine à un dossier. Beaucoup de sites hébergent leur blog sur un sous-domaine, puis décident de le ramener dans le site principal. L’opération est saine, mais il faut savoir que Google traite un sous-domaine comme une entité largement distincte : la Search Console suit des propriétés séparées, et l’outil de changement d’adresse ne migre pas les sous-domaines automatiquement. Il faut donc déclarer, vérifier et surveiller chaque périmètre séparément, sous peine de croire que tout va bien en ne regardant que la moitié du site.

Le site multilingue. Les annotations de langue sont l’élément le plus silencieux de toute migration. Elles ne provoquent aucune erreur visible quand elles cassent : le site fonctionne, les pages s’affichent, et Google se met simplement à proposer la mauvaise version linguistique aux visiteurs, ou à considérer deux versions comme des doublons. La documentation Google demande explicitement de mettre à jour ces annotations vers les nouvelles adresses. C’est la vérification la plus facile à oublier et la plus difficile à diagnostiquer trois mois plus tard.

Une quatrième situation mérite d’être signalée sans être un cas technique : la migration qui accompagne un changement de nom d’entreprise. Elle cumule le changement de domaine et la réécriture des contenus, ce qui contrevient au principe de ne changer qu’une chose à la fois. Elle est pourtant rarement évitable, puisque garder l’ancien nom sur le nouveau site n’aurait pas de sens. Dans ce cas, la seule protection consiste à figer tout le reste : ne pas en profiter pour refondre la structure, ne pas changer de technologie, ne pas revoir l’arborescence. Le nom et le domaine changent, le reste attend six mois. Les questions propres au domaine lui-même, détention, expiration et variantes, sont traitées dans nom de domaine, choisir, garder et en changer.

Qui fait ce travail, et ce qu’il faut écrire dans la commande

C’est la question qui décide du résultat, et elle se règle avant la signature.

Le plan de redirections n’est presque jamais inclus dans un devis de refonte, sauf mention explicite. Il n’y a là aucune malveillance : beaucoup de prestataires chiffrent la création d’un site, pas la conservation d’un capital dont ils ne connaissent pas l’ampleur. Le résultat est le même, cependant, et il se découvre tard : à trois jours de la mise en ligne, quand quelqu’un demande qui s’occupe des anciennes adresses.

Quatre lignes suffisent à couvrir le sujet dans une commande.

L’inventaire des adresses existantes, avec sa source. Précisez qui le produit et à partir de quoi. Un inventaire limité aux pages du menu n’est pas un inventaire.

La table de redirections, avec un critère de complétude. La formulation utile n’est pas « mettre en place les redirections » mais « chaque adresse de l’inventaire dispose d’une destination, et aucune ne pointe vers la page d’accueil par défaut ». Le premier libellé se satisfait de dix règles, le second oblige à traiter la totalité.

La recette avant mise en ligne, avec ses points de contrôle. Notamment la vérification de la directive d’indexation, qui doit figurer en toutes lettres. Elle prend une minute et évite deux semaines d’invisibilité.

La durée de maintien des redirections, et à qui elles appartiennent. Ce point rejoint une question plus large, celle de la propriété de ce qui est produit, que nous traitons dans ce qu’un prestataire lit dans un cahier des charges. Une table de redirections vit dans la configuration du serveur ou du CMS. Si vous changez de prestataire dans deux ans, elle doit vous suivre : elle fait partie de ce que vous avez payé.

Un mot sur le prix, sans chiffre. Ce travail se facture, et il doit se facturer, parce qu’il représente des heures réelles : l’inventaire, les arbitrages page par page, les tests. Un prestataire qui l’annonce et le chiffre vous dit quelque chose d’utile sur sa manière de travailler. Celui qui répond que « les redirections, c’est automatique » vous en dit tout autant. Aucun outil ne devine qu’une page sur les délais de livraison doit rejoindre la nouvelle page sur la logistique : cette décision se prend, elle ne se calcule pas.

Enfin, une remarque sur le calendrier de la commande. Le plan de redirections gagne à être posé avant que l’arborescence du nouveau site ne soit validée, et non après. Une fois que la structure est figée, il ne reste plus qu’à faire correspondre l’ancien monde au nouveau, avec les cas impossibles que cela produit. Quand les deux sont pensés ensemble, il arrive souvent qu’une page du nouveau site soit ajoutée précisément parce qu’une ancienne page rapportait des demandes et méritait un équivalent. C’est la différence entre subir l’héritage et s’en servir.

Les trente jours suivants

Une migration ne se termine pas à la bascule. Ce qui suit tient en quatre surveillances, à intervalle rapproché puis espacé.

Les erreurs. Chaque adresse qui renvoie une erreur est soit une URL oubliée, soit une redirection vers une cible inexistante. Dans les deux cas, la correction est immédiate et le coût de l’attente est réel.

La couverture d’indexation. Le nombre de pages connues de Google doit monter côté nouveau site et descendre côté ancien, de manière symétrique. Une asymétrie durable signale un problème d’accès, pas un retard.

Le trafic par page, pas en global. Un total qui baisse de 15 % ne dit rien. Le même total réparti différemment, avec trois pages qui ont perdu 80 %, dit exactement où regarder. La comparaison se fait page par page, ancienne contre nouvelle.

Les destinations publicitaires et les emails. Cette vérification se fait dans l’heure qui suit la bascule, pas dans le mois. Une campagne qui envoie vers une page en erreur consomme un budget en temps réel.

Enfin, un rappel sur le tempo. Google indique qu’un site de petite ou moyenne taille demande quelques semaines pour que la majorité de ses pages bascule. Une baisse dans les quinze premiers jours ne signifie pas que la migration a échoué. Ce qui doit alerter, c’est une baisse qui ne se corrige pas au-delà de six à huit semaines, ou une baisse concentrée sur les pages qui comptaient le plus.

Ce point n’a d’effet que replacé dans le parcours complet, du premier contact au rendez-vous, que décrit tunnel de conversion B2B.

Google recommande d’associer un spécialiste du référencement au plus tôt lors d’une refonte. Les critères de sélection sont réunis dans choisir un prestataire SEO.

En bref

• Une redirection permanente ne coûte pas de référencement. Google documente qu’elle n’entraîne aucune perte de PageRank. Ce qui coûte, ce sont les URL oubliées, les redirections vers la page d’accueil et le contenu réécrit en même temps que l’adresse.
• L’inventaire est la seule étape irréversible. Une fois l’ancien site éteint, ce qui n’a pas été relevé est perdu. Les journaux serveur et les destinations publicitaires en font partie, et aucun outil de référencement ne les donne.
• Trois défauts de la table de redirections se détectent par calcul : la chaîne, la boucle et la cible inexistante. En trouver après la mise en ligne signale une recette qui n’a pas eu lieu.
• L’outil de changement d’adresse ne vaut que pour un changement de domaine, et seulement 180 jours. Passé ce délai, Google ne reconnaît plus aucune relation entre les deux sites. Les redirections, elles, doivent rester en place au moins un an, et en pratique définitivement.
• Pour un site de PME, migrer tout d’un coup. C’est la recommandation explicite de Google pour les sites de petite et moyenne taille. Le conseil inverse s’adresse aux très grands sites.
• Le blocage par robots.txt annule la directive noindex. Une préproduction se protège par mot de passe, jamais par interdiction de crawl.
• Les chiffres qui circulent sur la perte de trafic sont fragiles. Les deux seules études à méthodologie publiée reposent sur du trafic estimé par des outils tiers, et donnent des ordres de grandeur différents parce qu’elles ne mesurent pas la même chose.

Si une refonte est en préparation, le meilleur moment pour poser le plan de redirections est avant que la structure du nouveau site ne soit figée, pas après. Parlons de votre projet, ou découvrez notre approche de la création de site web B2B.

Pour préparer l’amont, deux textes complètent celui-ci : quand refondre un site B2B traite de la décision elle-même, et ce qu’un prestataire lit dans un cahier des charges montre comment inscrire l’inventaire et les redirections dans la commande, avant qu’ils ne deviennent un supplément négocié en cours de projet.