Monitoring Merchant Center Disapprovals: 4 Signals to Watch

Merchant Center tells you this morning that 260 products are disapproved. It does not show you that yesterday there were twelve.

That is the whole problem. A number without yesterday means nothing. For one catalog, 260 disapproved products out of eighty thousand is an ordinary Monday. For another, it means a supplier rewrote availability across a quarter of the range on Friday evening and you have been losing revenue since.

I will show you four signals worth watching and a script that watches them for you. Setup takes ten minutes, it runs free inside Google and needs no server.

What Merchant Center does not show

The interface shows a state. You need a change.

Diagnostics does carry a 30-day trend, but it is a chart you have to go and look at. It has no thresholds, alerts nobody and sends nothing anywhere. Check it on Tuesday and you learn about Friday's incident four days late. A disapproved product stops running in the first minute.

Merchant Center writes to you on its own in two situations: an account-level action, and problems it judges to be serious. Both are a more serious category than the one I am describing. Gradual deterioration, the kind you could stop before it grows into an account action, passes unnoticed.

Add to that a catalog that moves. Products come and go, prices change, availability swings. The absolute count therefore drifts constantly, and without yesterday you cannot separate a blip from a trend.

Four signals to watch

One threshold for everything does not work. A small catalog needs something different from an eighty-thousand-item one.

I use four conditions together. Any one of them is enough:

1. Absolute increase. At least ten more disapproved products. On a catalog of five hundred items this is the reliable signal, because relative change swings on small numbers even without a cause.
2. Relative increase. At least 20 % more than yesterday. On a large catalog this is the main threshold: ten products out of eighty thousand is not news, two thousand is.
3. A new disapproval reason. A code that was not in the account yesterday. This catches a policy action or a broken attribute before it shows up in the counts.
4. Share of the catalog. Disapprovals crossed 5 % of the range. A backstop for the case where the problem grew slowly and slipped past the other three.

None of those numbers is a Google recommendation. Google publishes no thresholds; these are values that make sense against the results on the accounts I manage. Set your own according to what "something happened" means in your business.

Why the count alone is not enough

The increase tells you that you have a problem. The reason tells you who to call about it.

A disapproval for a missing GTIN is fixed in a supplemental feed in an afternoon and needs nobody's help. A disapproval for breaking the rules on restricted categories means a lawyer, a certification or a change to your range. An image_link_internal_error is an outage on your own server and belongs to a developer, not to a PPC specialist.

A single figure of "260 disapproved" does not separate those situations. The reason code does.

So what you need out of each run is a table, not one number:

184× availability_mismatch (disapproved)     +184  new
  2× image_link_internal_error (disapproved)   ±0
  1× recalled_product (disapproved)            ±0

Three seconds with that output and it is clear: one cause, it is new, and it hit 184 products. That is a feed import or an availability outage, something that can be rolled back. Five different reasons at thirty products each would be an entirely different scenario.

The full list of codes with a fix for each is in my piece on the ten most common reasons Merchant Center disapproves products. Monitoring tells you which of them is hurting you right now.

How to build it

The data comes from the Merchant API, specifically a query against the product_view table. One query returns every product's status along with its issues:

SELECT product_view.id,
       product_view.aggregated_reporting_context_status,
       product_view.item_issues
FROM product_view

The status takes four values. ELIGIBLE is fine, ELIGIBLE_LIMITED runs with a handicap, NOT_ELIGIBLE_OR_DISAPPROVED does not run at all and PENDING is waiting for review.

I would watch both problem categories. Limited performance tends to be a precursor to disapproval, and noticing it only once it tips over costs you a week.

One trap worth knowing up front: since 28 February 2026 the Merchant API only has v1. The v1beta version was discontinued and returns HTTP 409 with a migration link. Most tutorials you find online still point at it, so do not copy them.

The whole script, with setup instructions, is public on GitHub. It is a Google Apps Script, so it runs free inside Google, triggers itself once a day and sends the alert to Google Chat or by email. Setup takes ten minutes and needs no developer.

I took the same approach to the Google bidding change on 17 August, where Google also shipped no diagnostic and everyone had to build the list of affected campaigns themselves.

What to do with the alert

An alert nobody acts on is worse than no alert, because it creates the impression that something is being watched.

So set three things up. Send the messages where the work happens, not to an inbox nobody reads. Set thresholds so that quiet days produce nothing. And name in advance who responds to which reasons, so the message does not stall with someone who cannot act on it.

When an alert lands, the procedure is always the same:

1. Look at the reason, not the count.
2. Check whether the reason is new or merely larger.
3. For a new and numerous reason, check the last feed import.
4. Fix it in a supplemental feed when it is about data rather than policy.
5. Mark the items as fixed in Diagnostics and wait for the next crawl.

Once disapprovals pass 30 % of the catalog you are dealing with a different kind of problem. That is where an account-level action becomes a risk, and the procedure is in my piece on misrepresentation and account suspension.

Summary

1. Merchant Center shows a state, not a change. A number without yesterday means nothing.
2. Watch four signals at once: absolute increase, relative increase, a new disapproval reason and the share of the catalog. Set your own thresholds; Google gives none.
3. The count of disapproved products says you have a problem. The reason code says who should fix it.
4. One query against product_view in the Merchant API gets you the data. Use v1; v1beta ended on 28 February 2026.
5. The script and its setup are on GitHub, running free in Apps Script and alerting to Google Chat or email.
6. Check daily. No more than one feed import should fit between two checks.

If Shopping and Merchant Center are a long-term concern, have a look at Google Ads management. I treat the feed, the measurement and the campaigns as one thing, because each depends on the others.