SEO PrestaShop : checklist technique 2025 pour indexation et performance

Table des matières :

1. Périmètre de la checklist : versions, prérequis et critères de réussite
2. URL, canonicals et duplication : la zone où PrestaShop vous laisse trop facilement dériver
3. Robots.txt, meta robots et sitemaps : contrôler le crawl plutôt que le subir
4. Facettes, recherche interne et pagination : éviter l’explosion d’URL tout en gardant la discoverability
5. HTTP, codes de statut, rendu et signaux d’indexation : là où les logs tranchent
6. Performance front (Core Web Vitals) : votre SEO 2025 se joue sur LCP/INP, pas sur “minifier partout”
7. Performance back (TTFB, DB, cache) : l’indexation s’écroule quand le serveur tousse
8. Validation continue : monitoring, alertes et prévention des régressions SEO

Périmètre de la checklist : versions, prérequis et critères de réussite

Cette checklist SEO PrestaShop est pensée pour des boutiques en PrestaShop 8.1.x et 9.x (Symfony 6.4 côté back-office / architecture modernisée côté front selon les thèmes) avec PHP 8.2/8.3, un serveur Apache ou Nginx, et un accès réaliste à une pré-production. Les points ci-dessous ciblent deux objectifs mesurables : (1) une indexation maîtrisée (pas de facettes indexées par accident, pas de duplication massive, pas de pages vides) et (2) une performance mesurable (Core Web Vitals et TTFB) sans casser le checkout.

Pré-requis non négociables avant de “cocher des cases” : accès aux logs HTTP, à la Search Console, et idéalement à un outil de mesure RUM (Real User Monitoring) ou au minimum des exports CrUX / PageSpeed. Sans logs, vous raisonnez sur des symptômes. Sans pré-prod, vous ne maîtrisez pas les régressions (notamment avec PrestaShop où un module peut modifier templates, hooks, SQL et en-têtes). Sur les gros catalogues, ajoutez un suivi DB (slow query log) et un tableau de bord métriques (Prometheus, Grafana).

En pratique, si vous êtes en contexte France / UE, ajoutez aussi ces garde-fous (souvent oubliés côté “tech SEO”) :

• Pré-production non indexable : noindex global + protection (authentification HTTP / liste d’IP autorisées). La simple exclusion robots.txt ne suffit pas si des URLs fuitent.
• Mesures conformes RGPD : une partie des données RUM/analytics peut être limitée par le consentement (ex. Matomo/GA4). L’objectif n’est pas d’être “parfait” côté tracking, mais d’avoir assez de signal pour décider (notamment CWV et parcours critique).

Côté critères d’acceptation 2025 (toujours valables en 2026), alignez-vous sur les seuils Google des Core Web Vitals : LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 (source : web.dev/vitals). Sur l’indexation, l’objectif n’est pas “tout indexer” mais “indexer ce qui convertit” (catégories, produits, pages éditoriales) et désindexer ce qui pollue (recherches internes, tri, facettes sans landing, URLs à paramètres, pages techniques).

Critères de réussite concrets (à suivre mensuellement, pas une fois) :

• Search Console : baisse des “explorées, actuellement non indexées” sur les patterns à paramètres ; stabilité des pages valides.
• Logs : part de crawl Googlebot sur URL “business” (catégories/produits) en hausse ; baisse des hits sur paramètres inutiles.
• CWV RUM : amélioration du 75e percentile (la métrique à regarder, pas la moyenne).
• Checkout : aucune régression (taux d’erreur, temps de réponse, abandons) après optimisation cache/CDN.

URL, canonicals et duplication : la zone où PrestaShop vous laisse trop facilement dériver

