You find out about disapprovals from a budget line, not an alert. A handful of bestsellers quietly carries the campaign, the long tail never serves an impression, and the real list of excluded items only appears when someone finally opens Merchant Center diagnostics.
Ask how AI fixes this and most answers collapse into one word, optimization, which is where the trouble starts. The setup that actually reduces disapprovals is not a model rewriting a feed on vibes. It is a pipeline with a strict division of labor: deterministic rules catch what is provably broken before submission, machine learning maps what is genuinely ambiguous, and a feedback loop turns every disapproval into a rule so it cannot recur.
The myth: AI reads your feed and knows what Google wants
The belief: connect an AI, it ingests the feed, disapprovals drop. Here is the mechanism that disproves it. Most disapprovals at the data level are deterministic events. A price either parses or it does not. A GTIN is present or absent. An image URL returns an image or it 404s. No classifier is needed to know these things. A validator does the job perfectly, explains itself, and never gets tired.
Where judgment is involved, whether a free-text product type maps to the right taxonomy node or a title fits a channel's constraints, a language model guessing is only useful if something deterministic checks the guess. Otherwise you have traded a visible error for an invisible one. Prediction belongs on fuzzy inputs. Validation belongs everywhere else.
Two moments a disapproval can happen
Every disapproval fits one of two categories, and the distinction decides what automation can do about it.
Pre-submission failures are data problems your pipeline can catch before a single item uploads:
- missing required attributes, such as GTIN, brand, or size on apparel
- prices that fail format or currency checks
- availability values outside the accepted enum
- image links that are dead, redirected, or blocked to crawlers
- products mapped to the wrong taxonomy node
Post-submission disapprovals are policy decisions made after Google processes the feed and crawls your landing pages:
- feed price or availability disagreeing with what the page renders
- misrepresentation signals, which sit at account level
- prohibited or restricted products
- images that violate shopping ad policy
Pre-submission failures are engineering problems. Post-submission failures are trust problems. The first respond to validation. The second respond to consistency between feed, page, and policy. Only the first responds usefully to prediction.
The customs desk
Think of submission as crossing a border. Pre-submission validation is the manifest check at your own loading dock: the paperwork is yours, the fix is yours, and any error caught there costs minutes instead of impressions. Post-submission review is the officer at the border who opens the boxes. If the manifest says $29.99 and the page says $34.99, no reprinted manifest fixes that; you fix the store, not the form. In this picture, ML is the clerk who sorts thousands of parcels into the right customs codes, fast and occasionally wrong — which is exactly why the clerk works under a checklist while the border rules stay non-negotiable.
Rules vs. ML: the division of labor
| Task | Layer | Why |
|---|---|---|
| Schema and format checks (price, availability, IDs) | Rules | Binary outcomes; validators are exact, cheap, explainable |
| Image URL liveness and crawlability | Rules + fetcher | A request succeeds or fails; no prediction involved |
| Mapping free-text product types to the taxonomy | ML | Thousands of leaf nodes, fuzzy human input; a classification task |
| Extracting color, material, size from descriptions | ML | A language task, done once, applied consistently |
| Channel-specific title generation | ML, gated by rules | Generation is linguistic; length, casing, brand position are policy |
| Feed vs. landing page price and stock match | Rules + crawler | A comparison, not a prediction |
A rule from the validation layer looks like this. Boring on purpose, because boring is auditable:
rule: price-format
on: item.update
check:
price:
type: decimal
currency: required
greater_than: 0
on_fail:
severity: error
action: exclude_and_flag
reason: "price failed format check"Every flag carries its reason. When someone asks why an item is not live, the pipeline answers with a rule name, not a shrug.
The deployment path, in order
- Audit and bucket. Export every active disapproval from Merchant Center and sort each item into pre-submission or post-submission. You cannot automate a fix for a category you have not counted.
- Stand up the rules layer. Schema validators, attribute-completeness gates, URL liveness checks, price-format enforcement. This layer runs on every item before upload, every time.
- Add ML where input is fuzzy. Category classification, attribute extraction from descriptions, title generation inside channel constraints. ML proposes, rules approve.
- Close the loop. Crawl your own landing pages nightly and diff rendered price and availability against the feed. Feed every new disapproval reason back into the rule set. A disapproval that recurs is an automation bug, not an accident.
- Gate all generation. Nothing a model writes reaches the live feed without passing a deterministic validator first.
The arithmetic of a cleanup
Illustrative, not measured; the split is the point, not the digits. Suppose a store with 4,000 SKUs has 380 disapproved items. Bucketing them: 300 are pre-submission-type errors (180 missing GTINs, 70 dead image links, 50 bad availability values), and 80 are post-submission (60 price mismatches, 20 policy).
The rules layer catches all 300 before upload, because each is a binary check. A nightly crawler-diff catches 50 of the 60 mismatches before Google's own crawl finds them. ML category mapping recovers items whose wrong-node assignment had been tripping policy review, say another 40. That takes the excluded catalog from 9.5% to just under 1%, and impressions roughly track eligible inventory: nearly one item in ten that was invisible yesterday can serve today.
What AI cannot fix
No automation setup repairs the following. It can only surface them faster:
- a landing page that contradicts the feed: fix the page, then re-push
- policy strikes at account level: misrepresentation reviews judge your claims, not your data
- out-of-stock pages that still show a buy button: that is a store bug, not a feed bug
Honest limits are part of the design. A tool that claims AI solves policy violations is claiming AI can make your store trustworthy, which no model can.
AI enriches. Rules gate. The loop remembers. Remove any one of the three and disapprovals come back.
One ordering note that matters more than any tool choice: validation before generation. Running ML title rewrites on items that fail schema checks is polishing labels for boxes that never clear the dock. Fix eligibility first, then spend the model's tokens on items that can actually serve.