Approved, eligible, and invisible: what your product feed stopped doing

Product feed optimization used to end at Merchant Center approval. It no longer does. A compliant catalog can pass every diagnostic and still be absent from the surfaces where buyers now decide.

  • Approval confirms compliance, never visibility.
  • Feeds built for the ad auction read poorly to attribute-driven engines.
  • AI Mode and AI Overviews source differently and need different work.
  • ChatGPT runs its own product specification and its own eligibility rules.

Product feed optimization stopped at approval, and approval stopped meaning visibility

Merchant Center status is binary. Compliant, or not compliant. It reports whether your data violates a policy. It says nothing about whether a single product was served.

Teams read a screen full of approved items and conclude the work is done. That is the most expensive misreading in retail media today, and it shows up first in free listings: catalogs sitting in an approved and eligible state, no feed error, no policy flag, no diagnostic warning, and absent from merchant listings entirely. Nothing is broken in the sense the interface understands. The data is simply not good enough to be selected, and selection is a competition that the approval status does not describe.

What changed is the arithmetic around that indicator. Google Shopping feed optimization was built as a discipline around one destination and one question: will this product serve on this auction. The destinations are now plural. The selection logic differs at each one. The diagnostic still answers the 2015 question.

Approval is a floor. Treating it as a scoreboard is how a catalog goes invisible without a single alert firing.

Product feed optimization for paid media leaves you unreadable to machines that query attributes

Fifteen years of incentives produced a very specific kind of feed:

  • Titles engineered for keyword matching rather than for description
  • Attributes populated to the minimum the validator accepts
  • Marketing copy pushed into structured fields, because the field was there

It worked, because the system consuming it was an auction matching a query string to a product string.

Retrieval systems do not work that way. When an engine handles a request for a waterproof jacket under 200 dollars with sealed seams, it filters on attributes. If your feed does not state the material, does not carry the waterproof rating, does not distinguish the sealed seam variant, the product is not ranked lower, it is excluded from the candidate set before ranking begins. No amount of persuasive copy on the product page reverses that, because the page is not what was queried.

This is where product data optimization diverges from the older discipline. The old question was which words to put in the title. The new one is which fields exist at all, whether they are populated at variant level, and whether their values are machine comparable rather than human readable.

A catalog with 12 populated attributes per SKU and a catalog with 30 are not two versions of the same asset. They are eligible for different volumes of demand.

Google’s own specification has been signaling this for years, and most teams still work to the wrong ceiling: titles accept 150 characters, descriptions accept 5,000. Feeds routinely ship with 60 character titles and empty descriptions, because the storefront theme was the source of truth.

AI Mode reads your product data. AI Overviews do not. That distinction decides where the work goes

These two surfaces are constantly conflated, and the confusion wastes effort in both directions.

  • AI Overviews: the generated text is assembled from the web index, so it responds to content, structure and authority work.
  • AI Mode and shopping carousels: the product results are assembled from Merchant Center data, so they respond to feed work.

The practical consequence is an allocation decision. If your products are absent from AI Mode, rewriting the product page will not fix it. If your brand is absent from the answer text above it, enriching the feed will not fix it either.

Two surfaces, two levers, and in most organizations two teams who currently believe they are solving the same problem.

Which is also why agentic commerce is not a future scenario waiting on consumer adoption. It is an eligibility layer being built now, on data you already own and mostly under-maintain.

Your ChatGPT product feed is a separate specification, not an export of your Google feed

The assumption that a Merchant Center export can be repurposed is the most common shortcut in this area, and the most costly. The ChatGPT product feed is a distinct specification: its own format, its own refresh expectations, its own fields, its own eligibility controls. Products that are perfectly compliant on one side can be entirely absent on the other.

More useful than the specification is what OpenAI publishes about selection. When several merchants sell the same product, it states that it weighs:

  • Availability
  • Price
  • Quality
  • Whether the merchant is the primary seller
  • Whether Instant Checkout is enabled

Read that as a ranking factor disclosure, because that is what it is. Availability and price accuracy are feed attributes. Primary seller status is an identity and identifier problem. None of it is content marketing.

Merchants pay a fee on completed purchases through that channel, and the protocol is open while the checkout experience remains restricted to approved partners. That arrangement belongs in a margin conversation. The visibility question comes first, and it is simpler: can the engine describe your product accurately enough to recommend it.

Attribute depth is the new bid

