The disapproval taxonomy and Diagnostics
How to read Merchant Center Diagnostics properly: item-level vs account-level issues, data vs policy causes, and what severity, pending and preemptive states actually mean.
Merchant Center Diagnostics is the single source of truth for why products aren't showing, but it's organised in a way that trips people up. There are two levels (item and account) and two root causes (data and policy), and the fix differs for each combination. This guide teaches you to read the taxonomy so you fix the cause, not the symptom.
Two levels, two causes
Diagnostics splits into two tabs, and understanding the split is most of the battle. Item issues are problems Google found with specific products, such as a bad GTIN, a price mismatch, or a broken image. Account issues are problems with the account as a whole, such as a misrepresentation flag, a website-claim mismatch, or a policy that spans the catalogue. Account issues are rarer, far more serious, and can suppress every product at once regardless of how clean the individual items are.
Cutting the other way, every issue has a root cause that's either data or policy:
- Data issues are fixed in your feed. The value is wrong, missing, or malformed: a failed check digit, an empty
google_product_category, apricethat doesn't match the landing page. These clear automatically on the next crawl once the data is right. - Policy issues are fixed by changing content and then explicitly asking Google to re-review. Restricted terms, promotional overlays on images, misrepresentation. There's no automatic clear; a human or system re-checks after you request it.
The combination tells you the whole story: an item-level data issue is a routine feed fix; an account-level policy issue is a business emergency. Read both coordinates before you touch anything.
The taxonomy at a glance
| Coordinate | Typical examples | How it clears |
|---|---|---|
| Item · Data | Invalid GTIN, missing category, price/availability mismatch | Automatically, on next crawl after feed fix |
| Item · Policy | Promotional image overlay, restricted-term title | Fix content → Request review |
| Account · Data | Systemic identifier failure across the catalogue | Fix at source → resubmit → re-crawl |
| Account · Policy | Misrepresentation, website-claims mismatch, suspension | Fix trust signals → Request review (highest stakes) |
For the hands-on fix workflow across the common item-level causes, start with how to fix disapproved products. This article is the map; that one is the route.
How to read a Diagnostics entry
Every entry carries three things worth reading in order:
- The reason string. This is the diagnosis: "invalid value [gtin]", "mismatched value (page crawl): [price]", "generic image". Merchants lose weeks treating "disapproved" as one problem; it's dozens of distinct problems, and the reason string names which one.
- The affected attribute. Most item issues name the exact field at fault. That field is where your fix goes: not the title, not the description, the named attribute.
- The affected-item count. Sort by this. One root cause usually spans hundreds of products; fixing product-by-product wastes the day. A single "invalid [gtin]" entry covering 900 items is one bad column mapping, not 900 separate problems.
Severity, and why warnings matter
Google grades issues by severity, and the grade decides whether an item serves at all:
- Error / Disapproved: the item is not serving. Full stop. These are the ones that show up as lost coverage.
- Warning: the item is serving, but something is wrong: a missing recommended attribute, a soft identifier problem, a policy risk that hasn't tripped yet. Warnings suppress reach quietly and escalate to errors if ignored.
- Notice / Suggestion: non-blocking improvement hints; worth doing, not urgent.
The trap is treating warnings as optional. A "limited performance due to missing identifiers" warning doesn't stop the product: it just makes it lose auctions you can't see it losing. See limited performance and other warnings for the full list of the quiet ones.
Deep dive Pending, preemptive and the states between approved and disapproved
Diagnostics isn't binary. Between "approved" and "disapproved" sit several states that behave differently:
- Pending / Under review. The item isn't serving, but no decision has been recorded: Google is still processing it. Normal right after a first submission or a fix. Usually resolves within 72 hours on its own. Don't resubmit or request review while pending; you just reset the clock.
- Preemptive item disapproval. Google disapproves an item for a predicted problem (almost always price or availability accuracy) before any shopper hit the mismatch. It's triggered when your feed updates much less often than your site changes prices or stock, so Google stops trusting the feed's freshness. The fix isn't the individual item; it's the refresh cadence. See price and availability mismatch.
- Serving with a warning. Approved and live, but carrying a warning that caps reach or flags escalating risk. Easy to miss because the item is showing.
- Expiring. Items expire ~30 days after last fetch if the feed stops refreshing. Not a disapproval, but it reads as vanished coverage and is fixed by keeping the feed live.
The practical consequence: never read the headline disapproval count alone. A catalogue with zero disapprovals but 2,000 items serving-with-warnings and a stale feed producing daily preemptive disapprovals is in worse shape than one showing a clean 300-item error you can trace to a single bad mapping. Watch the states and their trends, not just the red number: a step change after a data import is the signal worth tracing. /tools change monitoring exists for exactly this: it tracks item states continuously and flags products matching known disapproval patterns before Google acts, so the fix lands before impressions are lost. See change monitoring and disapproval prediction.
Working order
When Diagnostics lights up, work it in this order every time:
- Account issues first. If the account is suspended or carries a misrepresentation flag, item-level work is wasted: nothing serves until the account clears. See misrepresentation and account suspension.
- Item errors, grouped by cause. Sort by affected-item count, fix the biggest root cause, resync.
- Item warnings. Once errors are clear, the warnings are your suppressed-reach backlog.
- Notices last. Improvement hints, when everything blocking is handled.
The durable version of this is not to work Diagnostics reactively at all: it's to validate identifiers, images and required attributes upstream so bad data never reaches Google, and to catch state changes the moment they happen rather than the next time someone opens the dashboard.
Frequently asked questions
What's the difference between "disapproved" and "pending"?
Disapproved means the item is currently not serving and you know why, because there's a reason string. Pending means Google is still reviewing it (common right after a fix or a first submission) and it isn't serving yet either, but no decision has been recorded. Pending usually resolves within 3 days without you doing anything.
An issue says "warning" not "error"; can I ignore it?
No. Errors stop an item serving outright; warnings let it serve but quietly cap its reach or flag a risk that escalates to disapproval if left. Warnings are the ones merchants ignore for months and pay for in lost impressions.
One account-level issue is listed but thousands of items are affected. Why?
Account-level issues apply to the whole account or a policy that spans products (misrepresentation, a systemic identifier problem). They're listed once but suppress everything. Always clear account-level issues before working item-level ones.