Product Schema: A Practical Guide to Product Structured Data

What is Product Schema?

Product Schema is structured data that uses the Schema.org Product type to describe an individual product. The product can be connected to other objects, including:

• a Brand identifying the maker;
• an Offer describing one purchasing option;
• an AggregateOffer describing a price range or several offers;
• an AggregateRating summarising genuine ratings;
• individual Review objects;
• a ProductGroup connecting variants of the same parent product.

A visitor can understand a product page from its layout. They see the name, image, price, colour selector, stock message and buy button. Product structured data labels those facts so machines can process them consistently.

Product: Trail Running Shoe
Brand: Example Sports
SKU: TRS-100-BLU-42
GTIN: 5012345678900
Offer price: 89.00 GBP
Availability: InStock
Condition: NewCondition

The markup should describe the product page, not create a second version of it. Every important claim needs to agree with the information available to shoppers.

Product snippets and merchant listings

Google separates Product structured data into two broad uses.

Product snippets

Product snippets can apply to pages about a product where the visitor cannot necessarily buy it directly. Examples include editorial product reviews, comparison content and other pages centred on a product.

Depending on the page and markup, a product snippet may use information such as ratings, reviews, price or availability.

Merchant listings

Merchant listings apply to pages where customers can buy the product. They support more detailed ecommerce information, including price, availability, shipping and returns.

Eligible merchant information can be used in Google Search experiences such as product snippets, shopping knowledge panels, Images and popular product results. The exact presentation is decided by Google and is never guaranteed.

Choose based on the page, not the desired appearance

A retailer's product detail page and a publisher's independent product review serve different purposes. Follow the documentation that matches the real page.

Do not add a checkout offer to an editorial article that does not sell the product. Do not describe a purchasable product page as an independent review merely to target star ratings.

Which pages should use Product Schema?

Product Schema belongs on a page primarily about one specific product or a clearly modelled set of variants.

Good candidates include:

• an individual ecommerce product page;
• a product page with selectable colours or sizes;
• a manufacturer page for a specific model;
• an editorial review focused on one product;
• a product comparison page when each reviewed product is represented accurately under the applicable guidance.

Use caution on category and collection pages containing many unrelated products, search-result pages, general service pages, brand landing pages without one primary product and thin parameter URLs that do not represent a stable product or variant.

The product needs to be the page's main subject. Marking every product tile on a category page does not turn that category into a set of eligible product detail pages.

The URL also needs to work as a search landing page. Check that it returns a successful response, is crawlable, can be indexed and points canonically to the intended product URL.

How Product, Brand and Offer fit together

Product describes the item

The Product object identifies what the item is. Common properties include:

• name, description and image;
• brand, sku, mpn and valid GTIN properties;
• color, size, material or pattern where relevant;
• offers;
• review or aggregateRating when genuine review data exists.

Brand identifies the maker

Use a nested Brand object when the product has a recognised brand. Keep the brand name consistent with the visible page, catalogue and Merchant Center data.

Do not use the shop name as the brand unless the shop actually manufactures or owns that product brand.

Offer describes the purchase

The Offer object represents a particular commercial offer. It can describe the purchase URL, price, currency, availability, condition, seller and eligible shipping or return information.

Use AggregateOffer when the page accurately represents several offers or a price range. Do not use it to hide the real current price behind an artificially broad range.

Separating the item from its offer matters. The shoe remains the same product when its price or availability changes; the offer carries those commercial facts.

A Product Schema JSON-LD example

This simplified example describes one new product with one offer:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "@id": "https://example.com/products/trail-running-shoe/#product",
  "name": "Trail Running Shoe",
  "description": "A lightweight waterproof trail shoe for mixed terrain.",
  "image": [
    "https://example.com/images/trail-running-shoe-blue.jpg"
  ],
  "sku": "TRS-100-BLU-42",
  "gtin13": "5012345678900",
  "brand": {
    "@type": "Brand",
    "name": "Example Sports"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/products/trail-running-shoe/",
    "priceCurrency": "GBP",
    "price": 89.00,
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  }
}
</script>

Replace every example value with data from the real product record. The visible page should show the same product, price, currency, stock state and condition.

This is a starting model rather than a universal template. Required and recommended properties vary between product snippets, merchant listings and specialised cases. Always check the current documentation for the feature you intend to support.

How to mark up price and availability

Price and stock information change quickly and have direct consequences for shoppers. They are also common sources of structured-data and Merchant Center errors.

Use a plain numeric price

Supply the number without a currency symbol or thousands separator:

"price": 89.00,
"priceCurrency": "GBP"

The three-letter currency code removes ambiguity. Make it agree with the prominent price and currency shown on the landing page.

Use a recognised availability value

Availability is expressed with a Schema.org URL such as:

