Product Feed Optimization: Why Approval Rate Hides the Real Work

Most advice on product feed optimization opens the same way: pull your disapproved products and fix them. We audited five live Merchant Center accounts on July 30, 2026, 11,107 products between them, and 21 products were disapproved. That is 0.19 percent of the catalog, and it is where the standard advice spends almost all of its attention.

The same read returned 1,281 open issues, of which 848 are data quality defects that Google flagged and then served anyway. Forty defects sitting inside the catalog for every one product Google actually stopped. If your feed work is scored on approval rate, you will never see any of them. None of that is specific to these five catalogs, so what follows is the counted breakdown, what each tier is worth, and the order to work them in.

What five live catalogs actually look like

These are live client catalogs we audited. Product counts are what the Merchant Center API returned on the read, and Catalog B hit the 5,000 product page cap, so its real catalog is larger. Verticals are generalized and the accounts are unnamed, since none of this is public client data.

Approval runs from 82 percent to 99 percent, and every one of these catalogs would pass a health check. Catalog C is the interesting one: 893 approved out of 1,089, and 627 open issues, more than any other account in the set including one more than four times its size.

Approval rate tells you almost nothing

Approval is a serving decision. Google is answering one question, which is whether this product is allowed to appear, and for a catalog that somebody maintains the answer is nearly always yes. Run that number monthly and you get a chart that sits at 99 percent and never moves, which is a fine thing to show a client and a useless thing to work from.

Everything that decides how a product performs once it is eligible lands in the tiers below the disapproval line. Google reports those as warnings and as information, and neither label carries any urgency in the interface. Warnings in particular are where the real backlog lives: 179 products in one account carrying a single warning code, none of them blocked, all of them competing with one hand behind their back.

So the score we actually keep is defect count per thousand products, split by whether the defect is ours to fix. Across these five accounts that number is 76 per thousand, against an approval rate of 97 percent for the same catalogs, and the two figures describe completely different amounts of work.

What the 848 defects actually are

Ranked by the number of products affected, with the number of catalogs each one showed up in:

Beyond those 848, the other 433 issues in the read are not feed data work, and it is worth separating them out so they do not inflate the list. 167 are status notices telling you Google processed something: a price update, a strikethrough price recalculated, an attribute sitting in review. Nobody needs to do anything about those. The other 266 are policy flags on Demand Gen serving, concentrated in two accounts, and those belong to whoever owns creative and policy.

Two patterns in that table are worth more than the individual codes. The first is that the top three defects account for 753 of the 848, so a feed program that fixes three things well beats one that works down a list of fifteen. The second is that missing_item_attribute_for_product_type and image_too_small_for_high_resolution showed up in four of the five catalogs, on completely different platforms and completely different verticals, which points at something structural in how catalogs get built.

One of these has a date attached to it

image_too_small_for_high_resolution is a warning today and a hard floor in six months. Google's 2026 update to the product data specification raises the minimum resolution for image_link and additional_image_link to 500 by 500 pixels across every product category. Warnings started on April 14, 2026, and enforcement begins January 31, 2027.

Google has said it will automatically optimize some undersized images and mark them in the Needs attention section, which is a mitigation rather than a plan. 171 products across four of the five catalogs we audited are already carrying the warning, and every one of those images has to be re-rendered or reshot at source before the end of January. Image work at catalog scale runs on photography schedules and asset pipelines, so a January deadline is a September conversation.

We cover the rest of that spec update, including video_link and the new shipping sub-attributes, in our breakdown of required and optional feed attributes.

Where a populated GTIN is still wrong

Catalog C carried 313 products flagged with ambiguous_gtin, which is 29 percent of that account. Every one of those products has a GTIN populated. A coverage report would score that field at or near 100 percent and move on, because coverage reports check whether a value is present and never check whether it is right.

Google's guidance on the gtin attribute is unusually direct for platform documentation: "Only provide a GTIN if you are sure it is correct," and "when in doubt do not provide a GTIN (for example, do not guess or make up a value)." The practical failure we see is a supplier code, a parent barcode reused across a variant group, or a digit transposed somewhere upstream, and all three produce a value that validates as a number and matches nothing. A wrong identifier costs you more than a missing one.

The optional fields are still empty everywhere

The other half of feed optimization is the block Google will never disapprove you for leaving blank. Our enrichment platform has published values to 8,276 products across these same accounts, so we counted how many carry any of Google's six conversational attributes, the fields AI shopping assistants read most heavily.

3,999 products of the 8,276 carry at least one, and all 3,999 of them sit in two of the five catalogs. The three catalogs that carry feed labels and nothing else are what pulls the total down, and on those the optional block is queued rather than done.

document_link at zero is the row we keep coming back to. Google shipped the field, we have the infrastructure to populate it, and across five real catalogs it is on nothing, because supplying it means having a manual, a spec sheet, or a care guide that lives at a stable URL for each product. That is a content problem wearing a feed problem's clothes, and it is why the field will stay empty across most of the market for a while. variant_option at 25 says something similar about how much variant data is genuinely structured versus stuffed into a title. Our field by field setup guide has the format and an example for each of the six.

How we score a feed

Four numbers, in this order, and each one is a percentage of SKUs so catalogs of different sizes stay comparable.

• Required coverage. Target is 100 percent and there is no judgment call in it. Anything less is inventory that cannot serve.
• Defects per thousand products, ours only. Strip the status notices and the policy flags first, because leaving them in makes the number move for reasons nobody controls. This is the number that should trend down month over month.
• Accuracy spot checks on identifiers. Sample GTINs against GS1 validation and against your own product records. Coverage will not surface a wrong value and neither will the disapproval queue until visibility is already gone.
• Optional coverage, attribute by attribute, ranked by revenue. Start at your best sellers rather than the top of an alphabetical list, and report each attribute separately. A blended optional-coverage score hides which field is actually missing.

Test every change through a supplemental feed. It layers new columns on top of the primary feed without touching it, and it can be pulled back out if a value looks wrong, which matters when you are pushing to thousands of SKUs at once. The same mechanism is how we handle price competitiveness work.

Where to start

Pull the issue list for your own account and split it into three piles: status notices you ignore, policy flags you route to somebody else, and data defects you own. Count the third pile, divide by your SKU count, and you have a number that will actually move when you do the work. Then check your image dimensions against 500 by 500, because that is the one item on the list with a date on it.

Populating the optional block well is the part that does not scale by hand, since every value is a small research problem repeated once per SKU. That is what our Merchant Center enrichment service is built to do: AI agents that ground every value in a real source on your own site, validate it, and publish through a supplemental feed with a human approving the batch.

Want the same read on your catalog? Book a call and we will run the defect count and send you the three piles.