Google Shopping Disapprovals:

How disapprovals actually work.

Google enforces its product data spec at two levels, and only one of them is an emergency. Item-level disapprovals remove individual products from serving — recoverable, usually in bulk, once the data defect is fixed. Account-level actions, led by misrepresentation, suspend everything, and they're almost always the escalation of an item-level pattern that sat unfixed: price and availability mismatches are the classic route.

The other thing to know is where the truth lives. Merchant Center's diagnostics view lists every affected item, the exact error, and Google's own description of the cause. Most disapproval mysteries aren't mysteries — they're unread reports. Start every investigation there, sorted by error type rather than by product, because the fix is almost always per-error, not per-SKU.

Timing matters too. Item-level errors re-process within about a business day of a corrected feed being fetched, which means the real cost of a disapproval isn't the fix — it's the discovery lag. A catalog audited weekly carries every error for an average of half a week before anyone knows. A catalog nobody audits carries them until the revenue dip forces the question, at which point the diagnosis starts from the campaign and works backward through every layer that wasn't the problem.

The pattern to internalize: Disapprovals are bulk-shaped. One template produced every image, one export produced every title, one mapping produced every blank attribute — so one defect flags hundreds of SKUs at once, and one rule-level fix recovers them the same way.

The twelve errors, decoded.

These are the disapproval classes that repeat across audited catalogs. For each: what Google's message actually means, and the data fix that clears it — at the rule level, so it stays cleared.

1. Mismatched value (price)

What it means: Google crawled your landing page and found a different price than the feed sent. The usual causes, in order of frequency: the feed lagging a price change, a promotion that started or ended on-site before the feed caught up, or the feed carrying the parent product's price while the crawler read a variant's. Google treats persistent price mismatch as the on-ramp to misrepresentation — the account-level policy class — which is why this error deserves more urgency than its item-level filing suggests.

The fix: Tighten sync cadence to match how often prices actually move — intraday movers need better than a nightly sync. Give every child SKU its own price field rather than inheriting the parent's. Then audit sale_price start and end dates across the catalog, because promo windows are where the drift lives: a sale that ends on-site at midnight and in the feed at noon the next day is twelve hours of policy violation.

2. Mismatched value (availability)

What it means: The feed says in stock; the page says sold out — or the reverse. Google verifies availability by crawl the same way it verifies price, and treats the mismatch the same way. The reverse case costs quietly: items marked out of stock in the feed while the page sells them simply don't serve, and nothing flags the lost impressions.

The fix: Sync availability at the pace inventory changes, and reconcile multichannel stock to one source of truth so a sale on Amazon decrements what Google sees. If stock moves intraday, a nightly sync guarantees this error class stays open permanently.

3. Limited performance due to missing identifiers (GTIN)

What it means: The product has a manufacturer-assigned GTIN and the feed didn't send it — or sent one that's invalid, expired, or recycled from another SKU. Identity degrades everything downstream: catalog matching, comparison placement, and the trust signals other surfaces read from the same feed. Invented GTINs are worse than missing ones; Google validates against the global registry and flags fakes.

The fix: Source GTINs from the manufacturer or your distributor data, validate structure and check digit before submission, and never reuse a code across SKUs. Where a product genuinely has no GTIN — custom goods, private label without registered codes — set identifier_exists to false and lean on brand plus MPN instead of padding the field with fiction.

4. Missing required attribute (apparel and variants)

What it means: Apparel and several other verticals carry category-specific required attributes: color, size, gender, age_group. A blank in any required field disapproves the item — and platform exports blank them constantly, because the storefront stores size in a variant option or buries it in the description where the export can't see it.

The fix: Map the attributes from structured variant data at the feed layer. Where the source genuinely lacks the field, extract it with a rule — size from the variant name, color from the option value — rather than retyping it per SKU. Then check google_product_category: a product mapped to the wrong node gets validated against the wrong requirement set, which manufactures this error out of nothing.

5. Image too small or low quality

What it means: Google's hard floor is 250×250 pixels; 800×800 or larger is the working standard, and apparel wants 1000×1000 or better. Undersized, blurry, or placeholder images disapprove the item outright. This error arrives in batches because one legacy upload pipeline or one template produced every failing file.

The fix: Audit image dimensions across the full catalog — not the flagged items only — and replace the failures at the source system. If multiple image sizes exist per product, point image_link at the largest clean rendering and demote the thumbnails to additional_image_link.

6. Promotional overlay on image

What it means: Text, watermarks, badges, borders, and collaged shots on the main product image violate image policy. The product must be the only subject on a clean background. Like the size error, this one is template-shaped: the same badge treatment produced every violation, so the flags arrive hundreds at a time.

