← Back to Merchant Feed Check

Why products get disapproved in Google Merchant Center — and what a feed checker can't see

Google Merchant Center and Meta Commerce Manager both reject individual product-feed items for reasons that fall into two very different categories, and conflating them is how a merchant ends up trusting a tool that cannot actually tell them what they need to know.

Category 1: data-specification problems — checkable from the feed alone

These are objective, deterministic checks against the published product-data specification. A feed file either conforms or it doesn't, with no need to know anything about the merchant's account, website, or business.

ReasonWhy it's common
Missing unique product identifier (GTIN/MPN + brand)Most product categories require it; sellers of handmade, refurbished, or private-label goods often have neither a real GTIN nor a way to get one, and skip the explicit identifier_exists: false opt-out that would make the omission valid.
Malformed price or availability fieldA bare number without a currency code, a currency symbol instead of an ISO code, or a free-text availability value ("Ships in 3 days" instead of in stock) is a common export-tool mistake.
Promotional or price text in the title or descriptionCopy written for a storefront ("50% off today only!") is reused verbatim in the feed without editing it for Shopping's stricter title/description rules.
Missing required attributeA CMS export that drops a field for any item missing a value (many plugins omit empty columns entirely) silently produces an incomplete row.
Duplicate item IDsA feed regenerated from two overlapping data sources, or a variant-handling bug, produces the same ID twice — the platform typically keeps only one and silently drops the other.

Merchant Feed Check checks every row in this table deterministically — see its own report for exactly which rule fired and why.

Category 2: account and policy problems — invisible to any feed checker

These require Google's or Meta's own crawl of the merchant's actual website, or a human policy reviewer, and no tool that only reads a feed file can evaluate them:

If a feed passes every check here and items are still disapproved, the cause is almost always in this second category — read the specific disapproval reason Merchant Center or Commerce Manager gives in your dashboard, since that is the only place these are visible.

Wiring the CLI into a deploy pipeline

Run it as a step right before whatever job uploads or syncs your feed — a scheduled GitHub Action, a cron job, or a step in the same pipeline that regenerates the feed from your product database:

- name: Check product feed
  run: node cli.mjs check feed.csv

Exit code 1 fails the job on any data-specification error, so a broken feed never reaches the sync step. Ecosystem note: this reads the feed file itself, so it works the same whether that file came from Shopify's native feed app, a WooCommerce plugin export, or a hand-rolled script — nothing here depends on which platform generated it.

Common questions

What is the single most common Merchant Center disapproval reason?

Missing or invalid unique product identifiers — a missing GTIN, MPN, or brand where the product category requires one — is consistently named as the most common data-quality disapproval across Google's own Merchant Center help content and seller community threads. A feed checker can verify the identifier is present and, for GTIN, that the check digit is mathematically valid; it cannot verify the GTIN is the correct one for that specific product.

Can a feed checker guarantee my products will be approved?

No. Disapprovals fall into two categories: data-specification problems, which a feed checker can catch, and account/policy problems — misrepresentation, prohibited products, insufficient trust signals, a landing page that does not match the feed — which require Google's or Meta's own crawl and account review and are invisible to a tool that only reads a feed file.

Why doesn't Dependabot-style automation exist for this already?

Google and Meta each publish a free, web-form feed validator, but neither ships a scriptable, zero-account CLI a merchant can wire into their own deploy pipeline the way a linter runs in CI, so a broken feed is caught only when a human remembers to paste it into a web form, or after the crawler already rejected it.