How to Show Price and Stock in Google Results: Product Structured Data Guide

In short, product structured data translates your page into a language machines understand. At Talha Aslan and team, this is one of the questions ecommerce clients ask us most often: "A competitor's result shows price and in stock, so why doesn't ours?" This guide answers that step by step. We also cover required and recommended properties, the Merchant Center connection, Search Console reports, and the most common errors.

First, let's set expectations. According to Google's own documentation, each experience shows result enhancements at its own discretion. In other words, correct markup is a necessary condition for display, not a sufficient one. Therefore we recommend you treat the goal as "earning eligibility."

Our aim is simple: after reading, you should be able to open your own product page and spot the missing property yourself. For that reason, every section first explains what Google's official documentation says. Then it explains what that means in practice. We also define technical terms the first time they appear, so you can follow along without a developer background.

Where exactly do price and stock details appear in search results?

Google can use product information in several places. A line with price, availability, and star rating can appear under the classic blue link. On the other hand, richer surfaces such as the Shopping tab, image results, and product panels can draw on the same data.

Google's official product structured data documentation splits these surfaces into two main groups: product snippets and merchant listing experiences. This split directly determines which properties you need to fill in. So before you start, you need to know which group your page belongs to.

• Product snippet: For pages that don't sell the product directly, for example a review article or a comparison site.
• Merchant listing: For pages where the visitor can buy the product from you, in other words a classic ecommerce product page.
• Overlap: When you add the required properties for merchant listings, the page can also become eligible for product snippets.

For example, a store that sells its own products and also runs a blog reviewing other products should mark up the two page types separately. The review article targets product snippets, while the product page targets merchant listings. That way each page reaches Google with properties that fit its purpose.

What is the difference between product snippets and merchant listings?

Both experiences use the same Product type. However, their expectations differ. Product snippets give more room to review information. For instance, an editorial review page can mark up pros and cons. Merchant listings, by contrast, focus on purchase details such as sizing, shipping, and return policy.

This table draws on Google's product snippet documentation and its merchant listing documentation. As a result, you know from the start why you fill in each property.

Which properties are required for merchant listings?

According to Google's merchant listing documentation, Product has three required properties. Offer has two more. If any of them is missing, the page won't qualify for the merchant listing experience.

1. name: The product name. It should match the name visitors see on the page.
2. image: The URL of a product image. Use an accessible image that actually shows the product.
3. offers: The sales offer. For merchant listings it has to be an Offer, not an AggregateOffer.
4. price: The price inside the Offer, or alternatively priceSpecification.price.
5. priceCurrency: A three-letter ISO 4217 currency code, for example USD, EUR, or GBP.

In addition, the documentation requires a price greater than zero for merchant listings. So a product that says "call for price" or shows 0 won't enter this experience. Product snippets don't have that limit.

Which recommended properties surface stock and shipping details?

Required properties open the door; recommended ones enrich the result. Specifically, if you want stock status to appear, don't leave availability empty. The recommended Offer properties include the following.

• availability: Stock status, using Schema.org values such as InStock, OutOfStock, or PreOrder.
• itemCondition: New, used, or refurbished.
• priceValidUntil: The date the price expires. A past date can stop the result from displaying.
• shippingDetails: Shipping cost and delivery time.
• hasMerchantReturnPolicy: Your return policy.
• url, validFrom, validThrough: The offer URL and its validity window.

On the Product side, recommended properties include brand.name, gtin, mpn, sku, color, size, material, and aggregateRating. They help identify the product precisely. For example, adding a GTIN (global trade item number, in other words the barcode number) makes it easier for Google to match the product with other sources. Therefore, if you have barcodes, we recommend you mark them up.

That said, never invent a GTIN for handmade products without a barcode. Instead, identify the product with its brand name and your own stock code (sku). A wrong GTIN can match your item with a different product and cause more harm than leaving the field out.

How do you add product structured data to a page step by step?

In practice, JSON-LD is the safest format. For a no-code starting point, you can use our Schema Generator tool. Then follow this order.

