Google Merchant Center Feed Errors: What Actually Gets Your Products Disapproved, and How to Catch Them Before They Cost You Sales

Open a Shopping campaign that’s been running fine for months and you’ll usually see the numbers you expect: steady impressions, a reasonable click-through rate, conversions ticking along. Then one week the impressions drop by a third and nobody touched a bid, a budget, or a single setting inside Google Ads. The campaign looks untouched. The account history is empty. And the answer isn’t in Google Ads at all — it’s sitting in Merchant Center, where a chunk of the product catalog quietly stopped being eligible to show.

This is one of the more disorienting problems in ecommerce advertising, because it breaks the usual troubleshooting instinct. Most Google Ads problems live in Google Ads: a bid strategy misbehaving, a negative keyword blocking too much, a budget capped too low. A feed problem lives one system over, in a product data pipeline that most people only open when something obviously breaks, and by the time it’s obvious, it’s usually been costing sales for days or weeks.

This post is about that blind spot: what actually causes products to lose eligibility, where Merchant Center tells you (if you know where to look), what changed in 2026 that’s worth knowing about, and how to build a habit of catching this before it shows up as a mysterious drop in Shopping performance.

Why a Healthy Shopping Campaign Can Hide a Sick Feed

Shopping and Performance Max campaigns don’t run on keywords the way Search campaigns do. They run on your product feed — the structured data you submit to Merchant Center describing every item you sell: title, price, availability, images, category, identifiers, and a long list of other attributes. Google Ads doesn’t independently verify any of that. It trusts Merchant Center to hand it a catalog of eligible products, and it builds ads from whatever comes through.

That division of labor is exactly why feed problems are so easy to miss. Google Ads reporting tells you what happened to the products that were eligible to serve. It has no reason to surface the ones that quietly dropped out, because from the campaign’s point of view, they never existed in the first place. A product that gets disapproved in Merchant Center doesn’t show up in your Google Ads dashboard as an error — it just stops generating impressions, and unless you’re watching product-level counts closely, a partial drop can look indistinguishable from normal demand fluctuation.

The scale of this varies a lot by catalog size. A retailer with forty SKUs might notice within a day if six of them go missing. A retailer with four thousand SKUs, spread across a feed that’s partially automated and partially hand-maintained, can lose a few hundred products to a data issue and not notice for a billing cycle, because the campaign-level numbers don’t collapse — they just quietly underperform relative to what they should be. That’s the trap: feed problems rarely take a campaign to zero. They shave off a percentage that’s easy to write off as “the market” when it’s actually a fixable data issue.

It’s worth being specific about why this matters more in 2026 than it used to. Performance Max has pulled more Shopping spend into a single automated campaign type that leans harder on feed data as its primary signal — no keywords to fall back on, no manual placements to inspect. If you’ve been through the exercise of auditing a live Performance Max campaign, you already know how much of PMax’s behavior traces back to inputs rather than settings. The feed is the biggest of those inputs, and it’s the one most PMax audits skip, because it lives in a different tab of a different product.

Where Merchant Center Actually Tells You What’s Wrong

If you learned Merchant Center a few years ago, the place you’d go looking for problems was the Diagnostics tab. That tab is gone. Everyone was migrated to the rebuilt interface — what Google called Merchant Center Next during the transition, and has simply called Google Merchant Center since a rename in mid-2026 — and the entry point for product-level problems moved to Products → Needs attention.

The Needs attention view is organized differently than the old Diagnostics list, and it’s worth understanding the structure before you start troubleshooting. Instead of a flat list of error codes, it surfaces issue cards ranked by estimated click impact — High, Medium, and Low — so the intent is to point you at the problem costing you the most traffic first, rather than the one that’s alphabetically first or most recently detected. That’s a genuine improvement if you’re triaging a big catalog, but it also means a low-impact issue affecting a handful of high-margin products can get buried under a high-impact issue affecting a lot of low-value ones. Don’t treat the ranking as the only thing worth looking at — skim past the top card occasionally and check what’s sitting further down.

The other distinction worth keeping straight is account-level versus item-level issues, because they require completely different responses. An account-level issue affects your entire Merchant Center account, or your entire eligibility in a target country — things like a suspended data source, an unresolved tax or shipping setup requirement, or a failed business verification. These show up as a banner at the top of the account and they’re the most serious category, because until they’re resolved, no amount of fixing individual products will restore visibility. If you ever see a banner like this, treat it as the priority over anything else on this list.

Item-level issues are narrower: they affect specific products rather than the account as a whole, and they’re the more common day-to-day reality for most merchants. A product with a missing GTIN, a mismatched price, or a policy-violating image gets disapproved individually, while the rest of your catalog keeps serving normally. This is the category that quietly erodes performance over time, because it’s easy for a handful of item-level disapprovals to sit unnoticed in a catalog of any real size — nothing about the account looks broken, just a slice of it.

