Données structurées PrestaShop : prix, stock et avis lisibles par les moteurs

Les données structurées déclarent à Google, dans un vocabulaire commun (schema.org), le prix, la disponibilité et la note que la fiche produit affiche déjà. D’après le code du thème Classic, PrestaShop émet un bloc de balisage à chaque fiche produit. Au 14 octobre 2026, ce balisage peut changer d’émetteur : depuis la version 9.2.0, publiée le 30 septembre 2026, le cœur le construit et le thème décide de l’afficher. Google n’en garantit jamais l’affichage.

• Les données structurées décrivent à Google ce que la fiche produit affiche déjà
• Le thème Classic de PrestaShop émet déjà un balisage de produit dont le tableau liste les champs
• La disponibilité balisée se déduit du stock, avec quatre valeurs possibles
• Le prix balisé suit l’affichage de PrestaShop, taxes comprises ou non
• PrestaShop 9.2 confie la fabrication du balisage au cœur : le thème choisit de l’afficher
• Les étoiles demandent de vrais avis, visibles sur la page
• Le test des résultats enrichis puis la Search Console contrôlent le balisage
• Une boutique dont le balisage est valide et concorde avec la page n’a rien à ajouter
• Sources consultées
• Foire aux questions

Les données structurées décrivent à Google ce que la fiche produit affiche déjà

Le vocabulaire de schema.org définit Product comme toute offre de produit ou de service. Une Offer porte le prix, la devise et la disponibilité. Un AggregateRating porte la note d’ensemble, calculée sur une collection d’avis. Google recommande le format JSON-LD, un bloc de données placé dans la page, et accepte aussi les microdonnées.

Deux usages coexistent chez Google. Les extraits de produit s’adressent aux pages où l’on ne peut pas acheter ; les fiches marchands, aux pages d’achat. Les propriétés exigées pour les fiches marchands ouvrent aussi l’éligibilité aux extraits. Selon la page de Google sur les produits, l’affichage reste à la discrétion de chaque fonction et n’est pas garanti.

Le thème Classic de PrestaShop émet déjà un balisage de produit dont le tableau liste les champs

Le gabarit product-jsonld.tpl du thème Classic (version 3.1.2, publiée le 11 mai 2026) donne à chaque fiche produit, d’après son code, un bloc de type Product. Le tableau compare ses champs aux exigences de Google pour les fiches marchands.

Au niveau produit, l’UPC, un code de 12 chiffres, est inscrit tel quel dans gtin13 ; au niveau de l’offre, le gabarit lui ajoute un zéro initial. Selon schema.org, un UPC devient un GTIN-13 par ce zéro. Autre point : le gabarit ne contient ni ProductGroup ni hasVariant, que Google réserve au regroupement des déclinaisons.

La disponibilité balisée se déduit du stock, avec quatre valeurs possibles

Le code de PrestaShop (versions 8.2.8 et 9.2.0) retient quatre cas. Une fiche inactive reçoit Discontinued. Une quantité positive, ou une gestion du stock désactivée, donne InStock. Une quantité nulle avec commande autorisée en rupture donne BackOrder. Le reste donne OutOfStock.

Les autres valeurs du vocabulaire, dont PreOrder et LimitedAvailability, ne sortent jamais de ce calcul. Scénario : une boutique vend en précommande et affiche « Précommande » grâce à un module. Le bloc dit BackOrder ou OutOfStock, pas PreOrder. Contrôlez trois fiches, l’une en stock, l’une en rupture et l’une commandable en rupture (réglage de commande en rupture de la fiche produit), et lisez la valeur du bloc.

Le prix balisé suit l’affichage de PrestaShop, taxes comprises ou non

Le prix du bloc reprend, d’après le code de PrestaShop, le montant affiché : toutes taxes comprises ou hors taxes selon le réglage d’affichage appliqué au visiteur. Scénario : un groupe de clients professionnels voit les prix hors taxes. Un visiteur non connecté, robot compris, dépend du groupe Visiteur et de son propre réglage : le bloc suit le prix de ce visiteur-là. Le contrôle compare, pour un produit remisé, le prix lu dans le code source à celui que la page affiche.

