What Is a Product Feed?
A product feed is a structured file of your inventory, one row per item, carrying the attributes a shopping platform needs: identifier, title, description, link, image, price, availability and condition.
A product feed is a structured file of your inventory, one row per item, carrying the attributes a shopping platform needs: identifier, title, description, link, image, price, availability and condition. It is not a copy of your product pages. It is the machine-readable version of your catalogue, and the two can disagree without anything on your site looking wrong.
Why the feed decides what shoppers see
Google’s shopping experiences are built from Merchant Center product data, not from a crawl of your product page. If an item is missing from the feed, it is missing from those surfaces, however good the page behind it is. Rankings in organic search and presence in shopping results are two separate systems reading two separate inputs.
The failure mode is specific and expensive. A price change goes live on site, the feed refreshes tomorrow, and for a day your listing advertises a price you no longer honour. Repeat that often enough and items get disapproved rather than merely wrong. Feed work is unglamorous, continuous and rarely in scope, which is exactly why it belongs in any honest account of what ongoing catalogue work costs rather than in a one-off setup fee.
How a feed gets processed
A feed is not published so much as submitted, validated and re-validated on a cycle you control.
- Generation. Your platform builds the file from the product database, either natively, through an app, or through a middleware tool that maps your fields onto the required attribute names.
- Submission. You upload the file, host it for scheduled fetching, or push updates through an API. Scheduled fetch is the common choice and the one most likely to be quietly failing.
- Validation. Each item is checked against attribute requirements and policy. Items that fail are disapproved individually, so a catalogue can be half live without any obvious signal that something is wrong.
- Matching. Identifiers such as brand, GTIN and MPN tie your item to a known product. Weak identifiers mean weak matching, and weak matching means your item competes as an unknown object.
- Reconciliation. Product structured data on the page can be used to correct price and availability mismatches, which helps only if the markup on the page is itself accurate.
- Expiry. Feed data goes stale unless refreshed on schedule. A feed that stops updating does not throw an error on your website; it simply stops representing reality.
Step four is where catalogues with options come apart. If every size and colour is a distinct sellable item, each needs its own row, its own identifier and its own availability, which forces a decision about how variants are structured on the site itself. Feed architecture and URL architecture are the same problem viewed from two ends.
| What goes wrong in the feed | What the shopper experiences |
|---|---|
| Availability says in stock, site says sold out | A click into disappointment, and a listing at risk of disapproval |
| Price in the feed trails the price on site | A mismatch that can suspend the item or the account |
| Missing GTIN or brand on branded goods | Poor product matching and reduced visibility against competitors |
| Titles written for the page rather than the query | Fewer matches, because the title is doing most of the relevance work |
| Scheduled fetch failing silently for weeks | A catalogue slowly ageing out of every shopping surface |
The blunt version
Here is the part that reorders your priorities: for shopping queries, the feed is increasingly the thing being read, and your product page is not. Shopping results are assembled from structured product data, and as those answers get generated rather than merely listed, the structured record is what the machine has to work with. A beautifully written product page with a stale feed row behind it is invisible in that context, and no amount of on-page optimisation fixes it.
Which reverses the usual order of work. Most e-commerce SEO budgets go to page copy, internal links and category content, while the feed is treated as an engineering artefact somebody set up once. If your traffic depends on shopping surfaces, an hour spent on identifiers, titles and availability accuracy is worth several spent rewriting descriptions nobody machine-readable is looking at.
Be honest about the uncertainty too. How much weight generated shopping answers place on feed data versus crawled page data is not something anyone outside Google can measure precisely, and we are not going to pretend otherwise. What is certain is the direction: structured, current, well-identified product data is the input, and a stale feed removes you from the conversation entirely. That is the same mechanism behind why product pages go uncited while competitors with duller pages appear.
Example
Say a footwear retailer with 3,000 styles runs a nightly scheduled fetch. A developer moves the feed file during a replatform and the old URL starts returning a 404. Nobody notices, because the website is faster, the product pages rank as well as ever, and organic traffic looks stable. Six weeks later shopping-driven revenue has quietly halved while the analytics dashboard still shows healthy sessions. The feed did not break loudly. It simply stopped refreshing, the catalogue aged out, and every item continued to exist perfectly on a site nobody was being sent to. The fix took ten minutes. Finding it took six weeks.
FAQ
Do I need a feed if my product pages already rank?
If you want presence in shopping surfaces, yes, because those are built from Merchant Center product data rather than from your pages. Organic rankings and shopping visibility are separate systems. Strong pages will keep earning organic clicks and still leave you absent everywhere a shopper compares products directly.
How often should the feed update?
As often as your prices and stock levels change, which for most retailers means daily at minimum and continuously if you sell fast-moving lines. The test is not a schedule but a mismatch: if the feed can ever disagree with the site during trading hours, it is updating too slowly.
Does product structured data replace a feed?
No. Markup on the page and a submitted feed do different jobs, though they overlap. Structured data can help reconcile price and availability differences and supports product results in search. The feed remains the record shopping surfaces work from, and the two should always tell the same story.
Related terms
- Product Variant URLs — how sizes and colours are addressed on site, which dictates how they are fed.
- Out-of-Stock Page Handling — what the page should do when the availability attribute finally says no.
- Staging Site Indexing — the neighbouring accident where the wrong environment ends up representing your catalogue.
Your product page is what a person reads. Your feed is what everything else reads, and only one of those is checked weekly by anyone. Put a monitor on the feed before you commission another round of description rewrites.