Refonte PrestaShop : la checklist qui évite la catastrophe SEO

Une refonte PrestaShop mal préparée, c'est -40% de trafic organique dès la semaine suivante, dans le meilleur des cas. Dans le pire : Google met 3 mois à comprendre la nouvelle structure, et le CA s'effondre pile au moment où on attendait l'inverse.

Voici la checklist qu'on applique sur chaque refonte. Elle vaut pour PrestaShop 1.7, 8.x et 9.x, mais 90% s'applique à tout e-commerce.

J-30 : avant de toucher au code

1. Cartographier l'existant

Exporter de Google Search Console :

• Top 100 pages par impressions sur 12 mois
• Top 50 mots-clés organiques
• Pages avec un CTR anormalement haut (à protéger en priorité)

C'est votre patrimoine SEO. Tout le reste tourne autour.

2. Lister toutes les URLs actives

https://votre-shop.fr/sitemap.xml

Croiser avec un crawl complet (Screaming Frog, Sitebulb) pour ne rien rater :

• Pages catégories
• Fiches produits actives + désactivées (souvent indexées)
• Pages CMS
• URLs filtrées (?category=...&color=...) qui sont parfois indexées par erreur

3. Décider du sort de chaque URL

Trois cas :

J-15 : préparation technique

4. Construire la table de redirections

Un fichier CSV : ancienne_url,nouvelle_url.

Pour PrestaShop, l'idéal est de gérer ça en règles serveur (.htaccess ou nginx) plutôt qu'en plugin - c'est plus rapide et survivra aux mises à jour.

Règle d'or : zéro chaîne de redirections. Une 301 pointe directement sur l'URL finale, pas sur une 301 qui pointe sur une 301.

5. Vérifier le robots.txt

Sur la version de staging : tout doit être bloqué (Disallow: /). Sur la production : ouvrir l'indexation au moment du go-live, pas avant.

C'est l'erreur la plus fréquente : on oublie d'enlever le Disallow: / au moment de la bascule, et le site reste invisible 3 semaines.

6. Préparer le nouveau sitemap

PrestaShop génère un sitemap natif, mais il faut souvent le compléter :

• Inclure les pages multi-catégories correctement
• Exclure les pages désactivées
• Définir les hreflang si site multilingue

J-7 : tests de performance

7. Lighthouse mobile sur les 5 templates

• Page d'accueil
• Catégorie type
• Fiche produit type
• Panier
• Tunnel de commande

Score cible : ≥85 sur chaque. PrestaShop avec un thème par défaut bien configuré peut atteindre 90+. Avec un thème acheté plein de carrousels, on tombe à 50.

Pour les gros e-commerce, automatiser ces tests via Lighthouse CI (intégré dans GitHub Actions) ou WebPageTest API : à chaque PR, vérification automatique que le score Lighthouse mobile ne régresse pas en dessous d'un seuil. Évite les mauvaises surprises post-merge.

8. Tester le tunnel d'achat

• Ajout au panier (mobile + desktop)
• Création de compte invité
• Paiement test (Stripe / PayPal sandbox)
• Email de confirmation reçu, lisible, mobile-friendly

C'est tellement basique que c'est souvent oublié.

9. Vérifier le tracking GA4 + Ads

• Évènements e-commerce GA4 : view_item, add_to_cart, begin_checkout, purchase
• Conversions Google Ads importées
• Pixel Meta branché si Facebook Ads
• Consent Mode v2 activé pour le RGPD

J-1 : revue finale

10. Backup complet et préparation rollback DNS

