SEO PrestaShop : optimiser fiches produits, schema.org et images WebP

Table des matières :

1. Fiches produits PrestaShop : URL propres, canonicals et gestion des doublons
2. Contenu et structure des fiches : Hn, attributs, données “catalogue” et signaux d’intention
3. schema.org dans PrestaShop : Product/Offer/Review/Breadcrumb en JSON-LD (sans tricher)
4. Images WebP (et AVIF) sur PrestaShop : génération, delivery, templates et cache
5. Validation : tests Rich Results, Core Web Vitals, logs et rollback propre

Fiches produits PrestaShop : URL propres, canonicals et gestion des doublons

Sur PrestaShop, la fiche produit est souvent la page qui concentre le plus de signaux SEO (contenu + maillage + conversions). Le problème, c’est que le cœur facilite aussi la création de doublons : combinaisons accessibles via paramètres, pages atteignables depuis des catégories multiples, tri/pagination, navigation à facettes, etc. Votre première optimisation “SEO PrestaShop” n’est donc pas un wording de méta-title : c’est de verrouiller l’URL canonique et d’éliminer les variantes crawlables inutiles.

Un bon réflexe “audit” consiste à quantifier le risque. Exemple simple : 8 000 produits × 12 déclinaisons en moyenne = 96 000 URL potentielles si chaque variation est exposée via ?id_product_attribute= et indexable. Ajoutez le tri (?order=), la pagination (?page=), des filtres (?q=), et vous pouvez vite dépasser quelques centaines de milliers d’URL découvrables… pour une base de contenu qui, elle, n’a pas grossi.

Concrètement, vérifiez comment vos liens produits sont générés. Dans PrestaShop 8.1.x et 9.x, la génération passe toujours par Link (legacy) côté front, et par des routes Symfony côté back-office, avec des ponts _legacy_link. Si vous avez des overrides (surcharges) ou un module qui injecte des paramètres (ex. ?id_product_attribute=), vous risquez d’exposer plusieurs URL pour le même contenu. Pour comprendre précisément où et comment l’URL est construite (et où corriger), partez du fonctionnement décrit dans Génération d’URL PrestaShop : Link, routes Symfony et legacy_link.

Ensuite, traitez le canonique comme un contrat strict : une fiche produit = une URL canonique. Si vous acceptez que la combinaison “taille/couleur” change le prix et la dispo, ne laissez pas Google indexer une URL par combinaison sauf cas très spécifique (catalogue mode avec variantes réellement distinctes, et encore). La plupart du temps, il vaut mieux : (1) exposer une URL produit canonique, (2) laisser le JS changer la déclinaison via AJAX sans changer d’URL, (3) publier des signaux structurés (schema.org) cohérents pour la variante par défaut. Si vous avez besoin d’URL de variantes pour l’UX, imposez un rel=canonical vers l’URL produit principale.

Pour rendre cela robuste, ajoutez une checklist “anti-duplication” (spécifique e-commerce) :

• Liens internes : assurez-vous que le site (catégories, produits associés, cross-sell, recherche interne) pointe majoritairement vers l’URL canonique sans paramètres. Si vous laissez des liens internes propager des URL à paramètres, Google les découvrira (et les testera), même si vous canonicalisez.
• Réglage BO : dans SEO & URLs, vérifiez la logique de redirection vers l’URL canonique (utile pour limiter les variantes accessibles). Testez avec et sans slash final si votre stack le modifie.
• Sitemaps : votre sitemap doit lister uniquement les URL canoniques. Si votre module de sitemap inclut des URL “sales” (paramétrées, ou non canoniques), vous envoyez un signal contradictoire.
• Facettes et filtres : si votre navigation à facettes génère des URLs crawlables (et que le catalogue est volumineux), prévoyez une stratégie : pages facettées utiles (indexables) vs combinaisons infinies (à contrôler par noindex et/ou règles de crawl au niveau serveur).
• Pagination/tri : ne laissez pas des paramètres de tri créer des pages “concurrentes” du canonique. Très souvent, le bon compromis est : pages paginées crawlables (si nécessaires) mais canonique sur la première page, et paramètres de tri non indexables.
• Logs crawl : validez en observant ce que Googlebot consomme réellement. Une simple revue de logs peut révéler qu’un module, un widget, ou un template injecte des URLs à paramètres à grande échelle (souvent via des blocs “nouveaux produits / best-sellers”).

