Un client m'appelle un mardi matin, paniqué. Son nouveau site est en ligne depuis six jours. Le trafic organique a chuté de 62 %. Pas une petite baisse saisonnière. Une chute verticale dans les analytics, comme une falaise. On avait pourtant tout préparé, tout vérifié, tout validé. Et pourtant, sa boîte perdait des milliers de visites par jour.
Ce n'était pas le design. Ce n'était pas la vitesse. C'était un robots.txt oublié en préproduction. Six jours perdus, une remontée qui a pris presque cinq semaines. Voilà à quoi ressemble une migration de site web sans perte de référencement quand ça déraille : jamais là où on l'attend.
Une migration, c'est l'opération la plus risquée qu'un site puisse subir. Plus risquée qu'un redesign, plus risquée qu'un changement de stratégie éditoriale. Pourquoi ? Parce qu'on touche à ce que Google a mis des mois, parfois des années, à comprendre. On déplace les murs d'une maison pendant que les habitants y vivent.
Points clés à retenir
- Une chute de -20 % de clics à J+14 dans la Search Console n'est pas un ajustement : c'est une alerte rouge.
- Le plan de redirections 301 ne se construit jamais après la bascule. Jamais.
- Les pages orphelines, paramètres d'URL et hreflang sont les angles morts qui font le plus de dégâts.
- Prévoyez toujours une fenêtre de rollback testée avant de toucher au DNS.
- La reprise complète des positions prend en général entre 2 et 8 semaines, rarement plus si tout est propre.
Pourquoi une migration de site web fait perdre du référencement (et pourquoi ce n'est pas une fatalité)
Le référencement repose sur un contrat implicite : une URL donnée renvoie un contenu donné, de façon stable. Google indexe cette promesse. Quand vous migrez, vous cassez ce contrat. Vous changez soit le domaine, soit la structure, soit les deux. Et à ce moment-là, le moteur doit réapprendre qui vous êtes.
Ce qui se passe concrètement côté moteur : les anciennes URLs sont recrawlées, elles renvoient un statut 301, le signal de PageRank et d'historique est transféré vers la nouvelle adresse, et l'indexation se reconstruit progressivement. Cette reconstruction n'est pas instantanée. Elle suit le rythme du crawl, qui dépend lui-même de l'autorité du site.
Les trois vraies causes de perte
Sur la dizaine de migrations que j'ai suivies ou récupérées, les causes de décrochage se répartissent toujours de la même façon :
- Redirections manquantes ou mal ciblées — la cause numéro un, de très loin. Une 301 vers la page d'accueil au lieu de la page équivalente tue le signal.
- Blocage technique involontaire —
robots.txten mode préproduction oublié, balisenoindexrestée dans le template, pare-feu qui bloque les crawlers. - Perte de contenu — une page supprimée sans équivalent, une pagination cassée, un blog migré avec la moitié des articles dans le vide.
Le point commun ? Aucun de ces trois problèmes n'est difficile à éviter. Tous se détectent avant la bascule, à condition d'avoir un vrai protocole.
Préparer la migration avant de toucher au DNS
Une migration qui se passe bien est une migration qui a été répétée. Pas testée une fois, sur trois pages, en se disant que ça ira. Répétée, sur un environnement complet, avec les données réelles.
Quand j'ai repris le projet de ce client dont je parlais plus haut, j'ai imposé une règle que j'applique systématiquement depuis : aucune bascule DNS ne se fait sans que l'environnement de préproduction ait été crawlable pendant au moins 48 heures avec les bonnes redirections en place et un robots.txt ouvert.
La checklist avant bascule
- Exporter l'inventaire complet des URLs indexées (via un crawl de votre propre site, pas seulement la Search Console).
- Construire la table de correspondance ancienne URL → nouvelle URL, exhaustivement.
- Vérifier que chaque ancienne URL renvoie bien un unique saut vers sa cible, sans chaîne de redirections intermédiaires.
- Retirer tout
noindex, tout mot de passe, toutrobots.txtrestrictif en préproduction. - Tester manuellement une cinquantaine d'URLs critiques : pages catégories, articles forts, pages de conversion.
Ce que cette préparation prend, concrètement : pour un site de 800 URLs, comptez deux bonnes journées de travail sérieux. Ceux qui la sautent le paient trois à dix fois plus cher dans les semaines qui suivent.
Les cas particuliers qui font le plus de dégâts
Personne ne parle jamais des pages orphelines ou des paramètres d'URL dans les guides de migration. Et pourtant, ce sont exactement les endroits où ça casse. Ils méritent leur propre section parce qu'ils échappent aux outils automatiques.
Pages orphelines et paramètres d'URL
Une page orpheline, c'est une URL indexée qui n'est plus liée depuis nulle part dans la nouvelle architecture. Google la connaît, elle existe, mais elle ne reçoit plus aucun lien interne. Elle s'éteint lentement. Pour les identifier, un crawl complet sur l'ancien site avec un outil qui remonte les URLs sans liens entrants internes est indispensable.
Les paramètres d'URL sont encore plus vicieux. Une URL du type ?page=2&sort=asc peut représenter des milliers de variantes dans votre index. Mal redirigées, elles fragmentent votre autorité sur des dizaines de versions quasi identiques. La règle : décidez une fois, pour chaque type de paramètre, s'il est indexé ou non, puis redirigez en bloc vers la version canonique.
Pagination, hreflang et redirections en chaîne
La pagination casse typiquement quand on remplace /page/2/ par un scroll infini. Sans point d'entrée URL stable, les articles de la deuxième page deviennent orphelins. Si vous changez de pagination, gardez des URLs fixes.
Pour les sites multilingues, chaque version linguistique doit rediriger vers sa propre version linguistique. Une page française qui redirige vers la version anglaise équivalente crée un signal contradictoire avec le hreflang. Google finit par désindexer l'une des deux.
Et les chaînes de redirections. A (ancienne) → B (intermédiaire) → C (finale) transfèrent mal le signal. Visez toujours un seul saut : A → C.
| Type de problème | Détection | Impact typique |
|---|---|---|
| Redirection manquante | Crawl + Search Console | Perte directe de la page |
| Chaîne de 301 | Analyse des en-têtes HTTP | Affaiblissement du signal |
| Page orpheline | Crawl interne | Extinction progressive |
| hreflang incohérent | Audit multilingue | Désindexation d'une version |
noindex oublié | Inspection d'URL manuelle | Disparition totale |
Jour de bascule et plan de retour
Voilà l'angle mort absolu des guides de migration : que faire si ça casse après la bascule DNS ? Personne n'en parle, comme si l'échec n'était pas une option. Or, il l'est. Il peut arriver. Et ne pas avoir de plan est irresponsable.
La fenêtre de rollback
Avant de changer le DNS, préparez un retour arrière testé. Concrètement : conservez l'ancien site accessible sur une adresse technique stable, prêt à être rebasculé en moins d'une heure. Vérifiez que le DNS peut être modifié rapidement, sans dépendre d'un prestataire injoignable un vendredi soir.
Pendant les 72 premières heures après bascule, surveillez trois choses en continu : le taux d'erreurs 404 dans les logs serveur, le nombre d'URLs indexées de votre nouveau domaine, et le trafic organique heure par heure. Si le trafic a perdu plus de 30 % en 48 heures, quelque chose ne va pas. Le rollback n'est pas un aveu de faiblesse, c'est une décision rationnelle.
J'ai poussé deux fois un rollback dans ma carrière. La première, j'ai mis huit jours à me décider. La seconde, en moins de douze heures. Le site qui a subi la première a mis près de deux mois à se remettre. Le second : dix jours. La leçon est arithmétique.
Suivre et récupérer après la migration
L'erreur la plus fréquente dans le suivi post-migration : regarder le trafic global et paniquer. Le trafic global bouge pour des dizaines de raisons. Ce qu'il faut suivre, c'est la réindexation des nouvelles URLs et la stabilisation des positions sur une sélection d'une vingtaine de mots-clés témoins.
Les seuils qui déclenchent une alerte, dans mon expérience :
- -20 % de clics à J+14 → vérifier les 301, les erreurs 404, les blocages de crawl.
- Aucune nouvelle URL indexée à J+7 → le crawl est bloqué quelque part.
- Positions qui reculent sur tous les mots-clés à la fois → problème global, pas éditorial.
La reprise, quand tout est propre, prend en général entre deux et huit semaines. Un site à faible autorité redémarrera plus lentement qu'un site installé. Ne vous attendez pas à revenir au niveau exact d'avant à la seconde où vous avez corrigé. La reconstruction du crawl prend son temps.
Ce que je retiens de chaque échec
La migration parfaite n'existe pas. Il y a toujours un truc qu'on n'a pas vu venir : une règle de pare-feu, un plugin oublié, une redirection qui boucle pour trois URLs insignifiantes. La différence entre une migration qui coûte quelques jours de trafic et une migration qui coûte deux mois, elle ne tient pas à l'absence d'erreur. Elle tient à la vitesse à laquelle on les détecte et on les corrige.
Le robots.txt oublié de ce client de mardi matin, on l'a retiré en trois minutes. La remontée a pris cinq semaines. C'est frustrant, cette asymétrie entre le temps de la casse et le temps de la réparation. Mais c'est la règle du jeu. Google ne pardonne pas plus vite qu'il n'oublie.
Alors la vraie question, avant toute migration, n'est pas « comment on fait pour ne rien perdre ? ». C'est « combien de temps serai-je capable de tenir si quelque chose casse, et à partir de quand j'appuie sur le bouton retour ? ». Répondez à celle-là avant de toucher au DNS, et vous serez mieux préparé que 90 % des gens qui migrent un site.
