Google Shopping feed setup: requirements, refresh and fixes

Feeding Google Shopping means sending Google Merchant Center a product feed: one row per sellable variant, with the id, price, availability and other attributes Google matches against searches.

The costly errors aren’t the syntax ones Merchant Center flags for free; they are stale prices and stock. With a once-a-day fetch, a changed price stays wrong in Google for 12 hours on average: half the refresh interval, for changes made at random times.

Which attributes does a Google Shopping feed need?

A Google Shopping feed needs at least an id, title, description, link, image_link, price and availability for every product, plus brand and gtin for most branded goods.

A feed is a table: each row is one sellable variant, each column an attribute with its own rule. Fill a cell wrong and the row either fails approval or matches searches it shouldn’t.

For how the feed fits between your shop, Merchant Center and Google Ads, see how a Google product feed works.

The limits come from Google’s product data specification, which also lists the extra attributes for apparel, such as size, colour, gender and age group. Books, films and music are the exceptions to the brand requirement.

Which attributes cause the most disapprovals?

Brand and GTIN gaps block approvals on branded goods faster than any other attribute, so audit those first. A product that has no manufacturer GTIN is declared with identifier_exists set to no; where a GTIN does exist, sourcing it from the manufacturer is the better fix.

The id causes the quietest damage. Keep it identical across every export: regenerate it and Google reads a brand-new item, splits the product’s history and can serve the same product twice under two ids.

Before the first upload, export your products, count the blanks in each column of the table and fix the biggest count first. On branded goods, brand and GTIN blanks usually outnumber everything else combined.

What makes a title and category match the right searches?

Titles do the matching. Lead with brand, product type and the attribute shoppers type, so “Acme Trail Runner Men’s Black Size 10” beats a line about grip; the field takes 150 characters, but an ad shows far fewer. Google Shopping title optimisation has the patterns per product type.

The google_product_category decides which comparison set a product competes in. When the categories have drifted, fix misclassified products in your feed before you scale spend behind them.

How should the feed reach Merchant Center, and how often?

A scheduled fetch suits most shops, and the Merchant API suits products whose price or stock changes several times a day. The delivery method sets a ceiling on how fresh the data in Google can be, so choose it by how often your prices and stock move.

The fetch is the default because nobody has to remember anything on a busy Friday: you publish a file at a stable address and Google pulls it on a timetable.

A file upload is fine for 40 products and a liability at 4,000, because it depends on a person. The Merchant API, which replaced the Content API for Shopping, updates one product at a time: the only workable answer when a promotion moves prices several times a day.

What does a slow refresh cost?

A slow refresh costs every click bought at a price the shop no longer charges, and the exposure grows with the gap between fetches: the worst case is the full interval.

Show the dataHide the data

How long a price change stays wrong in Google

Feed refresh	Average hours wrong	Worst case, hours
Once a day	12.0	24.0
Twice a day	6.0	12.0
Four times a day	3.0	6.0
Every hour	0.5	1.0

For example, a flash sale drops a jacket from €89.00 to €60.00 at 09:00, and the daily fetch ran at 06:00. Until 06:00 the next day, the ad shows €89.00 next to competitors’ prices while the page says €60.00, so the sale wins fewer clicks than it should and Google can flag the mismatch.

Raise a price instead, and every click in that window arrives expecting the old, lower one.

An approved product with a wrong price costs more than a disapproved one. The disapproved product stops spending; the stale one keeps going. If you’re weighing per-product updates against a scheduled file, the Merchant API guide for 2026 covers the setup and the developer time involved.

How do you build and submit the feed?

Build the feed from a clean export, freeze the ids, fill the required attributes, connect the variants, then submit a small test batch before the full range.

Take a realistic case: a 2,000-variant apparel shop with sizes and colours, prices that move during sales and a team that keeps adding styles. That range breaks naive setups; the sequence below survives it.

Why submit a test batch first?

A test batch of 10 to 20 products finds a mapping error before it spreads to the full range. Pick them from the messiest part of your products on purpose: a style with many variants, a product without a GTIN, an item that sells out often. If those go active cleanly, the rest will follow.

Finding a systematic mapping error across 20 rows costs an hour. Finding it across 2,000 costs a week of lost impressions. So a test batch must be active, with no critical issues, before the full upload.

How do you fix disapprovals and warnings?

Fix Merchant Center issues from the item-level diagnostics, worst first by number of affected products. A disapproval stops a product from serving at all. A warning lets it serve with limits, which is often the costlier state, because the product keeps drawing impressions it converts badly.

Item-level diagnostics name the exact attribute and the exact product, while an account-wide approval percentage tells you almost nothing you can act on. Sort by affected items and work down:

The full list, by Google’s own issue names, is in Google Merchant Center errors and their fixes.

Why does one change flag hundreds of products?

One root cause flags every product that shares it. For example, a shop changes how it shows tax on its product pages, and overnight 300 products are flagged for a price mismatch.

