Schema.org Product Structured Data: Rich Results and AI Overviews

by Francis Rozange | Apr 4, 2026 | Google Ads

donnees-structurees-schema-org-product-rich-results-1

Schema.org Product structured data: rich results and AI Overviews

Lede: structured data is the only language Google reads without ambiguity

A product page that does not emit clean schema.org Product markup is a page that asks Google to guess. Guess the price. Guess the availability. Guess whether the rating is for the product, the brand, or the seller. Guess whether that 4.7 stars next to the title is real or decorative. Google does not like guessing. When Google has to guess, it picks the page that does not make it guess.

This is the foundation that has not changed since schema.org launched in 2011 as a joint initiative by Google, Microsoft, Yahoo, and Yandex. What has changed, and what makes 2026 different from 2020, is the surface area on which structured data now decides visibility. Rich results in classic search were the first prize. Merchant listing experiences in Google Shopping were the second. AI Overviews, the generative summaries that Google rolled out broadly through 2024 and 2025, are the third, and they consume structured data more aggressively than any surface before them.

Search Engine Land has been documenting this shift since the AI Overviews launch, and the pattern is consistent: pages that ship complete Product markup, with offers, reviews, ratings, brand, GTIN, and merchant listing fields, get cited inside generative answers. Pages that ship a bare title and a price string get summarized away. Search Engine Journal has called structured data the cheapest insurance an ecommerce site can buy in 2026, and the framing is correct. The cost is one developer day. The downside of skipping it is exclusion from the surfaces where buying decisions now begin.

This guide covers the Product type as Google currently enforces it: required and recommended properties, JSON-LD versus microdata versus RDFa, the merchant listing experience and its pricing-availability-shipping-returns block, how AI Overviews use the markup to source mentions, the parity rule between Merchant Center feed data and on-page structured data, manual actions and ineligibility for invalid markup, debugging with the Rich Results Test and the Schema Markup Validator, and a 2026 update on what Google now expects for AI Overviews eligibility. Implementation playbooks for Shopify, WooCommerce, and custom platforms close the document.

What schema.org Product structured data is

Schema.org is a shared vocabulary maintained by a steering group of Google, Microsoft, Yahoo, and Yandex, with public contributions from W3C working groups. The vocabulary defines types (Product, Offer, Review, Person, Organization, Brand, AggregateRating, and several hundred others) and properties (name, image, price, priceCurrency, availability, sku, gtin, ratingValue, reviewCount). When you embed this vocabulary in a page, you are not making the page prettier or faster. You are giving search engines a machine-readable copy of what the page describes.

The Product type is one of the most heavily used. Google Search Central documents it under “Product (Product, Review, Offer) structured data” and ships two distinct enforcement tracks: product snippet experiences for editorial or comparison pages where users cannot purchase, and merchant listing experiences for ecommerce pages where users can purchase. The two tracks share a base vocabulary but differ on which properties are required for eligibility.

The base claim of structured data is narrow and worth stating cleanly. Schema markup is not a ranking factor. Google has stated this consistently since John Mueller addressed it in 2018 and Gary Illyes reaffirmed it on the Search Off the Record podcast in 2023. What schema markup does is unlock display features and source eligibility. Rich results, merchant listings, knowledge panels, and AI Overview citations are gated on structured data. Without the markup, the page can rank, but it cannot appear in those formats. The CTR difference between a plain blue link at position 3 and a rich result with stars and price at position 3 is the actual revenue impact of structured data, and it is large enough that the conversation about ranking factors is mostly a distraction.

JSON-LD versus microdata versus RDFa

Schema.org accepts three serialization formats. The vocabulary is identical across all three. The container is what changes.

JSON-LD (JavaScript Object Notation for Linked Data) is a script tag with type “application/ld+json” placed in the head or body of the document. It is fully decoupled from the visible HTML. The Google Search Central documentation explicitly recommends JSON-LD as the preferred format and has done so since 2015. Yoast and Rank Math both ship JSON-LD by default in their WordPress plugins. The reasons are concrete: maintenance is easier because the schema lives in one block rather than scattered across markup, the format is easier to generate server-side from a database, and Google’s Rich Results Test produces cleaner output for JSON-LD than for inline markup.

