Product Structured Data in WooCommerce: What Google Actually Reads

Product structured data in WooCommerce: what Google requires, what WooCommerce generates on its own, what is missing, and how to complete the markup without errors.

Attribute table with reliability and source for every value: uploaded datasheet, store data or web page, then the values proposed by the writer without a source, the image alt text and the GTIN

Every WooCommerce store already publishes structured data. From the moment it is installed, each product page carries a JSON-LD block describing the product, its price and its availability. Most merchants are unaware of it, and that is often just as well: the markup works. But “works” does not mean “complete”. Between what WooCommerce generates on its own and what Google recommends for its merchant results, there is a gap that SEO plugins fill with varying degrees of success.

Here is what Google actually reads in a product page’s markup, what it does with it, and what is worth adding.

Structured data: what we are talking about

Structured data is a description of the page’s content in a vocabulary that search engines understand without interpretation. For products, that vocabulary is schema.org: a Product type, properties such as name, brand or gtin13, and an Offer that carries the price, currency and availability.

Google accepts three formats, JSON-LD, Microdata and RDFa, and recommends JSON-LD: a script block separate from the visible HTML, simpler to produce and maintain. It is the format used by WooCommerce, Rank Math and Yoast.

Two Google rules frame the whole exercise. First, the markup must describe what the visitor sees: you do not mark up content that is absent from the page. Second, valid markup entitles you to nothing. Google states that it does not guarantee a rich result will be displayed, even when the data is correct.

Two uses at Google: product snippets and merchant listings

Google’s documentation distinguishes two families of product results, and the choice does not depend on the merchant but on the nature of the page.

Product snippets apply to pages where the product cannot be bought directly: reviews, comparisons, editorial write-ups. They display a rating, an indicative price, sometimes pros and cons.

Merchant listings apply to pages where the customer can buy the product from the site. That is the case for every WooCommerce product page. They open the door to richer displays in search results and the Shopping tab: price, availability, shipping, return policy.

Google adds a point that is often overlooked: providing both structured data on the page and a Merchant Center feed maximizes eligibility and helps it verify the information. The two sources must therefore say the same thing. The feed has its own article, Google Merchant Center and WooCommerce.

The properties Google expects

For a merchant listing, the requirements are as follows.

Level Product Offer
Required name, image, offers price (or priceSpecification.price), priceCurrency
Recommended description, brand, gtin (or gtin8, gtin12, gtin13, gtin14), sku, aggregateRating, review, color, material, size, pattern availability, itemCondition, url, shippingDetails, hasMerchantReturnPolicy, priceValidUntil

Two details matter. The price must be greater than zero for a merchant listing. And the offer must be of type Offer, because the site must be the seller of the product. The AggregateOffer type, which summarizes a price range, is accepted for product snippets, not for merchant listings.

For a plain product snippet, the requirements are lighter: a name, and at least one of the three properties offers, review or aggregateRating.

What WooCommerce generates without a plugin

WooCommerce’s native markup is produced by the WC_Structured_Data class. For a product page, it contains:

  • the name, URL, description (short or long) and main image;
  • the sku, or failing that the product’s internal ID;
  • the gtin, when the GTIN, UPC, EAN or ISBN field in the Inventory tab is filled in and valid;
  • one or more offers with price, currency, availability, URL, seller and price validity date;
  • the average rating and reviews, if reviews are enabled.

This foundation covers every required property. It does, however, leave out several recommended properties: the brand (brand), the condition (itemCondition), shipping costs, the return policy, as well as attributes such as color or material.

Variable products deserve attention. When the variations do not all share the same price, WooCommerce describes the offer as an AggregateOffer, with a low price and a high price. That is correct for a product snippet, but it does not match what Google expects from a merchant listing. For variants, Google documents a different approach: a ProductGroup that groups distinct Product entries, linked by hasVariant or isVariantOf, each with its own offer.

Completing the markup without duplicating it

There are three routes to add what is missing.

Fill in the fields WooCommerce already knows how to use. The GTIN is the most rewarding: a single field, and the property appears in the markup. The article on EAN codes and GTINs in WooCommerce explains where to enter it and how to check that it is valid.

Hand the markup over to the SEO plugin. Rank Math and Yoast, depending on their versions and modules, replace or enrich WooCommerce’s product markup with the brand, the condition or additional properties. You then need to check that only one system produces the Product block. Two competing blocks, one native and one from the plugin, often contradict each other on price or availability.

Declare shipping and returns in the right place. Shipping costs and the return policy can be marked up on the page, but Google also lets you configure them in Merchant Center or Search Console. For shipping, the order of precedence described in its documentation puts those settings ahead of the page markup. For a store that applies the same rules to its whole catalog, this is often simpler and less fragile.

Here is a minimal compliant block for a merchant listing, on a fictional product:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Kanō cast iron teapot 0.8 l",
  "image": "https://maison-oriel.example/img/theiere-kano.jpg",
  "description": "Enameled cast iron teapot, 0.8 l, removable stainless steel infuser.",
  "sku": "ORI-TH-080",
  "gtin13": "3760000000017",
  "brand": { "@type": "Brand", "name": "Maison Oriel" },
  "offers": {
    "@type": "Offer",
    "url": "https://maison-oriel.example/theiere-kano/",
    "price": "64.00",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  }
}

The price is written with a decimal point and no currency symbol, the currency being carried by priceCurrency in ISO 4217 format.

The case of the FAQ

Many product pages add an FAQ marked up as FAQPage. It is worth knowing what to expect from it in 2026. Since August 2023, Google had already restricted the display of rich FAQ results to authoritative government and health sites. On May 7, 2026, it stopped displaying them for all sites, then removed the corresponding documentation in June.

FAQPage markup is not penalized for all that. It remains a valid schema.org vocabulary, readable by other systems, and it cleanly describes a question-and-answer section. But it no longer produces any special display in Google. The value of a product FAQ now lies in its content: precise answers to the questions buyers actually ask, visible on the page.

Testing and monitoring

Google’s Rich Results Test indicates whether a URL is eligible for merchant listings and product snippets, and flags missing properties. It runs one page at a time, ideally on a simple product, a variable product and an out-of-stock product.

In Search Console, the reports dedicated to merchant listings and product snippets aggregate errors across the whole site. A warning on a recommended property does not prevent eligibility; an error on a required property does.

These tools check syntax, not truth. Markup that announces “in stock” for a sold-out product, or a wrong brand, will pass the test without complaint. Consistency between the page, the markup and the feed remains the merchant’s responsibility. It is also one of the items on the WooCommerce SEO checklist.

Markup fed by verified data

Fichewise enriches the Product markup from the information it has established for each product page: brand, GTIN, source-backed attributes, as well as the written FAQ, marked up as FAQPage. The full list of properties produced is in the documentation. The plugin is licensed and runs either on your own API keys (the cost is then limited to that of the API, around €0.25 per product page) or through the managed service with credit packs, with no key to manage; prices are on the pricing page.