"availability": "https://schema.org/InStock"

Other relevant values include OutOfStock, PreOrder, BackOrder, SoldOut and Discontinued. Map the ecommerce platform's internal stock states carefully rather than defaulting every active product to InStock.

Keep three sources aligned

1. The visible product landing page.
2. Product and Offer structured data.
3. The Merchant Center feed or API data.

Google may report or act on price and availability mismatches. Automatic item updates can help correct some differences, but they are not a substitute for maintaining accurate product data.

Handle sales deliberately

Make the current purchasable price clear. Keep sale periods, currency, effective dates and any strikethrough price information consistent across the page, markup and product feed.

Beware of caches and client-side updates. If the displayed sale begins immediately but stale JSON-LD retains yesterday's price, the same URL communicates two facts.

Test regional and member prices

International, regional, subscription and loyalty pricing require extra care. Do not assume a geolocation script, logged-in state or browser storage will expose the same offer to a crawler.

How to use product identifiers

Identifiers help distinguish one product or variant from another.

SKU

sku is the seller or catalogue's stock-keeping identifier. It should remain stable for the specific item or variant represented.

GTIN

A Global Trade Item Number is a recognised commercial identifier. Use the property that matches its real length, such as gtin13, and preserve leading zeros.

Do not invent a GTIN. An invalid number can associate the offer with the wrong product or fail validation.

MPN and product-group identifiers

mpn is the manufacturer's part number. It is useful when a genuine manufacturer identifier exists, particularly alongside the correct brand.

A parent or group identifier connects variants belonging to one product family. It is different from each variant's unique SKU or GTIN.

Keep identity consistent

The same item should use the same identifiers across the visible page, Product structured data, product catalogue, Merchant Center, internal feeds and APIs. Identifier consistency is also useful for AI-powered systems trying to connect a product mention with the correct catalogue item. Keep product data aligned with the preferred product URL and check the broader structured-data principles.

How to mark up product variants

Products often vary by colour, size, material, pattern or another selectable property. Each variant may have its own identifier, image, price, availability or URL.

Use ProductGroup for the parent family

Google supports ProductGroup with related properties including:

• productGroupID for the parent identifier;
• variesBy for the characteristics that distinguish variants;
• hasVariant for nested Product objects;
• isVariantOf when a Product refers back to its group.

The group can carry shared information such as brand, common description or aggregate rating. Each variant carries the properties that genuinely differ.

Give every variant a unique identifier

Each variant needs an identifier such as its SKU or GTIN. Reusing the parent's SKU for every colour and size makes it difficult to tell the purchasable items apart.

Model single-page and multi-page variants correctly

A site may use one canonical page with selectable variants or a separate URL for each variant. The markup and canonical strategy should reflect that real architecture.

For a single-page product group, Google expects one distinct canonical URL for the overall group. For multi-page variants, connect and identify the related products according to the current variant guidance.

Keep the selected state accurate

When a user selects a red size-eight shoe, the visible price, image, availability and variant URL should describe that choice. The structured output must not remain fixed on the default blue size-ten variant if the URL represents the selected option.

Test each variant pattern, including unavailable sizes and variants with different prices.

How to add product reviews and ratings

Product markup can include individual Review objects or an AggregateRating summarising a set of ratings.

Only add ratings and reviews that:

• refer to the product on the page;
• are genuine and collected under a defensible process;
• are visible to visitors;
• use the same rating scale and values as the page;
• show a count that agrees with the underlying reviews;
• follow Google's review-snippet policies.

Do not copy a shop-wide rating onto every product. Do not publish a five-star AggregateRating when the page has no product reviews. Do not import ratings for a different variant without deciding accurately whether they apply to the whole product group.

When an editorial page reviews a product, represent the reviewer and rating according to the product-snippet guidance. The rules for an independent review page differ from a merchant marking up customer ratings on a product it sells.

Reviews can add useful context, but they are not required on every product. Accurate Product and Offer data is more valuable than fabricated completeness.

Product Schema and Merchant Center feeds

Product structured data and Merchant Center feeds can work together.

Page markup describes the live landing page

The structured data travels with the product page. It helps search engines retrieve values such as price, availability and condition directly from the website.

The feed supplies catalogue data to Merchant Center

A feed or API can provide a larger and more detailed product dataset on a regular schedule. It supports shopping programmes, diagnostics and inventory management beyond the page itself.

Using both improves coverage and verification

Google recommends using structured data and Merchant Center product data together for the broadest eligibility. The sources can help Google verify one another, but inconsistencies can create warnings, disapprovals or stale listings.

Set one reliable product database as the source of truth. Generate the visible page, JSON-LD and feed from that data wherever possible.

Product Schema for LLMs and AI visibility

Product Schema is especially relevant to AI-powered discovery because product questions depend on precise attributes and current commercial facts.

