TL;DR: Products disappear from Google Shopping because a unit format did not map, a barcode is not a registered GTIN, or a flash-sale price stopped matching the landing page. The account keeps working, so nobody gets an alert — merchants find out from a revenue dip. PainHunt holds 45 posts scoring 10 or higher out of 15 describing this, and the recurring complaint is that every feed check happens after the rejection instead of before the push.
The evidence
Within the Merchant Center cluster, 45 posts scoring 10 or higher out of 15 describe item-level rejection rather than account suspension — averaging 11.6/15, pain intensity 7.6/10, willingness to pay 7.8/10. 42 of the 45 come from merchant Discourse communities.
The failure modes are specific enough to build against.
Attribute mapping that fails silently. One thread describes a store's internal ITEM unit failing to convert into the format Google expects for unit pricing, producing an unspecified-value error and stripping unit price information from every count-based product. The store is correct, the feed is correct in its own terms, and the mapping between them is where it breaks.
GTIN validation that small sellers structurally cannot pass. Merchants selling handmade goods — skincare, candles, custom items — have no manufacturer barcode to supply. Others report that their barcode app generates internal identifiers rather than registered GS1 numbers, which validate locally and fail at Google. Threads connect this to exclusion from newer AI-driven surfaces as well as from standard Shopping.
Sync failures with no error surface and no manual override. Merchants describe feed syncs that fail without visible errors and without a way to trigger a re-sync by hand, leaving them to notice from ad performance instead.
Expiry and availability churn. One thread describes products dropping out of Shopping repeatedly through the day as feed entries expire, producing intermittent ad visibility that is difficult to distinguish from normal fluctuation.
Promotions that disapprove themselves. Flash sales create windows where the feed price and the landing page price disagree. Merchants describe this producing price-mismatch disapprovals during exactly the campaign they built the sale for.
Why now
Feeds got more dynamic while validation stayed batch-shaped. Dynamic pricing, app-driven inventory, and frequent promotions mean a feed's correctness is a moving property. A validation model built around occasional full submissions does not describe how these stores actually operate.
Identifier requirements tightened as structured shopping data spread. As product data feeds more surfaces than a single ads product, the identifier fields that used to be advisory became gates — and the sellers least able to supply them are the ones with the most differentiated inventory.
The failure is quiet by construction. An account suspension announces itself. Item-level disapprovals subtract revenue without an outage, which is why the threads are full of merchants discovering the problem weeks late.
The wedge
The crowded build is another feed management app. Merchants already have those and are naming them while describing the failure. The narrower build is a validator that runs before the push and speaks in the merchant's own terms.
- Validate against the destination's rules before submitting. Check identifier formats, unit mappings, and required attributes at push time and refuse the bad rows rather than letting Google refuse them days later.
- Diff the feed against the live landing page. Price, availability, and title mismatches are the recurring disapproval causes and are all detectable by comparing two things the merchant already owns.
- Guard promotions explicitly. A pre-flight check on a scheduled sale — will these prices disagree with the page during this window? — targets the moment merchants describe losing the most.
- Give handmade and custom sellers a real answer on identifiers. Not "add a GTIN," which they cannot, but a validated route through the exemption and identifier-exists paths, and a check that the store is not emitting invented barcodes that will fail registry validation.
- Alert on disappearance, not just on error. The product merchants describe wanting is one that notices items silently leaving Shopping. That alert is the wedge, because the current experience has no equivalent.
Risks and honest caveats
- The platform owns both ends of this. Better native diagnostics or a more forgiving identifier policy would remove much of the demand. The durable parts are the ones spanning systems the platform does not control — the merchant's own store, apps, and promotion calendar.
- Rules change without notice and break your validator. Accuracy is the product, and maintaining it against a specification you do not control is a permanent operating cost, not a one-time build.
- Read access to a merchant's catalogue and ad account is a serious trust ask. For a tool bought while the merchant is already anxious about compliance, the security story has to be ready before the first sale.
- This competes with a free option: waiting. Some merchants tolerate the leak because each individual disapproval is small. The product has to make the aggregate loss visible before it can be sold, which is a marketing problem as much as a technical one.
- 45 threads is a signal, not a market size. It shows a real, repeated operational failure among active merchants. It does not tell you how many would pay, and treating it as sizing would be a mistake.
How to validate this further
The decisive question is whether merchants would pay for prevention before they have felt the loss, because a tool that only sells after a bad quarter has a much smaller market than one that sells at setup. Use the PainHunt dashboard to compare the feed threads against the suspension threads — merchants who have experienced both are the ones who buy prevention. Then test whether the disappearance alert alone is enough to convert, using idea validation.
Related reading: Google Merchant Center suspended for misrepresentation covers the account-level version of this failure, and how to automate Shopify product and collection setup covers the upstream catalogue work that determines whether a feed is correct in the first place.