Comment migrer PrestaShop sans perdre son positionnement Google

Pourquoi les migrations sont dangereuses pour le SEO

La migration d'une boutique PrestaShop est l'une des opérations les plus risquées que vous puissiez effectuer du point de vue du référencement naturel. Que vous changiez de serveur, de nom de domaine, que vous passiez de PrestaShop 1.6 à 1.7 ou 8.x, ou que vous restructuriez vos schémas d'URL, chaque migration comporte le risque de détruire des mois, voire des années, de positionnement accumulé dans les moteurs de recherche.

La raison est simple. Google et les autres moteurs de recherche ont indexé vos URL actuelles, leur ont attribué une autorité et ont construit une cartographie de la structure de votre site. Lorsque vous modifiez quoi que ce soit concernant ces URL, leur structure ou leur accessibilité, les moteurs de recherche doivent tout réévaluer. Si la transition est mal gérée, Google interprète le changement comme la disparition de votre ancien contenu et l'apparition d'un nouveau contenu non éprouvé. Le résultat est une chute de positionnement qui peut prendre des mois à récupérer, si une récupération complète est même possible.

La bonne nouvelle, c'est que les migrations peuvent être réalisées en toute sécurité. Avec une planification rigoureuse, une mise en œuvre correcte des redirections et une surveillance attentive, vous pouvez préserver la grande majorité de votre positionnement lors d'une migration. Ce guide détaille chaque étape du processus, de l'audit SEO initial au suivi post-migration.

Audit SEO pré-migration

Avant de toucher au moindre fichier de configuration, vous devez avoir une image complète de votre état SEO actuel. Cet audit remplit deux objectifs : il vous fournit une base de référence pour comparer après la migration, et il identifie les pages les plus précieuses qui doivent être traitées avec le plus grand soin.

Explorer votre site actuel

Utilisez un outil d'exploration comme Screaming Frog, Sitebulb ou la version gratuite de Screaming Frog (limitée à 500 URL) pour explorer l'intégralité de votre site. Exportez la liste complète des URL, leurs codes de statut HTTP, les titres de pages, les méta-descriptions, les balises canoniques et la structure de liens internes. Sauvegardez ces données. Vous en aurez besoin après la migration pour vérifier que rien n'a été perdu.

Exporter les données de Google Search Console

Google Search Console est votre source d'information la plus fiable pour savoir quelles pages reçoivent réellement du trafic organique. Accédez à Performances > Résultats de recherche et exportez les données des 16 derniers mois (le maximum disponible). Portez une attention particulière à :

Les pages avec le plus de clics et d'impressions. Ce sont vos pages génératrices de revenus. Un échec de redirection sur l'une de ces pages aura un impact immédiat et visible sur le trafic.

Les requêtes qui génèrent le plus de trafic. Après la migration, vous surveillerez ces requêtes pour vérifier la stabilité du positionnement.

Les pages avec beaucoup d'impressions mais peu de clics. Ces pages sont sur le point d'être bien positionnées et sont particulièrement sensibles aux perturbations.

Documenter votre structure d'URL

PrestaShop génère les URL en fonction de vos paramètres d'URL simplifiées, de la structure des catégories et des configurations produits. Documentez les schémas. Par exemple, vos URL produits sont-elles structurées comme /categorie/nom-du-produit.html ou simplement /nom-du-produit.html ? Vos URL de catégories incluent-elles des identifiants comme /3-nom-de-categorie ? Les pages CMS sont-elles à /content/5-nom-de-page ?

Comprendre ces schémas est essentiel car votre nouvelle installation peut générer des structures d'URL différentes par défaut, et chaque URL modifiée nécessite une redirection.

Vérifier les backlinks existants

Utilisez un outil de vérification de backlinks comme Ahrefs, Moz ou le rapport Liens de Google Search Console pour identifier quels sites externes pointent vers votre boutique et vers quelles pages spécifiques. Ces pages avec des backlinks portent le plus d'autorité, et les perdre signifie perdre la valeur SEO de chaque lien pointant vers elles.

Construire votre mapping d'URL

Le mapping d'URL est le document le plus critique de toute votre migration. C'est un tableur qui fait correspondre chaque ancienne URL à sa nouvelle URL correspondante. Chaque URL qui a déjà reçu du trafic, qui possède des backlinks ou qui apparaît dans votre sitemap doit avoir une correspondance.

Générer la liste des URL

