Guide Structured data · 7 of 8
Product Schema Markup: Choose, Add, and Test the Right Data
Choose the right product schema markup, adapt a Product and Offer JSON-LD example, and test price, stock, and live page data before changing your store.
Key takeaways
- Choose the search feature based on what the product page actually does.
- Check required Product and Offer fields for that feature.
- Keep price and stock linked to accurate catalog data.
- Test real page types and pair schema checks with broader page review.
Product schema markup describes a product and, where relevant, the offer attached to it. Start by deciding what the page does: sell an item, review it, or help readers browse a range. Then check the rules for the search feature that fits. A valid Product object is not a promise of a shopping result.
This guide explains that choice, shows a fictional Product and Offer example, and gives you a way to check live prices and stock. For the broader terms and formats, see our structured data for SEO guide.
Choose between product snippets and merchant listings
Google’s Product overview separates two paths. Product snippets can suit pages where readers cannot buy the item directly, such as a review. Merchant listings apply to pages where customers can buy products from you. There is overlap, so read the rules for your case. For the product page navigation, build and test a breadcrumb trail separately from its offer data. For the buying guide rather than the sales page, check Article and BlogPosting fields that describe the editorial content. If a review names a writer, connect author profiles to their articles separately from the product being reviewed.
Imagine a small store that sells a desk lamp and also writes a guide to choosing one. The product page and buying guide serve different tasks. Do not copy the same offer onto both just because the lamp appears in each.
A category page with many lamps also differs from a page for one lamp. Write down the page type and the item it describes before changing the template. That step prevents a general article or archive from inheriting facts that belong to one product.
Gather the product facts and their source
Use a short review sheet with a field, its source, and the value shown on the page. Include the product name, image, item URL, price, currency, and stock state where they apply. Name the person who owns updates to each field. For the seller behind the catalog, keep the business and publisher identity consistent.
For a store, the product catalog should drive the offer data. A writer should not need to edit JSON whenever stock changes. Ask the developer how the page and markup read the same source. Then check a live example rather than relying only on the store dashboard.
For a review site, check the difference between the product and a seller’s offer. Do not claim to sell an item when the reader must leave your site to buy it. Match the facts and page purpose before choosing which data to include.
Schema.org Product defines a broad vocabulary. Google’s search features use their own rules within that vocabulary. A field that is valid in Schema.org does not by itself make your page eligible for a Google feature.
Check the required fields for your chosen feature
Google’s product snippet rules require a name and at least one of offers, review, or aggregateRating. If you use an Offer, price or priceSpecification.price is required. Currency is strongly recommended for snippets and required for merchant listings.
For merchant listings, the core Product fields include name, image, and offers. Check the nested Offer rules as well, including price and currency. More detailed features have extra requirements. Treat the official guide as the specification for your own setup.
Keep missing facts separate from code errors. A shop with no reviews should not invent a rating to remove a warning. Decide whether a field truly applies. If it does, fix the source or collect the real information through an honest process.
Build a Product and Offer JSON-LD example
The sample below describes a made-up desk lamp for sale. The domain, image, product, price, and stock state are fictional. This is a small teaching example, not a full feed or a guarantee that a page meets every merchant rule.
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Example Reading Lamp",
"image": "https://example.com/images/reading-lamp.jpg",
"offers": {
"@type": "Offer",
"url": "https://example.com/products/reading-lamp/",
"price": "49.00",
"priceCurrency": "USD",
"availability": "https://schema.org/InStock"
}
}
A developer can place the object in a script element with type application/ld+json. In a store CMS, check what the product template already outputs before adding code. Replace sample values with the real catalog fields.
Open the image file and product link too. A correct-looking path can lead to an old image or a different model. Our image SEO guide covers the wider image checks. Here, focus on whether the file shows this exact product clearly.
Keep price, stock, and variants in sync
Test a price change on a safe copy of the store. Compare the visible price, markup, and the selected item. Then check the public output after release. A cached page can lag behind the catalog, even when the store editor shows the new price.
Do the same for an item that goes out of stock. The sample’s InStock value should not remain fixed while the page tells shoppers the lamp is unavailable. Give the stock field a source that updates with the store.
Variants need special care. A lamp may come in two colors or sizes with different prices. Google provides separate product variant guidance. Plan that model before copying one offer to every version. Record which variant the page, image, and price refer to.
Keep shipping and return claims accurate too. Do not copy another store’s policy into code. If you add those features, review their current requirements and use the actual policies shoppers can read on your site.
Test the live page before a broad rollout
Run the code through Google’s Rich Results Test. Then test the public product URL after the CMS saves it. Use the Schema Markup Validator to review the wider data model. Read each issue in context; the tools answer different questions. If a product report still shows a problem, fix and validate Search Console schema issues across the affected pages.
Choose a small test set: an item in stock, an item out of stock, a sale item, and a variant page if you have one. Record the expected values beside the live ones. That set gives you a repeatable check after template updates.
If two tools show conflicting prices or product names, trace which template or plugin generates each block. Our WordPress schema conflict guide explains the general method. Fix the source instead of adding a third copy.
Review page quality alongside product data
Google also supports product feeds through Merchant Center. If you use both a feed and page markup, keep the underlying facts aligned. A schema test alone does not review every feed rule or decide which search display appears.
DEX Health can help you check wider page quality and SEO, including on the free plan. Pair that review with product schema tests and any feed checks your store needs. Do not treat a high Health score as proof of merchant eligibility.
Put one person in charge of the test set and update record. Recheck it after changes to the catalog connection, theme, or product template. Explore DEX if you want page checks alongside your content work. Keep the goal clear: help shoppers see the right item, price, and next step on a useful page.
FAQ
What if I do not have customer reviews?
+
Do not add made-up reviews or ratings. Check the rules for your chosen feature and use real information that applies to your page, such as an accurate offer where appropriate.
Should an editor update the price inside every code block?
+
A shared product template should read the correct source fields. Ask the developer to check that connection so routine catalog changes do not depend on manually editing each page's code.
What should I save after a product schema test?
+
Keep the URL, date, selected item or variant, expected price and stock state, and findings. Use the same sample pages when you recheck a template change.
Sources
- Product structured data overview · Google