Short answer: Product schema is structured data on a product page that states the name, image, price, currency, availability, brand and identifiers in a form machines can read.
For a shop it makes the page eligible for Google's merchant listings and product snippets, and it gives AI assistants a clean copy of facts that are otherwise scattered through the page. It does not guarantee a listing, and nothing shows that the markup makes an AI engine recommend your product, so the rule that matters most is that the markup must always match what shoppers see.
What does product schema do, and what does it not?
A product page shows a price in one place, stock in another and the brand in a third. Product markup collects those facts into one structured block. Search features read it, and an AI assistant looking for the price or availability of a specific item has one tidy copy to read instead of inferring it from layout.
Be honest about outcomes. Markup makes a page eligible for product search features. It does not guarantee them, and no one outside the engines can show that markup makes an assistant recommend a product. The measurable proxy is whether engines cite your product page when shoppers ask questions, which is covered below.
Google's product rich results only support pages that focus on a single product, or multiple variants of the same product. Category pages and best-of lists are not eligible. (Google Search Central, Product structured data)
There is no product rule in the AEO Toolkit audit yet
The scoring engine does not fail a page for missing Product markup, so nothing in it can pass or fail product schema. Detection means reading its general structured-data findings and inspecting the page yourself. Do not tell anyone their audit passed product schema.
When does it apply, and when is it the wrong tool?
- It applies when you sell products directly: Or when a page lists a specific product people compare, with a price and a way to buy or evaluate it.
- It is wrong for category pages, blog posts and best-of lists: Google's product features support single-product pages. Marking a category up as if it were one product is a common mistake.
- It is wrong for services: A business that sells services should use local business or service markup instead.
- It is redundant if your shop already outputs it correctly: Many platforms emit Product JSON-LD. Check the rendered HTML before adding a second copy, because two Product nodes with different prices is a defect.
Which fields do you actually need?
Google splits product markup into two uses. Product snippets are for pages where people cannot directly buy the product, such as reviews and pros and cons. Merchant listings are for pages where customers can purchase from you. If you run a shop, target merchant listings: adding their required properties also makes the page eligible for snippets, and Google advises giving as much product information as you have.
| Level | Required | Worth adding |
|---|---|---|
| Product, merchant listing | name, image, offers | brand name, description, sku, mpn, GTIN, color, size, material, aggregateRating, review |
| Product snippet | name plus one of review, aggregateRating or offers | The same list as above |
| Offer | price, with priceCurrency alongside it | availability, itemCondition, url, shippingDetails, hasMerchantReturnPolicy, priceValidUntil |
- Currency is a three-letter ISO 4217 code: Give one availability value and one itemCondition value.
- Include a GTIN only if you truly have one: Use the most specific one, in numeric form with no URLs. If a product has none, omit the field. Never invent an identifier to quiet a warning.
- Set shipping and returns once: These are better defined at the organization level, or in Merchant Center, than repeated on every product.
- Sale prices need care: The active price carries no price type. A struck-through original uses the strikethrough price type.
What are the rules for reviews and ratings?
These are strict, and breaking them risks losing rich results. Ratings must be sourced directly from users, so do not hand-compile them. Reviews and ratings must be visible on the page, and you must not aggregate ratings from other sites. Do not mark up fake or undisclosed incentivised reviews.
The self-serving review trap
If the entity being reviewed controls the reviews about itself, pages using LocalBusiness or another Organization type are ineligible for star review results. That covers a company writing reviews of itself, in markup or through an embedded third-party widget. A review of a product sold on the page is the normal case. Do not attach the same ratings to your Organization node.
If you have no real reviews, leave the rating fields out. An empty promise is worse than no markup. The same applies to variants: one page with several colours or sizes should use a ProductGroup, with each variant carrying its own sku or GTIN, url and offers.
How do you add it, in summary?
Generate the markup from the same data as the page
Build the JSON-LD from the source that renders the visible price and stock, using a template or helper rather than a hand-pasted blob. This is the best protection against drift.
Emit one Product node per page
If an SEO plugin also emits one, turn off one source. Two nodes with conflicting prices is the most common defect.
Keep price, currency and availability identical to the page
Google's rule is that markup must be a true representation of the page content, and must not describe content users cannot see.
Make the page crawlable
It must not be blocked by robots.txt or marked noindex.
Keep any Merchant Center feed consistent
Google says markup and a feed together maximise eligibility, and a feed can supply pricing that markup lacks.
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Trail Runner 2 Shoe",
"image": ["https://example.com/img/trail-runner-2.jpg"],
"brand": { "@type": "Brand", "name": "Example" },
"sku": "TR2-BLK-42",
"offers": {
"@type": "Offer",
"url": "https://example.com/p/trail-runner-2",
"price": "129.00",
"priceCurrency": "CAD",
"availability": "https://schema.org/InStock",
"itemCondition": "https://schema.org/NewCondition"
}
}That is the minimum shape. The implementation guide for the agent skill adds Shopify, WooCommerce and Next.js recipes, variants, and a verification checklist. The skill can be installed into Claude Code and other coding agents so an agent makes the change on your store and checks the rendered output.
Read the full implementation guideThe skill source is public.
View the skill source on GitHubTo install any AEO skill into an agent, start from the index.
See how to install AEO agent skillsHow do you know it is working?
- Test a sample of products: Run Google's Rich Results Test on three to five products, including one out of stock and one with variants. You want zero errors, and read the warnings.
- Change a price and reload: Edit a price in your admin, reload the page, and confirm both the visible price and the JSON-LD changed together. If only one moved, the markup is hand-pasted or cached.
- Watch Search Console: The merchant listings and product snippets reports update after Google recrawls, which takes days to weeks. Do not expect same-day results.
- Sample shopper questions honestly: Pick five shopper questions and check which products and retailers get cited, before the change and again after engines have had time to re-fetch. The AEO Toolkit's visibility check queries Perplexity only and needs a Perplexity key, so it says nothing about ChatGPT, Claude or Gemini, and one run is one sample. Repeat the prompts, report a citation rate, and do not claim the markup caused a change from a single before and after.
What are the mistakes that cost you?
- A stale or inconsistent price: The markup price is out of date, or tax-inclusive on the page and tax-exclusive in the markup.
- Availability always InStock: It must follow real inventory.
- Copied or duplicated ratings: Ratings lifted from Amazon or a review site, or the same rating on every product.
- aggregateRating on the Organization node: This is the self-serving review problem described above.
- A fake GTIN: Adding an identifier you do not have to satisfy a warning.
- Assuming the theme already did it: Check the rendered HTML. A theme may output nothing, or it may output a copy that clashes with a plugin.
Common questions
What is the minimum product schema I need for Google?
For a merchant listing, Google requires name, image and offers, and the offer needs a price with a priceCurrency. Adding brand, description, sku or GTIN, availability and itemCondition is recommended. Only include identifiers you truly have, and keep every value identical to what shoppers see on the page.
Will product schema make ChatGPT or other AI assistants recommend my products?
Nothing shows that it does. Markup makes a page eligible for product search features and gives an assistant a clean copy of price and availability to read. It does not guarantee a recommendation. Measure instead whether engines cite your product pages for shopper questions, repeat the check over weeks, and treat any single result as weak evidence.
Can I add star ratings to product schema without real reviews?
No. Ratings must be sourced directly from users and be visible on the page, you must not aggregate ratings from other sites, and fake or undisclosed incentivised reviews are not allowed. If you have no real reviews, leave the rating fields out. Also do not attach product ratings to your Organization node, which can make the page ineligible for star results.
Do category pages need product schema?
No. Google's product rich results only support pages that focus on a single product or variants of the same product, so a category page marked up as a product is a mistake. Mark up each individual product page, and use ProductGroup when one page covers several colours or sizes of one product.
Sources
Related guides
Want it done for you
Want this done and re-checked every month? Our monthly maintenance re-runs your buying questions in ChatGPT, Perplexity and Google, ships the fixes that keep you out of the answers, and reports what moved. Or run the free check on your site first at advancelabs.dev/tools/audit.
See how it works