The product feed has historically been firmly in the domain of PPC teams, and for good reason. After all, for decades, feeds have been the basis for Shopping and the Paid side of this equation is where the biggest spend and revenue sit.

For an SEO, it was enough to check Google Search Console Shopping Results, and Bob’s your uncle.

Not anymore.

Product feeds have (not so) quietly become one of the most structurally important data assets in ecommerce – for paid, organic, and now agentic. They shape how Google interprets product pages across channels, how discrepancies between different product and category points get resolved, and increasingly, how AI evaluates and surfaces products to users.

The feed has outgrown single-team ownership because its surface area has expanded. And, SEO teams have been largely absent from the conversation.

The irony is hard to ignore: The industry is obsessing over duplicating our websites in markdown and llm.txt files while neglecting the one asset Google explicitly calls out in their new generative AI search guide as critical for product visibility in AI responses –  the Merchant Center (and by extension the feed).

This piece is about why that needs to change, what happens when we keep to the status quo, and what it looks like to put it into practice.

The Unholy Trinity: 3 Systems, 1 Goal

At last year’s Search Central Live, Google had a running joke about this. You add a standard to unify the standards, only to end up with an even bigger mess.

Rather than one unified system for understanding your products, Google is actually managing three distinct layers of data that have different rules, different structure, and, of course, different teams managing them on the organizational end.

First, you have the Product Feeds. These are the manual files you push to:

• The Google Merchant Center (GMC) contains your core attributes like titles, GTINs, and prices.
• The Manufacturer Center containing richer, more detailed product information

This is a parallel data structure that exists entirely independently of your website.

Next is the on-page structured data. This is most commonly JSON-LD markup tucked away in your code, designed mostly as a point of feed verification but also directly powering some of the ecommerce rich results. And, schema.org is also not the only player in town here. This came up repeatedly at Search Central Live last year, where Google explicitly referenced GS1, UN/CEFACT, and other ontologies.

Finally, there is the Website itself. This is the actual rendered page that a human sees or the machine-readable version that an agent sees, which it verified against the other two sources.

The friction comes from the fact that these systems play by different rules and are read differently by humans and machines.

Google is well aware that this setup is a headache. Back in 2024, they even discussed the possibility of unifying schema markup and feed data to simplify how merchants provide information. The goal was to move toward a more integrated processing system.

Until that unification actually happens, you are stuck managing three separate layers. And, that’s the issue.

Time and again, we see brands with feeds in complete disarray with schema that says something completely different and a website that contradicts both. This then forces Google (and agents) to make a judgment call.

Usually, that call doesn’t go in your favor.

Accuracy across all three isn’t just a “nice to have” anymore; it is the baseline for being discoverable and purchasable. And, a lack of harmony between them can sink your business results.

When It All Goes Wrong

Anyone working in ecommerce has seen a long list of issues that arise from this unholy trinity.

Some are easier to fix than others because they fall into a shared mental load between the teams. One excellent example of this is feed product titles. Time and time again, PPC managers use SEO-optimized titles to tweak their product feeds using rules or supplemental feeds. They understand that the SEO team has spent hours doing keyword research and tweaking the meta to fit search intent.

That kind of informal knowledge-sharing works well when the asset already sits within both teams’ remit.

When a PPC manager sees a disapproval spike, their diagnostic instinct naturally goes to feed attributes, quick website check, bid strategy, policy violations … all within their domain. And, that’s not a failure of skill; it’s a failure of scope. More often than not, they fix what they can see, escalate what they can’t to dev, and SEO never gets the call. Not because the structure failed, but because no single channel team has visibility across all three by default.

To illustrate the point, here are two recent examples from my agency of how this plays out in practice.

Schema, Feed & Website Misalignment

There are attributes that are nice to have and can help your products perform better on organic and paid listings.

For example, let’s say you are an ecommerce shop that also sells striped women’s dresses. On those products, you could use g:pattern in your feed and an equivalent Pattern Schema.org Property within Product schema type. Adding it to both might help you a bit when appearing for searches such as [striped women’s dress]. Or you might appear for those searches anyway. It’s likely that your website or feed/schema titles have some data on the pattern in the text anyway. Your products definitely won’t get disapproved in the GMC if you skip adding them to the feed or the schema.

