E-commerce Product Structured Data Guide

Describe the item first, then the commercial terms that apply to it.

Separate the product from the offer

Product identifies the thing being described: its name, brand, image, and other product details. Offer describes a seller’s terms for a particular purchase, such as price, currency, availability, and the URL that opens that offer. Schema.org defines the vocabulary; Google adds separate eligibility requirements for each Search feature. [15][16][1]

AggregateOffer summarizes a real set of offers, often with a low price, high price, and offer count. It is not a shortcut for hiding different variant prices or stock states. Google allows Offer or AggregateOffer for product snippets, while merchant listings require an Offer from the merchant selling the product. [17][2][3]

Treat example fields as practical choices rather than a universal required-property list. Google’s required and recommended properties vary by feature: for example, priceCurrency is recommended for product snippets and required for merchant listings. Valid markup can make a page eligible, but Google does not promise a rich result or a particular search presentation. [2][3][5]

A product page should describe the product shown and the offer a shopper can actually buy.

Start with one product and one real offer

This complete JSON-LD sample uses a numeric price, an ISO 4217 currency code, a full ItemAvailability URL, and absolute example URLs for the image and product page. Its fields are not all universally mandatory; check the current requirements for the specific Google feature you want to qualify for. [3][8][18]

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Northline 750 ml Trail Bottle",
  "image": "https://shop.example/products/trail-bottle/images/front.jpg",
  "description": "A fictional insulated stainless steel bottle for day hikes.",
  "brand": {
    "@type": "Brand",
    "name": "Northline Sample"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://shop.example/products/trail-bottle",
    "price": 28.00,
    "priceCurrency": "USD",
    "availability": "https://schema.org/InStock"
  }
}

Group related sizes or colors, but give every distinct variant its own facts and offer.

Represent variants at the level shoppers select

For variants of the same base product, Google documents ProductGroup with variesBy, hasVariant, and productGroupID. Put facts shared by all variants, such as the brand, on the group; give each variant its identifying name and attributes, its own Offer, and the URL that preselects it. That URL must show the same image, selected option, price, and availability described by the offer. [4][11]

If a store uses separate pages for variants, use each real page URL and follow Google’s multi-page guidance, which repeats the ProductGroup description on the variant pages. If one page switches variants, provide stable variant URLs and make each URL render or preselect the represented option. Do not group products that are merely similar but are different items. [4]

The sample below is one compact, single-page ProductGroup. It contains four complete Offer objects so their prices and availability can differ. The discontinued row is a Schema.org vocabulary example only: its fictional amount is not a current offer price to copy. If the seller no longer has a real offer, omit that Offer; Merchant Center says to remove permanently discontinued products from its data source. [4][18][12]

{
  "@context": "https://schema.org",
  "@type": "ProductGroup",
  "name": "Ridgeline Canvas Daypack",
  "description": "A fictional daypack offered in several colors and sizes.",
  "url": "https://shop.example/products/ridgeline-daypack",
  "brand": {
    "@type": "Brand",
    "name": "Northline Sample"
  },
  "productGroupID": "NLD-100",
  "variesBy": [
    "https://schema.org/color",
    "https://schema.org/size"
  ],
  "hasVariant": [
    {
      "@type": "Product",
      "sku": "NLD-100-MOSS-S",
      "name": "Ridgeline Canvas Daypack, Moss, Small",
      "description": "Fictional small moss canvas daypack.",
      "image": "https://shop.example/products/ridgeline-daypack/images/moss-small.jpg",
      "color": "Moss",
      "size": "Small",
      "offers": {
        "@type": "Offer",
        "url": "https://shop.example/products/ridgeline-daypack?color=moss&size=small",
        "price": 58.00,
        "priceCurrency": "USD",
        "availability": "https://schema.org/InStock"
      }
    },
    {
      "@type": "Product",
      "sku": "NLD-100-MOSS-M",
      "name": "Ridgeline Canvas Daypack, Moss, Medium",
      "description": "Fictional medium moss canvas daypack.",
      "image": "https://shop.example/products/ridgeline-daypack/images/moss-medium.jpg",
      "color": "Moss",
      "size": "Medium",
      "offers": {
        "@type": "Offer",
        "url": "https://shop.example/products/ridgeline-daypack?color=moss&size=medium",
        "price": 58.00,
        "priceCurrency": "USD",
        "availability": "https://schema.org/OutOfStock"
      }
    },
    {
      "@type": "Product",
      "sku": "NLD-100-SLATE-L",
      "name": "Ridgeline Canvas Daypack, Slate, Large",
      "description": "Fictional large slate canvas daypack, available for preorder.",
      "image": "https://shop.example/products/ridgeline-daypack/images/slate-large.jpg",
      "color": "Slate",
      "size": "Large",
      "offers": {
        "@type": "Offer",
        "url": "https://shop.example/products/ridgeline-daypack?color=slate&size=large",
        "price": 64.00,
        "priceCurrency": "USD",
        "availability": "https://schema.org/PreOrder"
      }
    },
    {
      "@type": "Product",
      "sku": "NLD-100-RUST-XL",
      "name": "Ridgeline Canvas Daypack, Rust, Extra Large",
      "description": "Fictional extra large rust canvas daypack, discontinued.",
      "image": "https://shop.example/products/ridgeline-daypack/images/rust-extra-large.jpg",
      "color": "Rust",
      "size": "Extra Large",
      "offers": {
        "@type": "Offer",
        "url": "https://shop.example/products/ridgeline-daypack?color=rust&size=extra-large",
        "price": 59.00,
        "priceCurrency": "USD",
        "availability": "https://schema.org/Discontinued"
      }
    }
  ]
}