The fix: Strip the overlay treatment from the image set at the source and resubmit the affected group together. Keep promotional framing where Google wants it — in the promotions feed and sale_price fields — and out of the pixels. If the badged images must exist for other channels, assign per-channel image fields so Google gets the clean set.

7. Promotional text in title or description

What it means: "Free shipping," "20% off," "best price," ALL CAPS, and exclamation marks in the title are policy violations, not style choices. Google reads promotional language in product data as misleading content, and the enforcement is mechanical.

The fix: Clean the fields with a catalog-wide rule that strips the promotional phrase list from titles and descriptions, so next season's imports inherit the fix instead of reintroducing the violation. The title space recovered is better spent on the attributes that match queries — brand, product type, material, variant.

8. Landing page not accessible

What it means: The link in the feed 404s, redirects through a broken chain, resolves to the wrong product, or blocks Google's crawler via robots.txt. The listing has nowhere valid to send a shopper, so Google removes it. Replatforms and site migrations are where this error spikes — old URLs die in bulk while the feed keeps sending them.

The fix: Validate URLs at catalog scale on a schedule, purge retired SKUs from the feed the day they're delisted, and confirm robots.txt permits Google's product crawler. After any replatform, re-crawl the full link set before the channel does it for you.

9. Wrong language or currency for the target country

What it means: The feed's currency or language doesn't match the target country's requirements — dollars sent to a market that requires local currency, or content in a language the destination doesn't accept. Common in catalogs that expanded internationally by pointing one feed at multiple countries.

The fix: Serve each target country its own feed rendering — correct currency, correct language, country-appropriate URLs — generated from the same master catalog. Multi-market is a per-market payload problem, not a copy-the-feed problem.

10. Restricted or prohibited product

What it means: The item, or a phrase in its data, trips a policy category: weapons-adjacent terms, healthcare and medical claims, regulated goods, and adult categories are the usual suspects. Sometimes the product is genuinely restricted; more often an innocent phrase — a knife block, a toy gun, a supplement claim — pattern-matched into a banned list.

The fix: Read the diagnostics detail to identify the flagged term, then remove or rephrase it at the rule level so every SKU sharing the phrase clears together. If the product itself is restricted for the destination, exclude it from that channel's feed rather than fighting the policy — the exclusion rule protects the rest of the account.

11. Missing shipping information

What it means: Most target countries require shipping cost data before items can serve, supplied either through Merchant Center account settings or shipping attributes in the feed. Without it, items are held back in bulk — and because the requirement is account-adjacent, the flags often arrive the day a new target country is enabled.

The fix: Set account-level shipping in Merchant Center for the simple cases, send shipping attributes in the feed where rates vary by product weight or class — and confirm the two sources don't contradict each other, because a conflict reads as another mismatch.

12. Inconsistent variant data (item_group_id)

What it means: Children missing the shared group ID, carrying inherited parent values instead of their own size and color, or showing the parent's image instead of their own. Google can't assemble the variant family, so it disapproves the members or indexes them as competing standalone products — and the campaign keeps running while the catalog quietly shrinks.

The fix: Give every child the group ID plus its own attributes, its own image, and its own price. The fix is structural, which means it recovers listings in batches — and it's covered in full in the variants guide, because the same defect breaks Meta delivery and Amazon family assembly too.

Fix the class, not the item.

The instinct when a disapproval lands is to open the product and edit it. Resist it. Editing one listing fixes one symptom and leaves the defect in place — the next import, the next season, the next policy pass reproduces it. The durable version of every fix above is a rule applied across the catalog: strip promotional phrases everywhere, validate GTIN structure everywhere, map size from variant data everywhere. New SKUs inherit the rule; the error class dies instead of the error instance.

The math on this is the whole argument. A 5,000-SKU catalog hit by one missing-attribute requirement is 5,000 manual edits or one rule. The manual version takes days and reproduces itself on the next import; the rule version takes minutes and holds. Teams that fix per-SKU are permanently behind their own catalog — the same defect classes cycle through every season, and disapproval management becomes a standing tax instead of a solved problem.

Prevention: validate before Google does.

Every error in this guide is detectable before submission. A pre-submission validation pass — every SKU checked against the channel's current rulebook — moves the entire conversation upstream: data errors get fixed while they're free, instead of costing impressions while they sit in a diagnostics report. That check is a standing stage of a managed pipeline, not a launch-week task, because the spec drifts and the catalog changes even when nobody touches the feed.

The practical rotation looks like this: validate on every sync, audit the diagnostics view weekly grouped by error class, and treat any new class as a structural event — trace it to the import, template, or policy change that produced it before fixing a single item. Merchants who run that rotation see disapprovals as a trickle of new-SKU edge cases. Merchants who don't see them as weather.

1. Google Merchant Center product data specification
2. Google Merchant Center policy and diagnostics documentation
3. GoDataFeed internal error-pattern and compliance history