Product Feed Controls on Meta and Google: What Changed in 2026

Your Meta ads ran all the way through October without anybody editing them. Then, on 28 October, a tap on one of them started opening a product page Meta assembled from your catalog, built out of whatever happened to be in your feed that morning. Your Google Shopping ads went through the same kind of handover back in April, when AI Max for Shopping began writing ad text out of feed attributes most brands have never filled in.

No campaign changed. Nobody logged in. The product feed quietly stopped being a list of things you sell and became the thing that decides what the ad says and where the click lands. Product feed controls on Meta and Google are campaign controls now, not catalog housekeeping.

That's a problem because one catalog usually feeds three platforms at once, and in most brands three different people own the three exports. If you're running Amazon alongside Meta and Google, our Meta and Google ads management starts at the feed before it touches a campaign, for exactly this reason. Catalog and attribute work is also what put Sparkle on page 1 for 500,000+ monthly searches on Amazon. Same product data, different surface. If you want somebody to read yours before Q4 closes, book a teardown.

Product feed controls in 2026: what changed, and when

Three platforms, three different dates, one direction of travel.

Platform	What the feed now controls	When
Google Shopping	Ad copy and landing page, generated from feed attributes by AI Max for Shopping	Announced 30 April 2026
Meta	The destination itself. Product browsing opens an in-app product page built from the catalog	Switched on for running ads from 28 October 2026
Amazon	Relevance and retrieval, through structured listing attributes	Years. Nothing changed here, which is the point

Google: the feed writes the ad now

Google announced AI Max for Shopping on 30 April 2026. It bundles three things: text customization, which generates ad copy matched to conversational queries, Final URL Expansion, which sends a shopper to the most relevant page on your site rather than the one you nominated, and Optimal Format Selection, which decides whether a text ad or a Shopping ad has a better chance on a given query.

All three read the Merchant Center feed. Google's own announcement names attributes like fabric softness, material durability and fit as the kind of detail the system uses to work out what a product actually is. Existing Shopping advertisers can turn the whole thing on in one click, and Final URL Expansion can be switched back off, which restricts delivery to Shopping ads again.

Read that as an operator and the implication is uncomfortable. An empty attribute used to mean a slightly worse match. It now means a sentence your ad never says. The brands with thin feeds aren't getting worse ads than they used to get, they're getting ads written from less information than their competitors handed over.

The field-by-field work on the Google side is its own job, and we've written it up separately in our Google Shopping feed optimization playbook. This post is about what happens when that same data has to serve two other platforms that have started making their own decisions with it.

Meta: the catalog became the landing page

From 28 October 2026, Meta began switching product browsing on for ads that were already live, unless the advertiser opted out before the deadline. With it on, a tap can open a product page inside the Meta app, assembled from your catalog, with other products from your catalog suggested alongside it. The visitor may never reach your site at all on that first tap.

Be careful with this one, including with this post. The 28 October date and the default-on behaviour are reported consistently across a lot of independent agency coverage, and we could not find either stated on Meta's own help pages. The opt-out button in the original in-product notice is also reported to have stopped working once the date passed. So treat the detail here as a prompt to go and look, not as documentation. The setting lives per ad, with the Advantage+ creative and destination settings in Ads Manager. Open one of your running ads and check what it says rather than trusting any blog on the subject.

The product-level controls on Meta are not where people look for them

Two things surprise brands here. The product-level filter is the product set, not a rule in Ads Manager, so excluding a product means excluding it from the set the campaign draws on. And eligibility runs through catalog fields: availability in the catalog is what decides whether an item can serve, which is why a stale availability value shows ads for something you can't ship.

Neither of those is new in 2026. What's new is the cost of getting them wrong, now that the catalog is also the page the shopper reads.

Amazon didn't change, and that's the useful part

Amazon has worked this way for as long as anyone reading this has sold on it. Titles, bullets, backend terms and structured attributes are what the retrieval system actually reads, and a product with a blank attribute simply doesn't come back for the query that depended on it. Brands accept that on Amazon without arguing about it.

So the honest way to describe 2026 isn't that Meta and Google changed. It's that Meta and Google arrived at the model Amazon has used all along, where the product record is the campaign input, and the clever targeting sits on top of whatever the record says. If you've already done the discipline on Amazon, you have most of the answer. You just have it in the wrong system.

Why one catalog across three platforms breaks

Across our client portfolio the shape of this is almost always the same. There's one real source of product data, usually a PIM or a Shopify export. Then there are three derived feeds, each transformed by a different tool, each with its own mapping rules, and each last audited by a different person on a different date. The Amazon flat file gets attention because somebody owns the Amazon number. The Merchant Center feed gets attention when disapprovals spike. The Meta catalog gets attention almost never, because until recently it only had to produce a thumbnail and a price.

What follows from that is predictable and still catches people out:

• A title written for Amazon's character limit reads as keyword soup when Google generates ad copy from it.
• A product excluded on Amazon for margin reasons stays in the Meta catalog, so the cheapest thing you sell becomes the suggested product next to it.
• An availability value that's fresh in one feed and three days stale in another means Meta is quietly selling what Amazon already marked out of stock.
• Variant structure that's correct for Amazon's parent and child model collapses into near-duplicate rows in Merchant Center.

What to fix first

In rough order of return, assuming a catalog in the hundreds to low thousands of SKUs:

1. Reconcile availability across all three feeds on the same day. It's the cheapest fix and the one that stops you paying for ads on things you can't fulfil.
2. Check which products your Meta catalog can actually show. Not which ones you meant to show. Pull the product set the campaign uses and read it.
3. Fill the attributes Google names. Material, fit, dimensions, intended use. These were optional when the feed was a display surface. They're copy inputs now.
4. Decide whether your Amazon titles should be your Google titles. Usually they shouldn't. Amazon titles are written for a retrieval system that rewards specificity over readability, and Google is now reading yours as source material for a sentence a human will see.
5. Go and look at what product browsing does to one of your Meta ads. Then decide. Don't decide first.

Where this goes wrong

Feed work has a ceiling, and it's worth saying so. If your unit economics don't work, a clean catalog makes you lose money more efficiently. If you have 40,000 SKUs, reconciling three feeds by hand isn't a project, it's a headcount decision, and the right answer is probably a feed management tool rather than a person.

Product browsing is the one we'd argue about internally. Keeping a shopper inside Meta's app removes a page load and a form, and for some brands that genuinely converts better than a cold landing page does. Turning it off because it happened without permission is a reflex, not an analysis. The case for switching it off is specific: you need the site visit for retargeting, or your product pages do work the catalog can't reproduce, like sizing guidance or bundles. If neither applies, the honest answer is to test it.

And the measurement problem is real. A tap that resolves inside Meta's app is a weaker signal back to your own analytics than a site visit is, so some of what you'll read as a drop in traffic is a change in where the session happens, not a change in demand. We've watched brands cut a working budget over exactly that kind of reporting artefact.

Who should own the feed

One person, and not the person who owns the channel. The moment catalog data is owned per channel, it drifts per channel, and the drift is invisible until a platform makes a decision with it. One owner, one source of truth, three mappings they can both explain and audit.

That's the argument for running the channels together rather than hiring three specialists who never meet. Not that cross-channel is fashionable, but that there's now exactly one asset underneath all three platforms and it can only have one owner.

If your Amazon catalog is in good order and your Meta and Google feeds are derived from it by somebody who's never sold on Amazon, you already know which end of that is going to break. We'd start there, and we'd start with the channels that are reading your feed hardest.