Product feed optimization is the work of making your catalog data good enough that the systems reading it can match, rank and recommend your products. Not the ad campaign, not the landing page: the data underneath both. This guide covers what actually gets checked, in what order to fix it, and how to tell whether the work paid off.
It is written for someone who already has a feed running and suspects it is holding them back. If you are not sure whether that is you, the fastest answer is a free feed analysis: it grades the catalog A to F in about two minutes without changing anything.
What a product feed is, and what it is not
A product feed is a structured file listing every product you sell, one row per item, with a defined field for each fact about it: title, description, price, availability, identifiers, category, image, and whatever attributes the category needs. It is not a copy of your website. It is the version of your catalog written for machines.
That distinction is the whole reason this work exists. On your product page, a shopper reads a paragraph and infers that the jacket is waterproof. In a feed, if there is no field saying waterproof, nothing is waterproof. The prose is invisible to the systems that decide which listing to show.
The same file feeds more surfaces every year. It started as a Google Shopping requirement. Now the same data drives Meta catalog ads, marketplace listings, comparison engines, on-site search, and increasingly the structured product data an AI assistant reads when someone asks it to recommend something. One file, many readers, each weighting the fields differently.
Which means a gap in the feed is never a single-channel problem. A missing size attribute costs you a Shopping match, a Meta catalog placement, and any chance of appearing when an assistant is asked for something in that size.
The fields that decide whether you get matched
Feed specifications run to dozens of fields. In practice a handful carry almost all the weight, and they are the same handful across every channel.
Title. The most heavily weighted field there is, and the one most often written by whoever added the product. It has to identify the item, not describe it. Brand, product type, then the distinguishing attribute a buyer searches on, is a structure that works in most categories: “Acme slim fit chino, sand, 32” rather than “Stylish and comfortable trousers”. Front-load the words people type, because titles are truncated in most displays and the tail is what gets cut.
Description. Less weighted than the title for matching, and still worth writing, because it is where the long-tail vocabulary lives. The failure mode here is uniformity: supplier copy pasted verbatim means your description is identical to thirty other retailers, which earns none of you anything.
Identifiers. GTIN, brand and MPN are how a system knows that your listing and someone else’s are the same physical product. Without them you are excluded from comparison surfaces entirely, and in Google’s case a missing GTIN on a product that should have one is a common disapproval reason rather than a soft penalty.
Category. Google’s taxonomy runs to more than 5,500 categories. Picking the right branch is not administrative tidiness; it decides which query set your product competes in. A jacket filed under a generic apparel node competes with everything, which is the same as competing with nothing.
Attributes. Size, colour, material, pattern, age group, gender, condition. These are what filters run on, and a filter is how a shopper narrows a hundred results to five. If the attribute is missing you are not in the five.
Price and availability. The two fields where being out of date is worse than being incomplete. A price in the feed that disagrees with the price on the page is a disapproval on every channel that checks, and they all check.
How to find out what is actually wrong
Before optimising anything, measure. Three sources, in increasing order of usefulness.
Merchant Center diagnostics. Free, already running, and the only one of the three that tells you why a specific product was rejected. Read the Diagnostics view rather than the dashboard count: it groups every disapproval by reason with an affected-item count, which turns “four hundred products are disapproved” into one fix rather than four hundred. The six reasons that cause most disapprovals and where to find them are worth reading in full.
Your own spreadsheet. Export the feed and count blanks per field. Unsophisticated, free, and it answers the one question diagnostics cannot: how many products are missing an attribute that no channel has flagged yet, because no channel requires it and every channel rewards it.
A grading tool. What this adds over a spreadsheet is ranking. Knowing that 412 products have no GTIN is a number; knowing that fixing those 412 matters more than the 900 with thin titles is a decision. Feed management is largely the business of making that ordering, and Verintra’s scan runs more than thirty checks per product and returns the findings ranked by revenue impact rather than by row count.
Fix in this order
The order matters more than the individual fixes, because the first two tiers change what is possible and the last one is polish.
- Anything that makes a product invisible. Disapprovals, missing required fields, broken image URLs, products absent from the feed entirely. A product that is not in the auction cannot be optimised. This tier is usually a handful of systematic causes.
- Anything that decides which queries you match. Titles, category assignment, identifiers. This is where the ceiling on your performance is set, and it is the tier most accounts skip because it is the least visible: nothing is broken, you are simply competing for the wrong things.
- Anything that decides whether you win the match. Attribute completeness, image quality, description depth, promotional fields. Real gains, and only after the first two tiers are done.
Within each tier, order by revenue at risk rather than by count. A hundred disapproved accessories and ten disapproved bestsellers are not the same problem, and no channel’s reporting will rank them for you: you have to join the issue list to your own sales data. This single reordering is usually the difference between a productive afternoon and a busy one.
Fix the feed, not the source
There are two ways to correct feed data and the difference matters more than it sounds.
At source means editing the product in your store’s admin. Correct in principle, and slow in practice: it needs whoever owns the catalog, it does not scale past a few dozen products, and for anything derived (a title assembled from fields) it means changing a template that affects everything.
At the feed layer means transforming the data on its way out, leaving the store untouched. Rules rather than edits: if the category is chinos and the title has no size, append the size field. One rule, applied to every product that matches, re-evaluated on every sync.
The layer approach wins on everything except one thing: your store still holds the wrong data, so any channel not going through the layer still gets it. In practice that argues for doing both, in this order: rules first because they work today, source corrections afterwards as the permanent fix, with the rule removed once the source is right.
This is why Verintra never writes back to your source feed. Replacements are held in separate fields and layered on at export, so nothing is destructive and you can compare the before and after on the same product.
Where AI assistants change the requirements
An assistant asked to recommend a product does not open your website. It answers from structured data, and that shifts two things about feed quality.
Attribute completeness stops being an optimisation and becomes a gate. In Shopping, a missing attribute costs you match quality and you still appear somewhere. In a generated answer there is no somewhere: if the assistant cannot confirm the boot is waterproof in size 42, it recommends one it can confirm. There is no second page.
Consistency starts to matter on its own. When the product name reads one way on the page, another in the feed, and a third in your structured data, a system that has to pick usually picks neither. Agreement across surfaces is a signal in itself.
Two honest caveats. First, you cannot currently measure traffic from AI answers in your analytics, so any confident number for it is an estimate. What you can measure is whether the data is readable. Second, the formats are still moving: the OpenAI ACP product feed is worth understanding as a direction of travel rather than a specification to freeze against.
How to tell whether it worked
Feed work is easy to do and easy to not measure. Four numbers, read weekly.
- Approved product count. The floor. If it drops, stop everything else until you know why.
- Impressions per product, not total impressions. Total impressions rise when you add products; per-product impressions rise when the data got better.
- Share of products getting any impressions at all. Most catalogs have a long tail that never surfaces. Moving that share is what feed work is for, and it is invisible in a channel-level report.
- Attribute completeness per required field. The leading indicator. It moves the week you do the work, weeks before revenue does, which makes it the only one of the four that tells you early whether the effort is landing.
One trap worth naming: do not read a week-on-week revenue change as feed performance. Feed changes propagate over days as channels re-crawl, seasonality moves more than most fixes do, and attributing a good week to yesterday’s title rewrite is how teams learn the wrong lesson. Compare per-product metrics across a longer window.
Frequently asked questions
How often should the feed be updated?
Price and availability as close to real time as your platform allows, because those two are the ones where being stale gets you disapproved. Everything else can be daily. If you are choosing where to spend engineering effort, make availability fast before you make anything else fast.
Does feed optimization help organic search too?
Indirectly, and more than most people expect. On most stores the product title, description and attributes come from one database, so the same data renders the product page and populates the feed. Improving it improves both, which is why feed work is usually the highest-leverage thing available to an e-commerce site: one fix, two channels.
Can I do this without a tool?
Up to a point, yes. A spreadsheet and Merchant Center diagnostics will get you through the first tier on a catalog of a few hundred products. What breaks down is scale and ranking: at several thousand products, counting blanks by hand stops being viable, and knowing which of six thousand issues to fix first is not something a spreadsheet answers.
Where should I start?
By measuring, not by fixing. Get a grade on the catalog as it stands, so you have a baseline and a ranked list rather than an instinct. The free scan is read only and takes about two minutes, and if you would rather have someone run the whole exercise on your catalog, that is what the consultancy side does.
