Perte de trafic après une migration e-commerce : les 7 erreurs à corriger

Une boutique qui perd une part importante de son trafic organique après un changement de CMS n'est presque jamais victime du hasard : dans la grande majorité des cas, la chute vient du plan de redirections, d'un blocage d'indexation hérité de la préproduction ou de contenus amputés au passage. La bonne nouvelle, c'est que ces causes sont identifiables en 48 heures et corrigeables pour l'essentiel en un mois. Voici les sept erreurs les plus coûteuses et la méthode de rattrapage.

Pourquoi une migration de CMS fait-elle chuter le trafic organique ?

Une migration de CMS fait chuter le trafic quand Google perd le lien entre les anciennes URL et les nouvelles. Chaque page indexée porte un historique : des liens entrants, des signaux de qualité, un positionnement. Si l'adresse change sans redirection propre, cet historique n'est pas transféré, la page repart de zéro et les positions acquises disparaissent. Le changement de plateforme en lui-même (Shopify, WooCommerce, PrestaShop, Magento) n'est jamais la cause : la cause, c'est la façon dont les URL, les contenus et le balisage ont été transposés.

Deux effets se cumulent souvent. D'abord une chute brutale dans les 72 heures, signe d'un problème technique bloquant (indexation, redirections, serveur). Ensuite une érosion lente sur trois à six semaines, symptôme d'une perte de contenu ou de maillage interne que Google met du temps à réévaluer page par page. Distinguer les deux courbes dans Google Search Console (search.google.com/search-console) orient déjà le diagnostic.

Quelles sont les 7 erreurs qui coûtent le plus de trafic ?

Les sept erreurs responsables de la majorité des pertes sont : un plan de redirections incomplet, des redirections mal implémentées, un blocage d'indexation hérité du site de test, des contenus tronqués, un maillage interne effondré, des données structurées disparues et une régression de performance. Chacune se vérifie avec un crawl et quelques requêtes.

1. Le plan de redirections ne couvre qu'une partie des URL

La plupart des plans de redirections se limitent aux pages produits et aux catégories, et oublient tout le reste : anciennes pages de marque, produits épuisés, articles de blog, pages de filtres qui recevaient du trafic longue traîne, fichiers PDF (guides des tailles, notices), et surtout les URL d'images. Sur une boutique, les images génèrent une part réelle du trafic via Google Images. Le réflexe : exporter la liste complète des URL ayant reçu au moins une impression sur 16 mois dans Search Console, la croiser avec un crawl de l'ancien site, et redirect chaque ligne.

2. Les redirections sont en 302, en chaîne ou renvoient vers l'accueil

Une redirection e-commerce doit être une 301 permanente, en un seul saut, vers la page nouvelle la plus équivalente. Trois fautes classiques : la 302 temporaire, qui demande à Google de conserver l'ancienne URL ; la chaîne (ancienne URL vers URL intermédiaire vers URL finale), qui dilue le signal et ralentit le crawl ; et la redirection massive vers la page d'accueil, traitée comme une page introuvable déguisée. Redirigez une fiche produit disparue vers sa catégorie, jamais vers l'accueil.

3. Le noindex ou le robots.txt de préproduction reste en production

C'est l'erreur la plus brutale et la plus fréquente : le site de recette était bloqué en Disallow: / ou en noindex, et cette configuration part en production avec le reste. Résultat : désindexation progressive de l'ensemble du catalogue en quelques jours. À vérifier le jour de la mise en ligne, avant même le reste : le fichier robots.txt, les balises meta robots, les en-têtes HTTP X-Robots-Tag, et les URL canoniques qui pointent encore vers le domaine de test.

4. Les contenus sont tronqués par la reprise de données

Les imports CSV perdent régulièrement les champs longs : descriptions produits détaillées, textes d'introduction de catégories, balises title et meta description personnalisées, attributs alt des images. Le site paraît identique côté visuel mais des centaines de pages sont devenues des pages vides, avec des titles générés automatiquement par le thème. Comparez un échantillon de 30 pages avant/après et mesurez le nombre de mots réel ainsi que les balises title générées.

5. Le maillage interne s'effondre

Les nouveaux thèmes remplacent souvent les blocs de liens éditoriaux par des carrousels chargés en JavaScript, suppriment le fil d'Ariane ou modifient la profondeur de navigation. Des pages qui recevaient dix liens internes n'en reçoivent plus qu'un. Un crawl permet de repérer les pages passées à plus de quatre clics de l'accueil : ce sont celles qui décrochent en premier.

6. Les données structurées Product ont disparu

Le balisage Product (prix, disponibilité, avis) alimente les résultats enrichis. Quand le nouveau thème ne le génère plus, les étoiles et les prix disparaissent des résultats de recherche : les positions bougent peu, le taux de clic s'écroule. Le rapport des résultats enrichis de Search Console montre cette perte en une minute.

7. La performance et le rendu régressent

Un nouveau thème plus lourd, des images servies en pleine résolution, un rendu des listes produits entièrement côté client : le crawl ralentit, les Core Web Vitals se dégradent, les contenus critiques deviennent invisibles sans exécution JavaScript. Testez l'affichage d'une page catégorie avec JavaScript désactivé : si la liste de produits est vide, le problème est là.

