Structured data is the difference between a search engine reading your product page as a wall of text and reading it as a product with a price, a stock status and a rating. It is also increasingly how automated systems — shopping surfaces, comparison tools, assistants — decide whether they can quote you at all. The work is unglamorous and mostly consists of being accurate.
Most WooCommerce stores already output Product schema through the core plugin, a theme or an SEO plugin. The common failure is not absence, it is inaccuracy: markup that disagrees with the visible page, or that describes things the page does not contain. That is worse than having none, because it can get the enhancement withdrawn.
The fields that carry the weight
A product needs a name, an image, a description and an offer. The offer is where the value sits: price, priceCurrency, availability and a priceValidUntil where relevant. Identifiers matter more than people expect — gtin, mpn and brand are what let systems recognise that your listing and someone else's are the same physical product, which is exactly what comparison and shopping surfaces need to do. Google's own guidance treats a missing identifier as a warning and not an error, so nothing breaks — the listing simply competes less well, which is the failure mode nobody notices in a validator. If you make the product yourself and it has no GTIN, supply mpn and brand and stop there; inventing an identifier is worse than omitting one.
- name, image, description, sku
- offers: price, priceCurrency, availability, url
- brand plus gtin or mpn wherever you have them
- aggregateRating and review only when the page really shows them
The rule that decides whether it works
Structured data must describe what is on the page, visible to the user. If your markup says the price is $49 and the page shows $59, or claims an in-stock status the page contradicts, that is a mismatch a crawler can detect automatically. The same applies to ratings: markup that reports four and a half stars on a page with no visible reviews is the single most common reason a store loses its rich results, and repeated abuse can attract a manual action on top of the quiet withdrawal.
This is a firm rule here for a reason. Review and rating markup is only ever added for real, permissioned customer reviews that appear on the page. Inventing them is a short-term trade for a long-term liability, and it is the same argument made in reviews and trust.
Variable products, where most stores get it wrong
WooCommerce variable products create a genuine modelling question: is a page one product with several offers, or several products? The workable answer is a product with an offer range — a low and high price with the currency — or, where the shopper selects a variant that changes the URL, distinct product markup for the selected variant. What does not work is marking up only the cheapest variant while the page displays a different price, which is how "price mismatch" errors appear in Search Console for stores that believed their schema was fine.
Availability is a promise, not a decoration
Stock status in markup should reflect the truth at the time the page is served. Cached pages are the usual culprit. A page cached while a product was in stock keeps declaring availability after it sells out. If your catalog moves quickly, either keep that field accurate through cache invalidation or accept that a stale field is a customer disappointment waiting to happen. Search Console's Merchant listings report is where the consequences appear first.
Do not stack three sources of schema
A common state on older stores: WooCommerce outputs Product schema, the theme outputs its own, and an SEO plugin outputs a third. The result is duplicated and sometimes contradictory markup on the same page, which forces the crawler to choose. Pick one source, disable the others, and verify with a testing tool that exactly one Product object appears. This is a ten-minute audit that resolves a large share of unexplained rich-result problems.
Beyond Product: the ones worth adding
BreadcrumbList helps search results display your category path instead of a raw URL, and it is cheap. Organization on the homepage carries your name, logo and contact details. FAQPage is worth adding only where the page genuinely contains questions and answers a customer asked — not as a way of injecting keywords into a results page. Beyond those, more schema types rarely produce more value on a store.
Verify, then verify again after every theme update
Test a product URL in the Rich Results Test after any change to the theme, the SEO plugin or the product template. Then watch Search Console's Product snippets and Merchant listings reports for the following two weeks, because that is where errors surface at scale, where a validator shows you one URL at a time. A theme update silently removing schema is common enough that it should be on your post-update checklist next to checkout testing — see Search Console for store owners for the reports that show it.
Why this matters more than it used to
Rich results were the original reason to care. The newer reason is that automated systems increasingly answer product questions by reading structured, unambiguous data, with no interest in parsing marketing prose. Accurate identifiers, explicit specifications and consistent naming across your site and your feeds decide whether those systems can describe your product correctly — which is the practical core of AI search visibility, minus the hype.
Structured data is not a ranking trick. It is a claim about your product that a machine can check — so make claims you can defend.