Ce qui casse la semaine après une migration vers PrestaShop
Le jour du lancement se passe presque toujours bien. C'est un faux signal
Une migration qui « fonctionne », au sens strict où la nouvelle boutique tourne et prend des commandes, est relativement facile à réussir : produits, prix, stock et historique des commandes sont des données structurées, les outils d'import les déplacent plutôt bien, et le premier jour tout semble en ordre. Les vrais problèmes n'apparaissent pas le jour du lancement, ils apparaissent sept à dix jours plus tard, quand les visiteurs arrivent avec une ancienne URL enregistrée dans leurs favoris, quand Google reprend son exploration avec la carte des adresses qu'il connaissait, et quand quelqu'un remarque qu'une fonction « qui existait avant » a disparu, non pas parce que quelqu'un l'a supprimée volontairement, mais parce qu'aucun outil d'import ne l'a jamais prise en compte. Cet article ne parle pas de la manière de migrer (des services spécialisés existent pour cela, ce n'est pas notre métier) : il parle de ce qu'il faut vérifier la semaine suivante, une fois la boutique en ligne et quand la liste des problèmes commence à remonter d'elle-même.
Des URL mortes, pas par dizaines : par centaines
Le problème le plus sous-estimé, c'est l'échelle. Ceux qui migrent s'attendent à corriger « quelques URL », pas toute la structure des adresses. En pratique, presque aucune plateforme ne partage le schéma d'URL d'une autre : un catalogue qui vivait sous /product/nom-du-produit/ sur WooCommerce, sous /nom-de-categorie/nom-du-produit.html sur Magento, ou sous /products/nom-du-produit sur Shopify, arrive sur PrestaShop avec un autre schéma encore, qui contient souvent l'identifiant numérique du produit dans l'adresse. Chaque URL qu'un moteur de recherche avait indexée, chaque lien qu'un autre site ou un client avait enregistré, pointe désormais vers un chemin qui n'existe tout simplement pas dans la nouvelle boutique. Sur un catalogue de quelques milliers de produits, avec les catégories, les pages de filtres indexées et les contenus éditoriaux, le nombre d'URL à rediriger atteint facilement quelques centaines, même pour une boutique de taille moyenne : ce n'est pas un cas limite réservé aux gros catalogues.
La bonne pratique, presque jamais appliquée à temps, consiste à exporter la liste complète des URL que l'ancienne plateforme avait fait indexer (depuis la Google Search Console, pas depuis le sitemap de l'ancien site, souvent déjà incomplet) avant la bascule, et à construire le plan de redirections comme une partie du projet de migration, pas comme une correction après les premiers rapports de trafic perdu.
Le bandeau cookies qui ne distingue plus les pays
Une migration multilingue faite dans l'urgence reprend presque toujours des textes et des réglages conçus pour la langue principale, et la configuration du consentement aux cookies est l'un des premiers endroits où cela se voit : un bandeau qui distinguait correctement le public par langue ou par pays revient parfois à une valeur unique par défaut après la migration, ou pire, affiche un texte non traduit pour les langues secondaires (nous avons trouvé et corrigé un défaut exactement de ce type en septembre 2026 dans notre propre module de consentement aux cookies, non pas à cause d'une migration mais pour la même cause de fond : des textes qui ne couvraient que deux langues sur cinq). Il vaut la peine de revérifier la configuration du consentement sur chaque langue active juste après la bascule, et pas seulement sur la langue principale sur laquelle les tests ont réellement été faits.
Les données de conformité que l'outil d'import ne savait même pas chercher
Les outils d'import déplacent bien tout ce qui existait déjà comme notion sur la plateforme d'origine : prix, description, images, catégories. Un champ comme « fabricant GPSR », « avertissement de sécurité pour ce produit précis » ou « mandataire dans l'UE » n'existait souvent pas du tout comme donnée structurée sur l'ancienne plateforme, et aucun outil d'import ne pouvait donc le transférer, tout simplement parce qu'il n'y avait aucun champ source à copier. Le vrai risque, c'est une boutique migrée qui suppose que « si c'était bon avant, c'est bon maintenant », alors que la lacune de conformité, si elle existait, était déjà là avant, et que la migration ne fait que la rendre plus visible en obligeant à repenser les données produit depuis le début.
La recherche interne qui repart de zéro
Si la boutique précédente avait un moteur de recherche réglé au fil du temps, avec des synonymes ajoutés à la main après que des clients avaient cherché un terme sans rien trouver, des mots vides calibrés sur la langue du catalogue, un ordre de pertinence corrigé après des mois d'observation de ce que les clients cliquaient réellement, rien de ce réglage ne voyage avec un import de produits. C'est un travail fait sur le comportement de la recherche, pas sur les données du catalogue, et aucun outil de migration ne peut le déplacer parce que ce n'est même pas une « donnée » au sens habituel : c'est de la configuration accumulée. Le symptôme typique est une baisse des conversions issues de la recherche interne dans les premières semaines, non pas parce que le nouveau moteur est moins bon en soi, mais parce qu'il part d'un réglage générique au lieu de mois de corrections.
Les flux produits qui pointent encore vers l'ancien schéma
Un flux Google Shopping ou marketplace est construit sur les URL et les identifiants de la plateforme d'origine. Après la migration, à moins de reconstruire entièrement le flux sur le nouveau schéma d'adresses, chaque annonce continue de pointer vers une URL qui renvoie une redirection ou, pire, une 404 : au-delà d'un certain pourcentage de liens cassés, Google Merchant Center commence à signaler le flux et peut suspendre la diffusion des annonces, ce qui est un préjudice commercial direct et immédiat, pas seulement un problème de référencement naturel.
Une check-list pour la première semaine
- Comparez la liste des URL indexées avant la migration (depuis la Search Console) avec ce qui renvoie un 200 aujourd'hui : chaque URL manquante a besoin soit d'une redirection permanente vers le contenu équivalent, soit d'une fermeture délibérée si le contenu n'existe vraiment plus.
- Vérifiez le bandeau cookies sur chaque langue et chaque pays actifs, pas seulement sur la langue principale.
- Revérifiez les données de conformité des produits (GPSR compris) en partant du principe que l'import ne les a pas transférées, parce que c'est presque certainement le cas.
- Suivez séparément les conversions issues de la recherche interne pendant les deux premières semaines : c'est le signal le plus rapide pour savoir si la configuration de la recherche doit être refaite.
- Reconstruisez le flux produits sur le nouveau schéma d'URL avant de relancer les campagnes, pas après avoir constaté la baisse.
En bref
La semaine qui suit une migration n'est pas une période tranquille de rodage : c'est le moment où apparaissent les problèmes que le jour du lancement ne pouvait pas montrer. Des URL que personne n'a redirigées, des réglages sans champ source à copier, des mois de réglages (recherche, consentement, flux) qui n'ont jamais existé comme « donnée » à migrer. Un gestionnaire de redirections avec suivi des 404, comme cll_seoredirect, aide à repérer ces lacunes au moment où elles s'ouvrent plutôt qu'après que les visiteurs les ont déjà remarquées, mais la check-list ci-dessus reste valable quel que soit l'outil utilisé.