Google peut vérifier les données d’une fiche marchande avant l’affichage, d’après la page sur les fiches marchands. Pour le flux de produits envoyé à Merchant Center, l’aide du service exige en France un prix toutes taxes comprises, identique à celui de la page. La version 9.2 arrondit le prix du balisage à la précision d’affichage, d’après ses notes de version.

La date de validité mérite sa propre attention. Une page servie depuis un cache plus ancien que 15 jours expose une date passée. C’est une déduction du gabarit : vérifiez le code source de la page telle que le visiteur la reçoit.

Décrire mon besoin →

PrestaShop 9.2 confie la fabrication du balisage au cœur : le thème choisit de l’afficher

La liste des changements de la 9.2.0-beta.1 (22 juillet 2026) comprend une modification intitulée « Render structured data on core side ». D’après le code de la 9.2.0, la fiche produit construit un Product avec nom, adresse web, description, images, identifiants, marque, caractéristiques, prix et disponibilité. La version 9.1.5 ne porte pas ce mécanisme, ni la 9.0.0.

Le thème décide ensuite. Hummingbird (branche de développement et version 2.1.2, publiée le 24 septembre 2026) affiche ces données quand elles existent, d’après son code, et retombe sur ses gabarits sinon. La branche de développement de Classic ne les lit pas, toujours d’après son code : sur une 9.2 avec Classic, c’est le gabarit qui parle.

Un hook, point d’accroche que PrestaShop offre aux modules, transporte les avis. Le commentaire du code de la 9.2.0 y renvoie les avis, et le balisage du cœur ne contient aucune note. Le module productcomments (version 9.0.0, publiée le 9 septembre 2026) en ajoute une à partir de la 9.2. Un module tiers de balisage, un thème et le cœur forment trois émetteurs possibles pour une page. Les pages de Google lues ne disent pas comment il tranche entre deux blocs concurrents ; garder une seule source est une précaution déduite, non une règle de Google.

Les étoiles demandent de vrais avis, visibles sur la page

Une note d’ensemble exige, selon la page de Google sur les avis, un nombre d’avis ou de notes, une note moyenne et des avis visibles des visiteurs. Les faux avis sont interdits, tout comme l’agrégation d’avis venus d’autres sites. Un module qui affiche les avis d’une plateforme tierce se vérifie contre cette règle avant tout balisage. Une fiche sans avis n’émet aucune note, d’après le code de PrestaShop, et le module calcule la moyenne selon le réglage de modération des avis. Sans module d’avis, la boutique n’a rien à déclarer.

Le test des résultats enrichis puis la Search Console contrôlent le balisage

Le test des résultats enrichis de Google lit une adresse et classe les erreurs critiques à corriger. Les avertissements non critiques n’empêchent pas l’éligibilité, selon la page de Google sur les extraits de produit. Un contrôle complet suit quatre gestes.

• Collez l’adresse d’une fiche produit dans le test des résultats enrichis.
• Comparez les valeurs du bloc au prix, au stock et aux avis visibles.
• Passez l’adresse dans l’outil d’inspection d’URL : la page ne doit être bloquée ni par le robots.txt (interdiction d’exploration), ni par noindex (interdiction d’affichage), ni par une connexion (voir l’indexation des filtres).
• Ouvrez les rapports de résultats enrichis de la Search Console : le rapport des fiches marchands, « Merchant listings », couvre les pages d’achat.

Suivez ces rapports après le déploiement, conseille Google : un balisage peut se casser à cause d’un gabarit ou d’un problème de diffusion. Relisez-les après chaque modification du thème ou d’un module.

Une boutique dont le balisage est valide et concorde avec la page n’a rien à ajouter

Un bloc qui passe le test et dit le même prix, le même stock et les mêmes avis que la page ne demande aucun module supplémentaire.

L’absence d’étoiles dans Google ne prouve pas une erreur. L’attente se justifie après une correction, le temps que Google relise les pages. L’action immédiate s’impose en cas d’écart de prix ou de stock, ou de date de validité passée. La montée en 9.2 ne se décide pas pour ce seul motif : le thème Classic y garde son gabarit.

