The sale went live at 9:00 AM. The feed refreshed at 2:30 AM. For seventeen and a half hours, every discounted SKU in your catalog told Google one price and told shoppers another.

Nobody did anything wrong. The site updated, the feed ran on its schedule, and the gap between them is where the disapprovals come from.

At 200 products you can fix that by hand. At 4,000 you cannot, and the same gap repeats every promo cycle until it becomes an account-level problem.

What Google expects after the click

When someone clicks a Shopping ad or free product listing, they expect the same price and availability on the landing page. Your feed is a promise. The landing page has to keep it.

Availability has to be consistent across the landing page, checkout, structured data, and your data source. A mismatch in any one can trigger a disapproval.

The mismatch causes that actually hit large catalogs

  • Sale windows out of sync
  • Multiple prices on the page
  • Variant preselection errors
  • Dynamic pricing and IP detection
  • Membership and discount prices
  • Slow or late-rendering prices
  • Availability edge cases

PID, and what "fix then request review" really means

When price or availability mismatches show up, you can land in preemptive item disapproval. Google disapproves items likely to violate requirements rather than waiting to check each one, and clearing it requires a review.

Do not request a review to see if it passes. Fix the class of problem, verify on live URLs, then request.

Automation: what to use and what not to lean on

Scheduled fetches should be timed to your site updates. Merchant API is the answer if prices change more than once a day. Automatic item updates are a safety net, not the plan.

The catalog-scale playbook

  • Treat a price change as one job that updates the site and pushes the feed together
  • Put promo start and end times in the same calendar the feed job reads from
  • Use sale price and sale price effective date for promos
  • Make variant URLs load the exact variant in the feed
  • Verify structured data after any theme change
  • Treat warning examples as a sample of a broken class