Product schema markup

A crawler sees a product page as text and layout markup. The price may sit in a span with the class «price», in a table, inside a tab or even in an image. Product markup removes that ambiguity: it states, in a machine-readable block, that this number is the current price, that this string is the item name and that this 4.6 sums up 128 reviews.

The vocabulary comes from schema.org and the central type is Product. Around it sit Offer, which carries the commercial terms; AggregateRating, which summarises the average rating; and Review, which represents one opinion with its author and score.

Three layers get confused daily and need separating. The markup lives in the page HTML and is read by the crawler. The product feed is a file the shop sends to Merchant Center. The visible page is what the person reads. All three must tell the same story, yet they are separate channels with separate rules.

The type itself also needs a boundary. Product describes one specific commercial item: not a category, not a listing and not the shop as a company. For the company there is Organization, and its rules on ratings are different.

The markup is placed in the HTML as a JSON-LD block. Google distinguishes two outputs for that same type.

Product snippets are meant for pages where the item cannot be bought on the spot, for example an editorial review. One of these three properties is enough: review, aggregateRating or offers.

Merchant listings are meant for pages where the item is actually bought, and they feed experiences such as the shopping knowledge panel, popular products and Google Images. There, name, image and an offers with price (or priceSpecification.price) and priceCurrency are required, and the price must be greater than zero. Also recommended are availability, shippingDetails, hasMerchantReturnPolicy, url and priceValidUntil. In July 2026 the documentation added Product.category and the duration of a sale price, aligned with the equivalent feed attribute.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Kora office chair",
  "image": ["https://example.com/kora-1.jpg"],
  "sku": "KORA-01",
  "brand": { "@type": "Brand", "name": "Kora" },
  "offers": {
    "@type": "Offer",
    "url": "https://example.com/kora-chair",
    "price": "249.00",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.6",
    "reviewCount": "128"
  }
}
</script>

There is a second circuit, the Merchant Center one. Automatic item updates read price, availability and condition from the landing page markup and correct the feed while it lags behind. If that correction is switched off and the values disagree, the product gets an item-level disapproval and stops appearing in free listings and ads.

The decision that depends on this is not «will I rank higher?» but «what does my catalogue look like when it appears, and is it allowed to appear at all?». Two pages in the same position do not perform alike if one shows price, availability and stars while the other shows a blue title.

The second decision is operational and costs real money. In the Merchant Center circuit, a mismatch between feed, page and markup does not degrade anything quietly: it disapproves the item. A deployment that changes prices in the visible template but leaves the JSON-LD served from an old cache can pull thousands of listings out of the shop window within hours.

The third is about where the effort goes. With the minimum markup (name, image, offers) the page is already eligible; the remaining properties widen where it can appear. Knowing what is required and what is recommended lets you decide whether development time spent exposing the return policy or shipping costs in the markup pays off, or whether it pays off better in the feed.

One warning about expectations: markup does not create eligibility for features Google has retired. Publishing vocabulary that no longer has a visual output does no harm, but it returns nothing either.

• Generate the JSON-LD from the same data source that prints the price on screen. Hand-written or separately cached markup drifts apart at the first price change.
• Mark up only the main product of the page, with the same price and the same currency the person sees, and with no currency symbol or thousands separator inside price.
• Ship the price change on the page, in the markup and in the feed within the same deployment. All three layers must agree before the crawler arrives.
• Use availability and itemCondition with the full schema.org URLs, and keep priceValidUntil on a future date while the offer is live.
• Use aggregateRating only when the ratings come from real customers about that item and are visible on the page itself.
• Validate with the rich results test before deploying, then check the matching Search Console report afterwards, which is where real behaviour at scale becomes visible.

• Putting aggregateRating on a category page or the homepage, covering a set that is not one specific product.
• Describing the company with Organization or LocalBusiness and hanging the reviews the company itself manages about itself off that type. Google declares such pages ineligible for the star feature.
• Leaving priceValidUntil on a date that has already passed, which can stop the listing from being shown.
• Writing the price with a thousands separator or putting the euro sign inside the numeric value.
• Treating markup and feed as projects of separate teams, with nobody comparing both values after each price or stock change.