Both categories get a severity label — error, warning, or notification — and it’s worth knowing what that actually means before you decide how urgently to react. Errors are the ones that have already caused a suspension or a disapproval; they’re not a warning about something that might happen, they’re a description of something that already did. Warnings and notifications flag things that could become a problem, or that Google thinks you should know about, but haven’t blocked anything yet. Sorting your response by that severity, rather than by how the issue is worded, is the fastest way to spend your time where it actually matters.

The Handful of Reasons Most Disapprovals Actually Happen

Merchant Center’s error list is long, but the overwhelming majority of real-world disapprovals trace back to a small number of root causes. Knowing these well enough to recognize them on sight will get you through most troubleshooting faster than trying to memorize the full error catalog.

Price and availability mismatches. Google’s crawlers periodically revisit your landing pages to confirm that what’s in the feed matches what a shopper would actually see if they clicked through. If your feed says $49.99 and the live page says $52.99 — even because of a temporary promotion, a currency rounding difference, or a caching delay after a price change — that’s a mismatch, and it’s one of the most common disapproval triggers there is. The same logic applies to availability: a feed that says in stock for a product the website marks “Sold Out” will get flagged, and so will the reverse. These are almost always the result of a sync delay between your ecommerce platform and your feed, rather than a deliberate data error, which is exactly why they’re easy to miss until Merchant Center points them out.

Missing or invalid product identifiers. Google wants brand plus GTIN, or brand plus MPN, for the overwhelming majority of product categories, and it uses these identifiers to match your listing against its own product catalog for richer results and better targeting. A product missing a valid identifier doesn’t always get outright disapproved, but it does get pushed toward reduced visibility — a quieter, harder-to-diagnose penalty than a flat rejection, because nothing in the account looks “broken,” your product just performs worse than an identical one with a clean identifier attached.

Image quality and policy problems. Watermarks, placeholder graphics, promotional text or logos overlaid on the product photo, and images that don’t match the actual product all fall under this bucket, and it’s consistently one of the largest sources of item-level rejections across merchant accounts of every size. It’s also one of the easier ones to prevent structurally, since it usually comes down to how images are sourced and processed before they ever reach the feed, not a one-off mistake on a single listing.

Missing required attributes. Depending on the product category, Google requires specific attributes beyond the basics — size and color for apparel, age group and gender where relevant, condition for anything that isn’t brand new. Leaving these blank, or filling them with a value that doesn’t match Google’s accepted list for that attribute, is a routine cause of disapproval that’s almost entirely preventable with a feed template that enforces the right fields for each category up front.

Policy violations. This is the broadest and most serious category — restricted products, misleading claims, prohibited content, or attempts to circumvent Google’s ad policies. Unlike the data-quality issues above, policy violations usually require an actual review before they’re lifted, not just a corrected data feed, and repeated or serious policy violations can escalate to account-level suspension rather than staying contained to individual items. If you get a policy disapproval that genuinely seems like a false positive, it’s worth requesting a review rather than assuming it will resolve itself — but only after checking carefully that the listing really does comply, since a rejected review request against a repeat violation carries more weight than a first-time one.

How Long a Fix Actually Takes, and Why That Timing Matters

Once you’ve corrected something, the natural next question is how quickly it takes effect — and the honest answer depends on which category of problem you’re dealing with. Data-quality issues, like a price mismatch or a missing attribute, are typically re-evaluated automatically the next time Google recrawls your feed and your landing pages, and corrected products are commonly back to eligible within twenty-four to forty-eight hours of the fix going live. Policy-related disapprovals move slower, because they usually require a human reviewer rather than an automated recheck — expect something closer to one to three business days after you submit a review request, sometimes longer during high-volume periods like the run-up to a major shopping holiday.

That timing gap is worth planning around, not just knowing in the abstract. If you catch a feed problem the week before a planned sale or a seasonal spike, a data-quality fix might genuinely resolve in time. A policy-related disapproval discovered at the same point almost certainly won’t clear before the event starts, which means the real fix is catching it earlier — ideally weeks before a peak period, not days. This is one of the strongest arguments for checking feed health on a routine cadence rather than only when something already looks wrong: the whole value of catching a problem early is that you still have the runway left to act on it.

The 2026 Merchant Center Changes Worth Knowing About

A few structural changes have landed in 2026 that are worth understanding, because they affect how you’ll interact with the platform going forward even if your day-to-day feed management doesn’t change much.

The first is cosmetic but has caused some confusion: in July 2026, Google dropped the “Next” from Merchant Center Next and it’s now simply called Google Merchant Center. Nothing structural changed in that rename — your account, feeds, campaigns, and login all carry over untouched — it just closes out a multi-year migration that started rolling out back in 2023. If you see references to “Merchant Center Next” in older documentation or a colleague’s notes, it’s the same product you’re already using.