Comment diagnostiquer la perte de trafic en 48 heures ?

Le diagnostic tient en quatre contrôles, dans cet ordre. Un : le robots.txt et les balises d'indexation. Deux : un crawl complet de la liste des anciennes URL pour vérifier le code de réponse de chacune, avec un outil comme Screaming Frog SEO Spider (screamingfrog.co.uk/seo-spider) en mode liste. Trois : le rapport d'indexation de Search Console, en surveillant les volumes de pages « introuvables » et « exclues par une balise noindex ». Quatre : la comparaison des pages d'atterrissage avant/après pour isoler les modèles de pages touchés.

Cette étape sert à trancher entre deux scénarios très différents. Si les pertes sont concentrées sur un type de page (fiches produits, blog, pages de filtres), la cause est structurelle et se répare par lot. Si elles sont uniformes sur tout le site, cherchez un problème global : indexation, serveur, canonical, ou domaine.

Quel plan de rattrapage appliquer sur 30 jours ?

Le plan de rattrapage se déroule en quatre temps : débloquer, rediriger, restaurer, consolider. Jours 1 à 3 : lever tout blocage d'indexation, corriger les canoniques, republier un sitemap XML à jour et le soumettre. Jours 4 à 10 : compléter le plan de redirections URL par URL en partant des pages qui généraient le plus d'impressions, et supprimer toutes les chaînes.

Jours 11 à 20 : restaurer les contenus perdus depuis une sauvegarde de l'ancienne base, en priorisant les pages qui étaient positionnées dans le top 20, puis réinstaller le balisage Product et les attributs alt. Jours 21 à 30 : reconstruire le maillage interne (fil d'Ariane, liens éditoriaux en HTML, liens entre produits complémentaires), optimiser les images et demander une réindexation des modèles corrigés. Gardez une trace datée de chaque correction : c'est le seul moyen de relier une remontée de courbe à une action précise.

Combien de temps faut-il pour retrouver son trafic ?

Quand les corrections sont faites proprement, la remontée est généralement visible sous deux à quatre semaines pour les pages à fort trafic, et s'étale sur deux à trois mois pour la longue traîne, le temps que Google recrawle l'intégralité du catalogue. Le rythme dépend directement du volume d'URL et de la fréquence de crawl du site : une boutique de 300 références se rétablit bien plus vite qu'un catalogue de 50 000 références.

Une nuance importante : si la migration a été accompagnée d'une réduction volontaire du nombre de pages (suppression de filtres indexés, regroupement de catégories), une partie du trafic perdu ne reviendra pas, et ce n'est pas forcément un problème. Comparez alors le chiffre d'affaires organique plutôt que les seules sessions.

Comment sécuriser une migration avant la mise en ligne ?

La prévention coûte toujours moins cher que le rattrapage. Avant la bascule : crawler l'ancien site en intégralité et archiver l'export, exporter 16 mois de données de performance depuis Search Console, construire le tableau de correspondance des URL ligne par ligne et le faire tester sur la préproduction, vérifier le balisage sur un échantillon de chaque modèle de page. Le jour J : contrôler robots.txt et indexation dans l'heure, puis suivre quotidiennement les codes de réponse pendant deux semaines.

FAQ

Faut-il conserver exactement la même structure d'URL lors d'une migration ?

Oui, dans la mesure du possible. Conserver les URL à l'identique supprime le principal facteur de risque d'une migration de CMS. Si le nouveau CMS impose un format différent (préfixes de type /products/ ou /collections/ par exemple), un plan de redirections 301 exhaustif et en un seul saut est indispensable, sans exception pour les images et les fichiers.

Combien de temps garder les redirections en place ?

Au minimum un an, et idéalement de façon permanente. Les anciennes URL continuent de recevoir des liens externes et des visites depuis des favoris, des e-mails ou des marketplaces bien après la migration. Supprimer les redirections au bout de quelques mois provoque une seconde chute, souvent plus difficile à diagnostiquer que la première.

Une chute de trafic juste après une migration peut-elle venir d'une mise à jour Google ?

C'est possible mais rare, et cela se vérifie. Comparez la date exacte de la chute avec le calendrier des mises à jour de Google, et regardez si la baisse touche tous les types de pages ou seulement ceux qui ont changé de structure. Une perte concentrée sur les pages dont l'URL a été modifiée est technique, pas algorithmique.

Faut-il migrer le blog en même temps que la boutique ?

Migrer le blog en même temps simplifie le maillage interne et évite de gérer deux systèmes, mais double le volume d'URL à traiter le jour J. Sur un catalogue important, décaler la migration du blog de quelques semaines permet de concentrer les contrôles techniques sur les pages qui génèrent le chiffre d'affaires.

Peut-on rattraper une migration ratée plusieurs mois après ?

Oui. Remettre en place des redirections 301 et restaurer les contenus manquants fonctionne encore six ou douze mois plus tard, avec une remontée plus lente car les anciennes URL ont été désindexées entre-temps. La condition est de disposer de la liste des anciennes URL : à défaut de sauvegarde, l'export Search Console et les archives web permettent de la reconstituer partiellement.