Product schema: keep price and availability accurate

Product structured data helps Google interpret an offer. It cannot replace a clear product page and does not guarantee a rich result.

Inspect visible information first

A buyer needs a product name, image, price, currency and availability. For variants, confirm which URL and price belong to each selection. Do not mark an unavailable item as in stock, or present an invented rating as a customer review.

Match markup to the page’s role

When your store directly sells an item, merchant listing markup links Product to Offer. Google sets out the merchant listing requirements, including consistency with the visible offer. An editorial page discussing a product sold elsewhere is different: Google distinguishes product snippets from merchant listings. That distinction matters for a magazine that links to another seller.

Test catalog changes

Inspect a simple product, one with variants and one that is out of stock. Use the Rich Results Test and Search Console reports to find missing fields. Check that stock and price updates change both visible HTML and markup at the same time.

Reliability matters more than filling every optional field. Record who owns updates to prices, variants and availability.

A common mismatch

A theme may display “sold out” while an app still inserts “in stock” into structured data. That mismatch matters more than a missing optional field. Run a test on a low-stock product, then inspect public HTML after inventory changes. For variants, check at least one different price and a partly sold-out selection. Keep a dated screenshot and test result so the behavior can be compared after a theme or app update.

Trace one product and its variants end to end

Choose a product with two variants, one of them unavailable. For each, record the URL, displayed price, currency, availability and catalog identifier. Compare those facts with the rendered HTML and Product markup. If a size is marked “in stock” but cannot be ordered, the underlying inventory or rendering may be wrong; a syntax test alone will not resolve it.

Illustrative example: a jacket comes in blue and black. The black version costs more and is sold out. One generic offer showing the blue price for every variant could mislead shoppers. Check how your theme and platform describe variants and compare your merchant feed if you use one. Never manufacture ratings or reviews to obtain a rich result; structured data must correspond to genuine, verifiable information.

Check again after catalog changes

After a price, stock or theme update, inspect a popular product, one with variants and one sold-out product. Run the URLs through Google's Rich Results Test, then compare the output with what a shopper sees. The test can confirm a supported format; it cannot guarantee a rich display or correct inventory. Add a manual cart check and, where relevant, Merchant Center checks.

Keep the date, URL and values you compared. When an alert later appears, that record will help distinguish a catalog, theme or caching problem.

Match markup to what buyers see

Before editing Product JSON-LD, open the public page and record name, image, price, currency, availability and variants. These values should match the visible offer and store settings. Markup saying “in stock” when the chosen variant is unavailable creates a contradiction; another tag cannot repair inaccurate inventory. If the theme or an app already generates markup, inspect the HTML before installing a second source.

Test a simple product and one with variants. Compare markup with the visible price for each option, respecting platform limits. Reviews should appear only when genuine and eligible under search and platform rules; inventing a rating to obtain stars is misleading.

Build useful monitoring

After a theme update, price import or app installation, check sample products in Google's testing tool and on public pages. Note URL, date, errors or warnings and the fix. Syntax validation shows code can be read; it does not prove rich-result eligibility or appearance in Google.

Tie the check to catalog operations: a person changing price and stock should know markup must follow. If Search Console reports many errors on one field, inspect their shared template or app instead of patching a hundred pages by hand. Accuracy for buyers comes first, then consistency of the data exposed to search engines.

A product-markup spot check

Select a simple product and one with several variants. Copy their visible name, price, currency, availability and image into a sheet, then compare with the structured data in the rendered HTML. Check whether more than one plugin or theme component emits Product markup. Run Google's test tool to identify syntax issues, but confirm facts manually against the live offer.

Change a test variant's stock status in a staging environment if available and see whether the visible page and markup update together. If they diverge, fix the source or template before publishing the change. Record the date of the check and repeat after app, theme or feed changes. A valid markup test is not a promise of rich results; consistent, truthful product data is the operational goal.