In an auction, you compensate for a weak asset by paying more. In a retrieval system there is no compensation mechanism. Either the attribute is present and the product is a candidate, or it is not and the product does not exist for that request.

That reverses the priority order most catalogs were built on:

  • Variant level identifiers stop being an administrative formality and become the condition for being distinguished from a near identical competitor.
  • Price and availability freshness stop being a hygiene task and become a selection criterion published by the engine itself.
  • Use, compatibility and material attributes stop being optional enrichment and become the fields that qualify a product for the constrained requests conversational interfaces generate.

The catalogs that suffer most are the large ones with long tails, because effort has historically concentrated on the SKUs carrying the spend. In an auction that concentration was rational. In a retrieval system it leaves most of the inventory undescribed and therefore unselectable, which is precisely the surplus a broad catalog exists to monetize.

Product feed management is a governance problem before it is a tooling problem

The recurring debate about buying a feed platform or running a supplemental sheet is a second order question. The first order question is who owns the data. In most organizations, the honest answer is nobody in particular:

  • Price sits with commerce
  • Promotions sit with trading
  • The feed sits with acquisition
  • The product page sits with content

Four functions, four roadmaps, four release cadences.

The symptom is a definition problem. Each system holds its own version of current: price accurate to the minute, page accurate to the last publish, feed accurate to the last sync. No individual system is wrong. The composite is incoherent. And when an engine reads price from one source, availability from another, and finds a mismatch, the safe decision for that engine is to select a merchant whose data agrees with itself.

Product feed management therefore starts with a single owner and a single definition of freshness, before any discussion of platform. The tooling question resolves quickly once that is settled, and rarely resolves at all when it is not.

It is also why the current API migration is causing more disruption than a technical change should. Google shuts down the Content API for Shopping on August 18, 2026. Organizations without a clear owner for that pipeline discover the dependency at the moment it breaks, rather than before.

You cannot optimize a surface you cannot measure

None of this appears in standard reporting. Conversation assisted traffic lands in direct or unassigned in most analytics configurations. AI channel reporting is aggregated, so it returns volumes rather than the requests that produced them.

So teams argue about whether the shift is real, instead of measuring which of their products are surfaced, and where.

Primelis built Outrank to close that gap: visibility measured across traditional search and generative engines, benchmarked against a competitive set, rather than inferred from traffic that no longer arrives. The principle carries over to catalogs without modification. The unit of measurement is presence on the surface, not the session that follows, because for a growing share of demand there is no session to attribute.

Measuring first also changes what gets fixed. Most catalogs do not need full remediation. They need to know which product families are excluded from which surfaces, and that is a far smaller question than it looks from the inside.

Product feed optimization is now an eligibility discipline

Approval is a floor, not a result. Feeds built for the auction are structured for matching rather than querying. The engines deciding visibility today filter on attributes your catalog may never have been asked to carry. Product feed optimization has quietly become the work of making a catalog eligible across several selection systems at once, each with its own rules and its own idea of what current means.

Across the 300 global brands and more than one billion dollars of annual media our teams manage, the pattern is consistent: the gap is never uniform. It concentrates in specific product families, specific attribute sets, specific markets. And it stays invisible until someone measures surface by surface instead of reading a diagnostic screen.

That read is where we would start, before a single euro of remediation budget is committed.

FAQ

  • What is product feed optimization?

    It is the practice of structuring and enriching product data so the systems consuming it can select and display your products. It covers titles, identifiers, attributes, pricing and availability. Its scope has widened from advertising platforms to include organic listings and AI-driven shopping surfaces.

  • Does Merchant Center approval mean my products are visible?

    No. Approval confirms your data complies with policy. It does not confirm products are being served, in Shopping, in free listings or on AI surfaces. Catalogs frequently hold an approved and eligible status while remaining absent from merchant listings entirely.

  • Do I need a separate product feed for ChatGPT?

    Yes. OpenAI operates a distinct product specification with its own format, fields and eligibility requirements. A Merchant Center export is not a substitute. OpenAI also publishes the criteria it weighs between merchants selling the same item, including availability, price and primary seller status.

  • Does product data quality affect organic visibility?

    Yes, though indirectly. Product results in AI Mode and shopping carousels are drawn from Merchant Center data rather than the web index. Generated answer text is drawn from the index. Feed quality therefore determines eligibility on product surfaces, while content work governs the answer text.