A product feed is a file that lists everything you sell, one row per product, with a named field for each fact: title, price, availability, image, identifiers, category, and the attributes that matter in that category. It is not a copy of your website. It is your catalog rewritten for machines to read.
If you already know what one is and want the work rather than the definition, the optimisation guide covers what to fix and in what order. This page answers the earlier questions: what is actually in the file, who reads it, and whether you need to think about it at all.
What a feed row looks like
Abstract definitions of feeds are unhelpful, so here is one product as a feed actually holds it.
| Field | Value | What it decides |
|---|---|---|
id | CH-1042-SAND-32 | Your own reference, stable across updates |
title | Acme slim fit chino, sand, 32 | Which searches you match. The heaviest field |
description | Cotton twill chino with a slim leg… | Long-tail vocabulary |
link | yourstore.com/chino-sand-32 | Where the click lands |
image_link | yourstore.com/img/ch-1042.jpg | Whether anyone clicks at all |
price | 1490.00 TRY | Must match the page, or the item is rejected |
availability | in_stock | Whether you can fulfil what you advertised |
brand | Acme | Half of how a product is identified |
gtin | 8691234567890 | The other half. The barcode |
google_product_category | Apparel & Accessories > Clothing > Pants | Which competition you are in |
size / color | 32 / Sand | Whether you survive a filter |
Multiply that by every product you sell and you have a feed. The file format varies, XML, CSV or JSON, and the format is the least interesting part of it: what matters is which fields are filled and whether the values are true.
Note what is not in the row. There is no place for “our bestseller”, no room for the paragraph about your brand story, and no field for a promotional banner. A feed holds facts a machine can compare against another machine’s facts. Anything persuasive belongs on the page the link points to.
Where the file comes from
You almost certainly have one already, generated automatically, and this is the part most people are surprised by.
Every major store platform produces a feed from your product database, either natively or through an app. It appears at a URL you can open in a browser, and the platform refreshes it on a schedule. Nobody writes a feed by hand, and if someone is maintaining one in a spreadsheet, that is the problem to fix before any of the rest.
Which means the feed is not something you create. It is something that already exists and is already representing you, whether or not anyone has looked at it. That is the useful reframing: the question is never “should we have a feed” but “what does ours currently say”.
Two practical consequences. First, because the feed is generated from your product database, a gap in the feed is usually a gap in the database, and fixing it at source fixes it everywhere. Second, because the generation is automatic, the feed changes when your catalog changes, which is why feed problems appear suddenly on a day nobody touched the feed.
Who reads it
The list has grown, and it explains why feed quality stopped being a Shopping-only concern.
- Google Merchant Center, which is where the requirements are strictest and the only reader that reports back. Its rejections are a free data quality audit, which is why the disapproval reasons are worth reading even if you do not run Shopping ads.
- Meta, for catalog and dynamic ads. Same file, different tolerance: shorter titles read better in a feed placement, and image quality matters more.
- Marketplaces and comparison engines, each with their own required fields, which is where identifiers earn their place: without a GTIN you cannot be matched to the same product on another listing.
- Your own site search, often overlooked. The same attributes that power a channel filter power your own, and an empty size field breaks both.
- AI assistants, the newest reader and the least forgiving. The feed behind agentic commerce asks for the same fields with no partial credit: an attribute an assistant cannot confirm is a product it does not recommend.
One file, many readers, each weighting the fields differently. That is why a single missing attribute is never a single-channel problem.
Feed, catalog, product page: three words for different things
These get used interchangeably and the confusion causes real mistakes, so it is worth being precise.
Your catalog is the products themselves, as your business thinks of them: what you stock, at what price, in which variants. It lives in your store’s database and it is the source of truth.
Your product page is the catalog rendered for a person. It can persuade, it can use photography, it can leave things implicit because a human infers them.
Your feed is the catalog rendered for a machine. Nothing can be implicit and nothing can be persuasive, because the reader is comparing fields.
The mistake this prevents: treating a good product page as evidence of a good feed. They are generated from the same catalog, and a page can read beautifully while the feed behind it is missing the four fields that decide whether anyone sees the page at all.
Why the fields are so specific
The field list can look arbitrary until you see what the reader is doing with it, and then most of it becomes obvious.
A channel receiving your feed has to answer three questions about every row, in order. Is this a real, buyable product? That is what price, availability, link and image are for, and why a broken image URL is a rejection rather than a cosmetic issue. Which product is it? That is identifiers and brand, and it is why a missing GTIN excludes you from any surface that compares listings: without it, nothing can tell that your chino and another retailer’s chino are the same item. Who should see it? That is title, category and attributes, and it is where the ranking actually happens.
Read in that order, the specification stops being a checklist and becomes a sequence of gates. It also explains the fixing order: a field that answers question one is worth more than a field that answers question three, because failing question one means questions two and three are never asked.
How to look at yours
Three steps, none of which need a tool or an account.
- Find the URL. On most platforms it is in the marketing or sales-channel settings, often labelled as a Google Shopping or product feed. If you already run Shopping ads, it is in Merchant Center under the feed settings.
- Open it in a browser. It will look like a wall of XML. That is fine. Find one product you know well and read its row.
- Ask three questions about that one row. Does the title identify the product to someone who cannot see the picture? Are the attributes a shopper would filter on present as fields, rather than mentioned in the description? Is the price the same as the price on the page right now?
If one product fails those three, the same failure is almost certainly systematic, because the row was generated by the same template as every other row. That is the good news about feed problems: they are rarely individual.
To see the pattern across the whole catalog rather than one row, the free feed analysis runs more than thirty checks per product and grades the result A to F. It is read only and takes about two minutes, and the point of it at this stage is a baseline rather than a fix list.
Frequently asked questions
Do I need a product feed if I do not run ads?
You already have one, so the question is whether to look after it. The case for doing so without ads: the same data drives marketplace listings, your own site search, the structured data on your product pages, and whether an AI assistant can describe your products. Ads are the most visible reader, not the only one.
What format should it be in?
Whatever your platform produces, usually XML. This matters far less than people expect: every major channel accepts more than one format, and no channel rewards you for choosing a particular one. Effort spent on format is effort not spent on the fields, which is where the outcome is decided.
How often should it update?
Price and availability as close to real time as the platform allows, because those are the two fields where being out of date gets products rejected rather than just ranked lower. Everything else can be daily without anyone noticing.
What is the difference between a feed and a supplemental feed?
The primary feed is the full catalog. A supplemental feed adds or overrides specific fields on products already in it, matched by id. It is useful when you cannot change the source: you can improve titles or fill in missing attributes without touching the store. It cannot add products, only enrich the ones already there.
Where do I go from here?
If your feed reads well on the three questions above, the next step is measurement rather than more reading. If it does not, the optimisation guide takes the fields one at a time and puts them in fixing order, and feed management is what doing that continuously looks like.
Pingback: Product feed optimization guide - Verintra Digital