· By Erik Svedin
How a Google Shopping feed works for a store with a till and a webshop: fields, variants, EAN, local inventory in Merchant Center and the most common disapprovals.
A Google Shopping feed is a file or an automated flow that tells Google Merchant Center which products the store sells, what they cost, whether they are in stock and what they look like. The feed is what makes the products appear in the Shopping tab, in Google's free listings and in Shopping ads, and it is also the basis for showing in-store stock on Google Maps. The principle is the same whether the store sells bikes, shoes, tools or kitchenware: the feed is a mirror of the article register, and it is never better than the data behind it. This page goes through the fields, the variants, the updating, the local inventory and the errors that most often stop a feed.
The feed is a table where every row is a sellable product and every column is an attribute defined by Google. It can be delivered as a TSV or XML file that Google fetches from an address on a schedule, as a Google Sheet, or directly through the Merchant Center API from the webshop. Abicart, WooCommerce, Shopify and most other webshop platforms can produce a feed, either built in or through an add-on. If EAN code, image or brand are missing in the till or the webshop, they are missing in the feed too, and then it is the register that needs correcting, not the feed.
Google distinguishes between required attributes, which stop the product if they are missing, and recommended ones, which affect how often the product is shown.
| Attribute | Requirement | What it means in practice |
|---|---|---|
| id | Required | The store's article number. Must be unique and must not change when the product is updated |
| title | Required | Brand, model and what distinguishes the variant, for example size or colour |
| description | Required | The product text. The supplier's text works, but your own text matches better |
| link | Required | The product page in the webshop, one per variant |
| image_link | Required | Main image, at least 100 × 100 pixels, without watermark or text |
| availability | Required | in_stock, out_of_stock, preorder or backorder. Must match the product page |
| price | Required | Price in SEK including VAT |
| brand | Required for everything except certain own-produced goods | The brand, not the supplier or wholesaler |
| gtin | Required if the code exists | The EAN code. See the section on missing codes below |
| mpn | Recommended, required if gtin is missing | The manufacturer's part number |
| condition | Required | new or used, for example for second-hand or trade-ins |
| item_group_id | Required for variants | Shared id for all sizes and colours of the same model |
| size, color, material | Recommended, required for clothing and shoes | The variant's properties, one per row |
| google_product_category | Recommended | Google's own category for the product type |
| product_type | Recommended | The store's own category, for example "Kitchen > Saucepans" |
| shipping | Required in Sweden unless set in Merchant Center | Shipping cost, or 0 for in-store pickup |
Every size and colour is its own row in the feed, with its own id, its own link and its own availability, and all rows for the same model share an item_group_id. That is how Google understands that a shoe that is sold out in size 42 is still available in 43, or that a bike that is sold out in frame size 50 is available in 54. The image should be the right colour for each row, and the title should include the variant, otherwise the wrong product is shown in the ad. The most common mistake is that the whole model sits as one row with a single stock level; the product is then either permanently in stock or permanently sold out, regardless of which variants are actually on the shelf.
If the product has an EAN code it must be included, always. If the product genuinely lacks an EAN code, which is common for small items, craft goods and parts from smaller manufacturers, set identifier_exists to false and let brand plus mpn identify the product. What does not work is inventing a code, reusing a code from another variant, or setting identifier_exists to false on a product that actually has a code; all three lead to disapproval or to the product being paired with the wrong product in Google's catalogue. Products without EAN get less reach than products with one, because Google cannot link them to its own product database, so it pays to fetch the codes from the supplier's price list rather than work around the problem.
At least once a day, and more often for price and stock. Google compares the feed's price and availability with what the product page shows, and a mismatch means disapproval for that product until the next fetch. A feed fetched on a schedule once a night is enough for range and texts, but stock levels for goods sold over the counter during the day should be sent through the API or by having the product page carry structured data that Google can read automatically. Merchant Center can update price and availability from the product page's schema.org markup between fetches, if the feature has been switched on.
Local inventory requires three things: a verified Google Business Profile for the store, an ordinary product feed, and a local inventory feed that states quantity and price per store and product. The local feed attaches a store_code to every row, and that is what makes a customer searching for "rain jacket near me" or "e-bike near me" see that the item is in the store today. The quantity in the local feed can come from the webshop, but most often it is taken from the till, because that is where the stock level for the physical store actually lives when the same goods are sold in both channels. If the store has several addresses, each address gets its own store_code and its own rows.
| Error in Merchant Center | Common cause | Fix |
|---|---|---|
| Price mismatch | Campaign price in the webshop, regular price in the feed | Let the feed take the price from the same source as the product page |
| Availability mismatch | The feed is updated once a day, stock changes all day | More frequent updates or automatic updates from the product page |
| Invalid GTIN | Code with the wrong number of digits, copied code, article number in the field | Fetch the code from the supplier, leave the field empty rather than wrong |
| Image with text or too small | Supplier image with logo or campaign text | Clean product image on a white background |
| Missing shipping | No shipping setting for Sweden | Set shipping in Merchant Center or per row |
| Duplicate id | Same article number on two variants | Unique id per variant, shared item_group_id |
| Title that looks like spam | Capitals, repeated keywords | Brand, model, variant, nothing else |
| Wrong category | The store's own category in the field meant for Google's | product_type for the store's tree, google_product_category for Google's |
The feed is a mirror of the store's product data, and the question is which source is mirrored. If the webshop is the only channel, the webshop's own feed is enough. If the store sells the same products in the till and the webshop, the stock level must come from the till, and then the till and the webshop must be connected before the feed can be right. If the store also has many suppliers with their own price lists, it is usually easier to gather article data, EAN, images and texts in one place and let both the webshop and the feed pull from there. That is where pricing and integrations come in: a feed that is filled from a correct article register rarely needs correcting by hand, whatever the store sells.
The bike trade shows the problems more clearly than most. The same bike comes in five frame sizes and three colours, so one model becomes fifteen rows with a shared item_group_id and the frame size in the title. EAN codes are often missing on parts from smaller manufacturers, while the bikes almost always have them in the supplier's price list. Bikes sold in the store during the day mean the local inventory feed has to follow the till, not the webshop. The solution is the same as for other stores: the right register behind it, a connection between till and webshop, and a feed that is filled automatically from there.