What is a Shopping feed disapproval?
A Shopping feed disapproval is a decision by Google Merchant Center that a product record does not meet a requirement, with the result that the product is removed from Shopping results and Shopping ads until the record is corrected. Every disapproval carries a reason that names the field involved and the rule it failed, which is the diagnosis a store needs: the field to change and the condition the change must meet.
Disapprovals are per item, per country and per destination, so one product can be approved for one market and disapproved in another. Merchant Center's diagnostics view lists them; the Product Catalog FTE on ftes.ai reads that view every day and puts the items into the morning brief with the field named.
Which causes are most common?
The most common causes of disapprovals are data problems rather than policy problems: a required identifier missing or invalid, a price in the feed that does not match the page, availability in the feed that does not match the page or the inventory, an image that fails an image rule such as a non-plain background or an overlay, and a required attribute absent for the product's category. Policy flags exist too, but for most catalogs they are a small share.
- Missing or invalid identifier: the product has no GTIN, MPN or brand, or the GTIN fails validation.
- Price mismatch: the feed price and the page price differ, often after a promotion starts or ends.
- Availability mismatch: the feed says in stock while the page or inventory says otherwise.
- Image rule failure: the main image has text, a watermark, a border, or a busy background.
- Missing category attribute: a field the product's category requires, such as size or age group, is empty.
Why is a feed rule the wrong fix?
A feed rule is the wrong fix for most disapprovals because it changes the feed's copy of the data without changing the record the feed is built from, so the next refresh reintroduces the problem or creates a new mismatch. A rule that overwrites the feed price to match the page fixes today's disapproval and breaks the day the page price changes. A rule that sets availability to in stock hides a stockout and earns a worse disapproval later.
The durable fix is in the product record: the identifier entered in the catalog, the promotion schedule aligned between page and feed, the availability driven from inventory. The Product Catalog FTE proposes fixes at that level, and the proposal names the record and field it changes.
How does the Product Catalog FTE handle a disapproval?
The Product Catalog FTE handles a disapproval in four steps that all happen before the owner sees it. It reads the reason and names the field and rule. It traces the cause to the source record, distinguishing a missing value from a mismatch. It drafts the fix in the product record, drawing only from the catalog, a supplier sheet or approved copy. It re-checks the corrected record against the same rule, so the proposal in Approvals is one that already passes.
The owner approves, and the item clears on the next feed processing. A disapproval that needs data the store does not hold, such as a GTIN only the supplier has, becomes a request to the owner with the SKU and field named, because the FTE does not invent identifiers.
What about warnings and limited visibility?
Warnings in Merchant Center do not remove a product from Shopping but can limit where and how often it appears, and they signal the same data problems a disapproval does, one step earlier. Common warnings include a missing optional attribute the category benefits from, an image below the recommended size, or a title that Merchant Center considers too generic. The Product Catalog FTE lists warnings after disapprovals in the brief and proposes fixes in the same way, ranked by revenue at risk.
Treating warnings as a second tier rather than ignoring them keeps the feed from drifting into disapprovals during a busy season, when a missing attribute becomes a required one for a new category rule.
How should a store keep disapprovals from coming back?
A store keeps disapprovals from returning by fixing source records rather than feeds, by aligning promotion schedules between the page and the feed, by driving availability from inventory, and by reading diagnostics daily rather than when Shopping revenue drops. The daily read is the part stores skip, because it is tedious, and it is the part the Product Catalog FTE does without being asked.
The disapproval count open and closed appears in every morning brief and in the monthly review, so the owner can see the backlog shrinking and see which causes repeat. A cause that repeats every import points upstream, usually to a supplier feed, and the report names it.