Combinez les URL provenant de l'exploration de votre site, de l'export Google Search Console, du rapport de backlinks et du sitemap XML. Supprimez les doublons et triez par importance (trafic et valeur des backlinks). Votre liste finale doit inclure :

Toutes les URL produits. Dans PrestaShop, celles-ci sont générées à partir du nom du produit et de votre configuration d'URL simplifiées. Si vous modifiez votre structure d'URL (par exemple, en supprimant les extensions .html ou en changeant le format du chemin de catégorie), chaque URL produit change.

Toutes les URL de catégories. Les URL de catégories PrestaShop incluent souvent l'identifiant de la catégorie, et cet identifiant peut être différent dans la nouvelle installation si vous réimportez les catégories.

Toutes les URL de pages CMS. Cela inclut votre page à propos, les conditions générales de vente, la politique de confidentialité et toutes les autres pages de contenu.

Toutes les URL de fabricants et fournisseurs, si vous utilisez ces fonctionnalités.

Les URL paginées pour les catégories contenant de nombreux produits.

Créer le mapping

Pour chaque ancienne URL, déterminez quelle sera l'URL correspondante. Si la structure d'URL ne change pas (même domaine, mêmes paramètres d'URL simplifiées, mêmes identifiants), beaucoup d'URL correspondront à elles-mêmes et aucune redirection ne sera nécessaire. Mais vérifiez-le. Même de petits changements comme une profondeur d'arborescence de catégories différente ou une différence de barre oblique finale créent de nouvelles URL qui nécessitent des redirections.

Si vous modifiez les schémas d'URL de manière systématique (par exemple, en supprimant toutes les extensions .html), vous pouvez utiliser des redirections basées sur les expressions régulières au lieu de mapper chaque URL individuellement. Mais vérifiez toujours l'expression régulière par rapport à votre liste réelle d'URL avant la mise en production.

Implémenter les redirections 301

Une redirection 301 indique aux moteurs de recherche qu'une page a été déplacée de manière permanente vers un nouvel emplacement. Elle transfère la grande majorité de la valeur SEO (l'équité de liens) de l'ancienne URL vers la nouvelle. C'est le mécanisme qui préserve votre positionnement lors d'une migration.

Où placer les redirections