The second is more consequential if your feed setup involves any kind of API integration rather than a manual upload or scheduled file fetch. Google’s older Content API for Shopping is being sunset on August 18, 2026, in favor of the newer Merchant API. If your product data comes from a Google Sheet, a scheduled URL fetch, or a manual file upload, this deadline doesn’t touch you directly — those pathways keep working. But if a developer built a custom integration against the Content API, or you’re using a third-party feed tool that hasn’t completed its own migration, that integration needs to move to the Merchant API before the cutoff or it will stop syncing data entirely. Given that a feed sync failure is effectively an account-level issue — it can silently stop updates to your entire catalog rather than a handful of products — this is worth confirming directly with whoever manages your feed pipeline rather than assuming someone else already checked.

Supplemental Sources and Attribute Rules: Fixing Data Without Touching the Root Feed

One of the more useful additions to the current Merchant Center is a pair of features that used to be called Supplemental Feeds and Feed Rules, and have since been renamed Supplemental Sources and Attribute Rules. The renaming is cosmetic; the functionality is what matters, and it solves a real, common problem: what do you do when your primary feed is generated by a system you don’t control — a platform export, a developer-owned pipeline — but you need to fix or override specific attributes without waiting for an engineering ticket?

A supplemental source lets you layer a secondary data source — often as simple as a spreadsheet — on top of your primary feed, and use it to fill in or override specific fields for specific products. Attribute rules go a step further, letting you define logic that transforms data automatically: appending a missing GTIN pattern, correcting a category mapping, or standardizing a value that’s inconsistently formatted across your catalog. Neither feature is enabled by default in the current interface — you’ll find the option under Settings → Add-ons — which is part of why a lot of merchants don’t know it exists even though it’s been available for a while.

The practical value here is speed. If you catch a data-quality issue in the Needs attention view — say, a missing brand attribute across two hundred products from an older import — filing a fix with whoever owns the primary feed can take days or weeks depending on their queue. A supplemental source or attribute rule can patch the same problem in an afternoon, without touching the underlying system at all. It’s not a replacement for eventually fixing root causes properly, but it’s a legitimate way to stop the bleeding while a proper fix works its way through a development backlog.

Feed Quality Beyond “Not Disapproved”

Everything up to this point has been about avoiding rejection. But a feed that clears Merchant Center’s checks with zero errors can still be a mediocre feed — eligible to show, but poorly set up to actually perform well once it does. This distinction matters because a lot of merchants treat “no errors in Needs attention” as the finish line, when it’s really just the minimum bar.

Product titles are the clearest example. A title that’s technically accurate but generic — just the internal product name, with no category context or distinguishing detail — gives Google’s matching systems less to work with than a title structured around how people actually search: brand, product type, and the specific attributes (size, color, material, model) that differentiate this listing from every similar one in the catalog. This isn’t just a Shopping-specific nuance either — Performance Max leans on the same feed data to build and match its automated ads, so a weak title doesn’t just underperform in classic Shopping results, it hands PMax’s models a weaker starting signal across every channel the campaign touches.

Images matter for the same underlying reason. Beyond the policy requirements around watermarks and overlays, clean, well-lit product photography on a plain background consistently outperforms busier lifestyle imagery in Shopping placements specifically, even though the opposite is often true in Display or social contexts. If your catalog was built around lifestyle photography for a different channel and repurposed for Shopping without adaptation, that’s worth revisiting even if none of those images are triggering an actual policy flag.

Custom labels are worth a specific mention because they’re one of the most underused fields in a typical feed. They don’t affect eligibility or approval at all — they’re free-text fields you control entirely — but they let you segment Shopping and Performance Max campaigns by margin tier, seasonality, bestseller status, or clearance state, which in turn lets you apply different bidding logic to different slices of a catalog that would otherwise all get treated identically by an automated campaign. A feed that’s technically clean but makes no use of custom labels is leaving a real lever unused, not committing an error, but it’s a gap worth closing once the more urgent disapproval issues are handled.

Where This Connects Back to Your Google Ads Reporting

Feed problems and campaign-level problems don’t stay neatly separated in practice, and it’s worth knowing what to check on the Google Ads side once you suspect a feed issue, rather than treating Merchant Center and Google Ads as two completely disconnected systems to monitor separately.

If you’ve already built the habit of reviewing your search terms report, the same discipline applies to Shopping and PMax placements — a sudden drop in impressions for a product category, or a shift in which search terms are triggering Shopping ads, is often the first visible symptom of a feed problem before you’ve even opened Merchant Center to confirm it. Product group performance inside a Shopping or Performance Max campaign is a similarly useful early-warning signal: a product group that quietly goes to zero impressions while its budget sits unspent is a strong hint that something in the underlying feed dropped out of eligibility, well before that same information surfaces as a disapproval count in Merchant Center’s own reporting.

