Un client m'appelle un lundi matin, panique dans la voix. Son nouveau site est en ligne depuis trois jours, plus beau, plus rapide, plus propre. Sauf que son trafic organique a plongé dans le vide : -68 % de sessions en une semaine. Il me demande de "réparer le SEO". Sauf que le SEO n'a rien cassé. La migration, oui.
Je vais être direct : la plupart des désastres que je vois ne viennent pas d'une mauvaise stratégie de référencement. Ils viennent d'un projet web mené sans personne pour penser à ce qui était déjà en place. On refait le site, on change de CMS ou de nom de domaine, on "modernise", et on oublie que derrière chaque URL il y a une position, une ancre interne, un lien entrant, une balise canonique.
Cet article liste les pièges qui me coûtent le plus de temps en intervention de crise, et surtout ce qu'aucune checklist générique ne vous dira : comment vérifier une migration après la livraison, comment gérer un rollback, et pourquoi une refonte n'est pas une migration même si tout le monde les confond.
Points clés à retenir
- Une redirection en chaîne ou une URL mappée "à la racine" suffit à perdre un mois de positions.
- Les balises canoniques, hreflang et données structurées ne sont presque jamais transférées — et personne ne s'en aperçoit avant deux semaines.
- Un crawl de contrôle et une comparaison de logs avant/après sont non négociables, pas optionnels.
- Sans plan de rollback écrit, vous improvisez en pleine chute de trafic. C'est là qu'on prend les pires décisions.
- Refonte et migration ne se pilotent pas de la même façon. Les mélanger garantit de perdre la trace de ce qui a bougé.
- Le maillage interne se reconstruit, il ne se "conserve" pas par magie.
Les pièges à éviter lors de la migration d'un site web pour le référencement
Le premier réflexe de tout le monde, c'est la redirection 301. Bien. Sauf qu'une redirection mal écrite est souvent pire que pas de redirection du tout. Je l'ai vécu sur un site e-commerce de 4 000 pages : le prestataire avait redirigé toutes les anciennes URL vers la page d'accueil. Résultat, Google a vu 4 000 pages qui pointaient vers un seul endroit. Positions effondrées en dix jours.
Erreur n°1 : les redirections approximatives
Une redirection utile est individuelle ou groupée par logique de contenu, jamais globale. Trois travers que je rencontre systématiquement :
- Les chaînes de redirection (A → B → C), qui diluent le signal et ralentissent la page d'arrivée.
- Les boucles infinies, qui font planter le crawl.
- Le renvoi massif vers la home "en attendant de faire le mapping". Sauf que "en attendant" dure six mois.
Ce qu'il faut faire : exporter toutes les URL de l'ancien site, les mapper une à une vers la nouvelle, et vérifier qu'un code 200 est bien renvoyé sur la cible. Pas un 302, pas un 304 bizarre. Un 200 clair.
Erreur n°2 : les 404 et le maillage interne oublié
Une page supprimée sans redirection, ça arrive. Mais ce qui fait vraiment mal, c'est le maillage interne. Sur un site média que j'ai suivi, la refonte avait supprimé toutes les ancres contextuelles dans les articles. Les pages profondes ont perdu leurs liens d'entrée. En trois semaines, les pages de "profondeur 4" ont disparu des premières positions.
Concrètement :
- Repérez les pages qui reçoivent le plus de liens internes avant la migration.
- Assurez-vous que la nouvelle architecture conserve un chemin équivalent (même profondeur de clic, même type d'ancres).
- Contrôlez les liens brisés après la mise en ligne, pas "plus tard".
Erreur n°3 : canoniques, hreflang et données structurées perdus dans le transfert
C'est le piège dont personne ne parle dans les checklists basiques. Une migration, ce n'est pas juste des URL. C'est un ensemble de signaux déclaratifs que les moteurs utilisent pour comprendre vos pages.
Les balises canoniques, par exemple. Si votre ancien site déclarait une version canonique pour éviter les doublons (paramètres, versions paginées, catégories), et que la nouvelle version n'en met aucune, vous recréez du contenu dupliqué sans le savoir. Les hreflang, si vous êtes multilingue, sont encore plus fragiles : une balise mal transférée et Google cesse de servir la bonne langue selon le pays.
Côté données structurées (schema.org), j'ai vu des sites perdre leurs rich snippets en une nuit — étoiles, FAQ, prix — simplement parce que le module qui générait le JSON-LD n'avait pas été reporté sur le nouveau thème. Le trafic ne baisse pas forcément en volume, mais le taux de clic chute. Et personne ne fait le lien.
Erreur n°4 : robots.txt, noindex et sitemap laissés en zone d'ombre
Le classique absolu : le site de préproduction avec un Disallow: / en place. On met en production. On oublie de le retirer. Deux semaines plus tard, tout est désindexé. Je ne rigole pas, je l'ai vu quatre fois.
Dans le même registre :
- Le
noindexoublié sur des pages stratégiques (souvent les pages de catégories dupliquées pendant les tests). - Le sitemap XML qui pointe encore vers les anciennes URL, ce qui envoie Google vers des 404.
- Les règles de robots.txt qui bloquent accidentellement les fichiers CSS ou JS, cassant le rendu mobile.
Un point que j'ajoute toujours : vérifiez ces trois éléments après la mise en ligne, sur l'environnement réel, pas sur le staging. C'est bête, mais c'est là que ça se joue.
Comment vérifier une migration après la livraison ?
La livraison n'est pas la fin. C'est le début de la phase la plus importante, et c'est précisément ce que la majorité des projets expédient en une heure.
Un protocole en quatre étapes
Voici ce que j'applique systématiquement, dans cet ordre :
- Crawl de contrôle complet. Je relance un crawl de tout le nouveau site et je compare la liste d'URL avec celle d'avant. Toute URL qui existait avant et qui renvoie un 404 sans redirection est une anomalie à traiter.
- Comparaison des logs serveur. Avant/après, sur 7 jours. Je regarde quelles pages Googlebot visite, à quelle fréquence, et si de nouvelles erreurs apparaissent. Une chute de fréquence de crawl sur une section précise est un signal fort.
- Suivi de positions ciblé. Pas tout le site. Je prends 30 à 50 mots-clés représentatifs, dont les 10 qui génèrent le plus de trafic, et je les suis quotidiennement pendant un mois.
- Vérification des signaux déclaratifs. Canoniques, hreflang, données structurées : page par page, sur les gabarits clés (accueil, produit, article, catégorie).
Sur un site de services que j'ai accompagné l'an dernier, cette étape a révélé que 12 % des URL n'avaient aucune redirection. On l'a corrigé en 48 heures. Trafic revenu au niveau initial en dix jours. Sans ce protocole, on l'aurait découvert trois semaines trop tard.
Faut-il prévoir un plan de rollback ?
Oui. Et si quelqu'un vous dit que ce n'est pas nécessaire, changez de prestataire.
Un rollback, ce n'est pas "remettre l'ancien site". C'est avoir une stratégie écrite qui répond à trois questions : à quel seuil de perte de trafic on déclenche, qui décide, et comment on remet en ligne techniquement (DNS, base de données, redirections).
Ce que je conseille : conserver l'environnement de préproduction opérationnel pendant au moins 30 jours après la mise en ligne. Si le trafic chute de plus de 30 % sur des pages à fort enjeu commercial, on peut basculer sans tout reconstruire. C'est brutal, mais c'est rassurant — pour vous comme pour le client.
Le pire scénario, c'est de découvrir le problème un vendredi soir sans sauvegarde propre. Ça m'est arrivé une fois. Une seule. Depuis, je refuse de lancer une migration sans point de restauration validé.
Refonte ou migration : pourquoi la confusion coûte cher
Les deux termes sont utilisés comme synonymes. Ils ne le sont pas. Une refonte change le design et parfois le code, mais les URL restent globalement en place. Une migration déplace le site : changement de domaine, de CMS, d'architecture, parfois les trois.
Pourquoi ça compte ? Parce que les risques ne sont pas les mêmes. Une refonte fait surtout peser un risque sur le maillage interne et le rendu. Une migration fait peser un risque sur tout : URL, redirections, signaux déclaratifs, liens entrants, indexation.
| Point de vigilance | Refonte | Migration |
|---|---|---|
| URL et redirections | Risque faible (URL souvent inchangées) | Risque élevé (mapping complet nécessaire) |
| Maillage interne | Risque élevé (menus et liens contextuels refaits) | Risque élevé (arborescence entièrement repensée) |
| Canoniques et hreflang | Risque modéré (gabarits à reporter) | Risque élevé (perte fréquente dans le transfert) |
| Liens entrants externes | Risque faible | Risque élevé (backlinks à re-pointer) |
| Plan de rollback | Souvent inutile | Indispensable |
La règle simple : tout ce qui touche à l'URL est un risque de migration, pas de refonte. Le jour où vous mélangez les deux dans le même planning, vous perdez la capacité à isoler la cause d'une chute.
Quand faut-il impliquer la personne en charge du SEO ?
Le plus tôt possible. Idéalement au moment du cadrage, avant même le choix du CMS. Pas parce qu'elle va "faire du SEO", mais parce qu'elle va cartographier l'existant : quelles pages rapportent du trafic, quels sont les liens entrants critiques, quelle structure est réellement indexée.
Sans cette cartographie, vous reconstruisez à l'aveugle. Et à l'aveugle, sur un site qui vit depuis cinq ans, vous détruisez forcément quelque chose que vous ne saviez pas précieux.
Un audit avant migration, ce n'est pas une dépense de confort. C'est l'assurance de ne pas perdre six mois de travail accumulé. Le reste, c'est de la mécanique.
Et si on vous promet une migration "sans aucun impact SEO", posez une seule question : pouvez-vous me montrer le mapping complet des URL et le protocole de vérification post-mise en ligne ? Si la réponse prend plus de dix secondes, vous avez votre réponse.