• Base de données (mysqldump complet)
• Fichiers du site (tarball)
• Fichier de redirections versionné quelque part
• TTL DNS abaissé à 300 secondes au moins 48h avant la bascule (sinon, en cas de problème sur le DNS bascule, vous êtes coincé pendant la durée de l'ancien TTL, parfois 24-48h)

Si la bascule explose, on doit pouvoir revenir à l'état initial en moins de 30 minutes.

11. Plan de bascule horodaté

J+1 à J+30 : surveillance

12. Monitoring quotidien

• Google Search Console : pic de 404, pic d'erreurs serveur, pages indexées
• GA4 : trafic organique, taux de conversion
• Logs serveur : Googlebot crawle-t-il bien les nouvelles URLs ?

Une bonne refonte se voit à J+45 : Google a digéré, les positions sont restaurées, le CA repart.

Les 5 erreurs qu'on voit le plus souvent dans une refonte PrestaShop ratée

La checklist ci-dessus, on l'a écrite à force de récupérer des refontes catastrophiques. À chaque fois que le téléphone sonne à J+30 d'une bascule, ce sont quasiment toujours les mêmes 5 erreurs qui reviennent. Aucune n'est complexe à éviter, mais chacune coûte plusieurs milliers d'euros à rattraper après coup.

1. Reprendre la même URL pour des produits qui ont changé de catégorie

Le scénario classique : l'équipe e-commerce profite de la refonte pour réorganiser le catalogue. Le produit table-en-chêne-massif.html passe de la catégorie "Salle à manger" à "Tables artisanales". L'URL change mécaniquement : /salle-a-manger/table-en-chene-massif.html devient /tables-artisanales/table-en-chene-massif.html. Sans 301, vous perdez la position SERP acquise depuis 4 ans.

Impact business : sur un catalogue de 800 produits, on a vu un client perdre 62% de son trafic organique parce que 230 fiches avaient changé de slug sans redirection. Récupération : 4 mois.

Correction : avant la bascule, exporter l'ancienne arbo, croiser avec la nouvelle, et générer un CSV ancienne_url,nouvelle_url. Même si vous gardez le slug produit identique, le chemin parent change et casse l'URL.

2. Oublier de migrer le schema produit (Product + Offer + AggregateRating)

PrestaShop 1.7 et 8.x ont des modules différents pour générer le JSON-LD produit. Quand vous changez de thème, le nouveau ne réinjecte pas forcément Product, Offer, Brand, AggregateRating. Résultat : vos fiches sortent des rich results Google (étoiles, prix, stock affichés en SERP).

Impact business : un CTR qui baisse de 30 à 50% sur les requêtes produit, même à position égale. Le visuel rich results pèse lourd côté clic.

Correction : avant la bascule, faire un test Rich Results Test sur 5 fiches produit représentatives. Après la bascule, refaire le test sur les mêmes 5 fiches. Si le schema a sauté, le développeur a 2 jours pour le recâbler.

3. Laisser le noindex global de staging passer en production

C'est l'erreur la plus stupide et pourtant la plus fréquente. Le staging est en noindex, nofollow pendant 3 mois. Le jour J, le dev migre la base et le code, mais oublie de désactiver le toggle "Empêcher l'indexation" dans Préférences > SEO & URL de PrestaShop. Le site part en prod avec un <meta name="robots" content="noindex"> sur toutes les pages.

Impact business : invisibilité Google totale tant que personne ne le remarque. Sur un client, on a constaté 11 jours de noindex en prod avant détection. Trafic organique remis à zéro pendant la période, puis ré-indexation lente sur 3 semaines.

Correction : ajouter à votre checklist de bascule un test curl -I https://votre-shop.fr | grep -i x-robots et un view-source qui cherche noindex sur 5 templates. 2 minutes de test évitent un mois de perte.

4. Sous-estimer la perte de jus des liens externes (backlinks)

Si une catégorie ou une fiche produit a généré des backlinks au fil des ans (article de blog, mention sur un comparateur, lien depuis un forum spécialisé), changer son URL sans 301 fait perdre une partie du PageRank transmis. Et même avec 301, on observe une dilution de 10 à 15% sur les premières semaines.

Impact business : sur une niche compétitive, perdre 15% du jus d'un backlink fort peut suffire à descendre de position 3 à position 8 sur un mot-clé buyer. Sur 30 produits clés, c'est plusieurs dizaines de milliers d'euros de CA annuel.

Correction : avant la refonte, exporter les top URLs par backlinks via Ahrefs, Semrush ou la GSC (Liens > Principales pages cibles). Sanctuariser ces URLs : soit on les garde identiques, soit on met une 301 directe (jamais en chaîne) et on contacte les sites référents importants pour qu'ils mettent à jour leur lien.

5. Ne pas prévoir de budget monitoring post-bascule

Les agences vendent souvent la refonte comme un projet qui s'arrête au go-live. C'est exactement l'inverse : la refonte commence vraiment à J+1. Sans suivi quotidien pendant 4 semaines, on découvre les problèmes au moment où ils ont déjà coûté cher (404 massives, pic d'erreurs serveur, Googlebot bloqué sur une URL aberrante).

Impact business : on a récupéré un dossier où une règle de réécriture nginx mal écrite générait 3 200 erreurs 500 par jour pendant 3 semaines. Personne n'avait monitoré. Perte estimée : 18 000 € de CA + impact durable sur la confiance Google.

Correction : prévoir au devis une enveloppe monitoring de 3 à 5 jours étalée sur J+1 à J+30. Vérification quotidienne de la GSC (Couverture, Améliorations, Core Web Vitals), des logs serveur (filtrage Googlebot), et du tunnel d'achat sur mobile.

Pour la documentation officielle PrestaShop sur la migration : PrestaShop DevDocs. Pour les redirections 301 et leur prise en compte par Google : documentation Search Central.

Questions fréquentes

On accompagne ce type de bascule sur PrestaShop régulièrement, en e-commerce vitrine et catalogue technique.