Ressource Agence BPC
Checklist refonte PrestaShop en 32 points
32 contrôles cochables organisés en 5 phases (J-30, J-15, J-7, J-1, J+30). Conçue pour PrestaShop 1.7 et 8.x, elle s'applique à 90% à n'importe quel e-commerce qui prépare une refonte.
Imprimez la page, posez-la à côté de votre clavier, cochez au fur et à mesure. Si un point est ignoré ou survolé, c'est typiquement le moment où vous perdrez 40% de trafic organique la semaine du go-live.
Phase 1 - J-30 : cartographier
- Exporter depuis Google Search Console le top 100 pages par impressions sur 12 mois glissants (CSV).
- Exporter le top 50 mots-clés organiques avec position moyenne et URL associée.
- Identifier les 10 pages au CTR anormalement élevé (CTR > 8%) : ce sont vos pages champions à protéger en priorité.
- Crawler le site complet avec Screaming Frog ou Sitebulb (mode JS rendering activé pour les fiches produits dynamiques).
- Croiser les URLs du sitemap.xml avec celles découvertes par le crawl. Lister les écarts dans un fichier « URL_actives.csv ».
- Identifier les fiches produits désactivées encore indexées (souvent 100+ sur un site mature). Décision : redirection ou réactivation ?
- Repérer les URLs paramétrées (`?category=...&color=...`) qui polluent l'index. Plan : noindex via meta robots côté nouveau site.
Phase 2 - J-15 : préparation technique
- Construire la table de redirections finale (CSV à 2 colonnes : ancienne_url, nouvelle_url). Ne jamais excéder 1 saut : 301 directe vers l'URL finale.
- Pour chaque URL gardée à l'identique : vérifier que la nouvelle structure ne casse pas l'URL (suffixe trailing slash, casse, présence du `.html`).
- Pour chaque URL changée : 301 vers la nouvelle URL (jamais 302, jamais via plugin, idéalement en règles `.htaccess` ou nginx).
- Pour chaque URL supprimée : 301 vers la catégorie parente la plus proche (jamais vers la home, jamais 404).
- Sur l'environnement de staging, vérifier que `robots.txt` contient `Disallow: /` et que les pages renvoient un header `X-Robots-Tag: noindex`.
- Préparer le nouveau sitemap.xml : exclure les pages désactivées, inclure les hreflang si multilingue, vérifier la fréquence (« daily » pour la home, « weekly » pour les catégories).
- Configurer les redirections de protocole et de www (HTTP→HTTPS et www↔non-www doivent tous pointer vers la version canonique).
Phase 3 - J-7 : tests
- Lighthouse mobile sur les 5 templates : home, catégorie type, fiche produit type, panier, tunnel de commande. Score cible ≥ 85 partout.
- Tester le tunnel d'achat complet : ajout panier (mobile + desktop), création compte invité, paiement test (Stripe ou PayPal sandbox), email de confirmation reçu et lisible.
- Tester le tunnel d'achat sur 3 navigateurs réels : Safari iOS, Chrome Android, Safari macOS. Chrome desktop ne suffit pas.
- Vérifier les évènements GA4 e-commerce : `view_item`, `add_to_cart`, `begin_checkout`, `purchase` (avec valeur de transaction et items).
- Vérifier les conversions Google Ads importées depuis GA4 (compte lié, conversion principale = `purchase`, valeurs cohérentes).
- Vérifier le Pixel Meta si Facebook Ads (events `Purchase` et `AddToCart` correctement déclenchés).
- Activer Consent Mode v2 RGPD : par défaut tout refusé, opt-in explicite avant tout tag marketing.
- Tester l'envoi des 3 emails transactionnels critiques : confirmation commande, expédition, mot de passe oublié.
Phase 4 - J-1 : revue finale
- Backup complet : dump base de données (mysqldump), tarball des fichiers, fichier de redirections versionné dans un repo Git distinct. TTL DNS abaissé à 300s au moins 48h avant la bascule pour permettre un rollback rapide.
- Plan de bascule horodaté distribué à toute l'équipe (créneaux précis et responsable par tâche, voir tableau ci-dessous).
- Mode maintenance configuré et testé (page propre, code 503, retry after 1h).
- Procédure de rollback documentée : si la bascule explose, retour à l'état initial en moins de 30 minutes garantis.
| Heure | Action | Responsable |
|---|---|---|
| 21:00 | Activation page maintenance | Dev |
| 21:15 | Déploiement nouveau code | Dev |
| 21:30 | Bascule DNS | Hébergeur |
| 21:45 | Vérification redirections (échantillon 20 URLs) | SEO |
| 22:00 | Désactivation maintenance | Dev |
| 22:05 | Re-vérif tracking GA4 + Ads + Meta | Marketing |
| 22:15 | Soumission nouveau sitemap dans Search Console | SEO |
Phase 5 - J+1 à J+30 : surveillance
- Search Console quotidiennement les 7 premiers jours : pic de 404, pic d'erreurs serveur 5xx, évolution du nombre de pages indexées.
- GA4 quotidiennement : trafic organique, taux de conversion, panier moyen. Comparaison vs même jour de la semaine précédente.
- Logs serveur : Googlebot crawle-t-il bien les nouvelles URLs ? Filter `Googlebot` dans les access logs et vérifier qu'il ne tape plus d'anciennes URLs après 7 jours.
- J+15 : audit d'un échantillon aléatoire de 50 anciennes URLs populaires. Vérifier que toutes renvoient bien la nouvelle URL cible en 1 saut.
- J+30 : comparer le rapport Search Console vs J-30. Sur une refonte réussie, on voit une légère baisse à J+7 (Google digère) puis un retour au niveau initial à J+30, et un dépassement à J+60.
- Si baisse persistante > 20% à J+30 : audit fond (mauvaise redirection, contenu coupé, structure modifiée trop brutalement). Ne pas attendre J+60 pour réagir.
Règle d'or
Une bonne refonte se voit à J+45 : Google a digéré, les positions sont restaurées, le CA repart. Si vous êtes encore en chute à J+45, c'est un problème structurel, pas un retard d'indexation.