WooCommerce product schema
Why a variable product needs one offer per variation, and how to check what your shop publishes today.
The problem with a variable product
A variable product is one post with several prices. A plugin that publishes the default variation's price publishes a rich result that is wrong for every buyer who wanted a different variation, and Google has no way of knowing it is wrong.
Correct output for a variable product is a price range plus an offer per variation, each with its own price, stock state, SKU and condition. The SolSEO plugin writes that.
The fields worth filling in
- brand, on every product. A missing brand is the most common warning on a shop.
- gtin where one exists. A handmade item has none and that is fine; leaving the field out is correct, putting the SKU in it is not.
- shippingDetails and hasMerchantReturnPolicy. Google has been steadily upgrading these from optional to expected, and they are a site wide setting rather than per product work.
- aggregateRating only if you have real reviews. Inventing one is a manual action.
Checking what you publish today
Open a product page, view source, and look for the application/ld+json block. Or let the audit do it: the WooCommerce category of a SolSEO crawl reads the rendered schema on every product rather than the plugin settings, because the settings are what somebody meant and the schema is what shipped.
The three findings worth acting on first:
- A price in the schema that disagrees with the price on the page.
- A product marked in stock in the schema and out of stock on the page.
- A variable product publishing one offer instead of several.
The first two are Merchant Center problems before they are SEO problems, which usually makes them the ones with money attached.
Testing what you publish
Google's Rich Results Test on one product URL, which tells you whether Google can read it.
Search Console's enhancement reports, which tell you what Google actually read across the whole site over time. This is the more useful of the two once the first one passes.
The SolSEO crawl, which reads the rendered schema on every product it crawls and compares it with the page beside it. That comparison is the part the other two do not do: a valid schema saying $49 next to a page saying $59 passes every validator and is still wrong.
Why a shop gets this wrong without noticing
Because nothing breaks. The page renders, the product sells, and the only symptom is a rich result that quietly does not appear, or appears with a price that makes the click worse than useless.
The schema is written by whichever plugin last claimed the hook. Change themes, add a second SEO plugin, or install a product feed extension, and the output can change without any setting being touched. That is why the audit reads the rendered output rather than the settings: the settings are what somebody meant, and the schema is what shipped.
Thirty four checks, not twenty eight
A product page in the SolSEO plugin gets thirty four checks against twenty eight on a post. The extra six are the ones that only make sense on something with a price, a stock state and variations.