Products disapproved in Merchant Center after nothing changed

Monday morning, forty products are disapproved. No deploy over the weekend, no price changes, no feed edits. The disapproval reasons read like a foreign language, and the first honest question is the right one: what actually changed?

Something did. Disapprovals are triggered, and if you did not pull the trigger, one of these four did.

The four things that change without you

Google re-reviewed. Google re-crawls product pages and re-evaluates items continuously. A page that passed in May can fail in July because the crawl failed this time, a policy got applied more strictly, or an automated system reclassified your product. Initial review windows also expire: new items sit in a pending state and then resolve to approved or disapproved days later, which looks like a change from nowhere.

Your feed re-submitted with different data. Scheduled feeds run unattended. An app update, a changed feed rule, or a currency setting can alter what gets submitted without anyone touching a product. Compare what the feed sent this week against last week before assuming the data was stable.

Another source took over. With more than one feed source, Google silently picks a winner per product. If the winner changed, the submitted data changed with it, and the disapproval traces to a source you were not watching.

Your storefront changed underneath the products. A theme update, an app injecting scripts, a password page, or a broken image host can fail Google’s page checks while the products themselves are untouched.

Reading the statuses like a diagnostician

Item statuses carry more information than the red badge suggests. Each disapproval names an issue code, the affected countries, and whether the fix is yours to make or pending Google’s own processing. Sort the reasons into two piles: data issues (price mismatch, missing identifiers, image problems) point at your feed or catalog; page and policy issues (page unavailable, policy violation) point at your storefront or account. The pile that dominates tells you where to dig.

Then find the boundary in time: which items flipped, and when. A spike sharing one issue code and one timestamp almost always shares one cause.

The monitored version

FeedWarden keeps the status timeline for every item, so a spike arrives with its boundary already drawn: what flipped, when, with which issue codes, and what else changed in the same scan window (feed data, winning source, page reachability). Disapproval incidents stay open until Google actually recovers the items, and the evidence packet documents the before and after for whoever has to act.