Structured data and product rich results in PrestaShop
Audit PrestaShop schema, correct product offers and variants, validate rich-result eligibility and monitor Search Console.
Use structured data to describe the products and business information customers can see on your store. Audit your current output before adding another provider, then validate the final public pages.
What we would do
We would keep accurate native output and repair a demonstrated gap before adding another generator. The route depends on your existing theme, SEO and review modules, catalogue data, pricing and stock integrations, markets and the team maintaining them. Record who owns each entity and which system supplies its values.
Rehearse a replacement on a staging copy with the same relevant modules and configuration, isolated from live emails and integrations. Keep staging access and indexing restrictions in place, and test captured HTML through the code input of the Rich Results Test and the Schema Markup Validator, since their URL tests may not reach a protected copy. Save the old configuration, prove the replacement survives cleanup and caching, then switch in a planned window with a rollback route. Recheck the public URLs after the switch.
If the source of conflicting markup is unclear, the PrestaShop SEO Audit & Action Plan can identify the cause and prioritise fixes for your developer.
Audit the active theme before adding markup
Schema.org supplies a vocabulary for products, offers, organizations and other entities. Google supports selected structured-data types for particular search features. Valid schema syntax and eligibility for a Google feature are separate checks. Google recommends JSON-LD where practical, while supported microdata remains valid; changing the format alone does not repair inaccurate values or missing required fields.
Classic theme versions can output JSON-LD for Product, Offer, Organization, WebSite or WebPage, breadcrumbs and product lists. Product output can include brand, identifiers, availability and conditional ratings. Older templates and customised themes can differ. Do not assume that PrestaShop only provides sparse microdata.
- Open a public product page and inspect its HTML for JSON-LD and microdata.
- Run the URL through the Rich Results Test.
- Repeat for a product with combinations, an unavailable item, a category, the homepage and a CMS page.
- Identify which theme or module owns each entity and which values it emits.
- Check the final response after caches and output-cleanup modules have run.
Multiple blocks are not automatically an error. They become a problem when they describe the same entity inconsistently. Keep identifiers and relationships coherent, and avoid competing prices or availability values.
Separate search features and requirements
Product data can reach Google through on-page structured data, Merchant Center feeds or both. On-page schema is not the sole route to every rich product experience. See Google's product-data overview.
| Feature | Core requirement | Practical check |
|---|---|---|
| Product snippet | A Product name and at least one of review, aggregateRating or offers, with that property's required fields | Validate the snippet use case rather than applying every merchant-listing rule |
| Merchant listing | A purchasable Product with name, image and an Offer, including the required active price and currency fields | Match the offer customers can buy on the page |
| Review enhancement | Applicable, genuine review or aggregate rating data | Check visible review content and the review guidelines |
| Breadcrumb appearance | A supported BreadcrumbList describing the page's hierarchy | Google can display breadcrumbs on desktop; mobile results use the domain |
Use the current product snippet and merchant listing requirements for each case. Required-field errors can block eligibility. Recommended-field warnings identify possible improvements; they do not all invalidate a listing.
Google stopped displaying FAQ rich results in May 2026. Keep useful questions on your page for customers, but do not plan an expandable Google FAQ result or FAQ rich-result monitoring. See the Search documentation updates.
Organization data can describe your business and policies. WebSite, CollectionPage and Article can describe other page types where appropriate. None guarantees a knowledge panel or a special search presentation.
Keep prices, availability and identifiers accurate
Generate offers from the product and customer-facing context used for the page. Check discounts, tax display, currency, condition and the selected combination. The schema's amount must agree with the visible offer.
Use real product identifiers. A shop SKU is not automatically a manufacturer part number or GTIN. Supply a brand from your catalogue's actual brand data, and avoid inventing missing values to remove a warning.
Zero stock does not always mean OutOfStock. If the selected item can be ordered for later delivery, its ordering policy can require BackOrder. Map availability from both quantity and the actual order policy.
Include priceValidUntil only when the offer has a real expiry. Do not insert the end of the year or a rolling future date just to fill the field. Inspect generated output even when a theme or module supplies that value automatically.
For offer-level details, use shippingDetails containing OfferShippingDetails and hasMerchantReturnPolicy containing MerchantReturnPolicy, and supply your actual countries, costs, delivery times, methods and policies. Do not copy illustrative free returns or fixed shipping prices into production markup. Complete the required nested properties when you add those enhancements.
For custom generation, construct a data structure on the server and serialize it with a proper JSON encoder and safe script-embedding flags. JavaScript string escaping is not a substitute for JSON serialization.
Describe combinations with stable variant identities
Different combinations can have different prices, images, identifiers and stock. Test them individually. An offer for the default combination cannot silently stand for every available size or colour.
Google's variant model uses ProductGroup with productGroupID, variesBy and hasVariant. Each variant Product needs a distinct identity and appropriate offer data.
Provide a URL that preselects the variant and displays its image, price and availability. Confirm that the customer can add that selected variant to the cart. Choose canonical handling that fits whether variants share one page or use separate pages.
Automatic SEO Schema Rich Snippets can use ProductGroup and variant Products when suitable distinct variant URLs are available. Otherwise it can publish the displayed combination's Offer. Configuration and integration steps belong in the schema module help.
A combination before and after the fix
Consider a T-shirt whose small size is in stock while its more expensive large size can be ordered for later delivery. Before the fix, opening the large-size URL shows the correct selection to shoppers, but its structured data still describes the cheaper small size as InStock.
After the fix, reopening that URL directly selects the large size, shows its current price and ordering terms, and describes that same variant and offer. Check its identity, image, identifier and availability, then add it to the cart to confirm the selection survives. If the URL cannot reliably preselect the combination, resolve that limitation before publishing a variant group.
Publish genuine reviews and ratings
Mark up ratings and reviews that belong to the product and are available to visitors. Keep the aggregate, count and scale consistent with the review system. Do not invent reviews or use a selected sample as the overall rating.
There is no general rule that you must wait for a particular handful of reviews. The data must be genuine and satisfy the applicable review requirements. Supplying it still does not guarantee stars in search.
Important product data is more reliable when present in the initial HTML. JavaScript-rendered reviews are not automatically invisible to Google. Use rendered output in URL Inspection or the Rich Results Test to check what is available, rather than deciding from View Source alone.
If your reviews module and schema provider are separate, confirm the integration. An Offer can be valid while no rating is supplied. Fix the data connection instead of hard-coding a rating.
Choose and maintain one coherent implementation
You can keep native output, customize templates or use a module. Base the choice on the missing behaviour and who will maintain it. A child theme is not inherently overwritten by every update, and a hooked module is not automatically compatible with every future release.
| Your audit finds | Starting choice | Evidence to ask for |
|---|---|---|
| Native output is accurate and covers your target feature | Keep it | Representative pages pass the relevant tests |
| A custom price or review integration supplies the wrong values | Repair the data connection | The generator reads the same source as the visible page |
| Coverage is missing and staff need back-office controls | Assess a schema module against the gap | Compatibility with your theme, reviews and cleanup |
| An unusual catalogue or pricing rule needs custom generation | Use a maintained template or module integration | A named maintainer, repeatable tests and an update plan |
Use staging to check theme, review and SEO-module interactions. If you replace existing markup, confirm that cleanup preserves the intended new output and does not remove unrelated useful entities.
The schema module marks its generated JSON-LD with data-mprschema="1", and its cleaner preserves that ownership attribute. Validate the final page after cleanup and confirm that the intended JSON-LD remains present.
Fill the underlying catalogue data first. An automatic generator cannot supply a missing genuine identifier or review. Keep preview validation and public-page validation as separate steps.
On staging, change a test product's price and ordering availability through the normal catalogue or integration workflow. Compare fresh and cached responses. If the visible page updates but its schema changes only after a manual purge, trace cache invalidation before launch. Repeat for the languages, currencies and shops you actually publish.
Validate output and measure search behaviour
The Rich Results Test checks supported Google features. The Schema Markup Validator checks schema vocabulary and structure more broadly. Inspect errors and optional warnings separately, and confirm that the reported values match the visible page.
Fix the cause in priority order
- Fix broken JSON and contradictions with the visible offer first, even if a validator accepts the syntax.
- Resolve required-field errors for the intended search feature. Group affected URLs by template or data source so you repair the shared cause.
- Assess optional warnings against genuine catalogue and policy data. Leave an unknown identifier absent rather than manufacturing it.
- Retest the affected page types after cache refresh, keep the before-and-after output, and use Search Console's validation workflow where available.
In Search Console, use the Shopping section's Product snippets and Merchant listings reports where available. Use relevant enhancement reports, such as Breadcrumbs, for other supported types. Inspect a changed URL and request indexing when appropriate; recrawling has no fixed completion time.
Valid markup makes an eligible page available for consideration. Google can still choose a plain result based on the query, page and presentation. Disappearing stars are not automatically proof of a new validation error.
Before changing the markup, export a Search Console baseline of impressions, clicks, CTR and position for the affected URLs and record the deployment date; repeat the export after Google has recrawled the changed pages. Use available Search appearance filters and compare similar queries, devices, countries and pages over comparable periods. A higher CTR on different rich-result pages does not prove that markup caused the difference.
Repeat representative page tests after changes to themes, prices, stock handling, reviews, URL generation or schema modules. See the merchant feeds guide for the separate product-feed workflow.
Questions owners ask
Can our team do this without editing templates?
Where the existing theme or a compatible module exposes the needed settings, yes. Give staff responsibility for catalogue facts and policies, and agree when a developer must handle a custom integration. Ask for a configuration handover they can repeat.
Should we put a single Product offer on a category page?
A category lists different products. Describe the collection and its items appropriately; do not present the whole list as a single purchasable product to chase a product result.
Will schema solve our wider SEO problems?
Do not buy it as a ranking uplift. Useful product content, crawl access and suitable page titles still need their own work. Assess richer presentation alongside those foundations.
What should we ask the developer or agency before sign-off?
Ask which generators changed, which entities remain, and where the tested URLs and before-and-after results are recorded. Request the rollback steps, the person responsible after updates, and evidence that a normal price or stock change reaches the final markup.