1. List the name, price, currency, and stock status that the product page shows.
2. Copy these values into the Product and Offer properties exactly; don't add information the page doesn't show.
3. Place the markup in the page's initial HTML, and avoid generating it later with JavaScript.
4. Check the page with the Rich Results Test and fix critical errors.
5. Use the URL Inspection tool to confirm Google can access the page.
6. Keep your sitemap current and allow time for recrawling.

Example scenario: a store at example.com adds name, image, an Offer with price 29.99 and priceCurrency USD, plus availability InStock, to a water bottle page. Then it runs the test and sees a clean result. The numbers here are for illustration only.

Why should the markup sit in the initial HTML instead of JavaScript?

Google's product snippet documentation advises merchants to put Product markup in the initial HTML. The reason is that JavaScript-generated markup can make Shopping crawls less frequent and less reliable. For a store whose prices and stock change often, that is a serious disadvantage.

For example, if an API call updates stock after the page loads, Google may see an outdated state. The result could then say "in stock" while the item sold out hours ago. Consequently, we recommend that your platform print price and stock on the server side, in the first response.

You can add markup through a tag manager, but that route doesn't suit every case. We cover the details in our article on adding schema with Google Tag Manager. For product pages in particular, we find the server-side approach sturdier.

So how do you tell which method your site uses? Open the page source and search for the word Product. If it appears there, the markup lives in the initial HTML. If it doesn't appear in the source but shows up in the testing tool, JavaScript adds it later.

Should you use Merchant Center and product structured data together?

Yes, use both whenever you can. Google's product documentation says that providing both on-page structured data and a Merchant Center product feed maximizes your eligibility for experiences. Some experiences combine the two sources.

Moreover, according to the documentation, product snippets may pull pricing from your Merchant Center feed if the page lacks it. However, the two sources must not contradict each other. If the feed says 29.99 and the page says 34.99, you'll run into trouble. We cover that issue in detail in our Merchant Center price mismatch guide.

If you haven't set up Merchant Center and free listings yet, read our Google Shopping and Merchant Center guide first. That article covers the account basics; here we focus on the page side.

How do you read the product reports in Search Console?

Google's product snippet documentation mentions two separate reports. The Product snippets report covers non-selling pages, such as reviews and aggregator sites. The Merchant listings report covers pages where shoppers can buy. These reports appear in Search Console once your site contains the relevant markup.

When you read a report, we suggest you look at three things.

• Invalid items: Pages with critical errors; these don't qualify for the experience.
• Valid items with warnings: Eligible pages that miss a recommended property.
• Trend: If errors jump right after a template change, the template is the culprit.

Also, if you see an unparsable data warning in an error row, the problem is syntax. We explain that case in our article on the unparsable structured data error.

Finally, be patient. After you fix the markup, don't rerun the test every day. Instead, watch the report trend for a week or two. If errors fall and valid items rise, you're on the right track.

Which product structured data errors come up most often?

The errors we see in audits tend to fall into the same few patterns. This isn't a statistic; it's a summary of what our team runs into most often.

1. Missing offers: The theme prints name and image but forgets the price block.
2. Wrong currency: The field holds a symbol like "$" instead of the ISO 4217 code USD.
3. Bad price format: The price field contains text such as "$1,299.90"; Google expects a numeric value.
4. Expired priceValidUntil: The sale ended, but nobody updated the date.
5. AggregateOffer misuse: Merchant listings need an Offer, yet all variants sit inside one AggregateOffer.
6. Product markup on category pages: A listing page carries product markup, which the documentation doesn't support.

In short, most errors don't come from a lack of technical knowledge. Instead, they come from templates nobody maintains. That's why we recommend testing a few product pages after every theme update.

What happens if the price is zero or "request a quote"?

Google's merchant listing documentation is clear: unlike product snippets, merchant listing experiences require a price greater than zero. As a result, products where you hide the price or show 0 won't enter merchant listings.

That doesn't mean the page disappears from search, though. It still shows as a normal result; only the price and stock line goes missing. For a B2B machinery seller that works on quotes, for instance, this may be acceptable. On the other hand, for a retail store it's a missed opportunity.

