price, availability and sale_price
The Merchant Center pricing attributes, price and currency format, availability values, the sale_price + sale_price_effective_date pattern, and why they must match your landing page exactly.
These three attributes tell Google what the product costs and whether it's in stock. Google checks them against your actual product page, and any mismatch, a price that's stale, a sale that's expired, an out-of-stock item still showing as available, gets the product disapproved. The rule underneath all of them: the feed and the landing page must always agree.
The pricing attributes
| Attribute | What it is | Example |
|---|---|---|
price |
The product's regular selling price, with currency | 49.99 GBP |
availability |
Whether it can be bought now | in_stock |
sale_price |
The temporary discounted price, when on sale | 39.99 GBP |
sale_price_effective_date |
The window the sale price applies for | 2026-07-10T00:00/2026-07-17T23:59 (BST) |
Together these are the attributes Google trusts least on faith and checks hardest against reality: because a wrong price or a phantom in-stock item is the fastest way to burn a shopper's trust in Shopping ads.
price and currency
- Format is
amount CURRENCY:49.99 GBP,12.00 USD,8.50 EUR. - Full stop as decimal separator, no thousands separators, no symbols (
£,$). - Currency must match the target country's expected currency.
- The value is the price a shopper actually pays at the point the feed represents: inclusive or exclusive of tax per the destination's convention (see shipping and tax).
availability
The accepted values are a fixed set:
in_stock: buyable now.out_of_stock: currently unavailable.preorder: not released yet, orderable ahead of a release date (pair withavailability_date).backorder: sold now, shipping delayed.
Availability is set per variant offer, not per product: the point of variant offers is that the sold-out size 10 goes out_of_stock while the size 12 keeps serving.
sale_price and the effective-date pattern
When a product is genuinely discounted:
- Leave
priceat the regular (higher) price. - Put the discounted price in
sale_price. - Set
sale_price_effective_dateto the start/end window.
Google then applies the strikethrough / sale treatment during the window and reverts automatically when it ends: no manual toggling, and no risk of an "expired sale still showing" disapproval. To qualify for the sale annotation, the regular price must have been the established price for a reasonable period before the sale; flipping a permanently inflated price to make everything look discounted is a policy risk.
Deep dive Why mismatches disapprove, and where they come from
Google crawls the product's landing page and compares what it finds there against the feed. When they disagree, the product is disapproved for a price or availability mismatch: and these are among the most common disapprovals precisely because they arise from timing and plumbing, not from anyone typing a wrong number:
- Feed lag. The site drops a price at 9am; the feed Google holds still says the old one until the next fetch. For fast-moving prices, the fetch cadence itself is the bug.
- Variant URL resolving to the wrong offer. The
linkdoesn't preselect the variant, so the crawler lands on the default variant's price, which differs from the one the offer claimed. Variant links must carry the variant selector. - Tax- or currency-inclusive display differences. The page shows a tax-inclusive or geo-converted price the feed doesn't account for, so the numbers differ even though nothing is "wrong".
- Expired sales.
sale_price_effective_dateended but the site still shows the sale, or vice versa. The effective-date pattern exists to prevent exactly this: use it rather than editingsale_priceby hand. - Availability drift. Stock sells out on site faster than the feed refreshes, so ads keep pointing at unbuyable items: wasted spend and a trust hit.
The single rule that prevents all of these: the feed value and the landing-page value must be equal at all times. Everything else is a consequence of that rule being violated by a delay somewhere in the chain.
How this works in /tools
Enrichment doesn't set your prices (those are yours and come straight from your store) but it validates the pricing attributes for the mismatches above: variant links that don't resolve to the right price, availability that's out of step with stock, and sale windows that have lapsed. These consistency and risk signals feed your Feed Health Score, and continuous monitoring surfaces a price or availability regression as it happens rather than after impressions are lost. For diagnosing a specific mismatch, see price and availability mismatch; for variant-level pricing, see item_group_id and variants.
Frequently asked questions
What format does price use?
A number followed by the ISO currency code, e.g. 49.99 GBP. Use a full stop as the decimal separator, no thousands separators, no currency symbol. The currency must match the country you're targeting.
Do I need sale_price if I use price?
Only when there's a genuine sale. Keep price as the regular (higher) price and put the discounted price in sale_price. Set sale_price_effective_date to the sale window so it starts and ends automatically. Don't drop the regular price into price and leave sale_price empty, you lose the strikethrough treatment.
Why does Google say my price doesn't match when it looks right?
Google crawls the landing page and compares. Common causes, the page shows a currency-converted or tax-inclusive price the feed doesn't, a variant URL that resolves to a different price, or a cached feed lagging a price change on site. The feed value must equal what a shopper sees on the page.