L’idée n’est pas d’interdire toute variation d’URL : c’est de décider quelles variations méritent un budget crawl et un potentiel d’indexation — et lesquelles diluent la popularité et polluent les signaux.

Contenu et structure des fiches : Hn, attributs, données “catalogue” et signaux d’intention

Sur un thème PrestaShop, la dérive classique est un HTML “plat” : un H1, puis des blocs sans hiérarchie, puis des onglets qui masquent le vrai contenu (ou le chargent tard). Pour un SEO PrestaShop propre, structurez la fiche comme un document : H1 unique (nom produit), H2 pour “Description”, “Caractéristiques”, “Livraison/retours”, et H3 pour les sous-parties techniques. L’objectif est double : améliorer le parsing sémantique et éviter que le contenu utile soit repoussé dans des zones peu visibles ou rendues uniquement côté client.

Un point pratique (souvent négligé) : si votre thème place la description et les caractéristiques dans des onglets, vérifiez si le contenu est présent dans le HTML initial (côté serveur). Si vos blocs sont injectés après interaction (ou chargés via XHR), vous vous exposez à une indexation plus instable et à des rendus incomplets selon les conditions de rendu. Sur une fiche produit, mieux vaut que l’essentiel (description synthétique, caractéristiques clés, infos de livraison) soit disponible dès le chargement.

Ne sous-estimez pas les champs “catalogue” qui se traduisent en entités exploitables : référence, EAN/GTIN, marque, caractéristiques, pièces jointes, compatibilités, délais, conditions de garantie. Ces données nourrissent (a) les extraits enrichis via schema.org, (b) le matching d’intention (requêtes longues), et (c) vos systèmes internes (recherche, filtres, feed). Si vous ne les renseignez pas, vous forcez Google (et votre moteur interne) à inférer depuis une description souvent bruitée. C’est particulièrement visible sur les sites où la recherche interne est un canal de conversion fort : pondérations et indexation côté PrestaShop sont déterminants, et vous gagnez à comprendre ce que le cœur indexe réellement (et comment) via Index de recherche PrestaShop : fonctionnement, tables SQL et pondérations.

Pour enrichir sans “blablater”, visez des blocs qui répondent à des questions d’achat réelles et mesurables (support, retours, demandes SAV). Exemples de micro-structures utiles sur une fiche produit :

• Tableau “Caractéristiques clés” (5 à 12 lignes max) : dimensions, matériau, poids, compatibilités, norme, contenu du colis. Les tableaux se scannent mieux que des paragraphes.
• Checklist “Avant d’acheter” : compatibilité, outils nécessaires, prérequis (ex. type de raccord, tension, format).
• FAQ courte (2 à 5 questions) : livraison, montage, entretien, pièces compatibles. Inutile d’en mettre 15 : mieux vaut 4 questions très fréquentes et factuelles.

Mini-scenario (très courant en France/Belgique/Suisse francophone) : vous vendez un accessoire technique, et les requêtes sont du type “référence + modèle” ou “compatible + appareil”. Si vous indiquez clairement “Compatible avec : Marque X / Modèle Y / Réf Z” sous forme de liste, vous (1) réduisez les retours, (2) améliorez la conversion, (3) captez des requêtes longues qualifiées. Ce gain est rarement obtenu par une description marketing seule.

