Product structured data should describe the real page and offer. Before asking someone to add markup, make sure the visible product, price, availability and option handling are consistent.
Begin with the customer-facing record
Choose an ordinary product and one with a meaningful variation. Record what a buyer sees before and after selecting an option. A product-wide starting price and a selected-variant price can be different, so the implementation needs to represent that deliberately.
Do not use an old catalogue export as unquestioned truth. If the live price changed yesterday, a technically valid block of stale data can still be wrong.
Understand the purpose without expecting a reward
Google documents product structured data for product-related search experiences, with different guidance for product snippets and merchant listings. Eligibility and valid markup do not guarantee a particular appearance in results. Google product guidance
Ask the implementer which experience the page is intended to support and which current requirements apply. Avoid copying a random code example without matching it to the page's actual type.
Make a field comparison sheet
Compare product identity, URL, image, currency, price, availability and any review information used. For every field, write where it comes from and when it updates. A value entered twice by hand is a maintenance risk.
The sheet should also identify who notices failures. If a stock change updates the page but not the structured data, the store needs an observable correction path, not a promise that it normally works.
Test difficult states deliberately
Inspect a sale ending, an unavailable item, a deleted product and a variant change. Use a controlled environment or an authorised existing example; do not alter live stock solely to obtain a screenshot.
A successful validation tool result is one check, not the entire test. Also compare the rendered page and the actual buying choice. Keep screenshots and the tested URL with the date so a later discrepancy can be investigated.
Avoid invented review evidence
Do not add an aggregate rating from a handful of unrelated testimonials or generate reviews to complete a schema example. Product reviews should belong to the product and retain their provenance.
Finish with a named source for each field and a regression check for changes. This is an implementation brief, not a claim that every oBizee deployment already exposes every form of markup. Use catalogue guidance to fix the underlying product record before adding another representation of it.
Illustrative case to check
A product page shows a starting price of ₹500, while the selected large option costs ₹700. Check which offer the markup describes and whether its URL leads to the matching choice. Do not force both amounts to ₹500 to pass a superficial comparison. Record the selection state and the intended representation, then ask the implementer to demonstrate the rule on another option.
Examples are illustrative. Confirm current features, charges and suitability before making a business decision.
Explore this topic → · Find an oBizee setup guide · Ask about your store