Why Your Sale Price Isn't Showing on Google Shopping: An Eight-Check Feed Diagnostic

You added sale_price to the feed, the product is approved, and the shopper still sees a single plain price with no strikethrough and no sale badge. Google's own documentation explains why this happens more often than feed teams expect: a sale price annotation needs a discount greater than 5% and less than 90%, a base price that has been charged for long enough (in most Shopping ads countries, 30 days within the past 200), and a landing page that shows both prices. Miss one condition and the product stays live without the annotation. This guide is for feed managers and paid media teams who run sales in Google Shopping. By the end you will be able to work through eight checks in order, find which one is failing, and fix it in the feed rather than in the store.

What "not showing" actually means

There are three different failures that get reported as "the sale price is not showing", and they need different fixes.

• The product is disapproved. Merchant Center notifies you. The sale price broke a data requirement, for example it was not lower than price or it did not match the landing page.
• The product is approved but the shopper sees the sale price without a strikethrough or badge. The data is valid, but the annotation eligibility rules are not met.
• The product shows the old price. The sale never reached Google, or it expired, or it was never scheduled correctly.

Google states plainly that sale price annotations are not always guaranteed to show even when you are eligible. So the goal of this guide is to remove every cause you control, and to be honest about the remaining uncertainty.

The eight-check diagnostic

Run these in order. The first four are data checks you can do from the feed alone. The last four need price history, the landing page, or account settings.

Check 1: price and sale_price are the right way round

Google's rule is simple: sale_price must be lower than price, and that difference has to be visible in your product data. A typical failure is a store platform that exports the already discounted figure in price and leaves sale_price empty or identical. Google tells merchants to submit the full, non-sale price in price and to put the sale price in price only if you do not use sale_price at all.

A correct pair looks like this:

price: 1000.00 TRY
sale_price: 799.00 TRY

Round to two decimal places in the feed, because Google rounds extra digits itself and the result can drift from the page.

Check 2: the discount percentage

Compute the percentage on every sale row before you publish: (price - sale_price) / price. Google requires it to be greater than 5% and less than 90%. In the example above it is 20.1%, which passes. A 3% markdown will never carry an annotation, and neither will a 92% row, which is usually a data error anyway.

Check 3: sale_price_effective_date format

The attribute is a date range in ISO 8601 with a start and an end, separated by a slash. Google's documented pattern is YYYY-MM-DDThh:mm[±hhmm] or YYYY-MM-DDThh:mmZ, with a limit of 51 characters. A Black Friday window for a store in Istanbul looks like this:

sale_price_effective_date: 2026-11-20T00:00+0300/2026-11-30T23:59+0300

Two defaults matter. If you omit the time, the sale starts at midnight on the start date and ends at 11:59 PM on the end date. If you omit the timezone, Google uses UTC. A Turkish store that writes 2026-11-20T00:00 with no offset starts its sale three hours late for shoppers in Turkey, and a MENA store in Dubai (UTC+4) loses four hours. Always write the offset.

Validate the dates too: Google's own help page contains an example with a 29 February in a non-leap year, so test examples before copying them.

Check 4: send both sale attributes

For online inventory update feeds, Google says sale_price and sale_price_effective_date must be provided together or not at all, and that sending only the price means the item has not been uploaded. For ordinary product data feeds the date is optional, but we send it for every scheduled sale so the end is explicit.

Check 5: base price history

This check is easy to miss, and it can leave a valid sale row without an annotation. Google requires the base price to have been charged for a minimum time. The figures below are the ones on Google's page at the time of writing.

Turkey does not appear in these lists. We cannot tell from the page what applies to a Turkish account, so check the status of your own products in Merchant Center rather than assuming the 30 days apply or do not apply.

The practical consequence is about sequencing. A new product launched at 1,000 TRY on 1 November cannot carry a sale annotation in a 30-in-200 country on 10 November. A product whose price was raised for a week just before a campaign may fail the same test, because the base price has not been charged for long enough. If your sale calendar depends on annotations, protect the base price for the weeks before it.

Check 6: the landing page

Google requires the original and sale prices to be shown on the landing page, and the sale_price value must match the price shown on the page and at checkout. If the product page only shows the discounted figure and the strikethrough is added later by a script that does not run for Googlebot, the feed and the page disagree. Check the rendered HTML for both prices. Our earlier guide on stopping Google from overriding your feed's price data covers what happens when the page and the feed diverge.

Check 7: what does not belong in sale_price