Enfin, arrêtez de traiter “SEO fiche produit” comme un bloc de texte marketing. La fiche doit répondre à des questions techniques implicites : compatibilité, dimensions EXACTES, contenu du pack, contraintes d’installation, consommables, normes, etc. Exemple concret : sur un catalogue de pièces détachées, une section “Références compatibles” (liste structurée, pas un paragraphe) réduit les retours et augmente le taux de conversion, tout en générant des impressions sur des requêtes de type ref + modèle. Dans PrestaShop, ça se modélise proprement via Features (caractéristiques) et, si nécessaire, une table dédiée alimentée par module (évitez d’encoder ça dans description_short).

schema.org dans PrestaShop : Product/Offer/Review/Breadcrumb en JSON-LD (sans tricher)

Si vous faites du SEO PrestaShop sérieux, le balisage schema.org n’est pas “optionnel” : c’est un protocole de données, pas un gadget. Google est explicite sur le fait que les données structurées servent à comprendre le contenu et à éligibiliser des résultats enrichis : elles n’obligent pas l’affichage, mais elles conditionnent l’éligibilité et la cohérence. Dans la documentation officielle, Google rappelle : « Structured data is a standardized format for providing information about a page and classifying the page content. » (Google Search Central, Understand structured data : Understand structured data (Google)). Pour l’implémentation, privilégiez JSON-LD injecté dans <head> (ou au minimum avant la fermeture du </body>), pas du microdata dispersé.

Le cœur PrestaShop et les thèmes “ready-to-use” produisent souvent un mélange de microdata incomplet, de champs manquants (GTIN, brand), et de valeurs incohérentes quand le prix change par déclinaison. Résultat : erreurs dans Rich Results Test, et surtout signaux contradictoires. Vous avez deux stratégies propres : (1) implémenter votre JSON-LD dans le thème enfant (override du template produit), (2) créer un module minimaliste qui hooke sur un point stable (ex. displayHeader ou un hook produit) et passe au template les données calculées côté PHP.

Pour cadrer la cohérence, gardez une règle simple : tout ce qui est balisé doit être visible (et vrai) sur la page. Sur un site e-commerce en EUR, cela signifie notamment :

• prix identique entre le visible et le JSON-LD (attention aux changements par déclinaison),
• disponibilité cohérente (ne pas baliser InStock si le bouton “Ajouter au panier” est remplacé par “Indisponible”),
• devise correcte (EUR la plupart du temps en France),
• URL absolue (HTTPS) cohérente avec les canonicals.

Mapping recommandé (et pièges PrestaShop)

