Sale price in the Shopping feed: sale_price attribute or just lower the price?

Running a 20% off promo across a few hundred SKUs, and I keep seeing people overwrite the price field for the sale and change it back afterwards. I'd skip that. Keep the regular price in price, put the discounted one in sale_price, and set sale_price_effective_date for the promo window. Merchant Center then shows the strike-through, the feed keeps a clean record of the normal price, and you don't end up with a week where the advertised price doesn't match the landing page because someone forgot to flip it back.

The counterargument is that sale_price is fiddly to maintain by hand across a big catalog, and that's fair. But if your feed is generated from the product database, it's a one-time template change and most of the fiddliness goes away.

Include a timezone offset in the effective date, something like 2025-06-01T00:00-0700/2025-06-15T23:59-0700. Leave it off and the window can start or end hours away from what you meant, which is a real problem on a promo with a hard end date.

The expiry is what saves you here. Once the end date passes, Merchant Center stops applying sale_price on its own and the listing falls back to the regular price, so nobody has to remember to flip anything. The catch is the landing page. If the site still shows the sale price after the window closes, you get a mismatch that looks like a feed problem even though the feed is fine. Is your on-site promo tied to the same date, or does someone switch it by hand?

Yeah, the mismatch is what bites. Say a home goods shop's sale ends Sunday night. The feed drops the sale price Monday morning, but the theme still shows the banner and the old price until someone updates it Tuesday. Google's crawler then sees a landing page that disagrees with the feed, and that can get items flagged for a price mismatch. The disapproval can hang around even after the page is fixed, so you lose a day or two of impressions on top of the confusion.

I'd set the on-site end time to the same offset you used in the feed and have the site switch at that exact moment instead of "the next day." If your platform supports scheduled promos, use that. If it doesn't, put a reminder on the calendar for the morning after the end date and compare a few landing pages against the feed. That's faster than trusting anyone to remember.

The feed doesn't actually drop anything on Monday. Once the sale_price_effective_date window closes, Merchant Center just stops applying sale_price on its own, so the only thing that has to change is the site. That's why the same offset should go on both the feed window and the on-site end time.

Before the promo starts, open one product page and compare the displayed price with what the feed says, tax included. If the theme shows gross prices and the feed is net, you'll get a mismatch even during the sale.

Agreed on the tax check. The sale window only works if the feed with those dates has already been fetched before the sale opens. Merchant Center applies the dates from whatever file it last pulled, so if your scheduled fetch runs at 06:00 and the sale starts at midnight, the first six hours show the regular price. Either move the fetch earlier or trigger a manual one just before the start time.

Manual fetches can take a while to process, so push the file the day before instead of an hour before midnight. If the fetch or processing is slow, you want to find out with a day to spare, not watch the first hours of the sale show regular prices.

Agreed, and a failed fetch is easy to miss. If the file has a bad row, like a sale_price higher than price or a currency mismatch, Merchant Center can quietly keep serving the last good version with no loud alert. So after the push, check the Diagnostics tab for sale price errors. Do it the day before the window opens, not the morning of, so you have time to fix a broken file.

Diagnostics only flags bad values. A file can parse cleanly and still silently drop half your rows, and you'd never see a price error for that. So before you trust a push, compare the item count on the feed's processing status against yesterday's. If it dropped noticeably, something got lost on the way in, even if every row that made it looks fine.