How do I show prices in Google search results?

A price can reach a search result through your own pages or through your product feed, and they are independent systems that happen to end up in the same place.

The first route is structured data on the product page. When a page carries a product entry with an offer, a price, a currency and an availability that all match what the page shows, that listing becomes eligible for a display that includes the price. This applies to your normal organic listing.

The second route is Merchant Center. A product feed submitted there, meeting the policies and passing review, can appear in shopping surfaces and free product listings, where the price is part of the format rather than an addition to it.

Neither route is a promise that the price will show. Both make you eligible, and eligibility is where your work ends and the ranking systems take over. Stores that treat this as a switch to be flipped end up frustrated. Stores that treat it as getting the data right, then measuring, do better.

The practical order is to fix the page markup first, because it is under your control and it also improves how shopping surfaces read your site, then get the feed clean.

The product entry on the page needs a small set of fields, and every one of them has to agree with what a visitor sees.

The product name, at least one image, a description, and an offer containing the price, the currency, the availability and the page URL. Add the brand and an identifier where the product has one, because they help the product be recognised rather than treated as an unknown listing.

The matching rule is where most stores fail. A price generated from a cached value, a currency hard-coded while the storefront switches markets, an availability that says in stock on a page showing sold out: each of these is a mismatch, and mismatches are the most common reason a price stops appearing.

Check the awkward cases specifically. A product on sale should carry the sale price, not the original. A product with variants at different prices should present a range that matches what the page shows. A product that just sold out should update within the same page load, not on the next cache refresh.

Then validate several pages and compare each field against the visible page. Markup that passes a validator can still be describing a different reality from the page it sits on.

A product feed gives your prices access to shopping surfaces, and it is a separate piece of work from the page markup.

The requirements are more demanding because the data is being used commercially. You need a claimed and verified website, a feed carrying the required attributes for your market, prices that match the landing page including tax and currency handling, accurate availability, shipping and returns information configured at account level, and products that pass policy review.

What you get in return is presence in formats built around products, where price, image and availability are the primary content rather than a decoration on a text listing. Free product listings mean this does not have to involve ad spend, though the same feed powers the ads if you run them.

The feed also has to stay current. A daily refresh is the minimum on most catalogues and it is not enough on a fast-moving one, because a price change on the site that has not reached the feed is a mismatch by definition.

This is the part where doing the work properly compounds. A clean, complete feed serves ads, free listings and the shopping tab from one source, and the same discipline fixes the mismatches that stop prices showing on your organic pages.

Eligibility is not display, and there are several ordinary reasons a correct setup shows no price.

The search result format is chosen per query. For some searches a price-carrying display is shown and for others it is not, and that decision is made regardless of how good your markup is.

The page may not be indexed yet, or the markup may have been added after the last crawl. Changes take time to be picked up, and asking for a recrawl of a few important pages speeds it up.

The product may not be eligible in your market, since availability of these features varies by country and changes over time.

There may be a quality issue at site level rather than page level, such as invented ratings elsewhere on the site, which can cause structured data to be discounted broadly.

Or the price genuinely is mismatched somewhere you have not looked. A common one is a store that shows a price including tax to one country and excluding it to another, with markup that only ever states one of them.

Check the search console reports for product issues rather than guessing. They will tell you whether the problem is validity or display.

The single discipline that makes all of this work is that the price is the same wherever it is expressed: on the page, in the markup, in the feed, and in the currency the shopper is browsing in.

That is harder than it sounds once a store has sales, markets and apps. The situations that break it: a discount applied in the cart rather than on the product page, so the page price and the eventual price differ. A currency converter that changes the displayed price without changing the markup. A sale that starts in the store before the feed refreshes. Country-specific pricing that the feed does not account for. Tax shown differently to different regions.

Set a routine check. Take a handful of products across price bands and markets, and compare four things: the page, the markup, the feed and the checkout. Do it monthly and after every promotion.

And handle sales deliberately. A sale price should be expressed as the current price with the original shown as a comparison, in the page and in the data, rather than the two swapping places depending on which system you look at.