Price is not one of those nice-to-have fields. It is an essential attribute in your feed, markup in your structured data, and information point on your website.

Recently, we have noticed across several ecommerce clients how much Google is cracking down on this. Products being disapproved in GMC left, right, and center because of the mismatch in price between the three layers.

One such example is our client working in office furniture, whose products started to be disapproved en masse recently.

Products like this one, where the website said £34.80, the price in the main feed was £34.80 GBP, and the Merchant decided the price was £33.54.

And, when we looked at the schema, we were faced with a 4th price of £29.

The schema markup on product pages was outputting the ex-VAT price rather than the inc-VAT final price, along with a priceValidUntil field.

Google uses schema to verify and sometimes overwrite feed prices via automatic item updates, which is why the wrong figure was showing in GMC and why all those products ended up on the disapproved list.

This is the kind of issue that only surfaces when someone has visibility across both systems.

And, this is an easy one to spot! Things get even more complex with fields that don’t have a direct schema equivalent or have different rules.

For example, fields such as availability.

In a GMC feed, Google accepts four standard values:

• In_stock
• Out_of_stock
• Preorder
• Backorder

Both preorder and backorder require an availability_date attribute –  the expected date the product will ship or be available.

On the schema.org side, the equivalent is the availability property on an Offer, which uses a different vocabulary:

and so on. If you’re managing these separately – feed in one team, schema in another – the chances of a mismatch are high.

Navigating the Variant Gap (item_group_id vs ProductGroup) is another example here and likely one of the most complex areas to align. Largely because feeds and structured data handle them through completely different architectures.

In a Google Merchant Center feed, product variants are submitted as a flat list, tied together by a shared item_group_id. On-page schema requires complex, nested parent-child relationships using the ProductGroup schema, alongside properties like hasVariant and variesBy.

Because an ecommerce site might have a feed that is massively larger than its indexable product pages, variant mapping will break down if the PPC team manages the flat feed while the SEO team builds the nested schema in isolation.

Infrastructure Failure

Price mismatches and schema conflicts are frustrating, but at least they’re visible. You can audit them, find the discrepancy, and fix it.

An infrastructure failure is different and, in some ways, more alarming because everything in your data can be perfectly aligned, and products will still disappear.

In one recent case, we saw a client’s products move from approved to not approved at scale almost overnight. The feed was fine. The schema was fine. The website was fine.

But a configuration change to the client’s CDN security settings had inadvertently begun blocking Google’s crawler. Bot protection rules, designed to defend the site, were treating Googlebot as a threat. With the website layer inaccessible, Google couldn’t verify it against the feed and schema data it already held, and with that verification broken, products were pulled.

While the fix was pretty straightforward, identifying the cause was definitely not. A PPC manager would have seen the disapproval. But, only someone thinking across crawl behavior, feed health, and site infrastructure simultaneously would have found the root cause.

SEO Case For Shared Feed Ownership

The old logic was simple: Merchant Center is primarily Paid Shopping, Shopping is PPC, therefore the feed is a PPC problem. This type of thinking is increasingly outdated.

Merchant Center handles paid and free listings, feeds impact rich results, the Google Shopping Graph, and now agentic ecommerce. It’s the infrastructure for your entire product presence. But infrastructure is only as good as the data running through it, and right now, too many feeds are riddled with issues.

Shared ownership isn’t a redistribution of credit. For PPC teams, it means fewer disapprovals to firefight, cleaner attribute data to optimize against, and a diagnostic partner.

SEOs need to be in the room when decisions are made because:

Feed Data Is Written For Databases, Not For Searchers

When SEOs aren’t involved in feed management, the feed stays as whatever the platform exports. And, that’s not always driven by search behaviors. Way too often, what the various feed plugins spit out are generic titles, approximate categorizations, and thin attributes.

This is the failure that doesn’t show up in the Merchant Center.

At best, PPC teams are quietly patching this with feed rules or supplemental feeds, both legitimate tools in the right context, with their own optimization logic, but neither designed to compensate for a primary feed that was never built with search intent in mind.

The feed is technically healthy, but if not dealt with,  it’s also commercially invisible.

Treating the feed as a search asset rather than a data asset means front-loading titles with high-intent keywords, refining taxonomy so products aren’t buried under generalized categories, ensuring attribute depth matches how customers actually filter and query, and maintaining the kind of ongoing hygiene that stops ghost products quietly disappearing from results.