Our advice is this: for products with a genuinely fixed price, show the price clearly and mark it up. For services with variable pricing, consider types that match the page's nature instead of Product. Writing a price into the markup that the page doesn't show, however, is a serious mistake.

How should you set availability for out-of-stock products?

When a product sells out, updating availability to OutOfStock is usually a better first step than deleting the page. That way users don't see a false "in stock" label in results. In addition, the page keeps the ranking signals it has built up.

If the product leaves your range permanently, the situation changes. Then the right choice among a 301 redirect, a 404, or a 410 depends on whether a successor model exists. We compare those options in our guide to out-of-stock product pages.

One more point matters here: your stock data needs a single source. For example, if the warehouse system says 0 units while the theme says in stock, the markup will be wrong too. So we recommend generating availability directly from the stock counter.

How do you mark up size and color for product variants?

Google's product documentation states that both product snippets and merchant listings support product variant structured data. In practice, that means you can describe the different colors and sizes of the same shirt under one product group.

In practice, you define a separate Product for each variant. Next, you link them with a shared group identifier (inProductGroupWithID or isVariantOf). Each variant has its own price, stock status, and ideally its own GTIN. As a result, when red size M sells out, the "in stock" label on blue size L stays accurate.

Example scenario: the example.com store sells three colors of a jacket on one page, and choosing a color changes a URL parameter. In that case each variant URL should match the url property in the markup. Also check, with your canonical setup, whether those variant URLs create duplicate content.

How do you mark up prices on a multi-currency site?

Google's merchant listing documentation says that if you sell in multiple currencies, you should have a distinct URL per currency. So showing USD, EUR, or GBP at the same address depending on the visitor's country creates a problem for markup.

For example, if example.com/us/ always shows USD and example.com/de/ always shows EUR, each page's markup stays consistent. A setup that switches currency by cookie or IP, however, leaves it unclear which price Google's crawler will see. Therefore, in multilingual and multi-currency stores, we recommend tying each language folder to one currency.

Also watch the decimal separator. The price value in markup should be a number that uses a period as the decimal separator, even if the page displays a different local format.

How do review stars get into a product result?

For stars, you use the aggregateRating or review properties. According to the product snippet documentation, these properties must follow the review snippet guidelines. For example, the review author's name must be a valid Person or Team.

Honesty is critical here. Adding reviews to the markup that the page doesn't show, or presenting reviews you wrote as customer reviews, violates the guidelines. Such markup also brings the risk of a manual action. We summarize the limits of rating markup in our schema markup guide.

Pros and cons (positiveNotes and negativeNotes) apply only to editorial product reviews. So they don't belong on a merchant product page or on customer reviews. They also require at least two statements.

On new products with few reviews, don't force rating markup. Instead, build a setup that updates aggregateRating automatically as real reviews come in. That approach is far healthier than a fixed rating someone typed by hand.

Does product structured data directly boost rankings?

No, there is no basis for claiming that. Google's documentation describes structured data as a way to enrich how a result looks and to earn eligibility for experiences. It makes no promise that it works as a ranking factor.

Still, an indirect effect is a realistic expectation. A result that shows price and stock tells users faster whether it fits their search. That can improve click quality. For instance, a user who sees "out of stock" in advance won't click, so you get fewer wasted visits.

In short, treat markup as part of a good product page, not as a ranking shortcut. The page's content, speed, and indexing remain the foundation. We cover that foundation in our guide to ecommerce SEO for product and category pages.

Why doesn't markup that passes the test appear in results?

This is one of the questions we hear most. A clean Rich Results Test shows eligibility; it doesn't guarantee display. Google's merchant listing documentation notes that Google may try to verify merchant listing product data before showing it.

The documentation's troubleshooting steps, in brief, are these.

1. Fix critical errors in the Rich Results Test; non-critical warnings aren't required for eligibility.
2. Use the URL Inspection tool to check that robots.txt, a noindex tag, or a login wall doesn't block the page.
3. Allow for recrawling and reindexing, which can take several days.
4. Submit a sitemap so Google learns about your changes.

Also, if the page isn't in the index at all, markup has no effect. So first make sure the product page is indexed. In addition, a new product page needs time for Google to discover and crawl it. Therefore we recommend you add new products to the sitemap right away and link to them from your main categories.