A person might ask an assistant for a waterproof shoe under £100, a product available in a particular size, a replacement part with a specific model number, an in-stock item from a particular brand or the differences between two variants.

Structured product data expresses those details through explicit fields rather than requiring a system to infer everything from the page layout.

Microsoft has described Schema.org Product data as useful for accurate indexing across search, shopping and AI-powered assistants. Google advises maintaining crawlable, indexable content and accurate structured data for its search experiences, including AI formats.

For stronger machine-readable product identity:

• use stable brand and product names;
• provide real SKU, GTIN and MPN values where they exist;
• connect each offer to the correct product or variant;
• update price and availability promptly;
• use canonical URLs consistently;
• make important specifications visible in the page content;
• remove conflicting or stale product objects.

Schema cannot guarantee that an LLM will cite a page, recommend a product or reproduce a specific price. It can give systems cleaner facts to interpret when they crawl, index or retrieve the page.

How to test Product Schema

Test during development

Use the Rich Results Test with a code sample to catch JSON syntax and Google-specific property problems. Use the Schema Markup Validator to inspect the wider object graph.

Test the live URL

After publishing, test the public product URL. Check that Google can fetch it and that the rendered output contains the final Product, Offer and variant values.

Test meaningful edge cases

• in-stock and out-of-stock products;
• standard and sale prices;
• products with and without reviews;
• single products and product groups;
• variants with different URLs;
• new, used or refurbished conditions;
• regional or currency-specific offers;
• products missing optional identifiers.

Compare markup with the page

Validation tools can check structure, but a human should confirm that the name, image, price, availability, rating and selected variant agree with the visible page.

Monitor Search Console and Merchant Center

Review Product snippet and Merchant listing reports in Search Console where available. Use Merchant Center diagnostics for feed, price and availability problems. Remember that each system may need time to recrawl or reprocess a corrected product.

How to audit Product Schema across a website

Define the product-page population

Identify the canonical product URLs that should contain Product markup. Separate them from categories, search pages, filtered collections and retired products.

Measure coverage

Compare the product-page set with pages containing Product, Offer, AggregateOffer and ProductGroup objects.

Find product pages with no Product object, objects on non-product pages, products without offers where an offer is expected, missing price, currency or availability patterns, product-group pages without variant connections and unexpected duplicate Product objects.

Check URL eligibility

Review response codes, canonical targets, robots directives and indexability. A Product object on a redirected or non-canonical URL may describe an offer that is not intended to appear independently.

Group errors by template

Segment issues by platform, template, market or product type. A missing currency across one regional storefront is a different repair from a single product with bad source data.

Review data consistency

Sample products and compare visible price with offers.price, displayed currency with priceCurrency, stock message with availability, selected variant with SKU and GTIN, visible rating with aggregateRating, canonical URL with product and offer URLs, and page data with Merchant Center values.

Check freshness

Fast-moving catalogues need a repeatable process. Monitor how quickly price and stock changes reach the visible page, JSON-LD, product feed and cached output.

Audit Product Schema with Clearcrawl

Clearcrawl helps turn one Product Schema error into an actionable page group. Instead of testing products at random, use the crawl to locate the affected template, select representative examples and confirm that the fix reached the entire catalogue.

Use Merchant Center for product-data and programme diagnostics, Google tools for feature validation, and Clearcrawl for the live website's technical and template-level patterns.

How to fix and verify Product Schema problems

1. 01
   Identify the affected product group

   Determine whether the problem affects one product, one category, one regional shop, one variant pattern or every product page.

2. 02
   Confirm the intended model

   Decide whether the page represents a merchant listing, editorial product snippet, individual variant or product group. Check the current requirements for that use.

3. 03
   Trace each value to its source

   Map name, image, brand, identifiers, price, currency, availability, condition and reviews to the catalogue fields that generate them.

4. 04
   Repair the product data first

   Correct inaccurate source records before changing the JSON-LD. Keep the storefront, structured data and feed driven by the same facts.

5. 05
   Update the shared template

   Handle optional values, escaping, arrays and variant relationships deliberately. Do not output empty properties or reuse a default offer when real data is missing.

6. 06
   Test representative products

   Validate ordinary products and edge cases in code and at their live URLs. Inspect the rendered values, not only the template source.

7. 07
   Compare the feed and landing page

   Confirm that Merchant Center receives the same price, currency, stock state and identifier as the page.

8. 08
   Recrawl the catalogue

   Measure coverage and issue counts again. Check that the repair did not remove markup from another product type or create duplicates.

9. 09
   Monitor fresh data

   Allow search systems time to recrawl. Watch Search Console and Merchant Center diagnostics, especially after promotions, catalogue migrations and stock-system changes.

Common mistakes

Frequently asked questions