Product Structured Data for Ecommerce: What Google Actually Requires in 2026 | OnyxRank

Product structured data will not get your store into AI Overviews, but it controls whether Google can read your price, availability, shipping and returns without guessing. Google's documentation is explicit that [no special schema.org structured data is needed](https://developers.google.com/search/docs/appearance/ai-features) for AI Overviews or AI Mode. What markup does is make your product pages eligible for the shopping features that sit beside and inside search results. At OnyxRank we treat it as a hygiene layer: cheap to get right, expensive to get wrong, and easy to audit.

This guide walks through what Google's documentation actually requires for ecommerce product pages, the mistakes that quietly disqualify stores, and a short workflow for fixing them.

The two things Google means by "Product markup"

Google's [Product structured data documentation](https://developers.google.com/search/docs/appearance/structured-data/product) splits product markup into two experiences, and picking the wrong one is the first common error.

**Product snippets** are for pages where people cannot buy directly, such as a review site or an editorial roundup. They support review features like pros and cons.

**Merchant listings** are for pages where shoppers can buy from you. They support richer commerce details: pricing, availability, shipping, return policy and apparel sizing.

If you run a store, you want merchant listing eligibility. Google notes that meeting the merchant listing requirements also makes the page eligible for product snippets, so you do not have to choose between them. The more complete the information you supply, the more enhancements are possible.

There is also a choice about where the data comes from. Google says you can add structured data to your pages, submit a Merchant Center feed, or do both, and that using both maximizes eligibility. Some experiences combine the two. For example, product snippets can use feed pricing if the page lacks it. For most stores the practical answer is to do both and keep them consistent.

What is required versus what is only recommended