• Product.name : nom du produit (langue courante)
• Product.image : URL absolue de l’image principale (attention HTTPS, CDN, trailing slash)
• Product.sku : référence produit (reference) ou référence déclinaison si vous choisissez une variante par défaut
• gtin13 / gtin14 : mappez le champ EAN/UPC si présent, sinon ne mentez pas (évitez "N/A")
• brand : {"@type":"Brand","name":"…"}
• offers : Offer ou AggregateOffer selon vos variantes
• availability : utilisez les URI schema.org (https://schema.org/InStock, OutOfStock, PreOrder, etc.)

Astuce “qualité” : ajoutez, quand c’est pertinent et disponible côté catalogue, quelques champs qui améliorent la précision sans sur-promettre :

• offers.priceValidUntil si vous avez des promotions à date fixe (sinon, abstenez-vous),
• offers.itemCondition (ex. https://schema.org/NewCondition) si votre catalogue est standard,
• offers.shippingDetails uniquement si vous êtes capable de l’alimenter proprement (sinon, mieux vaut rester minimaliste et cohérent).

La question la plus fréquente : Offer vs AggregateOffer. Si vos déclinaisons ont des prix/dispos différentes, AggregateOffer est souvent plus cohérent pour une URL unique (lowPrice/highPrice/offerCount). Si vous avez une variante “par défaut” stable (celle rendue serveur), vous pouvez publier un Offer unique aligné sur cette variante, mais vous devez accepter que Google ne verra pas forcément le prix sélectionné par l’utilisateur après interaction JS.

Voici un exemple JSON-LD “safe” côté serveur (à adapter) :

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "{$product.name|escape:'htmlall':'UTF-8'}",
  "image": ["{$product.cover.large.url|escape:'htmlall':'UTF-8'}"],
  "description": "{$product.description_short|strip_tags|truncate:160:''|escape:'htmlall':'UTF-8'}",
  "sku": "{$product.reference|escape:'htmlall':'UTF-8'}",
  "brand": {"@type":"Brand","name":"{$product.manufacturer_name|escape:'htmlall':'UTF-8'}"},
  "offers": {
    "@type": "AggregateOffer",
    "priceCurrency": "{$currency.iso_code|escape:'htmlall':'UTF-8'}",
    "lowPrice": "{$product.price_amount_min|escape:'htmlall':'UTF-8'}",
    "highPrice": "{$product.price_amount_max|escape:'htmlall':'UTF-8'}",
    "offerCount": "{$product.offer_count|escape:'htmlall':'UTF-8'}",
    "url": "{$product.url|escape:'htmlall':'UTF-8'}"
  }
}
</script>

La partie “reviews/aggregateRating” est un champ de mines : si vous n’avez pas de système d’avis robuste (modération, anti-spam, avis vérifiés), n’injectez pas d’aggregateRating artificiel. Google est très strict sur la cohérence entre le visible et le balisé. Si vous avez des avis, suivez la checklist (Review, Rating, author, datePublished, etc.) et vérifiez systématiquement via le test officiel. Pour une implémentation plus large (Product/Review/Breadcrumb + maillage), vous pouvez vous appuyer sur SEO e-commerce : implémenter schema Product Review Breadcrumb et maillage interne, mais gardez en tête que chaque custom doit être validé sur vos templates.

Côté Breadcrumb, utilisez aussi JSON-LD (BreadcrumbList) plutôt qu’un fil d’Ariane “visuel” sans data. Référence : schema.org/BreadcrumbList et doc Google : Google — Breadcrumb structured data.

Enfin, si vous suspectez des incohérences (prix, disponibilité, images), utilisez aussi le test d’URL dans Google Search Console (rendu HTML + ressources) : c’est souvent le moyen le plus rapide de voir si Google récupère le même état de page que vos visiteurs.

Images WebP (et AVIF) sur PrestaShop : génération, delivery, templates et cache

Optimiser les images n’est pas un détail cosmétique : sur e-commerce, l’image principale est souvent le LCP, donc un levier direct sur Core Web Vitals. web.dev — Largest Contentful Paint rappelle la cible : « To provide a good user experience, LCP should occur within 2.5 seconds of when the page first starts loading. ». Si votre fiche produit charge un JPEG de 400–800 KB en héro, vous venez de saboter votre budget de performance.

WebP est un standard pragmatique parce qu’il est supporté par tous les navigateurs modernes. Google indique : « WebP lossless images are 26% smaller in size compared to PNGs. » et « WebP lossy images are 25–34% smaller than comparable JPEG images. » (Google Developers — WebP). En 2026, AVIF peut être encore meilleur, mais la chaîne de production (encodage/qualité/CPU) et la compatibilité CDN/serveur doivent être maîtrisées. Si vous voulez un ROI rapide et stable : WebP d’abord, AVIF ensuite si votre pipeline est propre.

Deux points concrets à viser sur une fiche produit :

• Poids : réduire drastiquement l’image héro (souvent la plus lourde).
• Stabilité : s’assurer que WebP est réellement servi (bon Content-Type, bon Vary, bon cache), pas seulement “généré”.

Génération : offline (recommandé) vs à la volée (à éviter)

PrestaShop génère des déclinaisons d’images (types home_default, large_default, etc.) dans /img/p/… ou via un CDN si configuré. Le cœur n’a pas de pipeline WebP/AVIF natif homogène selon versions/thèmes, donc la génération “à la volée” au premier hit est une mauvaise idée (CPU, latence, cache incohérent). La stratégie propre :

1) Générer les .webp en tâche offline (cron/CLI) après régénération des miniatures.
2) Servir conditionnellement WebP si le navigateur l’accepte (Accept: image/webp).
3) Garder un fallback JPEG/PNG.