Pour PrestaShop sur Apache, les redirections vont dans le fichier .htaccess situé à la racine de votre document. Placez vos règles de redirection avant les règles de réécriture de PrestaShop (avant la section qui commence par # Dispatcher).

Pour PrestaShop sur Nginx, les redirections vont dans la configuration de votre bloc serveur. Vous devrez peut-être recharger Nginx après les modifications : sudo nginx -t && sudo systemctl reload nginx.

Syntaxe des règles de redirection

Pour Apache .htaccess, les redirections individuelles utilisent ce format :

Redirect 301 /ancien-chemin/ancien-produit.html https://www.nouveaudomaine.com/nouveau-chemin/nouveau-produit

Pour les redirections basées sur des modèles utilisant mod_rewrite :

RewriteEngine On
RewriteRule ^ancienne-categorie/(.*)$ /nouvelle-categorie/$1 [R=301,L]

Pour Nginx, redirections individuelles :

location = /ancien-chemin/ancien-produit.html {
  return 301 https://www.nouveaudomaine.com/nouveau-chemin/nouveau-produit;
}

Gérer un grand nombre de redirections

Les boutiques PrestaShop avec des milliers de produits nécessitent une approche plus évolutive que l'écriture de règles de redirection individuelles. Les options incluent l'utilisation d'un RewriteMap dans Apache (qui lit depuis un fichier texte ou une base de données), l'utilisation d'un module PrestaShop conçu pour gérer les redirections, ou l'implémentation des redirections au niveau applicatif via un module personnalisé qui intercepte les erreurs 404 et vérifie une table de redirections.

L'approche au niveau applicatif a l'avantage d'être gérable depuis le back-office, mais ajoute un léger surcoût de performance à chaque requête 404. L'approche par .htaccess est plus rapide mais plus difficile à gérer à grande échelle.

Mises à jour du sitemap XML

Votre sitemap XML indique aux moteurs de recherche quelles URL existent sur votre site et doivent être explorées. Après une migration, le sitemap doit refléter immédiatement la nouvelle structure d'URL.

Générer un nouveau sitemap

PrestaShop inclut une génération de sitemap intégrée, mais de nombreux propriétaires de boutiques utilisent un module comme Google Sitemap ou un module SEO tiers pour plus de contrôle. Après la migration, générez un nouveau sitemap qui inclut toutes les nouvelles URL. Vérifiez que le sitemap ne contient aucune ancienne URL qui redirige désormais.

Soumettre le sitemap mis à jour

Accédez à Google Search Console, naviguez vers Sitemaps et soumettez l'URL de votre nouveau sitemap (généralement https://www.votredomaine.com/1_index_sitemap.xml pour PrestaShop). Si l'URL du sitemap elle-même a changé, supprimez l'ancienne entrée de sitemap et ajoutez la nouvelle.

La soumission d'un nouveau sitemap signale à Google que la structure de votre site a changé et encourage une exploration plus rapide des nouvelles URL. Combinée avec des redirections 301 appropriées depuis les anciennes URL, cela donne à Google une image claire de ce qui s'est passé.

Étapes de migration dans Google Search Console

Migration sur le même domaine (changement de serveur ou mise à jour)

Si votre domaine ne change pas, aucune action spéciale dans Search Console n'est nécessaire au-delà de la soumission du sitemap mis à jour et de la surveillance. Google découvrira les changements lors de l'exploration normale.

Migration avec changement de domaine

Si vous changez de domaine, utilisez l'outil Changement d'adresse dans Google Search Console. Cela nécessite que l'ancien et le nouveau domaine soient vérifiés dans Search Console. Les étapes sont les suivantes :

Premièrement, configurez et vérifiez le nouveau domaine dans Google Search Console. Deuxièmement, assurez-vous que toutes les redirections 301 sont en place depuis l'ancien domaine vers le nouveau domaine. Troisièmement, accédez à la propriété de l'ancien domaine dans Search Console et utilisez Paramètres > Changement d'adresse. Quatrièmement, suivez les instructions pour spécifier le nouveau domaine.

Cela indique explicitement à Google que votre site a déménagé, ce qui accélère considérablement la transition. Sans cette étape, Google finit par le comprendre grâce aux redirections 301, mais cela prend plus de temps.

Considérations relatives à la propagation DNS

Si votre migration implique la modification des enregistrements DNS (pointer votre domaine vers un nouveau serveur), sachez que la propagation DNS n'est pas instantanée. Les différents résolveurs DNS à travers le monde se mettent à jour à des moments différents, et la propagation complète peut prendre de 24 à 72 heures.

Minimiser les temps d'arrêt

Avant la migration, réduisez le TTL (Time To Live) de votre DNS à une valeur basse comme 300 secondes (5 minutes). Faites-le au moins 48 heures avant la migration effective afin que l'ancien TTL élevé expire partout. Lorsque vous modifiez les enregistrements DNS, les résolveurs vérifieront les mises à jour toutes les 5 minutes au lieu de toutes les quelques heures.

Une fois la migration terminée et vérifiée, augmentez le TTL à une valeur normale comme 3600 (1 heure) ou plus pour réduire la charge de requêtes DNS.

Faire fonctionner les deux serveurs en parallèle

Pendant la fenêtre de propagation, certains visiteurs atteindront l'ancien serveur et d'autres le nouveau. Maintenez l'ancien serveur en fonctionnement avec une copie du site (ou au moins avec les règles de redirection en place) jusqu'à ce que la propagation soit terminée. Arrêter immédiatement l'ancien serveur provoque des temps d'arrêt pour les visiteurs dont le DNS n'a pas encore été mis à jour.

Surveillance du positionnement après la migration

Le travail ne s'arrête pas lorsque la migration est en production. La surveillance post-migration est essentielle pour détecter les problèmes avant qu'ils ne causent des dommages durables.

Vérifications immédiates (Jour 1)

Vérifiez que toutes les pages critiques se chargent correctement sur le nouveau site. Testez chaque redirection de votre mapping d'URL pour confirmer son fonctionnement. Vérifiez Google Search Console pour détecter de nouvelles erreurs d'exploration. Lancez une nouvelle exploration du site et comparez-la avec les données d'exploration pré-migration.

Surveillance de la première semaine

Vérifiez quotidiennement Google Search Console pour les erreurs d'exploration, les problèmes d'indexation et toute baisse de trafic. Consultez le rapport Couverture pour les pages qui ne sont plus indexées ou qui ont retourné des erreurs. Surveillez le positionnement de vos mots-clés principaux à l'aide d'un outil de suivi de positionnement. Des fluctuations sont normales la première semaine, mais des chutes importantes sur des mots-clés importants indiquent un problème de redirection.

Surveillance du premier mois

Comparez le trafic organique dans Google Analytics ou votre plateforme d'analyse avec la même période avant la migration. Vérifiez que toutes les pages importantes sont réindexées en recherchant site:votredomaine.com/page-specifique dans Google. Vérifiez que les anciennes URL sont supprimées de l'index (elles doivent rediriger vers les nouvelles URL, et Google doit finir par les remplacer dans son index).

Évaluation à trois mois

À trois mois après la migration, votre trafic organique devrait s'être stabilisé au niveau pré-migration ou proche. Si ce n'est pas le cas, examinez quelles pages ou requêtes spécifiques ont perdu du positionnement et vérifiez leurs chaînes de redirection, la qualité du contenu et leur santé technique.

Erreurs de migration courantes

Utiliser des redirections 302 au lieu de 301

Une redirection 302 indique aux moteurs de recherche que le déplacement est temporaire. Les moteurs de recherche ne transfèrent pas la totalité de l'équité de liens via les redirections 302. Utilisez toujours des 301 pour les migrations permanentes. C'est l'erreur la plus courante et la plus dommageable.

Oublier de rediriger non-www vers www (ou inversement)

Si votre ancien site utilisait www.exemple.com et que votre nouveau site utilise exemple.com (ou l'inverse), vous devez des redirections à la fois pour le changement de structure d'URL et pour le changement www/non-www. Oublier l'un de ces aspects crée une situation où certaines anciennes URL retournent des erreurs 404.

Ne pas mettre à jour les liens internes

Après la migration, vos liens internes doivent pointer directement vers les nouvelles URL, et non vers les anciennes URL qui redirigent. Bien que les redirections préservent la valeur SEO pour les liens externes, les liens internes qui redirigent créent des chaînes de redirection inutiles et ralentissent l'exploration.

Perdre le HTTPS

Si votre ancien site utilisait HTTPS et que votre nouveau site ne le fait pas (ou inversement), Google traite ces URL comme différentes. Assurez-vous que votre certificat SSL est correctement configuré sur le nouveau serveur avant la mise en production, et que toutes les redirections utilisent le bon protocole.

Modifier plusieurs choses en même temps

Si vous changez votre domaine, votre structure d'URL, votre contenu et le design de votre site en même temps, il devient impossible de diagnostiquer la cause d'éventuelles baisses de positionnement. Changez le moins de choses possible lors de la migration elle-même. Les mises à jour de contenu et de design peuvent être effectuées après la stabilisation du positionnement.

Calendrier de migration

Une migration PrestaShop bien planifiée suit ce calendrier :

4 semaines avant : Effectuez l'audit SEO complet, exportez toutes les données, commencez le mapping d'URL. Réduisez le TTL DNS si vous changez de serveur.

2 semaines avant : Finalisez le mapping d'URL, rédigez toutes les règles de redirection, configurez le nouveau site dans un environnement de staging et testez minutieusement.

1 semaine avant : Testez toutes les redirections en staging. Vérifiez que le nouveau sitemap XML est correct. Lancez une exploration complète du site de staging et comparez avec les données d'exploration de l'ancien site.

Jour de la migration : Déployez le nouveau site, activez les redirections, mettez à jour le DNS si nécessaire, soumettez le nouveau sitemap à Search Console, utilisez le Changement d'adresse si vous changez de domaine.

Semaine 1 : Surveillez Search Console quotidiennement, corrigez immédiatement toute erreur d'exploration, vérifiez le fonctionnement des redirections.

Mois 1 : Revues hebdomadaires de Search Console, comparaison du trafic avec la base de référence, vérification de la progression de l'indexation.

Mois 3 : Évaluation complète par rapport à la base de référence pré-migration. Traitement de tout problème restant.

Résumé

Une migration PrestaShop réussie qui préserve le positionnement Google nécessite trois éléments : une préparation rigoureuse, une implémentation correcte des redirections et une surveillance post-migration diligente. L'audit pré-migration vous fournit une base de référence et identifie vos pages les plus précieuses. Le mapping d'URL et les redirections 301 garantissent que la valeur SEO de chaque page est transférée vers le nouvel emplacement. La mise à jour du sitemap et la configuration de Search Console aident Google à découvrir et traiter les changements rapidement. Et la surveillance post-migration détecte les problèmes avant qu'ils ne deviennent permanents. Sautez l'une de ces étapes et vous risquez de perdre un positionnement qui a pris des mois ou des années à construire. Suivez-les toutes et votre migration devient une transition contrôlée plutôt qu'un désastre SEO.