Microdata embeds the vocabulary directly inside HTML elements using itemscope, itemtype, and itemprop attributes. It was the dominant format from 2011 to 2015 and is still common in older Magento and OpenCart themes. It works, Google still parses it, but every change to the visible HTML risks breaking the markup, and templating engines that wrap content in additional divs frequently end up with malformed itemscope hierarchies.

RDFa (Resource Description Framework in Attributes) is the W3C standard that predates schema.org. It is more verbose than microdata, less common in ecommerce, and Google parses it but does not optimize for it. Some Drupal Commerce installations still use RDFa because Drupal 7’s RDF module shipped it by default.

The Search Engine Journal recommendation, repeated across years of structured data coverage, is unambiguous: JSON-LD for everything, migrate microdata when you next touch the template, and do not start anything new in RDFa. Yoast’s schema documentation makes the same call, and Merkle’s technical SEO team has been advising the same migration path for enterprise clients since at least 2019.

One operational note: do not mix formats on the same page. Two competing JSON-LD blocks describing the same Product, or a JSON-LD block plus inline microdata, will produce duplicate entities in Google’s index, and the Rich Results Test will surface this as a warning. The site that ships clean Product markup ships exactly one Product entity per page.

Required and recommended properties for the Product type

Google Search Central splits Product properties into required and recommended, and the required list differs depending on whether you want product snippet eligibility or merchant listing eligibility. The minimum useful payload is the same in both cases.

Required for any rich result eligibility:

name: the product name as it appears on the page, exactly
image: one or more high-resolution image URLs, ideally above 1200 pixels on the longest edge, hosted on a stable domain
offers: an Offer object containing price, priceCurrency, and availability at minimum

Required for merchant listing eligibility (Google Shopping rich results), in addition to the above:

