Il y a deux types de migrations SEO. Celles qui se passent bien, et celles dont on découvre trois mois plus tard qu'elles se sont mal passées. La différence n'est presque jamais visible dans les jours qui suivent la mise en ligne, parce que les redirections fonctionnent, que Google indexe les nouvelles URL, et que le trafic semble tenir. Tout va bien pendant trois semaines. Puis ça décroche.
C'est typiquement le moment où notre agence seo intervient en récupération, quand il aurait mieux valu être consulté trois mois plus tôt.
Sur les missions de récupération que nous menons régulièrement, à peu près tous les sites avaient été audités en amont avec une check-list classique. Plan de redirections vérifié, sitemaps propres, balises canoniques correctes. Et pourtant, ils perdent 25, 40, parfois 60 % de leur trafic organique sur les trimestres suivants. Pourquoi ? Parce que les check-lists couvrent ce qui se voit immédiatement, pas les chutes structurelles qui mettent des semaines à se manifester.
Cet article ne va pas vous redonner la liste des 7 étapes d'une migration SEO. Le top 10 de Google la propose dans des variantes très proches. Il va vous montrer les six chutes invisibles que ces check-lists ne détectent pas, ce que l'IA peut anticiper et ce qu'elle vous fait crasher, et le protocole que nous appliquons sur les migrations Magento et Prestashop pour ne pas découvrir le problème trois mois trop tard.
Le chiffre est délibérément approximatif. Pas de méta-étude sourçable derrière, mais une observation cohérente sur les missions de récupération post-migration : la grande majorité des migrations entraînent au moins une perte partielle de trafic, même quand elles sont préparées avec sérieux.
Le piège classique. Les trois premières semaines post-migration affichent un trafic qui se maintient, parfois même qui progresse. L'équipe se félicite, l'agence aussi, on passe à autre chose. Sauf que Google met du temps à recrawler intégralement le site, à recalculer les scores d'autorité, à réévaluer les signaux de pertinence. Les premières semaines reflètent encore en partie l'ancien site dans l'index.
La vraie photographie de la migration arrive entre 6 et 12 semaines après la mise en ligne. C'est là qu'on voit si l'on a transféré la valeur ou si on l'a perdue en chemin. Les migrations qui chutent à ce moment-là ont presque toujours présenté des signaux faibles dans les 3 premières semaines, signaux que les outils standards ne savent pas lire.
L'idée que "tant que les redirections 301 sont en place, ça passera" est l'une des fausses certitudes les plus tenaces du SEO. Elle est partiellement vraie sur les petits sites simples. Elle est dangereusement fausse sur les sites e-commerce sérieux.
Un 301 transmet une partie de l'autorité, oui. Mais il ne transmet pas l'historique d'engagement utilisateur de l'ancienne URL. Il ne préserve pas la cohérence sémantique si le contenu de la nouvelle page diffère. Il ne maintient pas le contexte interne (les liens entrants depuis le reste du site) si l'arborescence change. Et il ne compense jamais une perte de signaux UX si la nouvelle page se charge en 6 secondes au lieu de 1,5.
Les redirections sont une condition nécessaire. Elles ne sont pas une condition suffisante. C'est tout l'enjeu de cet article.
Voici les six types de chute que nous identifions systématiquement dans les missions de récupération. Chacune a sa cause propre, son délai d'apparition typique, et son protocole de prévention.
Quand l'arborescence change, le maillage interne change avec elle. Une page qui recevait 50 liens internes depuis le reste du site peut se retrouver à n'en recevoir que 8, parce que les pages qui pointaient vers elle ont été restructurées ou supprimées. La redirection 301 préserve l'autorité externe, mais elle ne reconstruit pas le maillage interne de l'ancien site sur le nouveau.
Cette chute apparaît typiquement entre la 4ème et la 8ème semaine, quand Google a fini de recrawler et de recalculer les scores d'autorité interne. Elle touche en priorité les pages profondes du site, qui dépendaient le plus de l'irrigation interne pour exister en SERP.
Une page redirigée correctement vers une page de remplacement peut quand même perdre son trafic, si le contenu de la nouvelle page ne répond plus exactement à la même intention de recherche. C'est fréquent quand la refonte s'accompagne d'une refonte éditoriale : on a "amélioré" la page, on l'a rendue "plus complète", on a "modernisé" le ton, et au passage on a changé l'intention dominante qu'elle servait.
Google détecte ce décalage en quelques semaines via le comportement utilisateur (rebond, retours en SERP, faible engagement) et déclasse la page. Pas immédiatement, progressivement. C'est l'une des chutes les plus traîtres parce qu'elle ne se voit qu'à terme et qu'elle paraît inexplicable sans diagnostic approfondi.
Lors d'une refonte, plusieurs pages anciennes sont parfois fusionnées en une seule nouvelle page "plus complète". Sur le papier, c'est plus propre. En pratique, la nouvelle page essaie de couvrir trop d'intentions à la fois, et finit par n'en couvrir aucune correctement. Elle perd les positions de toutes les pages d'origine, sans en gagner de nouvelles.
C'est typiquement ce qui arrive quand on transforme un cocon sémantique existant en une grosse page hub. La logique est bonne en théorie, désastreuse en pratique si on n'a pas mesuré le poids SEO réel de chaque page fusionnée.
Une page qui était à 2 clics de l'accueil se retrouve à 5 clics après refonte. Mécaniquement, sa fréquence de crawl diminue, son autorité interne se réduit, et ses positions chutent. Cette chute est purement structurelle, indépendante de la qualité de la redirection. Elle touche particulièrement les pages catégories sur les e-commerces, quand la nouvelle navigation insère des niveaux intermédiaires.
Les Core Web Vitals comptent. Mais au-delà des chiffres bruts, le comportement utilisateur compte aussi. Si la nouvelle page se charge plus vite mais affiche un layout différent qui désoriente les visiteurs habitués, le taux de rebond augmente. Si le nouveau design change le placement des CTA, l'engagement chute. Google lit ces signaux et déclasse progressivement les pages qui semblent moins satisfaisantes.
Cette chute apparaît entre 4 et 10 semaines après la mise en ligne. Elle est particulièrement perfide parce que le diagnostic Core Web Vitals montre des chiffres améliorés, alors que l'expérience perçue par les utilisateurs s'est dégradée.
La dernière catégorie, c'est la chute qui arrive 4 à 6 mois après la migration, sans qu'aucun changement n'ait eu lieu entre temps. Elle correspond généralement à la fin de la "période de grâce" pendant laquelle Google maintient une partie de l'historique de l'ancien site, et au passage progressif sur l'évaluation pure du nouveau site. Si le nouveau site est structurellement moins solide que l'ancien, c'est à ce moment que ça se voit.
C'est aussi à ce moment que les chutes éditoriales (contenu de moins bonne qualité, perte d'EEAT Google, etc.) se manifestent pleinement.
Voici un outil simple qui vous donne une lecture de risque sur les six chutes identifiées plus haut, à partir de quelques caractéristiques de votre migration prévue ou réalisée. Plus vous cochez de cases, plus le profil de risque se précise.
Cochez les caractéristiques de votre migration. L'outil identifie les chutes les plus probables et leur niveau de risque.
L'IA et les outils automatisés ont changé certaines parties du travail de migration. Comme partout, ils sont utiles sur certaines tâches et dangereux sur d'autres. Voici la répartition que nous appliquons.
Pour matcher 30 000 anciennes URL avec 30 000 nouvelles, l'IA fait un travail rapide et globalement correct dans 85 à 92 % des cas. C'est un vrai gain de productivité par rapport à un mapping 100 % manuel. Le piège : ce sont précisément les 8 à 15 % de cas non triviaux qui contiennent le risque de chute majeure. Les pages les plus rentables d'un site sont souvent celles qui ont une histoire particulière, des URL non standard, des positions de niche qui ne se devinent pas par similarité textuelle.
La bonne pratique consiste à laisser l'IA traiter le gros volume, puis à isoler manuellement le top 200 ou top 500 des pages business prioritaires pour vérifier chaque mapping un par un. Sur les sites e-commerce significatifs, ce contrôle humain prend 2 à 5 jours et évite 80 % des pertes de trafic stratégique.
Sur la question "quelles pages garder, quelles pages supprimer ou fusionner avant migration", l'IA peut aider à cartographier le corpus existant. Elle identifie les pages similaires, les contenus orphelins, les sections vieillissantes. C'est un point de départ utile.
Mais la décision finale ne peut pas être déléguée : une page à faible trafic peut être stratégiquement essentielle (parce qu'elle se positionne sur une requête à fort taux de conversion), une page à fort trafic peut être en réalité une distraction (trafic non qualifié, taux de rebond élevé). Cette qualification croise des données business que l'IA n'a pas.
Les six chutes invisibles listées plus haut ont toutes ce point commun : elles ne se détectent ni en amont ni en aval avec des outils automatisés actuels. Aucun GPT n'est capable de vous dire "attention, après cette migration, vous allez subir une chute différée à 4 mois parce que votre nouveau site est structurellement moins solide que l'ancien". C'est précisément le travail d'un consultant SEO expérimenté que de poser ce diagnostic prédictif.
C'est aussi pour cela qu'un audit SEO sérieux avant migration n'est pas un luxe mais une assurance : c'est lui qui détecte les zones de fragilité structurelle qui amplifieront les chutes invisibles.
Sur les migrations Magento et Prestashop que nous accompagnons, nous appliquons un protocole en trois phases. Il n'a rien de révolutionnaire dans le principe, mais il s'attache spécifiquement à anticiper les six chutes décrites plus haut.
Quatre à six semaines avant la mise en ligne, on cartographie l'existant en profondeur. Pas seulement les URL et leur trafic, mais aussi : la matrice de maillage interne (qui pointe vers qui), l'intention dominante de chaque page stratégique, le profil de backlinks par URL, les performances UX page par page, et les requêtes secondaires sur lesquelles chaque page se positionne (souvent ignorées dans les briefs migration).
Cette cartographie produit un référentiel qui servira à comparer l'avant et l'après. Sans elle, on ne peut pas mesurer une chute, on peut juste la subir.
Sur l'environnement de pré-production, avant mise en ligne, on lance une série de tests qui vont au-delà du "les redirections marchent". On vérifie que les 200-500 pages stratégiques de la cartographie ont bien :
Chaque divergence est documentée et soit corrigée, soit acceptée explicitement comme un compromis avec un plan d'atténuation post-migration. Pas de surprise.
La migration n'est pas terminée le jour de la mise en ligne. Elle est terminée 6 mois après, quand on a la photographie réelle de ce qui s'est passé. Pendant ces 6 mois, on monitore :
| Période | Indicateurs surveillés | Seuils d'alerte |
|---|---|---|
| Semaines 1-3 | Indexation, erreurs serveur, logs Googlebot, redirections | Tout écart avec la cartographie initiale |
| Semaines 4-12 | Positions par page stratégique, trafic comparé, comportement utilisateur | Perte de plus de 15% sur une page top 100 |
| Mois 4-6 | Évolution globale du trafic SEO, CA SEO, comparaisons sectorielles | Tendance baissière sur 3 mois consécutifs |
Quand une alerte se déclenche, on agit immédiatement avant que la chute ne s'installe. Récupérer un trafic perdu en intervenant à la semaine 6 est faisable. Récupérer un trafic perdu en intervenant à la semaine 26 demande des mois de travail.
Les migrations entre CMS, ou les montées de version majeure (Magento 1 vers Magento 2, Prestashop 1.6 vers 1.7 ou 8.x), ont leurs pièges spécifiques. Trois patterns reviennent particulièrement souvent dans nos missions.
Le piège des URL paramétrées. Sur Prestashop, les anciennes URL non-réécrites contiennent des paramètres (?id_product=, ?category=) qui ne suivent pas la même logique que les nouvelles URL réécrites. Le mapping automatique fonctionne mal sur ces cas, et il est fréquent que 5 à 15 % des anciennes URL soient redirigées vers la page d'accueil par défaut, ce qui ruine tout le bénéfice de la migration.
Le piège des produits désactivés. Lors d'une migration, les produits désactivés dans l'ancien catalogue peuvent ne pas être migrés vers le nouveau. Or certains de ces produits désactivés captaient encore du trafic SEO via leur ancien indexation. Les rediriger vers une catégorie pertinente plutôt que les laisser en 404 préserve une partie du trafic.
Le piège du changement de logique de navigation à facettes. Magento 2 et les versions récentes de Prestashop gèrent différemment les URL de filtres. Une migration mal préparée peut soit générer une explosion d'URL filtrées indexables qui plombent le crawl, soit au contraire désindexer des pages filtres qui apportaient du trafic. Le passage d'une logique à l'autre demande un travail spécifique sur les canonicals et les robots.txt qui dépasse le simple mapping d'URL.
Plus généralement, une migration de CMS est une excellente occasion de remettre à plat la stratégie SEO globale du site, à condition de ne pas chercher à tout faire en une seule fois. Repenser l'architecture, refondre les contenus, changer de CMS et changer de domaine simultanément, c'est multiplier les facteurs de risque indépendants. Mieux vaut séquencer.
Sur un site e-commerce moyen, 6 à 10 semaines de préparation SEO en parallèle des développements techniques. Sur un site complexe (gros catalogue, multi-langues, refonte d'arborescence), comptez 12 à 16 semaines. Une migration préparée en moins de 4 semaines a une probabilité de chute significative supérieure à 80 %.
Pas explicitement, Google n'a pas de mécanisme pour "être prévenu". En revanche, des bonnes pratiques accélèrent la prise en compte : soumettre le nouveau sitemap dès la mise en ligne, garder l'ancien sitemap accessible quelques semaines, surveiller les rapports d'indexation dans Search Console, demander une réindexation manuelle des pages stratégiques.
Cela dépend de l'ampleur de la chute et de la rapidité du diagnostic. Une chute partielle détectée en semaine 4 et corrigée se rattrape en 2 à 4 mois. Une chute installée depuis 6 mois demande typiquement 6 à 12 mois de remédiation. C'est précisément pourquoi le monitoring sur 6 mois compte autant que la préparation.
Très déconseillé. Si votre site fait son chiffre principal en novembre-décembre (e-commerce généraliste, jouets, déco), évitez les migrations entre septembre et janvier. Si c'est l'été (mode, sport, voyage), évitez les migrations entre avril et août. Mieux vaut une migration en basse saison, même si elle retarde le projet.
Dans l'idéal, par étapes quand c'est possible. Migrer d'abord le contenu, puis l'arborescence, puis le CMS, puis éventuellement le domaine, en laissant 2 à 3 mois entre chaque étape. C'est plus long, mais ça permet d'isoler les causes en cas de chute et d'agir avec précision. La migration "big bang" en une seule fois n'est nécessaire que sur des contraintes techniques fortes.
Les backlinks externes pointant vers les anciennes URL doivent être préservés via les redirections 301. Mais la valeur transmise est partielle (estimée à 85-95 % de la valeur originale). Sur les pages qui reçoivent beaucoup de backlinks, il est utile de contacter les sites sources les plus importants pour mettre à jour leurs liens vers les nouvelles URL. Un travail de netlinking de qualité post-migration peut aussi compenser une partie des pertes.
Non, c'est même généralement déconseillé. Une migration est déjà une opération à risque. Y ajouter une refonte éditoriale massive multiplie les facteurs de chute. Mieux vaut migrer d'abord les contenus tels quels, puis lancer un programme de mise à jour de contenu SEO dans les mois qui suivent.
Trois indicateurs à 12 semaines post-migration : le trafic SEO global (doit être stable ou en progression), le trafic par page stratégique comparé à l'avant migration (chaque page top 200 doit être au moins à 85 % de son niveau d'avant), et l'évolution des positions sur les requêtes prioritaires. Si les trois sont au vert à 12 semaines, vous êtes probablement sauvés. Surveillez quand même jusqu'à 6 mois.
Sur les missions de migration que nous menons sous Magento et Prestashop, le moment où nous intervenons change tout. En amont, sur la préparation, nous pouvons anticiper les six chutes invisibles et construire un protocole qui les évite. En aval, sur une migration déjà mal partie, nous pouvons identifier précisément ce qui s'est cassé et le réparer, mais le travail prend des mois.
Si vous préparez une migration et que vous voulez savoir ce qui pourrait mal se passer sur votre cas spécifique, ou si vous venez de migrer et que vous voyez votre trafic décrocher sans comprendre pourquoi, nous pouvons en parler. Échangeons sur votre situation : diagnostic ciblé, anticipation des risques, plan d'action concret.
Si l'un des points évoqués dans cet article reflète une situation que vous vivez, parlons-en. Un échange court, un premier diagnostic, et un avis honnête sur ce qu'il y a à faire.
Demander un échange →