Use one status that matches the selected item and what the store will do next.

Keep availability truthful as stock changes

Schema.org’s ItemAvailability enumeration includes InStock, OutOfStock, PreOrder, and Discontinued, among other values. Use the full canonical URL in JSON-LD. For Merchant Center, map the page state to its supported feed value and follow its separate rules; the enum names are not a universal feed contract. [18][9][12]

• InStock

  Use when the store is taking orders and can fulfill the selected variant. The page, offer, checkout, and feed should all show it as available. [12]

• OutOfStock

  Use for a temporarily unavailable item when the store is not accepting orders. Keep the real price visible on the landing page and do not mark it InStock until it can be fulfilled. [9][12]

• PreOrder

  Use for a not-yet-released item that the store is accepting orders for. Merchant Center requires the actual availability date in the feed, and that date should also be visible on the landing page; do not reuse PreOrder for an existing item awaiting restock. [12][13]

• Discontinued

  Schema.org provides this value for an item that has been discontinued. Keep an informational product page accurate if it remains useful, but do not imply that it is currently purchasable. Merchant Center says to remove permanently discontinued products from its data source instead of retaining them as out of stock. [18][12]

Treat JSON-LD as a view of product data, not a separately maintained SEO copy.

Generate markup from the systems that own the facts

Google recommends product-page structured data together with a Merchant Center feed to help it understand and verify product data and maximize eligibility; neither guarantees a particular Search presentation. Generate price, currency, availability, variant identifiers, and product URLs from the same current records used to render the page and checkout. A PIM, ERP, CMS, inventory system, or catalog service can own product identity; inventory and pricing feeds or services can own changing offer details. Refresh both page markup and Merchant Center data when those source records change, and coordinate feed schedules with site updates. [1][8][10][9]

Keep the shopper-visible price and stock state, JSON-LD, feed, selected variant, and checkout aligned. Do the same for any structured review, shipping, or return-policy information: only publish real product-specific reviews and current policies that the page actually supports. Google may ignore markup that does not match visible content; serious structured-data violations can remove rich-result eligibility, but a structured-data manual action does not change a page’s ordinary web-search ranking. [8][11][5]

• Render current facts early

  For merchant listings, Google recommends Product structured data in the initial HTML. This is especially useful for fast-changing stock and prices that can be missed when they appear only after client-side rendering. [3][8]

• Update from the source of truth

  When a price or stock record changes, update the visible page, JSON-LD, feed, and any checkout-facing value together. For frequent changes, use an appropriate feed or API update cadence rather than a manually pasted template. [10][11]

A syntax test is a starting point; Google’s reports show what it can read after publication.

Validate the code, then monitor the live product pages

Run the Rich Results Test on a URL or paste the JSON-LD as code. Fix syntax errors and feature-specific missing requirements, then inspect a deployed URL in Search Console to confirm Google can access the page and see the intended variant. After crawling, review Search Console’s product rich-result reports for issues and use Validate fix when a report offers it. [4][19][7]

In Merchant Center, open Products → Needs attention (the current area formerly called Diagnostics) and review affected examples. Follow each issue to the underlying product record, correct the source data, then refresh or resubmit the data source. The test tools can catch technical issues, but a pass does not confirm that a result will appear or that every business fact is correct. [14][11][5]

• Check each selected variant

  Open every important variant URL and compare its visible name, image, price, currency, availability, and product identity with its corresponding Product and Offer data. [4][11]

• Recheck after source changes

  Repeat the test after catalog, template, inventory, pricing, review, shipping, or return-policy changes. A previously passing example can become stale when its underlying facts change. [8][10][7]

Structured data should be specific, typed correctly, and supported by the page.

Fix the underlying data instead of masking the mismatch

Do not mark a category or search-results page as one Product: Google’s product rich results are for a page focused on one product or variants of that same product. Do not reuse an unrelated AggregateRating across products. Only describe reviews that belong to the product and that meet Google’s review guidance. [2][6][5]

When a price, stock state, review, variant, shipping term, or return policy is stale or mismatched, correct the owning catalog or policy record and regenerate every output from it. Check that prices are numbers in JSON-LD, currencies use three-letter ISO 4217 codes, and image and product URLs are absolute, reachable, and about the marked-up item. [3][9][11][5]

Avoid keyword stuffing, generic markup pasted across unrelated products, unsupported ratings, and fields that shoppers cannot verify on the page. Incorrect or spammy structured data can be ignored and may lose rich-result eligibility; neither correct markup nor a clean test guarantees rankings, clicks, or a rich result. [5][7]

Use the generator as a formatter for facts you already know, then compare its output with the live product page.

Build focused markup from supplied product facts

This generator requires a product name and at least one Offer fact. It emits a supplied price as a JSON number, accepts a three-letter ISO 4217 currency code, and uses full Schema.org ItemAvailability URLs for the statuses it offers. These are the tool’s input and output rules; Google’s required and recommended properties still depend on the Search feature. [2][3][18]

Optional product and Offer properties are omitted when blank. If you provide an image or Offer URL, enter an absolute HTTP or HTTPS URL. Before publishing, check that every generated name, image, description, brand, price, currency, availability, and offer URL matches the current product page and purchase flow. [15][16][5][11]

The generated markup describes only the values entered here. It does not verify a live page, current catalog, Merchant Center feed, or Google eligibility; use the feature-specific documentation and validation tools for the result you want to check. [2][3][5]