La fiche elle-même, ses textes et ses photos relèvent de la refonte des fiches produits. Le flux de produits que Google lit à part se prépare dans les flux produits.

Le message du formulaire reçoit ces valeurs, pas un accès à la Search Console.

Décrire mon besoin →

Sources consultées

• Google, « Intro to How Structured Data Markup Works », mis à jour le 10 décembre 2025, consulté le 14 octobre 2026.
• Google, « Product structured data (Product, Review, Offer) », mis à jour le 10 décembre 2025, consulté le 14 octobre 2026.
• Google, « Product snippet (Product, Review, Offer) structured data », mis à jour le 8 septembre 2026, consulté le 14 octobre 2026.
• Google, « Merchant listing (Product, Offer) structured data », mis à jour le 8 septembre 2026, consulté le 14 octobre 2026.
• Google, « Review snippet (Review, AggregateRating) structured data », mis à jour le 8 septembre 2026, consulté le 14 octobre 2026.
• Google, « General structured data guidelines », mis à jour le 10 juillet 2026, consulté le 14 octobre 2026.
• Google, « Product variants (ProductGroup, Product) structured data », mis à jour le 8 septembre 2026, consulté le 14 octobre 2026.
• Google, aide Merchant Center, « Price [price] », consulté le 14 octobre 2026.
• Schema.org, types « Product », « Offer », « AggregateRating » et « ItemAvailability », consulté le 14 octobre 2026.
• PrestaShop, code du thème Classic, fichiers templates/_partials/microdata/product-jsonld.tpl (version 3.1.2 et branche de développement) et templates/_partials/head.tpl, consulté le 14 octobre 2026.
• PrestaShop, code du thème Hummingbird, fichier templates/_partials/head.tpl (branche de développement et version 2.1.2), consulté le 14 octobre 2026.
• PrestaShop, code du cœur, fichiers controllers/front/ProductController.php, classes/controller/FrontController.php et src/Adapter/Presenter/Product/ProductLazyArray.php, versions 8.2.8, 9.0.0, 9.1.5 et 9.2.0, consulté le 14 octobre 2026.
• PrestaShop, code du module productcomments, fichier productcomments.php (version 9.0.0), consulté le 14 octobre 2026.
• PrestaShop, notes de version « 9.2.0-beta.1 », consulté le 14 octobre 2026.

Foire aux questions

Un module tiers de balisage est-il utile si le thème en émet déjà un ?

Il se justifie pour un champ que le thème omet. Il faut alors vérifier qu’il remplace l’émetteur existant plutôt que de s’y ajouter : deux blocs Product sur une même page restent un risque. Le code source de la page montre chaque bloc présent.

Que faire quand la boutique n’a aucun avis client ?

Rien à déclarer. Pour les fiches marchands, la note est recommandée, pas exigée : le nom, l’image, le prix et la devise sont les propriétés exigées.

Faut-il un flux Merchant Center en plus du balisage ?

Selon la page de Google sur les produits, fournir les deux, le balisage de la page et un flux Merchant Center, maximise l’éligibilité ; certaines fonctions combinent les sources. D’après la page sur les fiches marchands, le flux au niveau produit l’emporte pour l’expédition et les retours sur les réglages du compte, puis sur le balisage. La préparation du flux relève des flux produits.

Les déclinaisons d’un produit ont-elles chacune leur balisage ?

D’après le gabarit Classic, un seul Product par page, sans ProductGroup ni hasVariant. La page de Google sur les variantes demande un identifiant unique par variante et une adresse qui préselectionne la variante par paramètre. Ouvrez une taille précise de votre boutique et lisez ce que le bloc renvoie.

Le balisage de l’organisation change-t-il en 9.2 ?

D’après le code de la 9.2.0, le cœur ajoute à l’Organization le téléphone, l’e-mail et l’adresse renseignés dans la boutique, ainsi que le logo avec ses dimensions. Seul un thème qui lit ces données les affiche : Hummingbird le fait, Classic 3.1.2 non. Vérifiez que ces coordonnées publiques sont celles à diffuser.