Opening 300 product records is the instinct; the fix is one field: include tax in the feed price as the page does, rerun the feed and let the next processing run clear the batch.

Most data issues clear on the next processing run after a correct resubmission. Policy reviews take longer, often several days, so fix the data issues next to a policy flag without waiting for it.

Clicks are scarce. Google Shopping ads had an average click-through rate of 0.86% in 2023, according to Semrush’s compilation of Google Ads statistics, which cites WordStream. Every impression spent on a broken or mismatched variant is one the right product didn’t get.

Do your products serve before you increase budgets?

An approved product isn’t necessarily a serving product: it can be error-free and still not eligible, and only Google Ads’ product reports show it.

There are two. The Shopping product report shows the current state of every product in linked Merchant Center accounts, including items that have never served.

The Shopping performance view holds the history of products that did serve: item id, brand, category, condition and custom attributes, with impressions, clicks, cost and conversions, as Google’s Shopping ads reporting documentation explains.

Run four checks before you increase budgets:

1. Count what’s active. Compare active products with the number you submitted. A gap of a few dozen across variants usually means orphaned size rows.
2. List the products that don’t serve. Read the reason for each and group them; they usually come down to two or three root causes.
3. After two weeks, compare spend and sales per product. Sort clicks and cost by item id and find the products drawing spend without sales.
4. Test changes per product. Google publishes no general lift from complete attributes, so judge a change with a controlled test, not a hunch.

The stakes rise with scale. Advertiser spending on Google Shopping ads, standard Shopping and Performance Max together, rose 16% year on year in Q3 2024, per Tinuiti’s Q3 2024 Digital Ads Benchmark Report.

By the end of 2024 more than 95% of retail advertisers running Shopping ads had adopted Performance Max, per Tinuiti’s Q4 2024 report.

Step 3 is where doing it by hand stops scaling: across thousands of variants, nobody compares cost and sales per product every week. Product Segmentation does it with machine learning on profitability, stock, product returns, potential and competitor prices; clicks are only one signal.

Segments update in real time over a window of 7 to 365 days (30 by default), and each product’s segment goes back to Merchant Center as a custom label through a supplemental feed.

How do you keep the feed accurate over time?

Keep identity and state apart: one clean primary feed for what a product is, and a supplemental feed or API updates for what changes daily. Merchant Center merges the supplemental rows onto the primary ones by id, so labels and prices can change without touching the record underneath.

A sale price then changes one row in the state layer, while the identity row, and the product’s history, stay untouched.

Four habits keep the two layers clean:

1. Map SKU to id the same way every time. One internal key maps to one Merchant Center id, with no transformation that breaks when someone edits a title.
2. Never let a state change rewrite identity. A price update that also regenerates the id or the item group restarts the product’s history, and promotions and custom labels belong in the state layer.
3. Run automated checks daily. Look for missing required attributes, invalid GTINs, inconsistent variant values, broken image or landing-page URLs and feed-to-page mismatches, before Google finds them.
4. Fix the affected rows, don’t reload everything. After each submission, read item-level diagnostics and correct only the affected products. Replacing the whole feed to fix 40 rows is how new errors get in.

For changes you want Merchant Center itself to make while it processes the feed, such as filling a missing brand or building a label, see Merchant Center feed rules.

Which feed numbers should you watch every week?

Watch four numbers weekly: item-level disapproval rate, stale-price rate, stale-stock rate and time to correction. They describe the products you’re actually running; an account-wide approval percentage doesn’t, and Google publishes no benchmark for it.

For example, the stale-price rate climbs from 1% to 6% in the week a new pricing tool goes live.

Show the dataHide the data

Stale-price rate before and after a pricing tool went live

Week	Stale-price rate
Week 1	1%
Week 2	1%
Week 3	1%
Week 4	1%
Week 5	6%
Week 6	6%
Week 7	1%

Because the number is tracked weekly, the cause shows within days: the jump lines up with one release, so you check that sync job instead of auditing the whole feed. An alert threshold, here 2%, turns the weekly review into a notification.

Final thoughts

The feed that hurts you is rarely the one Merchant Center rejects. It’s the approved one serving yesterday’s price, so put your effort into refresh speed and the stale-price rate before you polish another attribute. Start with your own numbers: how often does your feed refresh, and how often do your prices change?

If you sell refurbished or condition-graded products, a single-brand category page such as Google handsets at Used Mobiles 4 U shows how one brand’s range is laid out by model and condition; apply the same pattern, and the condition attribute, to your own ranges.

For shops that also sell from physical stores, Google’s local product data specification lists the extra attributes local inventory ads need, and notes that products can take up to two days to appear after submission.

For background on why the feed now sits at the centre of Google’s ads, this history of the Google Shopping model traces it from Froogle, a free comparison engine launched in December 2002, through Google Product Search in April 2007 to paid Google Shopping on 31 May 2012.