offers.price: numeric, no currency symbols inside the string, decimal point not comma
offers.priceCurrency: ISO 4217 three-letter code (USD, EUR, GBP, CAD, JPY)
offers.availability: one of the enumerated schema.org values, full URL form preferred (https://schema.org/InStock, https://schema.org/OutOfStock, https://schema.org/PreOrder, https://schema.org/Discontinued, https://schema.org/BackOrder, https://schema.org/SoldOut)
offers.priceValidUntil: ISO 8601 date when the price expires, required when the price is a sale price

Strongly recommended, and required for AI Overviews eligibility under the 2026 update covered later in this document:

brand: a Brand object with a name property, matching the brand visible on the product page
sku: your internal stock-keeping unit, unique per variant
gtin (or gtin8, gtin13, gtin14): the global trade item number, EAN or UPC, twelve to fourteen digits, used by Google’s Shopping Graph to deduplicate the same product across sellers
mpn: manufacturer part number, useful when no GTIN exists
aggregateRating: an AggregateRating object with ratingValue and reviewCount, both as strings, both matching what the page visibly displays
review: an array of Review objects with author, reviewRating, reviewBody, and datePublished

The Schema.org reference at https://schema.org/Product lists every property the type accepts, including specifications that Google does not currently use for rich results (color, material, weight, depth, model, productID). Including them does no harm, costs a few bytes, and prepares the page for future surface areas. Yoast’s documentation has been arguing this point for years: if the data exists, ship it in the markup.

Merchant listing experience: price, availability, shipping, returns

The merchant listing experience is the rich result format that displays pricing, availability, shipping cost, and return policy directly in the search results. It is what Google Shopping integrations now live or die on. The format requires a tighter set of properties than the basic product snippet and is enforced more strictly.

Pricing fields:

offers.price: the current selling price, in the priceCurrency, as a string with decimal separator. “1299.00”, not “1,299.00”, not “$1,299”
offers.priceCurrency: ISO 4217, no exceptions
offers.priceValidUntil: when the price expires; if absent on a sale price, Google will treat the markup as suspect
offers.priceSpecification: optional object that allows reference prices, unit prices, and minimum order amounts; useful for B2B and bulk pricing

Availability fields. Use the schema.org enumeration. The full URL form is the safe choice, the short form (just “InStock”) is parsed but produces warnings in some validators:

InStock: available now, ships immediately
OutOfStock: not available, no restock date
BackOrder: orderable now, ships when restocked
PreOrder: orderable for future release
SoldOut: no longer available, do not display in shopping
Discontinued: permanently unavailable
LimitedAvailability: small quantity remaining

Shipping fields, packaged inside an OfferShippingDetails object on the Offer:

shippingRate: a MonetaryAmount with value and currency
shippingDestination: a DefinedRegion with addressCountry, regionCode, or postalCode
deliveryTime: a ShippingDeliveryTime with handlingTime and transitTime, each a QuantitativeValue with minValue, maxValue, and unitCode (typically DAY)

Return policy, packaged inside a MerchantReturnPolicy object on the Offer:

applicableCountry: ISO country code where the policy applies
returnPolicyCategory: enumeration value (MerchantReturnFiniteReturnWindow, MerchantReturnNotPermitted, MerchantReturnUnlimitedWindow)
merchantReturnDays: integer number of days the buyer has to initiate a return
returnMethod: how the return is performed (ReturnByMail, ReturnInStore, ReturnAtKiosk)
returnFees: who pays (FreeReturn, ReturnFeesCustomerResponsibility, ReturnShippingFees)

Google rolled the shipping and returns fields into the merchant listing experience progressively from 2022 through 2024. The current state, documented at developers.google.com/search/docs/appearance/structured-data/merchant-listing, treats these fields as eligibility-gating: a merchant listing rich result will not show shipping or returns unless the markup ships them, and the absence is now a competitive disadvantage on price-sensitive queries. Search Engine Journal coverage from late 2024 quantified this: merchant listings with full shipping and returns markup pulled 22 percent higher CTR than listings missing those fields, on identical queries and positions.

How rich results work, and the eligibility requirements

A rich result is a search result that displays additional information beyond the standard blue link, snippet, and URL. For Product structured data, the supported rich result formats are:

Product snippet: stars, review count, price, availability shown under the result; eligible on any product page with valid Product markup
Merchant listing: a richer card-style result that can include images, shipping cost, returns, and direct purchase signals; eligible only on pages that allow direct purchase, with all merchant listing required fields present
Product knowledge panel: the side panel that aggregates a product across sellers; eligible primarily on pages with valid GTIN and matching Merchant Center feed

Eligibility is the operative word. Google’s documentation is explicit: valid markup makes a page eligible for a rich result. It does not guarantee one. Whether the rich result displays depends on query intent, page authority, the Quality Score signals Google computes for the page, and the competitive set on the SERP. A small niche site with perfect markup will frequently see rich results because the competition does not have them. A large brand competing against Amazon and Walmart on the same SKU may have perfect markup and never see a rich result on that query because Google has chosen to display a different result type entirely.

The other half of eligibility is technical correctness. Google enforces a long list of rules that, if violated, downgrade the page from rich-result-eligible to plain-result-only:

The structured data must be present in the rendered HTML that Googlebot sees, not injected after JavaScript execution that Googlebot does not run
The values in the markup must match the visible page content; a price of 199 in the markup and 219 on the page is a markup violation
The aggregateRating must reflect actual reviews visible on the page, not synthesized or imported from off-site sources without attribution
Image URLs must be crawlable, not blocked by robots.txt, not behind authentication
The Product must be the dominant entity on the page; a category page that lists ten products and emits Product markup for one of them will be flagged

Yoast’s structured data documentation walks through these rules in detail and is one of the better technical references outside of Google’s own docs. The Schema.org primer at schema.org/docs/gs.html covers the vocabulary side; Yoast covers the enforcement side.

AI Overviews: how Google uses structured data to source product mentions

AI Overviews are the generative summaries that appear at the top of certain Google search results, synthesizing information from multiple sources into a single answer. They launched in limited beta as Search Generative Experience (SGE) in May 2023, expanded to a broader rollout as AI Overviews in May 2024, and have been a permanent fixture of US English commercial queries since late 2024. International rollouts followed through 2025.

The mechanics, as documented by Google in I/O 2024 and 2025 sessions and confirmed in Search Off the Record discussions, are:

The query triggers Google’s Gemini model to compose a generative answer
Gemini does not invent facts; it grounds its answer in pages from Google’s index
The grounding sources are selected based on relevance, authority, and the parseability of the page’s content
Pages with structured data are easier to parse and are weighted higher as candidate sources
The cited sources are displayed as link cards inside or beneath the AI Overview, and clicks on those cards drive traffic to the source pages

Search Engine Land’s coverage through 2024 and 2025, drawing on conversations with Google’s search liaison and on third-party measurement studies, has been consistent on one finding: pages with rich, complete Product markup are cited in AI Overviews at a rate that is several multiples higher than pages without markup. The exact ratio varies by query type and category. Search Engine Journal published an analysis in early 2025 that measured a 2.4x to 3.1x lift in citation rate for Product-marked pages on commercial queries, with the higher end of the range concentrated in queries that explicitly ask for comparisons or recommendations. Merkle’s technical SEO team published similar findings at SMX Advanced 2025, with measurements specific to enterprise ecommerce clients.

The intuition behind these numbers is mechanical, not magical. When Gemini grounds a price comparison answer, it needs prices it can extract reliably. A page that emits offers.price as a clean numeric string with offers.priceCurrency next to it gives Gemini the answer in two reads. A page that buries the price in a span with class “price-display” inside three nested divs requires Gemini to do template parsing, which is slower and less reliable. Gemini will pick the structured-data page as the citation source nine times out of ten, even when both pages contain the same information.

The same logic applies to availability, ratings, and shipping. Every property that the page emits in clean schema is a property that AI Overviews can cite without doing parser archaeology. Yoast made this argument as early as 2023 and has been broadcasting it consistently: the era of writing for humans and ignoring machines is over because the machines now write the answers humans see.

Feed data and structured data parity: the rule that breaks more sites than any other

Google operates two parallel ingestion pipelines for ecommerce data. The first is the Merchant Center feed, where merchants upload product data as XML, CSV, or via Content API. The second is structured data on the source page, parsed by Googlebot. Both pipelines feed the Shopping Graph, which is the unified product knowledge base behind Google Shopping, AI Overviews, Lens, and the various conversational shopping surfaces.

The rule, stated bluntly: the data in the feed and the data in the structured data must match. If they do not match, the product enters a degraded state in the Shopping Graph and may be excluded from one or more surfaces.

The fields where parity is enforced most strictly:

title in the feed must match name in the markup
price in the feed must match offers.price in the markup, to the cent
availability in the feed must match offers.availability in the markup; “in stock” in the feed maps to InStock in the markup
currency in the feed must match offers.priceCurrency in the markup
gtin in the feed must match gtin in the markup
brand in the feed must match brand.name in the markup
image_link in the feed must point to the same image, or one of the images, in the markup’s image array

The Merchant Center diagnostics dashboard surfaces parity mismatches as warnings, not errors, which is why so many merchants ignore them. The cost of ignoring them is gradual, not sudden. Mismatched products do not get hard-blocked; they simply lose merchant listing rich result eligibility, then lose Shopping Graph deduplication, then lose AI Overviews citation eligibility, in a cascade that plays out over weeks. By the time the merchant notices the traffic loss, the diagnostics dashboard has been showing the same warnings for two months.

The fix is structural. Generate the feed and the structured data from the same source of truth, ideally a database query that produces both formats from the same field set. Search Engine Land has run this advice in multiple feed management columns: the feed and the markup are not two systems, they are two views of one system, and any architecture that lets them drift apart will eventually drift apart.

Invalid markup: manual actions and ineligibility

Google enforces structured data quality through two mechanisms: algorithmic ineligibility and manual actions.

Algorithmic ineligibility is the soft enforcement. The page emits markup that Google parses but rejects on validation grounds: a missing required field, a malformed value, a value that does not match visible content, an image URL that returns 404. The page does not get penalized in ranking; it simply does not get the rich result. The Search Console Enhancements report flags these as errors or warnings depending on severity. The fix is to repair the markup, request re-validation in Search Console, and wait for the next crawl cycle.

Manual actions are the hard enforcement. A human reviewer at Google has examined the page or the site and concluded that the structured data is being used to mislead users. The Search Console Manual Actions report will surface a “Structured data issue” or “Spammy structured markup” notice. The page or the site loses rich result eligibility entirely until the action is resolved through a reconsideration request.

The behaviors that trigger manual actions, documented in Google’s structured data guidelines:

Marking content that is not visible to users (hidden reviews, hidden prices, content gated behind tabs that Googlebot cannot click)
Marking content that is not on the page (reviews from a different page, prices imported from a feed but not displayed)
Inflating ratings (synthesizing reviews, importing reviews from off-site without attribution, applying ratings to the wrong entity)
Misrepresenting availability (marking out-of-stock products as InStock to keep the rich result)
Marking up entities that do not match the page topic (a recipe page emitting Product markup for an unrelated affiliate offer)

The reconsideration process is slow. Google’s guidance is to fix the underlying issue, document the fix in the request, and expect a wait of several weeks before the action is lifted. During that period, the affected pages run as plain links. For a high-traffic ecommerce site, the revenue impact of a manual action is usually a six-figure number even at moderate traffic levels.

The defense against manual actions is procedural. Validate every template change with the Rich Results Test before deployment. Sample twenty product pages weekly and compare visible content to markup. Monitor the Search Console Enhancements report and treat any new error or warning as a same-week priority. Most manual actions are the result of an incremental drift, not a single deliberate violation, and the drift is detectable in the diagnostics if anyone is watching.

Debugging with the Rich Results Test and the Schema Markup Validator

Two tools cover the validation surface area for Product structured data.

The Rich Results Test, hosted at search.google.com/test/rich-results, is Google’s official validator. It accepts a URL or a code snippet, fetches the page using Googlebot’s mobile rendering pipeline, parses the structured data, and reports which rich result types the page is eligible for. The output is the only validator that matches Google’s actual ingestion. If the Rich Results Test says the page is eligible for a Merchant listing rich result, that is the same parser decision Google’s index will make. If it says the page is not eligible, the rich result will not appear regardless of what other tools report.

The Rich Results Test surfaces three categories of issues:

Errors: missing required fields, malformed JSON, invalid enumeration values; the page is ineligible until fixed
Warnings: missing recommended fields, deprecated property names, soft validation issues; the page is eligible but display quality is reduced
Detected items: a list of every entity Google parsed from the page, with each property visible; useful for confirming that nested objects are correctly structured

The Schema Markup Validator, hosted at validator.schema.org, is the schema.org community’s validator. It validates against the formal schema.org specification, not Google’s specific rich result requirements. It catches structural issues that the Rich Results Test passes silently because the Rich Results Test does not care about them: invalid property types on properties Google does not consume, misuse of expected types, deprecated vocabulary. For a debugging session, the workflow is to run both tools in parallel: Rich Results Test for Google eligibility, Schema Markup Validator for vocabulary cleanliness. Discrepancies between the two are usually a sign that the markup is using a property in a non-standard way that Google tolerates but other consumers may not.

For ongoing monitoring once the page is in production, the Search Console Enhancements report is the primary signal. It groups errors and warnings by report (Products, Merchant listings, Review snippets), shows trends over time, and provides the affected URLs. The pattern to watch for is a rising error count after a deployment, which indicates that a template change has broken markup at scale. The fix is to roll back the deployment, repair the template, and redeploy with a Rich Results Test pass on the changed pages.

Yoast and Rank Math both ship validation steps inside their plugin admin views, which catch common mistakes before the page is published. For custom platforms, integrating the Rich Results Test API into the deployment pipeline as a pre-merge check is the discipline that prevents structured data regressions, and is what mature ecommerce engineering teams do.

2026 update on AI Overviews eligibility

Google’s I/O 2025 announcements, expanded in early 2026 documentation updates, tightened the requirements for product mentions in AI Overviews. The changes are not a formal eligibility specification; they are a set of de facto signals that determine which pages get cited.

The 2026 baseline for AI Overviews citation eligibility on commercial queries:

Product markup must include name, image, description, brand, sku, gtin (or mpn if no GTIN exists), and an offers block with price, priceCurrency, and availability
aggregateRating with ratingValue and reviewCount must be present when reviews exist on the page; pages without reviews are still eligible but cited less frequently
review array with at least one Review object including author, reviewBody, and datePublished increases citation rate measurably
Merchant listing fields (shipping, returns, priceValidUntil) are required for citation in shopping-intent AI Overviews; the same query may pull from product-snippet markup for editorial intent
The page must match a Merchant Center feed item if the merchant operates one; mismatched products are filtered out of shopping AI Overviews entirely

The pattern that the 2026 documentation makes explicit is the parity rule applied to AI surfaces. A page can have valid markup, valid feed, and still be excluded from AI Overviews if the two sources disagree. Search Engine Land’s coverage of the 2026 updates uses the phrase “structured data is the table stakes, parity is the entry ticket,” and the framing is accurate. Markup gets the page into the candidate pool. Feed parity gets it onto the citation card.

The other 2026 development is the increased weight of brand verification signals. Google’s Shopping Graph now uses brand verification (claimed brand pages in Merchant Center, verified business profiles, official domain ownership) as a tiebreaker between competing sources for the same SKU. A small reseller with perfect markup may lose the AI Overview citation to the manufacturer’s official site even when the reseller’s price is lower. The advice from Merkle’s enterprise SEO practice is to claim brand pages in Merchant Center, file the brand verification, and ensure the structured data on the brand’s official domain is at least as complete as the resellers’ markup. Brands that do not maintain their own structured data are effectively giving the citation traffic to whichever reseller markets up most cleanly, which is rarely the best customer experience and is often a margin-destroying outcome.

Real CTR lift data from public case studies

The CTR lift from rich results is one of the more measurable effects in technical SEO, and several public case studies have established the range.

Search Engine Land’s rich results coverage has cited Nestle’s case study showing an 82 percent CTR lift on pages displayed as rich results compared to non-rich results on the same queries, originally published in Google’s own case study series in 2018 and reaffirmed in updated coverage through 2023.

Search Engine Journal’s 2024 ecommerce structured data analysis measured CTR uplift across a sample of mid-market retailers and reported a range of 25 to 40 percent CTR lift on Product-marked pages with full merchant listing fields, compared to the same pages with markup removed. The lower end of the range was concentrated in branded queries where the page would have been clicked regardless; the upper end was on generic comparison queries where the rich result genuinely differentiated the listing on the SERP.

Merkle’s technical SEO team published a 2025 enterprise study that measured the impact of adding Review and AggregateRating markup to product pages that previously had only basic Product markup. The result was a 17 to 22 percent CTR lift on the affected pages, with the variance driven by the visibility of the star rating in the rich result (some queries surfaced ratings, some did not). Merkle’s framing was that the AggregateRating addition paid back the implementation cost within the first month for any retailer above a threshold of approximately 100,000 monthly organic ecommerce sessions.

Yoast’s case study series, published through 2023 and 2024, focused on smaller WordPress and WooCommerce sites and reported CTR lifts in the 15 to 35 percent range after enabling full Product markup through the Yoast SEO plugin. The methodology was less rigorous than the enterprise studies but the direction and magnitude are consistent.

The consolidated picture across these sources: a 20 to 40 percent CTR lift is the realistic central case for adding complete Product markup with reviews and ratings to pages that previously had no markup or basic markup only. The 82 percent figure from Nestle is the upper bound and reflects unusually favorable conditions (highly competitive SERPs where the rich result displaced equivalent plain-link competitors). Anyone presenting structured data ROI projections should anchor on the 25 to 35 percent range and treat anything higher as a stretch case.

Common mistakes

The catalog of common mistakes is short and stable, in that the same mistakes recur across most of the audits Search Engine Journal, Yoast, and Merkle have published.

Mistake one is the price as a string with currency embedded. “$199.00” is wrong. The correct form is offers.price as “199.00” and offers.priceCurrency as “USD” in separate fields. Google rejects the embedded form silently in some cases and surfaces it as a warning in others, but it is never the right form.

Mistake two is the rating that does not match. The page displays four stars. The markup says 4.7. The Rich Results Test passes because the markup is internally valid, but Google’s runtime parity check downgrades the eligibility. Search Console eventually flags it. The fix is to compute the rating at render time from the same data source that drives the visible stars.

Mistake three is hidden reviews. The page has a review section that loads asynchronously after a click, but the markup includes all reviews from the database. Google’s parser sees the markup, attempts to verify the visible reviews, finds none on initial render, and flags the markup as misrepresenting content. The fix is to render the first batch of reviews on initial page load and only lazy-load additional pages.

Mistake four is the missing reviewCount. AggregateRating requires both ratingValue and reviewCount. Sites frequently ship the rating without the count because the count is harder to fetch in the template. The fix is to fetch the count as part of the same query that produces the rating.

Mistake five is the wrong availability enumeration. “Available”, “In Stock” (with title case spaces), “yes”, and custom values like “ShipsToday” are all rejected. The correct values are the schema.org URLs: https://schema.org/InStock, https://schema.org/OutOfStock, and the others listed earlier in this document.

Mistake six is missing priceValidUntil on sale prices. Google now treats sale prices without an expiry as suspect and reduces the merchant listing eligibility. The fix is to set priceValidUntil to the actual end of the sale, in ISO 8601 date format.

Mistake seven is markup on category pages. The category page lists ten products. Some templates emit a Product schema block for each one. Google parses this as ten Product entities competing on the same page, none of which is the dominant entity, and downgrades all of them. The correct pattern on category pages is either no Product markup at all, or an ItemList with embedded Product references that Google parses as a list, not as ten standalone Products.

Mistake eight is the duplicate Product block. Two plugins, or a plugin and a hand-coded block, both emit Product markup for the same page. The page now has two Product entities. The Rich Results Test surfaces this as a warning in some cases and silently picks one in others. The fix is to disable one source and pick a single owner for the markup.

Mistake nine is the GTIN that is not actually a GTIN. The field is populated with the SKU, or with a UPC plus a check digit error, or with leading zeros stripped by an Excel export. Google’s Shopping Graph deduplicates products by GTIN, so a wrong GTIN binds the page to the wrong product or to no product at all. The fix is to validate the GTIN against the GS1 check digit algorithm before publishing.

Mistake ten is the manual implementation that drifts. The team hand-codes Product markup for the top 200 SKUs, ships it, and then forgets about it. Six months later, prices have changed, descriptions have updated, and the markup is stale. The fix is to never hand-code structured data; always generate it from the same data source that drives the visible page content, so that the two cannot drift apart.

Implementation playbook for ecommerce platforms

Shopify

Modern Shopify themes (Dawn, Sense, Refresh, the 2024 Online Store 2.0 baseline) ship Product structured data natively. The markup is generated in the theme.liquid layout and the product.liquid template, using Liquid expressions that pull from the product object. The native markup covers name, image, description, brand, offers (with price, priceCurrency, availability), and aggregateRating when product reviews are enabled.

The native markup has known gaps. GTIN is not emitted by default; the product.barcode field exists but is not wired to the schema. Variant-level offers are sometimes collapsed into a single Offer, hiding inventory and price differences across variants. Merchant listing fields (shipping, returns, priceValidUntil) are not emitted at all.

The fix path on Shopify is to add a custom JSON-LD block in theme.liquid (or in a snippet included by theme.liquid) that supplements the native markup with the missing fields. The block reads from product.barcode for GTIN, iterates product.variants for per-variant offers, and pulls shipping and returns from shop settings or metafields. Apps in the Shopify App Store (Schema Plus, JSON-LD for SEO, Smart SEO) automate this addition with a configuration UI, which is the right choice for merchants who do not want to maintain Liquid code.

Validation: run the Rich Results Test on the live product page, not on the theme preview, because Shopify’s theme preview does not always render the same JSON-LD that the live page does.

WooCommerce

WooCommerce does not ship Product structured data in core. The markup must come from a plugin. The two production options are Yoast SEO and Rank Math.

Yoast SEO’s WooCommerce extension generates JSON-LD Product markup from the WooCommerce product fields, with name, image, description, sku, brand (when set via Yoast’s brand field or a third-party brands plugin), offers, and aggregateRating from WooCommerce reviews. The Yoast schema graph approach connects the Product to the Organization (the store) and the Person (the reviewer) as a connected graph, which is structurally cleaner than competing implementations and matches Google’s preferred entity model. Yoast’s documentation at yoast.com/help/woocommerce-seo-product-schema covers the field mappings.

Rank Math ships a more configurable Product schema with explicit fields for GTIN, MPN, manufacturer, multi-offer structures, and merchant listing fields (shipping, returns). Rank Math syncs with WooCommerce variations automatically and emits per-variant Offer objects, which is the correct behavior for variable products. The settings live under Rank Math > Schema > Product.

For requirements that exceed what either plugin handles, the manual route is to hook into wp_head with an action that emits a JSON-LD block conditionally on is_product(). The block constructs the array from $product->get_name(), $product->get_price(), $product->get_stock_status(), $product->get_average_rating(), and $product->get_review_count(), encodes with json_encode, and outputs inside a script tag with type “application/ld+json”. This route is fragile across WooCommerce upgrades and should be a last resort.

Magento and Adobe Commerce

Magento 2 ships partial Product structured data in the Luma theme through the schema_org module. The native markup covers name, description, image, offers with price and availability, and aggregateRating. It does not ship GTIN, brand, review array, or merchant listing fields by default.

The path forward on Magento is either an extension (Mageplaza Rich Snippets, Amasty SEO Toolkit, Mirasvit Rich Snippets) or a custom module. Custom modules in Magento are heavier than Shopify Liquid additions but produce more predictable output. The pattern is to register a block on catalog_product_view that emits the JSON-LD, with the block’s data provider pulling from the Product entity and any custom attributes.

Custom and headless platforms

Custom ecommerce platforms (Next.js commerce, Remix, Hydrogen, custom PHP, Django, Rails) build the structured data from scratch. The pattern is consistent across stacks:

Define a server-side function that takes a Product entity and returns a JSON-LD object
Render the JSON-LD inside a script tag in the page head, using the framework’s standard mechanism for head injection (next/head, react-helmet-async, Rails head tags, Django template blocks)
Source every property from the same query or service that produces the visible product data, never from a separate fetch
Validate the output in CI by running the Rich Results Test API against a representative sample of product URLs on every deploy

The headless variant adds one operational requirement: the markup must render server-side, not client-side. A React product page that hydrates on the client will emit the JSON-LD in the hydrated DOM, but Googlebot reads the initial HTML. Server-side rendering or static generation are the two acceptable approaches; client-only rendering of structured data is broken even when it appears to work in the browser.

Conclusion

Schema.org Product structured data is no longer the optional polish at the end of a technical SEO project. It is the table stakes for visibility in search results, merchant listings, and AI Overviews. The vocabulary has been stable for over a decade. The validators are free, public, and easy to integrate. The plugins on the major ecommerce platforms ship competent default implementations. The reasons not to ship complete Product markup in 2026 are operational, not technical, and they are reasons that compound into compounding traffic loss.

The implementation discipline is small and repeatable. Pick JSON-LD. Generate from the same source as the visible content. Ship name, image, description, brand, sku, gtin, offers (price, priceCurrency, availability, priceValidUntil), and the merchant listing block (shipping, returns). Add aggregateRating and review when reviews exist. Validate with the Rich Results Test on every deploy. Monitor Search Console Enhancements weekly. Reconcile the structured data with the Merchant Center feed monthly. Manage the brand entity and verify it in Merchant Center.

The teams that do this consistently see the CTR lift, the AI Overviews citations, and the merchant listing display, in that order, over a six to twelve week ramp. The teams that do not do this lose the surfaces silently to competitors that do. The cost asymmetry is what makes structured data the highest-ROI activity in ecommerce technical SEO, and what makes the absence of it in 2026 a competitive failure.