La duplication d’URL est un problème structurel sur PrestaShop dès que vous activez : tri, pagination, paramètres de tracking, facettes (ps_facetedsearch) et parfois des variantes de produit exposées via paramètres. La première étape de la checklist technique 2025 est donc un inventaire : export des URL vues dans les logs, crawl (Screaming Frog / Sitebulb), puis regroupement par patterns (?order=, ?q=, #/page-, ?resultsPerPage= etc.). C’est ce mapping qui dicte la stratégie : canonicals, robots, règles de réécriture, et pages d’atterrissage SEO dédiées.

Avant même de toucher au thème, vérifiez aussi les réglages natifs (souvent “OK en apparence”, mais incohérents après migration ou changement de module) :

• URLs simplifiées activées et stables (sinon explosion de variations).
• Forçage cohérent de HTTP→HTTPS et d’un seul host (www ou non-www), sinon duplication de domaine.
• Gestion des slash / trailing slash, et surtout des majuscule/minuscule (certaines stacks Nginx + rewrite laissent passer des doublons).
• Présence (ou absence) de redirection “vers canonique” : utile dans certains cas, mais à tester car peut provoquer des chaînes de redirections si mal combinée avec un CDN/reverse proxy.

Pour la canonicalisation, appliquez une règle simple : toute variation non stratégique doit indiquer une URL préférée (catégorie/produit sans paramètres). La documentation Google Search Central sur la consolidation d’URL dupliquées décrit le rôle de rel=canonical et la logique “preferred version”. En pratique PrestaShop ne gère pas toujours correctement les canonicals en présence de facettes et de pages triées ; il faut donc auditer le <link rel="canonical"> réellement rendu par votre thème et vos modules, et surcharger si nécessaire.

Cas concret fréquent : une catégorie indexable qui devient dupliquée par tri (?order=price-asc) et pagination (?page=2). Sur ces URL, vous avez trois options : (1) noindex, follow sur les variations (souvent le plus safe), (2) canonical vers la page 1 (acceptable mais peut créer des signaux contradictoires si le contenu diffère fortement), (3) créer des landing pages SEO dédiées (facettes maîtrisées) et n’indexer que celles-là. La partie “landing pages + facettes” est détaillée sur le site ici : Pages d’atterrissage SEO : maîtriser facettes, indexation Google et maillage interne.

Un moyen simple de rendre la stratégie lisible (et d’éviter les décisions “à l’instinct”) est de formaliser un tableau d’arbitrage par pattern :

Pattern d’URL observé	Exemple	Valeur SEO ?	Action recommandée
Tri	?order=price-asc	Faible	noindex, follow + exclure du sitemap
Pagination	?page=2	Variable	Indexer si catégories longues qui convertissent, sinon noindex, follow
Tracking	?utm_source= / ?gclid=	Nulle	Canonical vers URL propre (et idéalement normalisation côté serveur)
Facettes combinatoires	?q=marque-nike/taille-42/couleur-noir	Souvent faible	Noindex ou blocage crawl selon volume + landing pages SEO ciblées

Enfin, en multi-langue / multi-pays (FR/BE/CH ou international), évitez le piège “canonicals cross-lang” : une page /fr/ doit canoniser vers sa version propre, et la stratégie d’alternates (hreflang) doit rester cohérente. Même sans entrer dans une checklist “international SEO” complète, repérez au moins les anomalies : canonicals qui pointent sur la mauvaise langue, ou alternates absents après changement de thème.

Robots.txt, meta robots et sitemaps : contrôler le crawl plutôt que le subir

Le robots.txt sert à contrôler l’exploration, pas l’indexation (Google peut indexer une URL bloquée si elle est massivement référencée). En revanche, il reste crucial pour réduire le bruit sur des patterns inutiles : pages de recherche interne, paramètres de tri, pages panier/commande, endpoints techniques, etc. Pour PrestaShop, votre checklist doit inclure un diff entre le robots.txt actuel et vos patterns réels (logs). Sur des boutiques avec modules, on voit souvent des paramètres non anticipés (campaign ids, filtres, pagination). N’appliquez pas une “liste générique” : basez-vous sur vos URL.

Exemple (à adapter, et à valider via logs/crawl) de patterns souvent à contrôler sur PrestaShop :

User-agent: *
Disallow: /panier
Disallow: /commande
Disallow: /connexion
Disallow: /recherche
Disallow: /*?order=
Disallow: /*?resultsPerPage=
Disallow: /*?utm_
Disallow: /*?gclid=

Ensuite, utilisez meta robots (ou en-tête X-Robots-Tag) pour gérer l’indexation là où un blocage robots serait contre-productif. Exemple : sur les pages de tri et de facettes, vous voulez souvent noindex, follow afin de conserver la circulation de PageRank vers les produits tout en évitant d’indexer 50 000 combinaisons. Pour les pages vides / erreurs de rendu (souvent causées par JS, overrides, templates), le problème est plus vicieux : une page 200 “vide” peut être indexée et dégrader la qualité globale. Une méthodologie dédiée existe ici : Page vide : causes fréquentes et impact sur l’indexation Google.

Sur les sitemaps, ne vous contentez pas de “générer un fichier”. La documentation Google Search Central rappelle l’usage et le rôle des sitemaps. Dans une boutique PrestaShop, un sitemap utile est filtré (pas d’URL paramétrées), segmenté (produits/catégories/pages CMS), et cohérent avec vos règles noindex/canonical.

Points de checklist concrets sur les sitemaps (souvent responsables d’une indexation “sale”) :

• Respecter les limites du protocole : 50 000 URLs et 50 Mo non compressé par fichier (au-delà : découper + index de sitemaps).
• N’inclure que des URLs 200, indexables, et canoniques (si une URL est en noindex, elle n’a rien à faire dans le sitemap).
• Segmenter pour diagnostiquer : si “produits” décroche mais “catégories” va bien, vous gagnez du temps.
• Sur gros catalogues : mise à jour “raisonnable” du lastmod (uniquement quand un changement pertinent intervient), sinon vous envoyez un signal de bruit.

Pour l’approche opérationnelle : Plan de site : optimiser l’indexation Google avec un sitemap clair.

Facettes, recherche interne et pagination : éviter l’explosion d’URL tout en gardant la discoverability

Sur PrestaShop, ps_facetedsearch peut devenir un générateur de dette SEO : paramètres multiples, URLs parfois “propres” mais combinatoires, pages à contenu trop proche, et (dans le pire cas) indexation massive de pages qui ne convertissent pas. En 2025, la checklist technique doit explicitement séparer : (a) facettes “utilitaires” (noindex), (b) facettes “SEO” (landing pages, indexables), (c) facettes “toxiques” (bloquées/exclues car trop fines ou générant du duplicate). Ne pas documenter cette taxonomie, c’est garantir une régression lors du prochain ajout d’attributs.

Une manière pragmatique de décider quelles facettes méritent une landing SEO (donc une URL stable, un contenu éditorial minimal et un maillage interne) :

• Demande : la combinaison correspond-elle à une recherche réelle (Search Console, données SEA, outils keyword) ?
• Offre : avez-vous un stock/choix suffisant (sinon pages “vides” ou qui changent trop souvent) ?
• Marge : est-ce une typologie de produits rentable (utile si vous devez arbitrer entre 20 landing pages possibles) ?
• Différenciation : pouvez-vous proposer un texte, des FAQ, des éléments uniques (éviter 200 pages quasi identiques) ?

Mini-scénario classique : une boutique mode active les facettes “taille”, “couleur”, “marque”, “matière”. En SEO, indexer “couleur + taille + matière” crée vite des milliers de pages au contenu similaire. En revanche, indexer quelques pages “marque + catégorie” (ex. “Chaussures de randonnée Salomon”) peut apporter un trafic qualifié si la page est éditorialisée et maillée depuis la catégorie.

La recherche interne est une autre source classique de pages parasites (?s= / /recherche?search_query=) : elles sont utiles aux utilisateurs, mais rarement à indexer. Bloquez l’indexation (noindex) et évitez d’ajouter ces URLs au sitemap. En parallèle, traitez la recherche interne comme un signal produit : tolérance aux fautes, tri commercial, analytics RGPD. Vous avez deux ressources internes directement actionnables : Recherche interne PrestaShop : live search, tolérance fautes et tri commercial et Recherche interne PrestaShop : analytics RGPD et optimisation du moteur.

Pour la pagination, évitez les recommandations “SEO 2016”. Aujourd’hui, Google traite la pagination comme des pages distinctes ; la checklist 2025 se concentre donc sur : (1) liens internes corrects (pagination crawlable), (2) contenu non vide sur les pages profondes (sinon soft-404), (3) stratégie d’indexation (souvent indexable si catégories profondes, sinon noindex selon votre modèle). Sur les gros catalogues, ce choix doit être dicté par la marge (catégories longues qui génèrent des ventes) et par la capacité serveur (crawl).

Point d’attention moderne : si vous utilisez un infinite scroll, assurez-vous que PrestaShop expose toujours des URLs paginées accessibles via des liens HTML (sinon Googlebot ne découvre pas correctement les produits “sous la ligne de flottaison”).

HTTP, codes de statut, rendu et signaux d’indexation : là où les logs tranchent

Une checklist SEO PrestaShop sérieuse inclut une table “URL type → code attendu”. Exemples : produit actif = 200 ; produit désactivé = 404 (ou 410 si suppression définitive) ; produit remplacé = 301 ; page filtre noindex = 200 + meta robots ; page inexistante = 404 (pas 200). Le cœur PrestaShop + certains modules ont tendance à renvoyer des 200 sur des pages “non pertinentes” (ex : search empty, catégories sans produits, erreurs de template). Ces soft-404 sont coûteuses : elles diluent le crawl budget et dégradent les signaux qualité.

Table opérationnelle (à adapter à vos règles métier) :

Type d’URL	Statut attendu	Indexation	Canonical	Contrôle principal
Produit actif	200	index	self	contenu + schémas + perf
Produit en rupture temporaire	200	index	self	éviter “page vide”, proposer alternatives
Produit supprimé définitivement	410 (ou 404)	noindex implicite	—	suppression propre + retrait sitemap
Produit remplacé	301	—	—	redirection vers produit successeur
Catégorie active	200	index	self	pagination/tri/facettes
Catégorie sans produits	404/410 ou 200 noindex	selon stratégie	cohérent	éviter indexation de pages faibles
Page facette non stratégique	200	noindex, follow	vers URL propre	meta robots + liens internes
Recherche interne	200	noindex, follow	vers URL propre	éviter dans sitemap
Panier/commande/compte	200	noindex	—	sécurité + pas de crawl inutile

À ce stade, arrêtez de deviner : utilisez une analyse logs. Mesurez : volume de hits Googlebot, ratio 200/3xx/4xx/5xx, top URL crawled, et fréquence de crawl par type (produit vs paramètres). Corrélez avec la Search Console (Couverture/Indexation, pages explorées mais non indexées). Sur les environnements où l’infra est non triviale (reverse proxy, HA), standardisez la visibilité via X-Forwarded-For, et surveillez la santé des backends. Pour les architectures derrière HAProxy : HAProxy : configuration avancée ACL, health checks et sticky sessions.

Astuce “anti soft-404” issue du terrain : dans les logs, isolez les 200 dont la taille de la réponse est anormalement faible (ou constante) pour repérer les templates cassés, pages “sans produits” rendues comme une page standard, ou des erreurs silencieuses côté front.

Enfin, si votre catalogue change souvent, IndexNow peut accélérer l’indexation sur Bing/Yandex et réduire la latence de découverte (ce n’est pas un substitut aux sitemaps). Dans un contexte e-commerce (prix/stock), c’est particulièrement utile. Pour la mise en œuvre côté PrestaShop et les pièges : IndexNow : intégration PrestaShop et stratégie d’indexation pour e-commerce.

Performance front (Core Web Vitals) : votre SEO 2025 se joue sur LCP/INP, pas sur “minifier partout”

Sur PrestaShop, le LCP est souvent : image principale produit, hero bannière, ou grille produit de catégorie. La checklist technique commence donc par une mesure : Lighthouse + WebPageTest + RUM si possible. Ensuite, corrigez l’ordre des causes : (1) TTFB, (2) poids/format image, (3) CSS bloquant, (4) JS qui retarde le rendu. Les “optimisations” au pif (activer/désactiver CCC) sans profiler donnent des gains instables et cassent parfois le cache.

Actions concrètes, orientées PrestaShop (LCP/CLS en priorité) :

• Ne lazy-loadez pas l’élément LCP (souvent la première image produit). Le lazy-loading doit cibler le “sous la ligne de flottaison”.
• Stabilisez le layout : dimensions (width/height) sur images, placeholders, éviter l’injection tardive de bannières/cross-sell qui poussent le contenu (CLS).
• Optimisez les polices : limiter les variantes, précharger si nécessaire, et surtout éviter le blocage rendu.
• Images : formats modernes (WebP/AVIF selon support), tailles réellement adaptées (pas de 2000px servi à un mobile).

Si vous cherchez une base objective pour comparer avant/après, le Chrome UX Report (CrUX) explique comment les données “terrain” (RUM agrégé) sont construites et utilisées dans PageSpeed Insights.

Ressources internes utiles : PrestaShop : optimiser performance via cache Smarty, CCC et CDN et LiteSpeed Cache : lazy‑loading, LQIP et VPI pour optimiser les images.

Pour l’INP (remplaçant de FID), le problème n’est pas “avoir moins de JS” en théorie, c’est réduire le travail main-thread au moment des interactions (variantes produit, ajout panier, menus, sliders). Auditez les bundles et les handlers ; supprimez les librairies non utilisées ; évitez d’attacher des listeners sur des listes de produits entières si un event delegation suffit. Sur PrestaShop, surveillez particulièrement :

• les scripts de modules (upsell, avis, chat, tag manager) chargés sur toutes les pages ;
• les “quick view” et sliders qui font du recalcul DOM au scroll/click ;
• les handlers attachés à chaque carte produit en listing (catégories) au lieu d’un seul handler délégué.

Et si vous externalisez les assets via CDN, vérifiez la cohérence Cache-Control, la compression Brotli, et les headers de sécurité qui peuvent bloquer du preload. Pour choisir un CDN avec des contraintes e-commerce (purge, TLS, POP, coût), voir : CDN en 2026 : comparatif Bunny.net, Cloudflare, Akamai, CloudFront, Fastly.

Performance back (TTFB, DB, cache) : l’indexation s’écroule quand le serveur tousse

Le TTFB conditionne à la fois le LCP et l’efficacité du crawl : si Googlebot rencontre de la latence/5xx, il ralentit. Dans PrestaShop, les causes typiques de TTFB élevé sont : requêtes SQL non indexées (filtres, recherche, modules), surcharge PHP (hooks), et absence de cache applicatif. Commencez par instrumenter : APM (Blackfire, New Relic…), slow query log, et métriques PHP-FPM. Un guide DB orienté production est disponible : PrestaShop MySQL : analyser slow query log et optimiser index.

Repères pragmatiques (à contextualiser selon stack et cache) :

• Objectif raisonnable sur pages cacheables : TTFB “vu utilisateur” bas et stable (éviter les p95/p99 qui explosent).
• Sur pages dynamiques (panier/commande/compte) : viser surtout la stabilité et la baisse des erreurs/timeouts plutôt qu’un chiffre “magique”.

Côté PHP, vérifiez OPcache et ses paramètres (mémoire, validation timestamps, JIT si pertinent), et évitez les redémarrages FPM trop agressifs qui détruisent le cache opcode. Sur PrestaShop 9, la modernisation (services, contrôleurs, Twig) peut améliorer certaines choses, mais ne supprime pas la réalité : un module mal écrit peut encore déclencher du N+1 SQL ou des appels IO bloquants. Pour une baseline OPcache : PHP OPcache : paramètres recommandés pour optimiser les performances. Pour une approche “profiling → refactoring” : Optimisation de code PrestaShop : diagnostiquer lenteurs et requêtes SQL.

Enfin, sur les gros catalogues, l’infra fait la différence : NVMe, Redis (sessions/cache), reverse proxy si vous savez l’opérer, et une config système cohérente. Attention aux “fausses bonnes idées” : un cache full-page agressif qui met en cache des fragments panier/compte peut casser le checkout ou créer des bugs intermittents très coûteux. Une boutique “gros catalogue” qui reste sur un mutualisé sans tuning fin finira mécaniquement par plafonner en SEO (crawl + UX). Pour un socle Debian dédié et ses choix d’optimisation : Serveur dédié PrestaShop : installation et optimisation Debian pour gros catalogue. Pour la stratégie “gros catalogue + CWV” : PrestaShop performance : optimiser gros catalogues et Core Web Vitals.

Validation continue : monitoring, alertes et prévention des régressions SEO

En 2025, le SEO technique n’est pas un audit ponctuel : c’est un contrat de non-régression. Mettez en place une CI minimale : tests de statut HTTP sur un échantillon d’URL, vérification du canonical, présence des balises meta robots attendues, et validation du sitemap. Sur chaque déploiement de thème/module, comparez un snapshot (headers + HTML minimal) pour détecter la disparition d’un canonical, l’ajout d’un noindex, ou l’injection d’un script qui casse l’INP.

Checklist “non-régression” simple (efficace même sans grosse équipe) :

• Un échantillon fixe : 20 produits, 10 catégories, 5 pages CMS, 10 pages à paramètres.
• Pour chaque URL : statut HTTP, canonical, meta robots, présence dans sitemap (oui/non), temps de réponse.
• Un échantillon variable : les 50 URLs les plus crawlées par Googlebot (via logs) → pour détecter l’émergence d’un nouveau pattern parasite.

Côté production, instrumentez. Un stack simple et efficace : Prometheus + alerting sur erreurs 5xx, latence p95/p99, saturation PHP-FPM, et timeouts DB. Les alertes doivent être actionnables (seuils, runbook, owner). Pour la partie métriques/alerting : Prometheus : configuration des alertes, métriques et requêtes PromQL. Pour les boutiques utilisant des files de jobs (emails, exports, reindexations), surveillez aussi la queue (backlog, retries) : Symfony Messenger : configuration avancée, choix du transport et performances.

Dernier point, souvent négligé : documentez vos décisions. Pour chaque pattern d’URL, notez : indexable ? noindex ? canonical vers quoi ? bloqué robots ? présent dans sitemap ? Cette “matrice d’indexation” évite que le prochain intervenant “optimise” en ré-ouvrant les facettes, ou que l’équipe produit ajoute des paramètres de tracking qui explosent le crawl.

Modèle de matrice (format tableur) à tenir à jour :

Pattern	Exemple	Crawl autorisé	Indexation	Canonical	Sitemap	Owner
Catégories	/categorie/chaussures	Oui	Oui	self	Oui	SEO
Tri	?order=price-desc	À décider	Non (noindex)	URL propre	Non	SEO/Tech
Tracking	?utm_source=...	Oui (idéalement normalisé)	Non	URL propre	Non	Marketing/Tech
Recherche	/recherche?search_query=...	Oui	Non (noindex)	—	Non	Produit

Et si vous préparez une montée de version, alignez cette checklist avec votre plan de migration/validation (staging, diff SEO, redirections) : Migration PrestaShop 9 : checklist complète sécurité, SEO, performance.