Fix Common Merchant Centre Disapprovals in 30 Minutes
Triage matrix for the most frequent Merchant Centre disapprovals, with a 30-minute fix workflow, supplemental feed patches, and rollback-safe recovery.

A Merchant Centre disapproval wave is one of those problems that looks scary in the dashboard and is usually mundane in the data. Three or four error codes account for almost everything; the rest are noise. This playbook is the 30-minute version of the fix.
Before you start: know what you’re fixing
Disapprovals come in four flavours, each with a different recovery path:
- Hard disapproval, SKU is removed from Shopping ads and free listings. Fix it or lose impressions.
- Country-level disapproval, SKU still serves in some countries, not others. Often a shipping or tax setup gap.
- Account-level warning, none of your SKUs are removed yet, but Google is signalling that a cluster of issues will trigger a broader action if left.
- Quality demotion (no disapproval), SKU still serves but with suppressed impressions. Doesn’t appear in Diagnostics; only visible in performance reports.
Start with hard disapprovals because they’re recoverable in hours. Quality demotions can take weeks of consistent improvement to recover.
The 30-minute fix workflow
Step 1, Pull diagnostics, group by code (5 minutes)
Merchant Centre > Products > Diagnostics > Issues. Filter to “Disapproved” status, download the CSV. Open in Sheets, pivot by Issue field. The top three issues are your work order.
Most catalogs cluster around the same offenders:
| Issue code | Typical cause | Fix speed |
|---|---|---|
image_link_broken | CDN URL changed | Slow (re-crawl) |
price_mismatch | Promo price not synced to landing page | Fast |
missing_gtin | New SKU added without GTIN backfill | Medium |
invalid_image_overlay | Marketing image with “20% off” badge | Medium |
mismatch_shipping_country | New country opened in storefront, not in Merchant Centre | Fast |
policy_violation | Restricted claim language | Slow |
Step 2, Decide patch path per cluster (5 minutes)
Two paths, two speeds:
Source-fix path. The change goes into your catalog (Shopify, BigCommerce, Akeneo, your ERP) and rides the next full export. Use for identifier, category, title, and policy errors, these need to persist across every future sync.
Supplemental feed path. A second feed runs alongside the primary, overriding specific fields on matched SKUs. Use for price, availability, custom labels, and shipping overrides. Supplemental feeds let you fix 500 mispriced SKUs in 10 minutes without touching the catalog.
Document the decision per cluster before you start patching, switching mid-fix is where teams waste the most time.
Step 3, Patch a 50-SKU slice (10 minutes)
Pick 50 SKUs that span the top 3 error codes. Apply the fix. Push as a supplemental feed (even if some of the fixes are source-fixes, for the validation slice, you want speed).
Wait one fetch cycle (1-4 hours for scheduled, <15 minutes via Merchant API). Confirm the 50 SKUs flip to Approved.
This validation step is the most-skipped and most-important. If your fix was wrong, you’ve broken 50 SKUs instead of 5,000.
Step 4, Scale (10 minutes)
If the slice approved cleanly: trigger the full corrected feed export. Source fixes go in the primary. Supplemental overrides stay in the supplemental.
If the slice didn’t approve: don’t push the full feed. Look at why the slice failed before scaling.
Specific recovery patterns
Image disapprovals
Image errors are the slowest to recover because Google’s image crawl is independent of feed ingestion. Even a perfect image URL won’t approve until Google has crawled it.
Recovery shortcut: push the corrected feed, then warm the image URL by issuing a GET request to each new image link from a non-residential IP (your CDN logs are fine). Don’t trigger re-crawl from your own browser, Google fetches with a different user-agent and the warm helps the Googlebot fetch, not your test request.
Price/availability mismatches
The fastest recovery in the catalog. Two-thirds of mismatches come from one of:
- Sale price in feed, regular price on landing page (forgot
sale_price_effective_date) - Out-of-stock product hidden on landing page but still listed in feed
- Currency formatting that doesn’t match (commas vs periods, currency symbol position)
Push the fix via Merchant API for sub-15-minute recovery. The Merchant API products.update call propagates faster than file feeds because it doesn’t wait for the next scheduled fetch.
Identifier disapprovals
GTIN and brand fixes need to live in the source catalog. Supplemental feeds can override identifier fields, but if your source is wrong it’ll keep regressing.
Recovery shortcut: for SKUs that genuinely don’t have a GTIN (custom, private label, vintage), don’t invent one. Set identifier_exists to no. This satisfies the requirement and the SKU approves.
Policy disapprovals
The slowest to recover and the most likely to recur. Policy errors usually require copy rewrites, not data fixes. Cluster the disapproved SKUs by policy code, rewrite the offending copy, push the fix.
Categories with regulated approvals (CBD, alcohol, financial services) need account-level approval that Google grants per category, per country. Apply early; the approval window is 2-4 weeks.
What to do when the wave keeps coming back
If you’re fixing the same 200 SKUs every Monday, you have a system problem, not a feed problem. Three patterns we see most often:
1. The marketing team ships a promo image and forgets the feed. Solution: separate marketing_image_url and feed_image_url in your CMS. Feed only ever pulls the clean version.
2. The platform team ships a deploy that changes image URLs. Solution: pin image URLs to a stable bucket. Don’t include build hashes in CDN paths for product imagery.
3. The catalog grows faster than GTIN backfill. Solution: block new SKU creation if GTIN or identifier_exists is blank. A small forcing function at SKU creation saves weekly disapproval waves.
When to use a feed manager vs raw Merchant Centre
For under 500 SKUs with stable categories, the Merchant Centre UI plus a clean source catalog is usually enough.
Past 1,000 SKUs the manual approach breaks down, diagnostics export becomes painful to review weekly, supplemental feeds are awkward to maintain, and re-crawl monitoring is full-time work.
AI Shopping Feeds runs a pre-publish audit that catches the top 6 disapproval families before they hit Merchant Centre, maintains supplemental feeds programmatically, and pushes time-sensitive fixes (price, availability) via Merchant API for sub-15-minute recovery. For teams running multiple brands or 5,000+ SKU catalogs it’s the difference between a controlled weekly review and ad-hoc fire drills.
Recovery checklist
- Diagnostics CSV pulled and grouped by error code
- Top 3 error clusters identified
- Source-fix vs supplemental decision made per cluster
- 50-SKU validation slice patched and approved
- Full corrected feed exported
- Performance > Countries reviewed for silent country-level suspensions
- Weekly diagnostics review scheduled in calendar
Sources
- Google Merchant Center Help, Disapproval reasons
- Google Merchant Center Help, Supplemental feeds
- Google Merchant API, products.update reference
- Related read: Top Google Shopping feed errors and quick remediation playbook
Why wait? Try it free today.
Stop managing feeds manually. Start optimising with AI in 30 seconds.
- 100% free forever, no credit card required
- 1 brand, 1 feed, 100,000 products per feed
- Full AI Product Optimisation, Rule Engine, and 200+ channel exports
- Pay only for AI credits when you need them