This is really the same argument made in favor of routine account review generally, just applied to a system that’s easy to forget is even part of the account. The campaign-side symptoms — product groups going quiet, budget pacing drifting below plan, impression share collapsing on categories that used to perform — are exactly the kind of signal that daily monitoring is built to catch, and it’s part of why Growera’s continuous daily account monitoring reviews Shopping and Search campaigns together rather than as separate silos. ERA doesn’t read your Merchant Center feed directly, but when a feed problem starts showing up as a stalled product group or an unusual pacing shift inside the Google Ads account itself, that’s precisely the kind of drift a daily review is designed to flag while it’s still small, instead of three weeks into a quiet decline that eventually gets blamed on “the market.” If you’re running Shopping and Search campaigns for an ecommerce account, that combination of catching campaign-side symptoms early and knowing where to look in Merchant Center when they show up is most of the battle.

A Quick Way to Tell Which System Actually Broke

When Shopping performance drops, the instinct is usually to start in Google Ads, because that’s where the dashboard lives and where most day-to-day changes happen. That’s not wrong, but it’s worth having a quick way to decide whether the cause is likely to be a feed problem or a genuine campaign problem before you spend an hour adjusting bids for something a data fix would have solved in minutes.

A few patterns tend to point toward the feed rather than the campaign. If the drop is concentrated in a specific product, brand, or category rather than spread evenly across the account, that’s a feed signal — a campaign-level setting change would rarely affect one slice of the catalog so cleanly. If impressions collapsed on products with unspent budget sitting behind them, that’s also a feed signal, since a genuine demand drop usually comes with lower competition and cheaper clicks, not products going silent while money sits unused. And if the timing lines up with a known change upstream — a new product import, a platform migration, a pricing update pushed live — treat that as the first place to look, not a coincidence to rule out later.

By contrast, a broad decline spread evenly across the whole account, alongside a market-wide event (a seasonal lull, a competitor’s aggressive promotion, a genuine demand shift), usually points toward something outside the feed entirely — worth checking auction insights or seasonal trends before assuming a data error is to blame. Neither pattern is a guarantee, but starting with this quick sort saves a lot of wasted troubleshooting time, especially on accounts where Google Ads and Merchant Center are managed by different people who don’t automatically compare notes.

A Practical Feed Health Routine

Pulling the above into something you can actually act on, here’s a reasonable cadence for most catalogs of meaningful size:

• Weekly: Check Products → Needs attention for new high-impact issue cards, and skim past the top result to check what’s further down the list. A five-minute weekly check catches most new item-level disapprovals before they’ve been live long enough to matter.
• Before any sale or seasonal push: Run a full pass at least two to three weeks out — not the week before — so there’s enough runway for a policy-related disapproval to clear a review cycle if one turns up. Confirm price and availability sync specifically, since promotional pricing changes are exactly when mismatches spike.
• Monthly: Review a sample of your feed for quality issues that don’t trigger an error — generic titles, thin descriptions, missing custom labels, lifestyle images where plain-background photography would perform better. Nothing here is urgent, but it compounds if it’s never addressed.
• Whenever a Shopping or PMax product group goes quiet: Treat a sudden drop to near-zero impressions on a specific product group as a feed question first, campaign-settings question second. Check the corresponding products in Needs attention before assuming it’s a bidding or budget issue.
• Whenever your feed pipeline changes: A new ecommerce platform, a new feed management tool, or a developer touching a custom API integration is exactly when to confirm you’re not still pointed at the Content API ahead of its August 2026 sunset, and to double check that identifiers, pricing, and availability are still syncing correctly after the change.

None of these individually take long. The value, as with most account maintenance, comes from actually doing them on a schedule rather than only when a campaign’s numbers have already dropped enough to force the question.

The Bottom Line

A Shopping or Performance Max campaign is only as good as the product data feeding it, and that data lives in a system most advertisers only open when something’s visibly wrong. That’s the core problem with feed health: it degrades quietly, one disapproved product or one stale price sync at a time, and the campaign built on top of it doesn’t throw an error to tell you — it just performs a little worse than it should, in a way that’s easy to attribute to seasonality, competition, or an algorithm having an off week.

The fix isn’t complicated. Know the difference between an account-level issue and an item-level one, check Needs attention on a real cadence rather than only during a crisis, understand the handful of root causes — price and availability mismatches, missing identifiers, image and policy problems — that account for most disapprovals, and use supplemental sources or attribute rules when you need to patch a data problem faster than a development queue can move. Layer in the 2026 changes — the Merchant Center rename and the Content API sunset — so nothing catches your feed pipeline off guard. None of it requires specialized tooling. It requires treating Merchant Center as a system worth checking on purpose, the same way you’d check bids, budgets, or search terms inside Google Ads itself.