The [merchant listing documentation](https://developers.google.com/search/docs/appearance/structured-data/merchant-listing) is specific. Here is the short version.

Required properties

• **Product name**, an **image**, and **offers**.
• A **price** greater than zero. Google states merchant listings require it.
• A **priceCurrency** in three letter ISO 4217 format, such as USD or EUR.
• The offer must be a single **Offer**, not an AggregateOffer, because the merchant must be the seller.

Recommended properties worth the effort

• **availability**, with one value such as InStock. It is recommended, not required, but a shopper comparing options cares about it more than almost anything else.
• **shippingDetails** and **hasMerchantReturnPolicy**. Google recommends defining your standard shipping and return policies once under your Organization markup and only using offer level properties for exceptions.
• **gtin** (or gtin8, gtin12, gtin13, gtin14, isbn), using the most specific type that applies and a numeric value rather than a URL.
• **brand**, with a single brand name.
• **description**, which Google strongly recommends, plus sku, mpn, aggregateRating and review where you have real data.

A store that supplies only the required fields is eligible. A store that supplies the recommended fields gives Google the information it needs to show the details shoppers actually compare.

Five mistakes that quietly cost eligibility

These come from reading the documentation against how stores commonly ship their templates. Treat them as an audit list, not as measured failure rates. I am not citing a percentage because I do not have a source for one.

1. Marking up category pages as products

Google says eligible pages must focus on a single product or its variants, not category listings. If your collection template outputs Product markup for every item in the grid, you are describing content that the page is not primarily about. Put Product markup on product detail pages only.

2. Using AggregateOffer on a page you sell from

Themes and plugins often emit a price range through AggregateOffer when a product has variants. For merchant listings, Google requires a plain Offer because the merchant is the seller. If you sell variants, read Google's [product variants guidance](https://developers.google.com/search/docs/appearance/structured-data/product-variants) and mark them as variations of a parent rather than as a range.

3. Markup that does not match the visible page

Google's [structured data policies](https://developers.google.com/search/docs/appearance/structured-data/sd-policies) say not to mark up content that is not visible to readers. If your markup says a product is in stock at 49.00 and the page shows 59.00 or a sold out message, you have a mismatch. Common causes are cached markup, a promotion that updates the display but not the template, and variant selectors that change the visible price without changing the JSON LD.

The policy page also describes what happens when markup is spammy: a structured data manual action removes rich result eligibility. Google states it does not affect how the page ranks in web search, but losing the enhancements still costs you visibility in shopping style results. You can check for one in the Manual Actions report in Search Console.

4. Markup injected late with JavaScript

Google's merchant listing documentation warns that dynamically generated markup can make Shopping crawls less frequent and less reliable, which matters for data that changes quickly such as price and availability. It recommends placing Product markup in the initial HTML for best results. If you must generate markup with JavaScript, make sure your server can handle the extra crawl traffic. For fast moving inventory, the safe default is server rendered JSON LD.

5. Duplicating policy data on every product

Writing return and shipping policies into each product offer invites inconsistency. Define the standard policies once at the Organization level and override only where a product genuinely differs, such as final sale items or oversized freight.

A workflow to fix a store in one week

You do not need a full replatform. Run this sequence.

1. **Inventory your templates.** List every template that outputs Product markup: product detail, quick view, collection, bundle, search results. Mark which should keep it and which should lose it.

2. **Pick one source of truth.** Price and availability in the markup should be generated from the same field that renders the visible price. If two systems feed them separately, drift is guaranteed.

3. **Validate a sample.** Use Google's Rich Results Test on a spread of products: simple, variant, sale priced, out of stock. Google advises fixing critical errors and says non critical issues are advisable to fix but not required for eligibility.

4. **Check the live render.** Use the URL Inspection tool in Search Console to confirm Google sees the markup on the deployed page, not only in your staging output.

5. **Align the Merchant Center feed.** Compare feed price and availability against the page for the same SKUs. Mismatches are the easiest problem to find and the most common to ignore.

6. **Add policy markup once.** Put shipping and return policy under Organization and remove per product duplicates unless they are true overrides.

7. **Recheck after every theme or app update.** Plugins overwrite templates. Put a monthly spot check on the calendar.

How this connects to AI search visibility

Because Google says structured data is not a requirement for AI Overviews, it is worth being precise about what markup does and does not do for you in AI search.

What it does: it keeps your product facts machine readable and consistent with the page, and Google lists consistency between structured data and visible content among its general best practices for appearing in these features. It also protects eligibility for the shopping experiences that surface your products.

What it does not do: it does not substitute for pages that are indexed and eligible to show with a snippet, which Google identifies as the only technical requirement for AI features. It does not make thin product descriptions worth citing. A page with a clean price and a ten word description still gives an AI system nothing to quote about fit, materials, compatibility or use.

So the sequencing for a store is: first make sure product pages are crawlable and indexable, second get the markup and feed accurate, and only then invest in the content that answers buyer questions. If you want a second opinion on where your store stands, our [free SEO audit](/free-audit) checks indexability, rendering and markup consistency on a sample of your product pages.

Frequently asked questions

Do I need Product schema to appear in AI Overviews?

No. Google's AI features documentation says there is no special schema.org structured data you need to add and no new machine readable files or markup required. Your pages need to be indexed and eligible to appear in Search with a snippet.

Should I use JSON LD, Microdata or RDFa?

Google supports all three. Choose the one your platform can generate reliably in the initial HTML. Most stores find JSON LD easiest to maintain because it lives in one block instead of being woven through the template.

Will wrong structured data hurt my rankings?

Google states that a structured data manual action removes rich result eligibility but does not affect how the page ranks in web search. The cost is lost enhancements, and the fix is to correct the markup and request review.

Is a Merchant Center feed enough without on page markup?

Google says you can use either or both, and that using both maximizes eligibility. A feed alone works for some shopping experiences, but on page markup gives you eligibility for more of them and keeps your pages describing the same data your feed does.

Key takeaways

• Product markup is an eligibility layer for shopping features, not a switch for AI Overviews.
• Stores want merchant listing markup: name, image, offers, a positive price and a currency are required.
• Add availability, shipping, returns, GTIN and brand, and define shared policies once under Organization.
• Markup must match what shoppers see, and should sit in the initial HTML for fast changing data.
• Audit templates, not individual products. One broken template breaks thousands of pages.

If you would rather have someone audit the templates and feed together, start with the [free audit](/free-audit), or see how our engagements work on the [pricing page](/pricing).