En pratique, sur un serveur Linux, vous pouvez utiliser cwebp (package webp) ou ImageMagick (magick input.jpg -quality 82 output.webp). Attention : lancez ça hors heures de pointe, et surveillez l’I/O (sur gros catalogues, ça tape). Côté infra, si vous n’avez pas de marge CPU/IO, commencez par stabiliser le socle (NVMe, caches, reverse proxy) — voir Serveurs dédiés infogérés e-commerce : NVMe, Redis, Varnish et haute disponibilité.

Point méthode : faites un test sur un échantillon (par exemple 200 produits représentatifs) et validez :

• le gain de poids moyen,
• l’impact sur la qualité (notamment sur des photos produit avec texte ou détails fins),
• la charge serveur pendant la génération (CPU/IO),
• le comportement du CDN (si vous en avez un) et l’invalidation.

Delivery : Apache .htaccess et Nginx try_files

Sur Apache (mod_rewrite activé), le pattern classique consiste à servir un .webp s’il existe et si le client l’accepte. Exemple (à adapter, à tester en staging, et à rollback si conflit avec d’autres règles) :

RewriteEngine On

# Servir .webp si accepté et si le fichier existe
RewriteCond %{HTTP_ACCEPT} image/webp
RewriteCond %{REQUEST_FILENAME} \.(jpe?g|png)$
RewriteCond %{REQUEST_FILENAME}.webp -f
RewriteRule ^(.+\.(jpe?g|png))$ $1.webp [T=image/webp,E=accept:1,L]

<IfModule mod_headers.c>
  Header append Vary Accept env=accept
</IfModule>

Sur Nginx, on préfère un try_files dans un location images (en tenant compte du chemin réel PrestaShop) :

location ~* \.(png|jpe?g)$ {
  add_header Vary Accept;
  try_files $uri.webp $uri =404;
}

Le point critique : le cache. Si vous avez Varnish/CDN, le Vary: Accept doit être correctement géré, sinon vous servez du WebP à un client qui ne le supporte pas (ou l’inverse). Si vous êtes déjà sur une stack cache multi-niveaux, relisez vos règles de cache et d’invalidation avant de toucher aux images : Cache PrestaShop : Varnish, Redis, Memcached et OPcache côté serveur et, en période de charge, PrestaShop soldes : optimiser caches, CDN et Varnish pour trafic élevé.

Checklist de validation “delivery” (rapide mais efficace) :

• dans DevTools (onglet Network), vérifier Content-Type: image/webp sur les images servies en WebP ;
• vérifier Vary: Accept sur les réponses d’images ;
• vérifier que deux navigateurs (ou deux requêtes curl avec Accept) reçoivent bien des formats différents ;
• vérifier que votre CDN ne “mélange” pas les variantes (c’est un symptôme classique quand Vary n’est pas pris en compte).

Pour approfondir le diagnostic côté protocole, la documentation MDN sur l’en-tête Vary est une référence utile : MDN — Vary header

Templates : <picture>, srcset, lazy-loading (sans casser le thème)

Le “bon” rendu côté front est de préférer <picture> pour annoncer WebP, avec fallback JPEG/PNG. Sur un thème Smarty (Classic et dérivés), vous pouvez wrapper l’image principale produit :

<picture>
  <source type="image/webp" srcset="{$product.cover.bySize.large_default.url}.webp">
  <img
    src="{$product.cover.bySize.large_default.url}"
    width="{$product.cover.bySize.large_default.width}"
    height="{$product.cover.bySize.large_default.height}"
    alt="{$product.name|escape:'htmlall':'UTF-8'}"
    loading="lazy"
    decoding="async"
  >
