---
title: "Google Shopping Feed Setup: Requirements, Refresh and Fixes"
description: "Google Shopping feed setup: the attributes Merchant Center needs, how often to refresh price and stock, a seven-step build and fixes for disapprovals."
canonical: "https://www.productmetrics.io/blog/feed-google-shopping"
pageType: article
language: en
publisher: "Product Metrics"
author: "Berend Vrakking"
datePublished: 2026-11-13
dateModified: 2026-11-13
image: "https://www.productmetrics.io/og/blog/feed-google-shopping.png"
---

> Content index: https://www.productmetrics.io/llms.txt

# Google Shopping feed setup: requirements, refresh and fixes

## Key takeaways

- Send one row per sellable variant with a permanent id of up to 50 characters; a regenerated id makes Google treat the product as new.
- Fetch the feed four times a day rather than once: a sale price then reaches Google within 3 hours on average instead of 12.
- Fix Merchant Center issues by item count, not one product at a time: a single tax setting can flag 300 prices at once.

Feeding Google Shopping means sending [Google Merchant Center](https://www.productmetrics.io/glossary/google-merchant-center "Google Merchant Center (GMC) is a free Google tool where a shop uploads and manages its product data, so its products can appear on Google Shopping and across Google.") a [product feed](https://www.productmetrics.io/glossary/product-feed "A product feed is a file or data source that lists your products, one per row, with attributes such as ID, title, price and availability."): 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](https://www.productmetrics.io/glossary/gtin "A GTIN (Global Trade Item Number) is a unique number that identifies a product that can be priced, ordered or invoiced, usually shown as a barcode.") 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](https://www.productmetrics.io/blog/google-product-feeds).

| Attribute | Requirement | Rule or limit | Example value |
| --- | --- | --- | --- |
| **id** | Required | Stable and unique, maximum 50 characters | ACME-TR-BLK-10 |
| **title** | Required | Up to 150 characters; lead with brand, product type and key attribute | Acme Trail Runner Men's Black Size 10 |
| **description** | Required | Plain text, up to 5,000 characters | Waterproof trail runner with a 6 mm lug sole |
| **link** | Required | The exact landing page for this variant | Product page URL |
| **image_link** | Required | Public https URL; at least 500 × 500 px, enforced from 31 January 2027 | Product image URL |
| **price** | Required | Number with currency code, tax included where the country requires it | 89.00 EUR |
| **availability** | Required | in_stock, out_of_stock, preorder or backorder | in_stock |
| **brand** | Required for most new products | The brand name as sold, up to 70 characters | Acme |
| **gtin** | Required when assigned | 8, 12, 13 or 14 digits with a valid check digit | 12-digit UPC |
| **item_group_id** | Required for variants in many countries | One shared value across every size and colour | ACME-TRAILRUN |
| **google_product_category** | Optional | A category from Google's product taxonomy | Apparel & Accessories > Shoes |

The limits come from [Google's product data specification](https://support.google.com/merchants/answer/7052112?hl=en), 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](https://www.productmetrics.io/blog/google-shopping-product-title-optimization) 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](https://www.productmetrics.io/blog/google-shopping-category) 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.

| Method | Best for | Refresh pattern | Setup effort |
| --- | --- | --- | --- |
| **Scheduled fetch** | A feed file at a stable web address | Daily or several times a day | Low: set the URL once |
| **File upload** | A test batch or a few dozen products | Manual, each time someone uploads | Low, but easy to forget |
| **Merchant API** | Large ranges or fast-changing prices and stock | Per product, close to real time | High: needs developer time |
| **Supplemental feed** | Labels and extra attributes on top of the primary feed | Its own schedule | Medium: a second file or sheet |

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.

**Figure: How long a price change stays wrong in Google.** Each extra daily fetch shortens the window: a feed fetched once a day shows a changed price wrong for 12 hours on average, an hourly one for 30 minutes.

![Bar chart of hours a price change stays wrong by feed refresh: 12 average and 24 worst at once a day, 3 and 6 at four times a day, 0.5 and 1 hourly.](https://www.productmetrics.io/images/blog/feed-google-shopping/stale-price-window-by-refresh.webp)

| 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 |

_Source: Calculated: average window = refresh interval ÷ 2, worst case = the full interval, for changes made at random times; Google's processing time comes on top_

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](https://www.productmetrics.io/blog/google-shopping-apis) 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.

**Build and submit a Google Shopping feed**

1. **Export one row per sellable variant.** A parent row for "Trail Runner, all sizes" hides the unit that serves an ad. Pull the live price and current stock in the same export, or the feed mixes two different moments.
2. **Freeze the id.** Give each internal SKU a permanent identifier of 50 characters or fewer and never regenerate it on export. A changed id creates a duplicate offer and resets the product's history.
3. **Fill the required attributes.** Complete every required column from the attribute table and validate each GTIN check digit: a malformed or reused code is disapproved or matched to someone else's product.
4. **Connect the variants.** Give every size and colour of one style the same item_group_id and item_group_title, so the variants stay linked in reporting and the right one is shown.
5. **Create the primary feed, and only that.** Add a supplemental feed later for extras such as custom labels. Rewriting the core feed for a promotional flag is how two versions of the truth start.
6. **Check feed values against the landing pages.** Price and stock are the fields your shop changes without telling anyone, and the two where a mismatch becomes a disapproval.
7. **Read item-level diagnostics after the first run.** Check that the products went active, and why any didn't, before you touch campaigns or budgets.

### 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:

| Symptom | Likely cause | Fix |
| --- | --- | --- |
| **Missing required value** | Attribute blank in the source data | Fill the field at the source and resubmit |
| **Invalid GTIN** | Wrong length, failed check digit or reused code | Correct it from manufacturer data, or set identifier_exists to no when none exists |
| **Price mismatch** | Feed price differs from the page, often over tax | Sync the feed price with the page before each release |
| **Out of stock** | Feed says in_stock while stock is zero | Set out_of_stock when stock runs out and refresh during the day |
| **Image not accessible** | Image blocked, broken or below the minimum size | Serve it publicly over https at the required size |
| **Landing page problem** | Link errors or redirects to the homepage | Point link at the exact product page |
| **Variant not connected** | Missing or inconsistent item_group_id | Give all variants of a style one group id |
| **Duplicate product** | Same product under two ids | Keep one stable id per variant and remove the old rows |

The full list, by Google's own issue names, is in [Google Merchant Center errors and their fixes](https://www.productmetrics.io/blog/google-merchant-center-errors).

### 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](https://www.semrush.com/blog/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](https://developers.google.com/google-ads/api/docs/shopping-ads/reporting) 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](https://www.productmetrics.io/glossary/performance-max "Performance Max is a goal-based Google Ads campaign type that uses automation to reach customers across Google advertising channels.") together, rose 16% year on year in Q3 2024, per [Tinuiti's Q3 2024 Digital Ads Benchmark Report](https://tinuiti.com/research-insights/research/digital-ads-benchmark-report-q3-2024/).

By the end of 2024 more than 95% of retail advertisers running Shopping ads had adopted Performance Max, per [Tinuiti's Q4 2024 report](https://tinuiti.com/research-insights/research/digital-ads-benchmark-report-q4-2024/).

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](https://www.productmetrics.io/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](https://www.productmetrics.io/glossary/supplemental-feed "A Google Merchant Center supplemental feed is a secondary data source that adds details to, or overrides details in, the products of your primary feed.").

> **Get more revenue out of Google Shopping.** Every product segmented and labelled in Merchant Center, so your top performers get more priority. [Analyse your products for free](https://app.productmetrics.io/) Log in with Google, no credit card.

## 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.

| Attribute | Layer | How often it changes |
| --- | --- | --- |
| id | Primary feed: identity | Never |
| brand, gtin | Primary feed: identity | Rarely |
| item_group_id | Primary feed: identity | When a style is added |
| price | Supplemental feed or API: state | Daily during sales |
| availability | Supplemental feed or API: state | With every stock movement |
| custom_label_0 to custom_label_4 | Supplemental feed: state | When a segment or promotion changes |

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](https://www.productmetrics.io/glossary/custom-labels "Custom labels are five attributes in a product feed, custom_label_0 to custom_label_4, that you fill with your own text to group products in campaigns.") 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](https://www.productmetrics.io/blog/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.

| Number | How to calculate it | A rise usually means |
| --- | --- | --- |
| Item-level disapproval rate | Disapproved items ÷ submitted items | A mapping or source-data error |
| Stale-price rate | Items whose feed price differs from the page ÷ items checked | A broken price sync |
| Stale-stock rate | Items in stock in the feed but sold out in the shop ÷ items checked | Inventory updates lag behind sales |
| Time to correction | Hours from an issue appearing to its fix going live | Nobody owns the fix |

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

**Figure: Stale-price rate before and after a pricing tool went live.** A jump from about 1% to 6% in the week a new tool went live points at one broken sync job, not at the feed as a whole.

![Line chart of weekly stale-price rate: flat at about 1% for four weeks, then 6% in week 5 when a new pricing tool went live, and back to 1% after the sync fix. Illustrative data.](https://www.productmetrics.io/images/blog/feed-google-shopping/stale-price-rate-sync-break.webp)

| 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% |

Reference line: Alert threshold (2%).

_Source: Illustrative data_

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](https://usedmobiles4u.com/product-category/googlefeed/) 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](https://support.google.com/merchants/answer/14779112?hl=en) 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](https://ppc.land/product/) 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.

## Frequently asked questions

### Should prices in a Google Shopping feed include VAT?

Yes, in the EU and the UK the feed price includes VAT, matching what the shopper pays on the product page. In the US and Canada it excludes sales tax, which you set in Merchant Center instead. A feed on the wrong tax basis is a common cause of price mismatches.

### Can a Google Sheet be your Google Shopping feed?

Yes. Merchant Center accepts a Google Sheet as a product data source and fetches it on a schedule. It suits a few dozen products that someone edits by hand; for hundreds of variants with changing prices, export the feed from your shop instead.

### Do you need a feed management tool to feed Google Shopping?

No. Most shop platforms can publish a feed URL or connect to Merchant Center directly, and that covers one channel. A feed management tool earns its cost when you send the same products to several channels, or need rules that rewrite titles and attributes in bulk.

## Keep reading.

- [Google product feed: how it works, IDs, sync and fixes](https://www.productmetrics.io/blog/google-product-feeds)
- [PIM to Google Merchant Center: the product-data workflow](https://www.productmetrics.io/blog/pim-to-google-merchant-center)
- [How Google Shopping ads work, from feed to sale](https://www.productmetrics.io/blog/how-google-shopping-ads-work)

---

Written by Berend Vrakking, founder of Product Metrics. Last updated 2026-11-13.

1M+ products analysed · Nominated at the Dutch Search Awards for Best Measurement Campaign (2023) and Best Use of Data (2024)

HTML version: https://www.productmetrics.io/blog/feed-google-shopping