Google Shopping Feeds: The Full Specification for Getting Your Products Approved
You have put real work into your product pages. They read well, they are structured, and they convert on your own store. Yet on Google Shopping your products do not show up — or worse, they get disapproved without an obvious reason. The explanation fits in one sentence: Google does not read your product page, it reads your data source. These are two different objects. Your product page speaks to a hesitating human; the data source speaks to a machine that ranks and verifies. It expects exact attribute names, values from a closed list, and identifiers that match the real product. This guide walks through the official specification attribute by attribute: what is required, what is conditionally required, the real character limits, and the mistakes that get a product disapproved. It also covers a deadline worth noting: from 31 January 2027, Google enforces a minimum image size of 500 × 500 pixels.
A product page is not a data source
On your store you write to persuade. You describe a use, you answer an objection, you show a lifestyle photo. Google Shopping does not treat that text as such: it receives a structured file where every piece of information carries a precise attribute name and sits in its own column. If the information is there under a different name, it does not exist.
The vocabulary changed recently. What used to be called a "feed" is now a data source in Merchant Center. The principle is unchanged: you describe each product with a set of standardised attributes, and Google then decides whether to approve it, disapprove it, or approve it with warnings.
If you already work on your listings, the raw material exists. The job is to translate it into a format the machine understands, without losing what makes it sell.
The attributes without which nothing shows
Seven basic attributes are required for every product, plus brand for any new product (see below). If a single one is missing, the product is disapproved, and no amount of optimisation elsewhere will compensate.
- id — your unique identifier, up to 50 characters. It must never change between uploads, or Google loses the product history.
- title — the title, up to 150 characters.
- description — the description, up to 5,000 characters.
- link — the product page URL, which must start with http or https.
- image_link — the main image URL, also http or https.
- availability — stock status, from a closed list: in_stock, out_of_stock, preorder or backorder.
- price — the price as a number followed by the currency code, for example 15.00 USD.
Two useful details. If you declare a product as preorder, the availability_date attribute becomes required, in ISO 8601 format. And the price must include the three-letter currency code: a bare number is rejected.
The id attribute needs particular care. Some stores regenerate it on every export, for instance from a row number. To Google, the product disappears and a new one appears: you start from scratch with every upload.
brand, gtin and mpn: three attributes to get right
These three attributes connect your offer to the real product, the one other merchants may also be selling. That is what lets Google compare offers. The rules are precise: a mistake can get the product disapproved.
- brand — up to 70 characters. Required for all new products, except movies, books and music recordings.
- gtin — the manufacturer barcode, up to 14 digits, no dashes or spaces. Strongly recommended whenever one exists.
- mpn — the manufacturer part number, up to 70 alphanumeric characters. Required when the product has no manufacturer-assigned GTIN.
- identifier_exists — set to no only when the product genuinely has no GTIN, no MPN and no brand. It defaults to yes.
The most expensive mistake is inventing an identifier to push a product through. An incorrect GTIN does not pass unnoticed: it can get the product disapproved, because Google checks those codes. If you do not have the identifier, declare its absence rather than fabricate it.
Unbranded products deserve particular care. If you sell a generic item with no identifiable maker, do not drop your shop name into brand out of habit: that field describes the product manufacturer, not the reseller.
The title: 150 characters, but not all of them are equal
The limit is 150 characters, far more generous than on most marketplaces. That does not mean you should fill it. A data source title has two jobs: letting Google understand what the product is, and giving the buyer enough to recognise what they are looking for.
Order matters. The decisive information — brand, product type, distinguishing feature, size or compatibility — goes first. What follows should clarify, not persuade.
Two practices get a title disapproved, and the specification rules them out explicitly: promotional text and all-caps. "Free shipping", "Sale", "-30%" do not belong in a data source title. That information lives elsewhere, in its own attributes.
A good test: write the title as if you had to find your own product among a thousand others without seeing the image. If you cannot, neither can the buyer.
The description: 5,000 characters to describe, not to sell
The limit is generous — 5,000 characters — but the instruction is strict: the description must describe the product, and only the product. References to your store, your shipping terms, your commercial warranty or your other products do not belong there.
This is the sharpest difference from a store product page. On your own site, mentioning your customer service is useful and reassuring. In a data source it is off-topic, and it can trigger a disapproval.
What works: concrete specifications, dimensions, materials, uses, compatibilities, what is in the box. In other words, what a buyer would want to verify before ordering.
Variants: item_group_id and the attributes that differentiate
A t-shirt in five sizes and three colours is fifteen distinct products in your data source, each with its own id. What ties them together is item_group_id, shared across all fifteen rows, capped at 50 alphanumeric characters.
Without it, Google treats fifteen unrelated products. With it, it understands a single article with variants, and can present them together. In several countries, and for free listings, it is in fact required.
- color — up to 100 characters in total. Required for certain apparel and for multi-colour products.
- size — up to 100 characters. Required for clothing and shoes in certain cases.
- material — up to 200 characters, required when it distinguishes one variant from another.
- pattern — up to 100 characters, on the same logic.
- age_group and gender — required for certain apparel depending on the country; both use closed value lists (newborn, infant, toddler, kids, adult for one; male, female, unisex for the other).
The general rule is simple: any attribute that distinguishes one variant from another must be filled in on each of them. An empty field drops the variant out of filtered searches, exactly as it does on marketplaces.
Images: the 500 × 500 pixel rule is coming
This is the deadline to take away from the specification: from 31 January 2027, a minimum size of 500 × 500 pixels will be enforced on images. Stores still feeding Merchant Center with catalogue thumbnails have until then to redo their visuals.
Accepted formats are JPEG, WebP, PNG, non-animated GIF, BMP and TIFF. The image URL must be publicly reachable and start with http or https: an image behind authentication or served from a private space will never be fetched.
If you plan a single visual project this year, make it this one. Reworking an entire catalogue to a 500 × 500 minimum takes time, and the date is known in advance.
How to submit the data
Merchant Center accepts several routes, and the choice mostly depends on catalogue size and tooling.
- A tab-delimited text file (.txt or .tsv), suited to small and medium catalogues.
- An XML file, in RSS 2.0 or Atom 1.0 format, better suited to many variants, nested attributes and automated exports.
- A Google Sheet, which exports to tab-separated values.
- Connecting your e-commerce platform to Google, where that integration is offered.
- Adding a product manually in Merchant Center, useful for a test.
- The Merchant API, for catalogues managed by a third-party system.
Two technical details save hours of debugging. Files must be encoded in UTF-8 or UTF-16: anything else mangles every accented character. And Google recommends tab-separated over CSV, precisely because commas also appear inside descriptions.
Some errors are simply mechanical: a missing tab in a text file, an unclosed tag in XML, or a file saved in the wrong encoding. Before suspecting your content, check the container.
What carries over from your product pages, and what does not
If your product pages are already well written, part of the work is done. But the transposition is not mechanical, and this is where many stores get it wrong.
- Carries over well: concrete specifications, dimensions, materials, compatibilities, and the vocabulary buyers actually use.
- Carries over partly: the title, provided you strip anything promotional and move the decisive information to the front.
- Does not carry over: reassurance arguments about your store, shipping or commercial warranty mentions inside the description, superlatives, and anything that talks about you rather than the product.
A method that works: write the product page for the human first, with its benefits and answered objections, then derive the factual version for the data source. Doing it the other way round produces flat pages on your own store, and that costs conversions.
Structuring that content is exactly what FichePro AI does on your listings: a calibrated title, a structured description, features turned into usable information, and an SEO score out of 100 that points at what is missing. Formatting it for Merchant Center, with the exact attribute names described above, remains your step.