</picture>

Deux remarques non-négociables : (1) renseignez width/height pour limiter le CLS, (2) ne mettez pas loading="lazy" sur l’image LCP si elle est au-dessus de la ligne de flottaison (ça peut dégrader LCP). Pour les miniatures (product-miniature), lazy-loading est pertinent, mais testez l’impact réel (Lighthouse + WebPageTest) au lieu d’appliquer des “recettes”.

Autre point souvent rentable : utilisez srcset (et potentiellement sizes) pour éviter d’envoyer une image “large_default” à un mobile. Même sans refaire toute la chaîne responsive, une sélection de 2–3 tailles bien choisies peut réduire fortement le poids transféré sur smartphone, sans toucher au design.

Validation : tests Rich Results, Core Web Vitals, logs et rollback propre

Vous ne “faites” pas du SEO PrestaShop en déployant des templates au doigt mouillé. Vous mesurez, vous validez, vous monitorez. Pour schema.org : utilisez le Rich Results Test et le validateur schema.org validator. Pour la perf : Lighthouse (CI ou local), WebPageTest, et les rapports CrUX / Search Console. L’objectif n’est pas d’avoir un score 100 ; c’est de supprimer les régressions évidentes (LCP, CLS, TTFB) et de stabiliser.

Pour éviter les faux positifs, adoptez un protocole “avant / après” sur un petit set de pages (10–30 URL) :

• 5 fiches produit très visitées (top ventes),
• 5 fiches produit lourdes (images nombreuses),
• 5 fiches produit avec déclinaisons (prix variable),
• quelques catégories clés (car elles alimentent les fiches).

Notez les métriques et les vérifications indispensables :

• SEO : canonique présent et correct, codes HTTP (200/301), absence de duplication évidente, sitemap cohérent.
• Schema : Rich Results Test sans erreurs critiques, cohérence prix/dispo/image.
• Perf : LCP/CLS sur mobile, poids total transféré, nombre de requêtes, cache (HIT/MISS si vous avez Varnish/CDN).

Côté diagnostic, ne négligez pas les logs : un template mal modifié peut déclencher des erreurs PHP/Smarty, des 500 intermittentes, ou des timeouts sur les endpoints d’images (surtout si vous faites de la conversion à la volée, ce qui est précisément ce qu’il faut éviter). Si vous n’avez pas déjà une routine de surveillance, mettez-en une avant de toucher au rendu produit : PrestaShop monitoring d’erreurs : logs PHP, MySQL, JavaScript et alertes e-mail. Et si vous devez profiler, activez proprement les outils (sans laisser traîner en prod) : PrestaShop debug profiling : activer et analyser performances SQL.

Enfin, formalisez un plan de rollback. Toucher .htaccess, Nginx, Varnish, ou la génération d’images, ce n’est pas “un petit changement front” : c’est une modification de delivery qui peut impacter tout le site. Travaillez en staging, versionnez vos templates, documentez les diffs, et gardez une checklist de contrôle avant publication (HTTP codes, canonicals, balisage, perf). Une méthodologie reproductible d’audit (avant/après) évite 80% des surprises : Audit SEO technique : contrôle qualité avant publication des pages web et, côté TTFB, gardez un objectif chiffré (et testez-le) : TTFB PrestaShop : réduire le Time To First Byte sous 200 ms.

Si vous appliquez ces trois axes — fiche produit propre (URL/canonique/contenu), schema.org cohérent (JSON-LD aligné sur le visible), images WebP servies correctement (sans casser le cache) — vous couvrez l’essentiel du SEO PrestaShop moderne, avec des améliorations qui se mesurent : moins d’erreurs de données structurées, baisse du poids page, meilleur LCP, et surtout une indexation plus stable sur les pages qui comptent vraiment (produits).