Why product feeds get disapproved, and how to fix each reason

The first time I open a new client's Merchant Centre account, the Diagnostics tab is usually already full of red flags, and nobody on their team has touched the feed in weeks. It is rarely a new stock issue or a policy change from Google. In my experience it is almost always the same handful of causes repeating themselves, because the fixes tried so far only ever touched the feed, never the page the feed was describing.

A disapproved product in Google Shopping (the free and paid listings inside Google's shopping surfaces, fed by your Merchant Centre product data) means Google's automated checks or a manual reviewer found a mismatch between what your feed claims and what your site, or Google's policy, requires. The most common cause by volume is price or availability drift between the feed and the live page. This article covers the main disapproval categories in plain terms: price and availability mismatches, missing required attributes, policy issues, and image requirements, plus how long fixes actually take to clear and how to stop a disapproval reappearing after you have already fixed it once.

If you are staring at a Merchant Centre Diagnostics tab full of red flags with no idea which ones matter, treat this as a triage guide rather than a full feed-setup tutorial: what to fix first, what to ignore, and why the fix has to happen upstream of the feed rather than inside it.

What a disapproval actually is, and what it is not

A disapproval is Merchant Centre telling you that a specific product, or in some cases a specific attribute on that product, failed a check and will not show in Shopping results until it passes. It is item-level far more often than account-level. That distinction matters because the two demand completely different urgency.

An account-level suspension is rare and serious: usually a sustained pattern of policy violations, misrepresentation, or a trust and safety flag across a meaningful share of the catalogue. Item-level disapprovals are routine and constant. A catalogue of any real size will always have some percentage disapproved at any given moment, because prices change, stock runs out, and promotions expire faster than feeds regenerate. Aim to keep the disapproved share small and understand why each cluster exists, rather than chasing zero.

Price and availability mismatches: why they dominate

This is where most disapprovals live, and it is worth understanding the mechanism rather than just the symptom. Google's crawler visits your live product page periodically and compares what it finds there against what your feed submitted. If the price or stock status on the page does not match the feed within Google's tolerance, the item gets disapproved for price mismatch or availability mismatch.

The mismatch usually has one of four causes, and none of them are exotic:

Tax display inconsistency. Your feed submits a price excluding VAT while the page displays it inclusive, or vice versa, and the two numbers genuinely disagree once compared like-for-like.

Expired promotions. A sale price expires on the site at midnight but the feed, generated on a schedule, still carries the old discounted figure for several hours.

Currency drift. Multi-currency stores sometimes submit a feed in the wrong currency code for a given target country, which reads as a huge and obviously wrong price mismatch.

Stale stock status. The page shows "out of stock" the moment the last unit sells, but the feed only refreshes availability on a batch schedule, so Google sees a live page saying unavailable and a feed still claiming in stock.

In every one of these cases, the honest fix is upstream. If you patch the number directly inside the feed file, you have fixed the symptom for exactly one crawl cycle. The feed is almost always generated automatically from the same product record that feeds the page, so the next scheduled regeneration overwrites your patch with the same wrong value, and the disapproval comes back within a day or two. I have watched this exact sequence play out more than once: the feed gets patched, the disapproval clears, and days later it returns because nobody touched the price or stock field in the platform itself.

Missing required attributes

This is the second largest cluster, and usually the most mechanical to fix. Google requires a specific set of attributes depending on category: GTIN (the barcode-level identifier), brand, a condition value, and category-specific fields like size and colour for apparel, or age group and gender where relevant. Miss one required field for a given product type and the whole item gets disapproved outright.

The gotcha here is that "required" is category-dependent, not universal. A field that is optional for homeware can be mandatory for apparel. When I take over a feed audit, this is usually the first place I look, because it clusters by product type rather than by individual SKU: if trainers are disapproved for missing GTIN, check whether every pair of trainers is missing it, not just the one you noticed.

I see the same pattern from the other side on 18 Carati, a Magento 2.4 jewellery retailer where Merchant Centre sits inside the same engagement as the SEO and paid media I run. Jewellery pulls in its own required fields on top of the general set, material and gemstone type among them, and a meaningful share of a fine-jewellery catalogue is made as one-offs or in short runs with no manufacturer GTIN to submit. The fix there isn't chasing down a barcode that doesn't exist, it's setting identifier exists to false in the feed so Google stops treating a legitimately absent GTIN as a missing one and disapproving the item outright.

Policy issues, and why they need a copy fix

This category is different in kind from the first two. Price and attribute disapprovals are data problems. Policy disapprovals are content problems: restricted or prohibited categories, misleading claims in the title or description ("best", "guaranteed", superlatives that read as unsubstantiated), pricing language that implies a discount that cannot be verified, or images that violate the visual requirements below.

Policy disapprovals are the ones most likely to escalate. A single misleading price claim on one product is an item-level fix. A pattern of misleading claims repeated across dozens of listings is exactly the kind of signal that turns into an account-level review, which is a much longer and more disruptive process. Treat any policy flag as worth fixing properly rather than editing around, because the review that follows a repeated pattern looks at the account, not the individual item.

Image requirements

This cluster is smaller in volume and easy to overlook, because a human scanning the page doesn't always spot what the automated check catches. Google disapproves images that carry promotional overlays, watermarks, placeholder graphics, or text baked into the image itself, rather than the plain product shot it expects for the primary image field. In my experience these cluster around one templated image style, most often a "sale" badge or a border added by a bulk image-export tool, rather than being scattered randomly across the catalogue. Find the template that produced the bad batch and a single export re-run can often clear the whole batch, rather than editing each product individually.

How long a fix actually takes to clear

There is no single published number, and any article that gives you an exact day count is guessing. What is true, and what I tell clients when they ask, is this: automated checks (price, availability, most attribute checks) clear on the next crawl once the feed and the page genuinely agree, which in practice is usually within a day. Anything routed to manual review, which policy flags often are, has no guaranteed turnaround and can sit longer. The honest answer to "when will this clear" is "once the underlying data is actually consistent, and the next crawl confirms it," not a countdown.

Why the fix doesn't stick

On more than one account I have taken over, the person who owns the Merchant Centre account and the person who owns the product catalogue turned out to be in different teams, and neither had told the other about the disapprovals. The fix that is fastest to make (editing the feed export, or a supplemental feed override) is not the fix that lasts, because it never reaches whoever can actually change the field.

The order that actually works: identify the disapproval reason in Diagnostics, trace it to the specific field in the product record (not the feed file) that generates the wrong value, fix it at that source, then let the feed regenerate naturally rather than patching it by hand. If your platform genuinely cannot fix the root cause in time (a legacy stock system with a slow sync, for example), a supplemental feed override is a legitimate short-term bridge. Log it as a known workaround with a date to revisit, rather than leaving it in place indefinitely.

When to stop worrying about a disapproval

Not every red flag in Diagnostics deserves a fire drill. A handful of disapproved products out of a catalogue of several thousand, cycling in and out as prices and stock change naturally, is normal operating noise. What deserves attention is a disapproval count that is growing week over week, a single reason accounting for a large share of the catalogue, or anything flagged as a policy issue, because those tend to sit upstream of a bigger problem rather than resolving themselves on the next crawl.

If your feed work sits inside a wider Performance Max or Shopping campaign, I would check feed health before touching bids. A campaign rarely outperforms the data feeding it, and I go into what that means for bidding in Performance Max for retail. If you want a second pair of eyes on a Merchant Centre account before scaling spend against it, that is the kind of audit my paid search team runs before we touch bidding at all.