Which products won't Google show product results for?

Google's product snippet documentation states that content promoting widely prohibited or regulated goods doesn't qualify for these experiences. As examples, it lists firearms, recreational drugs, and tobacco and vaping products.

Page type matters as well. The documentation wants markup to focus on a single product or variants of the same product; it doesn't support category or listing pages. Consequently, putting Product markup on a category page such as "Men's Shoes" won't deliver the result you expect.

Finally, the documentation notes that Car isn't automatically a Product subtype. Car sellers should therefore list both types together.

How should you set up product markup for price drop displays?

Google's product snippet documentation recommends using an Offer rather than an AggregateOffer to qualify for the price drop enhancement. In other words, for a product with a single price, give the exact price instead of a price range.

Google decides when this enhancement appears, and the documentation publishes no threshold or percentage. For that reason, we don't answer "at what discount does it show?" with a number. Our advice is to make sure the markup and the page update at the same moment whenever the price changes.

Example scenario: the example.com store cuts a headphone price from 120 to 99 dollars. The page shows the new price, but the markup still holds the old one. Google then sees inconsistent data, so you can't expect a price drop label. The numbers are for illustration only.

Also, if you use priceValidUntil during sales, clear or update that date when the sale ends. Otherwise a past date can stop the result from appearing at all.

Where should you declare return and shipping policies?

Google's product documentation recommends nesting return policy (MerchantReturnPolicy) and loyalty program markup under Organization. The logic is simple: most stores apply the same return policy to every product. So instead of repeating it on hundreds of product pages, you define it once at the organization level.

Shipping, however, can vary by product. For example, shipping a bulky sofa costs more than shipping a small accessory. That's why using shippingDetails inside the Offer, per product, makes more sense. On the other hand, if shipping is free on everything, stating that consistently is enough.

Return and shipping details directly affect purchase decisions. What's more, the page itself should show these policies clearly; a policy that lives only in markup misleads users. We explain overall product page structure in our ecommerce product page guide.

How do you audit product markup on an off-the-shelf platform?

Hosted platforms usually generate product markup automatically. That doesn't mean the markup is complete, though. A theme, a plugin, and an app can all print separate Product blocks on the same page. Then the two blocks may show different prices or stock states.

For the audit, we suggest this routine.

1. Pick five different products: single-price, with variants, discounted, sold out, and newly added.
2. Run each one through the Rich Results Test and note how many Product blocks appear.
3. If there's more than one block, find the plugin behind it and turn off the extra one.
4. Compare the price and stock in the test result with the values the page shows.
5. Match the outcome against the Merchant listings report in Search Console.

This short audit often reveals the source of the problem within an hour. That way you go straight to the cause instead of testing plugins at random.

What should a product structured data checklist include?

Before launch, we recommend running this checklist once per template, and again after every major update.

• Does the page describe one product or its variants?
• Are name, image, and offers (as an Offer) present?
• Is price numeric and above zero, and is priceCurrency an ISO 4217 code?
• Does availability come from the real stock counter?
• If priceValidUntil exists, is it a future date?
• Is the markup in the initial HTML, and does it match the visible values?
• Does the Merchant Center feed price match the page price?
• Does the relevant Search Console report show any new errors?

Applying this list regularly catches problems before they grow. As a result, you won't spend sale season chasing results that show the wrong price.

Should you handle this yourself or bring in specialist help?

With a small catalog on a ready-made ecommerce platform, you can manage this yourself. However, in a store with many variants, several currencies, or custom software, the sources of error multiply. For example, the template, a plugin, and the feed can each produce a different price at the same time.

As part of our SEO consulting, Talha Aslan and team audit your product templates, fix missing and conflicting properties, and track your Search Console reports on an ongoing basis. We don't promise rankings or display, because the final call belongs to Google. Meeting every eligibility requirement, however, is our job.

If your site doesn't show price and stock details, send us your product page URL and request a quote from our SEO consulting page. We'll review the situation and come back with a clearly scoped proposal.

Core guide: What Is Digital Marketing? Its types, examples and how it is done, on one page with an interactive film that travels through the brain.