Google Merchant Listing Schema 2026: Product, Category & Sale Price Checklist

1. Confirm that the page is a purchasable product page

Merchant-listing experiences are intended for pages where a shopper can purchase a specific product or a variant of it. Do not apply one Product entity to a generic category, collection or article simply to obtain a rich result. The visible page should clearly identify the product, offer, seller and action. Editorial reviews use different product-snippet guidance.

2. Choose one canonical product identity

Use a stable product ID, SKU and appropriate global identifier where available. Keep the name, brand and identifiers consistent across the page, feed, inventory and order system. Do not create a new identity for every temporary campaign. For variants, define whether each selection has its own URL and ensure the structured data describes the variant actually visible at that URL.

3. Provide truthful name, description and images

The product name and description should match what the customer sees and receives. Use original, high-quality images that show the real item and relevant angles. Avoid promotional text, watermarks or placeholder imagery where the platform rules prohibit them. Do not add hidden keywords or claims to schema that are absent from the page; structured data must represent visible product facts.

4. Encode the active price and currency correctly

Merchant listings require an active price greater than zero and the corresponding three-letter currency, such as INR. If the active price appears both at the Offer level and inside a price specification, Google says the Offer-level price takes precedence. Keep tax and minimum-quantity meaning consistent with the visible page and checkout. Never mark a “starting from” number as the purchasable price when the shown item cannot be bought for it.

5. Add sale pricing only when the sale is real

Google distinguishes active, strikethrough and member pricing. The higher reference price should be a genuine regular price, not an inflated number created for an artificial discount. Mark the active sale price and, where applicable, the strikethrough price using the supported price specification. The visible page and checkout must show the same commercial reality.

6. Define sale start and end time

Google’s clarified 2026 guidance supports validFrom with validThrough or priceValidUntil to state the effective period. Use ISO 8601 dates and include time and timezone for precision. Ensure the start is not after the end. Expired priceValidUntil data can prevent a listing from displaying, so the promotion process must remove or replace old dates automatically.

7. Use category information as a classification aid

Google documented the Product category property with Text or CategoryCode types to align more closely with Merchant Center concepts such as product type and Google product category. Use a specific, accurate hierarchy rather than a list of keywords. Keep the merchant-defined category and any official taxonomy mapping controlled in the catalog system so different pages do not classify the same SKU inconsistently.

8. Keep availability synchronized

Use supported availability values such as InStock, OutOfStock, BackOrder, PreOrder or LimitedAvailability only when they match current order capability. A feed that says in stock while the page or checkout rejects the order creates a poor customer experience and possible product-data issues. Set a refresh and exception process for fast-moving stock, store-only items and discontinued products.

9. Handle variants without duplicate confusion

Colour, size, material and pack variants may need distinct URLs and offers. Make the selected variant clear in the URL, visible content, canonical strategy, images, SKU, price and availability. Do not list every combination as the same unnamed product. Test that search engines and customers land on an orderable selection rather than a default option that changes the price silently.

10. Align shipping and return policy data

Google supports merchant shipping and return-policy information through structured data and Merchant Center settings, with regional feature differences. Prefer a global policy at the organisation level where appropriate and override only genuinely different products. Publish the real delivery area, cost, handling time, return window, conditions and refund method. Do not copy examples from another country when the supported fields or business policy differ in India.

11. Keep Merchant Center and website facts consistent

Structured data and a Merchant Center feed can complement each other. Decide which catalog system supplies title, link, image, price, availability, identifiers and category. Reconcile feed diagnostics with website changes rather than fixing only one surface. A schema plugin cannot correct an inventory feed that exports yesterday’s stock or a checkout that adds an undisclosed mandatory charge.

12. Audit reviews and ratings carefully

Use review and aggregate-rating markup only for genuine product reviews that are visible to users and follow the current guidelines. Do not copy marketplace ratings without permission, combine ratings from unrelated variants or mark up a business-level testimonial as a product review. Google has explicitly strengthened guidance around fake and undisclosed incentivised reviews. Keep moderation, source and calculation documented.

13. Validate code before broad rollout

Test representative pages with Google’s Rich Results Test and check critical and non-critical issues. Then use URL Inspection in Search Console to see the rendered page. Deploy to a small product group first, confirm that prices and variants are correct and monitor the merchant-listing report. Passing a syntax test does not prove that the underlying commercial data is accurate.

• Code check: valid JSON-LD, required Product and Offer properties and supported values.
• Page check: every marked-up fact is visible, current and purchasable.
• Feed check: identifier, price, stock and destination URL match the page.
• Checkout check: final price, delivery and return conditions do not contradict the offer.

14. Monitor errors by revenue and risk

Prioritise products with high traffic, sales or data volatility instead of treating every warning equally. Critical errors can affect eligibility, while recommended-property warnings may improve completeness but are not always required. Build alerts for price mismatch, expired sale dates, unavailable landing pages, missing images and stock divergence. Assign each issue to catalog, engineering, merchandising or fulfilment ownership.

15. Measure search value honestly

Use Search Console product-result impressions and clicks where available, Merchant Center performance, landing sessions, add-to-cart, purchase and contribution. Rich-result visibility can change, and Google does not guarantee display. Compare a controlled product group over sufficient time and note promotions, stock and seasonality. Do not attribute all sales growth to schema merely because markup was deployed.

16. Run a 30-day implementation sprint

Days 1–5: choose a product group and map the source of every field. Days 6–12: fix page facts, identifiers, images and variant URLs. Days 13–18: add and validate structured data plus feed alignment. Days 19–25: monitor Search Console and Merchant Center diagnostics. Days 26–30: correct recurring causes, document ownership and decide whether the catalog is ready for wider rollout.

17. Use a publish, repair or pause rule

Publish broadly when the source data is stable, schema passes validation, checkout matches the offer and operational owners can maintain updates. Repair when warnings reveal missing completeness or recurring sync delay. Pause merchant markup for a product when price, stock, policy or identity cannot be kept truthful. Accurate basic data is more valuable than ambitious markup built on unreliable operations.