What Schema Does an Ecommerce Website Need? (Product, Offer, Review, Explained)

The schema stack an ecommerce site actually needs

Most stores stop at Product and maybe AggregateRating, then wonder why rich results never show up. In 2026 that's not enough for two separate audiences: Google's Merchant listing pipeline, which wants a fuller product record than it did a few years ago, and AI shopping agents, which read your JSON-LD to decide whether they trust your catalog enough to recommend or check out from it. Five schema types cover almost every ecommerce page:

The sections below go field by field, in the order Google and AI agents actually check them.

Product schema: the fields that are actually required in 2026

The old advice — name, image, offers, done — still validates in the Rich Results Test, but a thin Product object is easy for a crawler or an agent to skip past when it's comparing your listing to five competitors that filled in every field. Treat the following as the real minimum, not the legal minimum:

Here's a trimmed example showing the required nesting:

{
  "@context": "https://schema.org/",
  "@type": "Product",
  "name": "Trail Runner Backpack 28L",
  "description": "A 28-liter hiking backpack with a ventilated back panel, hydration sleeve, and rain cover, built for multi-day trail use.",
  "image": [
    "https://example.com/images/backpack-front.jpg",
    "https://example.com/images/backpack-back.jpg"
  ],
  "sku": "TRB-28-BLK",
  "gtin13": "0123456789012",
  "brand": {
    "@type": "Brand",
    "name": "TrailWorks"
  },
  "category": "Outdoor > Backpacks > Hiking Backpacks",
  "color": "Black",
  "material": "Ripstop nylon",
  "offers": { "@type": "Offer" },
  "aggregateRating": { "@type": "AggregateRating" }
}

A Product object missing offers won't qualify for a rich result at all, so that's next.

Offer schema: price, stock, and the return-policy field most stores skip

Offer is where most manual actions and suppressions actually happen, because it's the part most likely to drift out of sync with the live page. Google's Merchant listing requirements for the Offer object are stricter than a basic Product snippet:

If your platform auto-generates schema (Shopify, WooCommerce, a headless storefront), check that price and availability are pulled live from the same source the storefront renders from — a cached or scheduled schema export is the most common way stores end up with a price mismatch they don't know about until rich results silently disappear.

Review and AggregateRating: what still earns star ratings

Google tightened review snippet guidance again in July 2026, and the rules are worth reading closely because Product is one of the few entity types still eligible — LocalBusiness and Organization lost self-review eligibility back in 2019, and that restriction hasn't loosened.

• Nest, don't scrape. AggregateRating and Review should be nested inside the Product object, and the content must come from reviews actually visible on that page — pulling an average rating from a third-party platform and stuffing it into markup violates the guidelines.
• The name property is required on Review items — specify what's being reviewed via itemReviewed, not just the rating.
• Disclose incentives. Google's July 2026 documentation update explicitly bars fake or undisclosed incentivized reviews — a review written for a discount or free product is fine to publish, but only if that's clearly disclosed on the page and in the markup context.
• One rating, one item. AggregateRating on a category or collection page representing many different products is a common violation — it belongs on the individual product page.
• Keep it visible. If users can't see the rating and review count on the page itself, the structured data version won't be trusted either.

Get this section right and you're one of the few remaining rich result types where the payoff is direct: star ratings under an organic listing measurably move click-through rate.

Merchant listings vs. product snippets: which one your store needs

Google actually runs two overlapping product features, and conflating them is why some stores implement "full" schema and still don't see the enhancement they expected.

In practice, an actual storefront product page should implement the fuller Merchant listing property set — doing so also makes the page eligible for the product snippet enhancements, since the requirements overlap. If you run both a live storefront and a separate editorial review section, treat them as two different schema jobs rather than reusing one Product object across both.

BreadcrumbList and Organization: the schema that makes Product trustworthy

Product schema doesn't exist in isolation — Google and AI crawlers weigh it against how coherent the rest of the site's structured data is.

• BreadcrumbList on every category and product page turns your URL hierarchy into a machine-readable trail (Home > Outdoor > Backpacks > Hiking Backpacks), which shows up as breadcrumbs in search results and helps crawlers understand where a product sits in your catalog without guessing from the URL slug.
• Organization on the homepage anchors your brand identity — legal name, logo, sameAs links to verified social/marketplace profiles. It's the schema type most likely to feed a knowledge panel, and it's also the entity your Brand and Product objects should reference for consistency.

Neither produces a flashy rich result on its own, but both raise the confidence signal for everything nested underneath them.

Don't spend time on FAQPage schema anymore

If your ecommerce build plan still includes FAQPage markup for product FAQs, drop it. Google retired the FAQ rich result and its Search Console report in May 2026, and structured data that no longer feeds a Search feature has no visible effect — it's not penalized, but it's also not worth engineering time. Keep FAQ content on the page for genuinely answering buyer questions and for AI answer engines that read page content directly, just don't budget schema-implementation hours toward the FAQPage type itself.

Common mistakes that get rich results suppressed

Validate before you publish

Three checks catch nearly everything above before it costs you a rich result:

1. Rich Results Test — run it on the live URL, not a staging copy, and check which enhancements the page actually qualifies for, not just whether the JSON-LD parses.
2. Google Merchant Center diagnostics — if you have a product feed, this catches feed-vs-markup mismatches (GTIN, price, stock) the generic validator doesn't see.
3. Search Console Enhancements report — the ongoing view once you're live; watch it after any theme, platform, or feed change, since that's when schema quietly breaks.

Ecommerce platforms increasingly need to satisfy a third reader too — the emerging layer of AI shopping agents and checkout protocols that read this same structured data to decide whether they can transact with your store at all, not just whether Google will show a star rating. That's a distinct implementation on top of everything above; if you're mapping out what agent-readiness actually requires, our SEO/AEO/GEO service covers the full stack from this schema baseline through agent-facing endpoints.