Google excludes three things. Promo-code discounts belong in the store's discount settings, not in sale_price. Loyalty and membership prices go in loyalty_program. And sale prices submitted as Merchant Center promotions do not count as sale prices for annotation purposes. If your campaign is "extra 10% in the basket", it is a promotion, and the feed price stays as it is.

Check 8: has Google read the change?

A scheduled fetch can leave a gap. Feedance's own Google Merchant Center integration page notes that Merchant Center can re-read a hosted feed hourly, daily, weekly or monthly, and that catalogs with fast price changes may need API pushes instead. After any sale change, open the product in Merchant Center, confirm the price shown is the new one, and only then judge whether the annotation is missing.

A worked example with price history

This is a hypothetical row, not client data. A jacket is listed at 1,000.00 TRY. On 10 November it is cut to 800.00 TRY for a week, returned to 1,000.00 TRY on 17 November, and then offered at 700.00 TRY for Black Friday on 27 November.

price: 1000.00 TRY
sale_price: 700.00 TRY
sale_price_effective_date: 2026-11-27T00:00+0300/2026-11-30T23:59+0300

The feed passes checks 1 to 4: the discount is 30%, the dates are valid and the offset is present. For Google's base price test, the product was charged at 1,000 TRY for most of the lookback, so it is likely to pass check 5 in a 30-in-200 country. The Turkish rule is a different test, and it is the one that catches this row. Since the amendment published in the Resmi Gazete of 18 February 2022 (issue 31754) took effect on 1 March 2022, the pre-discount price for a discounted sale is the lowest price charged in the 30 days before the discount, according to KPMG's summary of the amendment. Here the lowest price in the previous 30 days is 800 TRY, so the honest discount against that reference is 12.5%, not 30%. The burden of proving the discount facts lies with the seller. A feed that strikes through 1,000 TRY on the landing page while the 800 TRY week sits in the price history is a regulatory problem even if Google shows the annotation.

For any market, the artifact that helps with both tests is a daily record of the price you actually charged per SKU.

Pre-flight checklist for a sale feed

1. Export price, sale_price and sale_price_effective_date for every sale SKU.
2. Calculate the discount percentage and flag anything at or below 5%, or at or above 90%.
3. Flag rows with no timezone offset.
4. Join to your price history and flag SKUs whose base price was changed in the last 30 days.
5. Render ten sample product pages and confirm both prices are visible without user interaction.
6. Confirm no promo-code or loyalty price has been written into sale_price.

Measuring whether the annotation helped

Do not assume a strikethrough lifts results. Compare matched product groups over the same dates, using the approach in our guide to measuring the ROAS impact of a feed change. If TRY, AED or SAR formatting is inconsistent, fix that first; see our guide to VAT, currency and decimal errors.

Where this guide breaks down

We worked from Google's help pages as they read when we checked them, and Google changes these requirements. We could not confirm what applies to Turkish accounts, because Turkey is absent from the country lists on the annotation page. We cannot see inside your Merchant Center account, so eligibility can differ from what the rules suggest, and Google itself says annotations are not guaranteed. We also have not covered Meta or other channels, whose sale price fields follow separate rules. The Turkish regulation section is based on a secondary summary, not the Resmi Gazete text, and it is not legal advice; confirm with counsel. Channable publishes its own explainer on sale price annotations, which is worth reading alongside this one.

Frequently asked questions

Why is my sale_price approved but there is no strikethrough?

Approval only checks data validity. The annotation has extra conditions: a discount above 5% and below 90%, a base price valid long enough for your country, and both prices visible on the landing page. Work through checks 2, 5 and 6 first.

Do I need sale_price_effective_date?

For ordinary product data feeds it is optional. In online inventory update feeds Google says both sale attributes must be sent together. We recommend sending it for every scheduled sale so the end of the sale is explicit.

Can I put a promo code discount in sale_price?

No. Google asks you to manage promo-code discounts in the store's discount settings. Loyalty and membership prices go in the loyalty_program attribute instead.

Does a Merchant Center promotion create a sale annotation?

No. Google states that sale prices submitted as promotions do not count. Use the sale_price attribute for sale annotations and promotions for offers such as basket discounts.

How long must the original price have been live?

In most Shopping ads countries Google lists 30 days within the past 200. In the US for Shopping ads it is 5 days within the past 30 or 15 days within the past 200. Local inventory ads need 60 days.

Why does the discount I show differ from the one in Turkish law?

Google tests the base price you charged. Turkish rules, as summarised by KPMG, set the reference as the lowest price in the 30 days before the discount. A temporary markdown can lower the reference price you may legally advertise against.

Check your own feed

If you want a second pair of eyes on the price attributes in your feed, run it through the free Feedance product feed audit tool.