Approved is not visible: Merchant Center eligibility, parity and reporting contexts
The short version
“Approved” does not mean visible, and it does not mean serving. Merchant Center evaluates products separately for destinations such as Shopping ads and free listings; campaign exclusions, feed-to-page mismatches and weak auction access can still keep an approved product out of sight.
Audit the complete offer instance—channel, language, feed label and offer ID—then rank gaps by margin, demand and duration. Use the free product feed scanner to catch feed defects, but verify destination status and actual serving inside Merchant Center and Google Ads.
Separate the three gates
A useful audit treats exposure as three successive gates:
- Eligibility: is this offer approved for the specific destination and market instance?
- Visibility: can the approved offer enter the intended surface, or is another platform or campaign rule excluding it?
- Serving: did the offer actually receive impressions in the period being reviewed?
Do not collapse those into one “approved products” percentage. Each gate has a different owner and a different fix.
A disapproved offer needs a product-data or policy correction. An approved but excluded offer needs a campaign or inventory-filter change. An eligible offer that enters auctions but rarely serves may need a bid, budget, relevance or demand diagnosis.
Name the reporting context before counting
Merchant Center tracks status by reporting context. A product can be approved for Shopping ads and disapproved for free listings at the same time.
Every denominator in the audit should therefore state the destination explicitly:
- Shopping ads;
- free listings;
- any other program or market being reviewed.
“92% approved” is incomplete. “92% of active UK Shopping-ad offer instances approved on August 15” is auditable.
Keep contexts separate until the final summary. Mixing them can make a healthy paid-feed population hide a free-listing problem—or the reverse.
Join at offer-instance grain, not SKU grain
The same SKU or offer ID can appear in several channel, language, feed-label and country combinations. Those instances can carry different prices, statuses and issues. This is why country-instance counts can exceed the product count visible in the Merchant Center interface.
Build the join key from the processed product identity available in the export. At minimum, retain:
- channel;
- content language;
- feed label or market scope;
- offer ID;
- destination or reporting context.
Do not reduce that key to SKU before checking uniqueness. A SKU-only join can combine an approved UK instance with a disapproved US instance and produce a status that was never true for either market.
Before analysis, report:
- source rows;
- unique processed offer instances;
- matched and unmatched rows;
- duplicate keys;
- the destination and snapshot date.
Low match coverage is a measurement problem, not a weak business result.
Build the audit population from products worth selling
Start from active, purchasable, in-stock catalog offers. Add the commercial fields needed to prioritize work:
- unit contribution margin or a defensible margin band;
- recent demand or sales;
- stock depth;
- issue duration where repeated snapshots exist.
Then join feed membership and destination status. Split the population into:
- missing from the feed;
- present but pending;
- present but disapproved;
- approved but not visible or included;
- included but not serving;
- serving.
Rank each gap by commercial value, not by item count. Two percent of products can represent forty percent of expected contribution. A thousand low-value warnings should not outrank one parity defect suppressing a profitable bestseller.
Verify parity from feed to checkout
Platform status is not enough. For a value-weighted sample, compare the exact offer across:
- the processed feed instance;
- the rendered product page, including structured data;
- checkout.
Check price, sale price and dates, currency, availability, GTIN and brand, image, variant identity and landing URL. The page must open the same variant represented by the feed, and checkout must preserve the same price and purchasable state.
A file can pass syntax validation while the processed offer remains commercially wrong. Automatic item updates, item issues and price or availability mismatches are evidence that the platform already sees a parity break.
For each defect, record the exact offer key, conflicting values, surfaces checked, request time and the owner of the source field. Retest the same offer after the fix.
Check the gates after approval
Approved products can still be absent from campaigns or auctions. Cross-check high-value approved offers against:
- listing-group subdivisions and exclusions;
- inventory filters;
- campaign priorities and negatives;
- market and feed-label selection;
- bids and budgets for the product cluster;
- actual impressions by surface and period.
Keep the diagnosis narrow. No impressions does not automatically prove a feed defect. First show that the offer is eligible for the destination, included by campaign structure and measured in a comparable reporting window.
When enriching titles, identifiers or campaign labels, use a reversible supplemental source rather than replacing the primary feed. Limit the fields and product population, save the pre-change baseline, and define the rollback condition before upload.
Preserve time and definition boundaries
A single snapshot can prove current scope. It cannot prove that an issue “has been broken for weeks.” Duration requires repeated snapshots or explicit issue timestamps.
Reporting definitions can also change. Merchant Center’s August 24, 2026 update separates YouTube affiliate traffic from Organic, restates affected YouTube history from July 1 and expands ads product-level reporting across more formats. A step change across that boundary may be classification or coverage—not better or worse serving.
For every extract, save:
- pull time and timezone;
- destination and market filters;
- traffic, interaction and network definitions;
- query or export method;
- reporting window.
Split time series at a definition change or recut both periods like for like before attributing movement to feeds, campaigns or demand.
Run the audit in this order
- Inventory primary, supplemental and API-written sources, with last successful refresh times.
- Define active, purchasable, in-stock offers and add margin, demand and stock.
- Export processed product identities and per-context statuses.
- Join at the complete offer-instance grain; stop on weak coverage or duplicate keys.
- Quantify missing, pending and disapproved value by destination.
- Sample high-value offers for feed-to-page-to-checkout parity.
- Cross-check approved offers against campaign inclusion and actual impressions.
- Rank fixes by margin, demand and duration.
- Assign an owner, reversible change and verification condition to every action.
- Repeat the same extracts and samples after the fix.
Run the product feed scanner before upload to catch field and formatting problems. Then verify processed status and serving in the destination platform; a clean source file is only the first gate.
The finished report
A decision-grade report states the population, join grain, match coverage, destination denominators, snapshot dates and reporting definitions. Its top result should be a mechanism someone can fix: a parity break verified end to end, a value-weighted eligibility hole, or a serving gate on profitable approved inventory.
Avoid an issue inventory with no commercial weight. The output is not “312 warnings.” It is “these offers represent the largest recoverable exposure, this is the gate suppressing them, this owner can change it, and this retest proves whether the fix worked.”
Sources
- Google Merchant Center product data specification — product attributes, identifiers, price and availability requirements; checked August 15, 2026.
- Google Merchant Center performance reporting updates — August 24, 2026 reporting-definition changes; checked August 15, 2026.