These are things SEOs do instinctively elsewhere; they just rarely get asked to apply them here.

Structured Data Is The Hidden Variable Across Paid, Organic & Free Listings

When our clients’ price mismatch surfaced, my PPC team could see the disapproval. What they couldn’t see was why, because the answer was in the schema, and schema isn’t a PPC domain.

The blast radius also doesn’t stop at paid. The same schema error affects free listings, where Google pulls directly from GMCIn a GMC feed, Google accepts four standard values and applies the same validation logic.

And it affects organic rich results – price, availability, review count appearing in standard SERPs – which are driven by on-page structured data and carry no disapproval mechanism to flag when something is wrong. Incorrect information just surfaces silently.

I found this because I was in the room. If SEO isn’t co-owning the feed, there’s no reason anyone ever looks at the schema when paid goes wrong. And, no reason anyone connects the dots to what it’s doing to free listings and organic rich results at the same time.

Feed Quality Is Increasingly A Signal, Not Just A Campaign Requirement

Google has been explicit that Merchant Center feed quality affects more than Shopping ad eligibility. The overall health of a Merchant Center account (things like: disapproval rates, missing attribute warnings, policy compliance…) contributes to how Google evaluates a merchant’s trustworthiness as a data source. A feed with widespread attribute gaps or recurring disapprovals is a signal about data quality at scale, affecting eligibility and display across all Google surfaces. The feed is being read as a proxy for how reliable you are as a data source.

Google has also formalized this through the Shop Quality program, which evaluates merchants against each other across signals, including approval rates, shipping data completeness, and return policy clarity. Performing well here has a direct, visible impact on listings, with the Top Quality Store badge appearing on placements in both paid and organic results. This makes account health a competitive factor, not just a compliance one.

The Shopping Graph layer makes this even more consequential. The Shopping Graph now contains more than 50 billion product listings and feeds directly into AI Overviews, AI Mode, and Gemini. How reliably Google can verify and trust your product data determines your position within that graph.

To put it simply, consistency across structured data, landing pages, and Merchant Center feeds is what helps Google trust what it sees, and trust is the difference between an eligible, compelling listing and one that underperforms.

The Organic Stakes Are Changing

Organic Shopping has never been invisible to SEOs. We’ve worked on optimizing for organic shopping using strategies such as structured data and on-page elements, and reported on it via Google Search Console. We just didn’t pay much attention to the Merchant Center or the feed. And yet, this is what also powers those results.

SERP itself is also quietly restructuring around us.

The severity of this shift is brilliantly illustrated by ecommerce SEO expert Brodie Clark, who notes that Google’s search results are increasingly feeling like a product detail page in their own right. Rich results like visual product grids that take up prominent SERP real estate are cannibalizing branded search terms, particularly for brands stocked by major third-party retailers. The issue is compounded on mobile, where they can take up several scrolls before a brand’s own category pages appear at all.

This makes the feed an increasingly important data source behind a larger share of the commercial SERP.

Agentic Commerce Changes What ‘Discoverable’ And ‘Purchasable’ Mean

This is the part that’s easiest to underestimate, and where the stakes of feed neglect shift from significant to structural.

Discovery Is No Longer Only Human-Led

AI-powered surfaces like AI Overviews increasingly draw on Merchant Center data to surface products in response to commercial queries. A product with thin feed attributes and minimal structured data starts from a significant disadvantage at the discovery phase. Not just in Shopping, but in the AI layer being built on top of it.

This is no longer speculative. Google’s UCP documentation states explicitly that merchants should use their existing GMC account shopping feeds to capture high-intent customers during discovery, with UCP unlocking access to surfaces like AI Mode in Search and Gemini.

Google is already extending this further by introducing conversational commerce attributes in Merchant Center, such as compatibility, substitutes, related products, specifically designed to feed AI modes and reduce hallucinations.

Purchasability Is A Technical Problem, Not A Content One

Visibility is also only half the problem. If an AI agent then attempts to actually buy that product, it relies on a machine-readable representation of your site – the raw HTML, the accessibility tree, and rendered screenshots.

The accessibility tree is particularly interesting here. Your tree is a high-fidelity map distilling the page into the roles, names, and states of interactive elements. Non-semantic HTML,  i.e.,