466 disapproved products and nothing wrong: when a Merchant Center alert is just a feed you decided not to use

A Google performance email landed in a client's inbox at the start of the month: 466 products not approved, zero approved. The client forwarded it to me not knowing which account it referred to, or whether this was something to panic about.

It took twenty minutes to answer. The account belongs to a Swiss building-materials company I look after — paving, walling, gravel — and every product in the feed is disapproved. Three quarters of them for missing shipping information. The remaining quarter for missing a price. No account-level problems, no policy strikes, no suspension warning.

And zero ad clicks. Zero spend. Not a single campaign attached to that feed.

Which makes this the most interesting kind of alert: one that is completely accurate, perfectly severe-looking, and describes a state we chose on purpose two months ago.

Why the products can't be approved, and shouldn't be

The website is a quote-request business. You browse the range, you ask for an offer, somebody prices it by tonnage and delivery distance and calls you back. There is no cart and no checkout, which is the entire commercial model of the sector and not an oversight.

Google's requirements are explicit about what that means for Shopping. Checkout requirements state that customers "must be able to add in-stock products to their cart and finalize their purchase," that availability in your product data must match the product and checkout pages, and that the price can't rise at checkout. Separately, products without a shipping cost simply "won't show to customers until you add a shipping cost."

Our catalogue fails all of that by design. Prices depend on volume and haulage, so there is no single number to submit. Shipping is a quote line, not a table. Fulfilment ends in a phone call. We took this decision in writing back in the summer: Shopping is not available to a pure quote-request site, so don't build for it, and don't pretend to.

So "466 not approved" isn't a defect report. It's Google correctly describing a catalogue that doesn't meet a standard we deliberately aren't meeting.

An alert can be entirely true and still be about nothing.

The actual failure is a pipeline nobody retired

Here's the part that is a problem, and it isn't the one the email was shouting about.

The shop plugin is still syncing the full assortment into Merchant Center every day — hundreds of items, no prices, no shipping, going nowhere. The decision to skip Shopping was made. The pipeline that fed Shopping was never switched off. So every month a system generates an alarm about a thing we aren't doing, somebody reads it, somebody forwards it, and a little attention gets spent confirming a known answer.

Multiply that by the number of integrations a mid-sized company accumulates and you have a meaningful tax. The Google SRE book makes the point in an operational register: an alert should mean something is actionable, and a page that fires on a state you've accepted trains people to ignore the channel. Marketing stacks are full of these, and they're worse than engineering's because nobody owns the inbox.

The clean fix is one of two things. Narrow the sync to the shortlist that will become genuinely buyable when a paid checkout launches — there's a palette-level sub-range where a fixed price and a shipping table are realistic — or pause the sync entirely until that day arrives. Either one stops the monthly email at source. Neither one is urgent, which is exactly why it has sat there.

The triage question that saves the time

What made this a twenty-minute answer rather than an afternoon was asking one question before touching anything: is any money running on this?

Zero clicks, zero cost, no campaign attached. That single fact converts an alarming email into a housekeeping item, and it should be the first thing anyone checks when a platform warning arrives. Severity in these notifications is a function of how many items are affected, not of whether anything is at stake. Four hundred and sixty-six is a big number and a small problem. Sixty disapproved ads on a funded campaign is a small number and an expensive problem.

The order that works, for anyone sorting these: what account is this, what is running on it, what did we decide about this channel, and only then what does the error say. Skipping to the error is how teams end up building checkout requirements for a business model that doesn't have a checkout.

It's the same discipline as not counting a price-list download as a lead, or testing whether a dip is a signal before you go hunting for a bug: establish what the thing is before deciding what it means.

What I write back to the client

Three sentences, in this order. This is your account, not the other one. Nothing is running on it and no revenue is affected. The products are disapproved because we decided not to do Shopping on a quote-only site, and the only outstanding item is switching off the feed that keeps generating the email.

No remediation plan, no ticket, no apology for a thing that isn't broken. Part of being useful as a fractional marketing exec is being the person who can say "ignore that" with a documented reason — and then quietly close the loop so it doesn't need saying again next month.

The cost of an alert isn't the alert. It's everyone who reads it.

Sources & further reading

External
Checkout requirements and best practices — Google Merchant Center Help
How to fix missing shipping information — Google Merchant Center Help
Editorial and professional requirements — Google Merchant Center Help
Monitoring distributed systems — Google SRE Book

Related posts
A price-list download is not a lead
Attribution only gets real when it joins the order book
Test whether a dip is a signal before hunting for a bug
Check product-query fit before cutting a Google Ads campaign