Ecommerce Product Structured Data: Prices, Availability and Variants

Product structured data should describe the item a customer can actually inspect and buy. It is not a hidden place to add optimistic prices, invented reviews or availability that the warehouse cannot support. The useful goal is consistency between catalogue information, the visible page and the data search systems receive.

This guide uses a hypothetical skincare shop to explain the workflow. Its products and examples are illustrative, with no health or customer-result claims. You do not need to begin by writing a large code block. Begin by identifying the fields, their owners and the product states your implementation must represent accurately.

Know which product experience you are describing

A purchasable product detail page is different from an editorial comparison or a category containing many products. Google's Product structured-data overview distinguishes merchant listing and product snippet experiences. Use the requirements appropriate to the page rather than adding a generic Product template everywhere.

For a skincare store selling a cleanser, the page should clearly identify the actual product and offer. A guide comparing several routines is not automatically the same kind of page. Do not pretend that an entire collection is one purchasable product simply to obtain a validation result.

Make the scope explicit in the implementation brief: which templates are included, which are excluded and which system currently produces the markup. This prevents a theme, plugin and custom integration from each publishing conflicting versions of the same information.

Build a field-ownership worksheet

List the product name, description, image, product identifier, brand where applicable, offer URL, price, currency and availability. Add relevant variant properties and actual shipping or return information supported by the implementation. For each field, record the source and the person responsible for accuracy.

For example, merchandising might own the product name and pack size, inventory might own availability, and the commerce platform might calculate the active offer. Do not ask an editorial writer to guess a price or product identifier because a template requires one.

Use this worksheet during changes as well as initial setup. A price promotion, new pack size or retired variant can invalidate information that was correct when the page first launched. A one-time successful test is not a maintenance process.

Check the current merchant requirements

Google's merchant listing documentation is the reference for required and recommended Product and Offer properties. Review the current requirements for the feature you intend to support. More properties are useful only when the data is accurate and applicable.

Start with a representative, purchasable item. Inspect the rendered data alongside its visible name, image, active price, currency and availability. If the markup says one pack size while the photograph and heading show another, the problem is factual even if the JSON parses correctly.

Do not copy the documentation's example reviews, identifiers or prices into a live product. Example values demonstrate a format; they do not become facts about your store. Where information is genuinely unavailable, resolve the source question or omit optional fields appropriately.

Make the offer match the transaction

Test what a customer sees before and after selecting a variant. Check the price and currency on the product page, basket and checkout path. If a membership price, sale price or regional offer applies, confirm the conditions rather than exposing a lower number without explanation.

For an illustrative cleanser available in two pack sizes, the selected offer must relate to the chosen size. A product-family description is not enough to explain which item the displayed price buys. Keep the underlying catalogue relationship clear before adding more structured properties.

Also check update timing. A cached page, feed export and inventory integration can refresh at different times. Record how a merchandising change propagates and where the team will detect a mismatch. Our out-of-stock product guide provides a decision framework for availability changes.

Describe genuine variants as a group

Variants are different purchasable options of the same parent product, not every loosely related item in the shop. Google's ProductGroup guidance explains supported relationships using product-group and variant properties for single-page and multi-page implementations.

Use your catalogue worksheet to identify the actual variation dimensions, such as size or colour where relevant. Then test direct variant URLs and their visible states. A group relationship should make the data easier to understand, not hide that two products have different ingredients or purposes.

Agree on an implementation owner for the group, variant and offer output. If one plugin publishes the parent while another publishes individual offers, review the combined result for contradictions and duplicate identities before releasing it.

Do not manufacture eligibility signals

Only include ratings and reviews that genuinely exist, are applicable to the product and meet the relevant policies. Never invent a customer, a star score or a review count to make the markup look complete. The same principle applies to brand claims, certifications and stock information.

Google's structured-data policies require truthful, relevant representation and explain that valid markup does not guarantee a rich result. A successful syntax check is an engineering check, not an endorsement from Google or proof of improved rankings.

For the hypothetical skincare example, avoid adding treatment claims that the product's approved information does not support. The SEO implementation should preserve factual boundaries, not expand them because a field accepts arbitrary text.

Validate data and behaviour separately

Use Google's Rich Results Test to check supported structured-data output, then inspect the live URL and relevant Search Console reports after release. These checks answer different questions: whether the format is understood, whether the page is accessible and what Google has observed.

Perform your own factual review as well. Compare fields against the page and source catalogue, change a representative stock state and open a variant directly. A tool may not know that the business stopped selling the displayed pack yesterday.

Keep a small regression set: a standard product, a sale item, a product with variants, an unavailable item and a page that should not receive product markup. Re-run it when themes, plugins, feeds or pricing rules change.

Product-data release checklist

Before extending the implementation across the store, confirm the following:

1. Identify the page type and intended Google product experience.
2. List the component that generates each markup block.
3. Assign a verified source and owner to each product and offer field.
4. Compare name, image, identifiers, price, currency and availability with the visible page.
5. Open variant URLs directly and confirm the correct item and offer.
6. Remove example values, invented reviews and unsupported claims.
7. Validate required properties and investigate conflicting output.
8. Check accessibility to crawlers and review representative live pages after deployment.
9. Save test results, release dates and the process for future catalogue changes.

Treat validation errors as work items with owners, not simply a score to reduce. Group recurring problems by template or source field. If one catalogue mapping is wrong, correcting that mapping may be more reliable than manually editing hundreds of product pages.

Our product page SEO checklist helps review the customer-facing information that structured data must represent. Start there when the underlying product explanation is incomplete.

Improve your ecommerce SEO with 1Rank

Use 1Rank's SEO workflow to organise product-content and technical priorities around information your store can verify. Create your 1Rank account to begin with the available website baseline. Registration is separate from paid ongoing services and does not activate a paid plan. Structured data can support eligibility, but rich results, indexing, rankings and sales are not guaranteed.

Frequently asked questions

Do I need both a product feed and structured data?

They are complementary ways to provide product information, with requirements depending on the experience you use. Google describes benefits to using both. Keep their values consistent; having two sources is not useful if they disagree about the offer.

Does passing the Rich Results Test guarantee a rich result?

No. It helps validate supported structured-data output. Google decides whether an eligible enhancement appears, and wider policies and page conditions still apply. Treat the result as a technical check rather than a ranking or display promise.

Can I leave sample ratings in a generated template?

No. Remove all sample customer names, scores and counts. Publish only genuine, applicable information that meets the relevant policies. If a product has no qualifying reviews, do not invent them to fill optional fields.