Merchant Center disapprovals: how to find the real root cause

I have seen teams spend hours “fixing Merchant Center” when Merchant Center was only reporting a problem created somewhere else. That can happen because a catalogue field is wrong upstream, a feed transformation changed the value, the landing page disagrees with the submitted data, a policy requirement is not being met or the update process is simply too slow for the rate at which price and stock change.

The practical difference matters. If the source system owns the wrong GTIN, adding a rule in Merchant Center may make one channel look healthier while leaving the catalogue broken everywhere else. If the feed is correct but the landing page emits stale structured data, rebuilding the feed does not solve the mismatch. If the issue is policy rather than data quality, cleaning attributes alone may never get the offer approved.

A disapproval is a status, not a diagnosis

Google's current Merchant Center interface groups affected products under Needs attention and provides issue-level detail, including examples and business-impact information. That is the right starting point because it tells you the issue Google is seeing and gives you a population of affected items. It is not the end of the investigation.

Before changing anything, capture three things: the issue name, the affected product count and a small sample of representative item IDs. If the interface gives you an issue timestamp or example products, keep those too. You want a fixed reference point because live catalogues move while you investigate them.

Scope the issue before you touch the data

Disapprovals behave differently depending on their scope. I normally classify the problem before opening a feed tool.

• One product or a handful: often bad item-level data, a variant edge case or a specific landing-page problem.
• One category or brand: often a shared mapping, taxonomy rule, identifier source or template issue.
• A large percentage of the catalogue: often update timing, a global transformation, site template, policy setting or system-wide source problem.
• Account-level impact: treat this differently from an isolated item error. The commercial risk and review process may be much higher.

Also separate policy issues from data-quality issues. They can appear together, but they usually need different evidence and different owners. Do not send a policy problem to the feed team simply because the product appears in Merchant Center.

The five layers I inspect

Layer	What I am checking	Typical owner
1. Source catalogue	Is the core fact correct before any channel transformation? GTIN, brand, title, price, stock, variant relationship, product type.	Ecommerce, PIM/ERP, merchandising, supplier data
2. Feed / transformation	Did mapping, an attribute rule, supplemental source or feed platform change the value?	Feed team, agency, data team
3. Merchant Center	What processed value does Google hold? Is the issue eligibility, account setup, policy or data quality?	Ecommerce / performance team
4. Landing page	Does the customer-visible content match the submitted offer and selected variant?	Ecommerce / developers
5. Structured data / timing	Does JSON-LD or microdata expose a different price/availability, or are systems updating at different times?	Developers / platform team

This is why I prefer source-to-channel diagnosis. It keeps teams from treating every Merchant Center warning as an advertising problem.

A root-cause workflow that scales

Common traps that make feed problems harder

Editing products directly until the warning disappears

Direct edits can be useful for testing, but they can also create a second source of truth. If the primary data source refreshes tomorrow, your emergency fix may disappear. Work out whether the correct value belongs in the catalogue, a supplemental source or a channel rule.

Building another rule for every exception

Attribute rules are powerful and Google explicitly supports them for transforming incoming data. They are not automatically the best home for every correction. When important facts repeatedly need repairing downstream, that is evidence of source-data debt.

Treating the item shown in the UI as the whole problem

The example product may only be one member of a wider affected pattern. Export the issue list where possible and look for commonality before deciding the work is item-specific.

Ignoring the website because “the feed is correct”

Price, availability and certain other offer details are checked against the landing page. Structured data can also be used by Google. If those layers disagree, a technically valid feed can still produce problems.

Optimising before restoring eligibility

Title experiments and segmentation are useful once the catalogue is stable. They are not the first priority when important products are disapproved. Separate blockers from performance work.

What I would hand to a developer or data team

“Merchant Center error” is a poor technical ticket. A useful handoff should contain:

• the affected item IDs and issue name;
• the expected value and the incorrect value;
• where the incorrect value first appears;
• the relevant source field, API response, template or transformation if known;
• whether the issue affects all items or a defined subset;
• what must remain unchanged;
• how the fix will be validated after release.

That turns a vague marketing problem into a testable technical change.

Common questions