A Google Shopping feed is not a marketing asset. It is a schema with a validator attached. Every disapproval traces back to an attribute that was empty, malformed, or contradicted by your own website. Google publishes the whole specification. Below is what it requires, which omission triggers which disapproval, and which of those a feed tool can fix. The rest have to be fixed in the PIM.
What a Google Shopping feed must contain
Seven attributes are required for every product in Google’s product data specification, regardless of category or country.
| Attribute | Rule | What goes wrong |
|---|---|---|
| id | Unique per product, maximum 50 characters. | Reused after a SKU is retired, so history and reporting break. |
| title | Maximum 150 characters, must match the landing page. | Generated from a template that does not match what the page shows. |
| description | Maximum 5,000 characters, must match the landing page. | Carries promotional text or competitor names, which the spec disallows. |
| link | Your verified domain, starting http or https. | Points at an interstitial, or at a redirect chain. |
| image_link | Must accurately show the product. | Below the minimum pixel size, or carries a watermark. |
| availability | One of in_stock, out_of_stock, preorder, backorder. | Contradicts the landing page, which is a disapproval. |
| price | ISO 4217 currency, matching the page and checkout. | Excludes a surcharge that the checkout adds back. |
Note what is doing the work in that table. Four of the seven rules are not about the value being present. They are about the value agreeing with something else: your landing page, your structured data, your checkout. That is the part feed tools handle badly, because a feed tool only sees the feed.
Two more requirements are conditional but bite almost everyone. brand is required for new products, except movies, books and music, with a limit of 70 characters. Google is explicit that you should not submit “N/A” or “Generic”. And condition is required whenever the product is used or refurbished.
For apparel there is a further set. Free listings for clothing and shoes require size, age_group, the colour attribute and item_group_id for variants. That applies in the UK, and in Brazil, France, Germany, Japan and the United States. Note that Google’s specification spells the colour attribute the American way. If you sell workwear or safety footwear alongside industrial lines, this applies to you. It usually surprises the team.
The identifier rules that catch distributors out
This is where distributor catalogues fail most often, and where the guidance is most misread.
Google’s position on unique product identifiers has three parts. Provide gtin, brand and mpn when you have them. Never fabricate or approximate a value. Leave a field blank rather than submit something incorrect.
The gtin attribute accepts UPC, EAN, JAN, ISBN and ITF-14 formats, up to 14 digits per value. Google requires that “the checksum digit is present and correct”. A bad check digit is not a warning. It is an invalid value.
mpn is required only where the product has no manufacturer assigned GTIN. It is limited to 70 alphanumeric characters, and it must be the most specific one available. Google’s wording is to “only submit MPNs assigned by a manufacturer”. Your internal part number is not an MPN.
When identifiers are missing or unrecognised, Google raises “Limited performance due to missing identifiers”. Its own description is that the values submitted “are either missing or aren’t recognised as a valid identifier”. The fix Google gives is binary. Provide an accurate GTIN, or provide both an MPN and a brand.
identifier_exists is not a workaround
We see identifier_exists set to no across whole feeds, usually because somebody wanted the warnings to stop. That is not what the attribute is for.
Google’s guidance says to submit no only where the product genuinely has no assigned identifier. The examples it gives are custom or one of a kind goods, handmade items, and products made before GTINs existed, including books published before 1970. It then says to “ensure that you only set the value to no or false… if you’re certain that your product doesn’t have any assigned unique product identifiers”.
A branded valve with a manufacturer part number is not a one of a kind good. Declaring it as one suppresses a warning and loses you the match to Google’s product knowledge graph. The honest fix is slower and permanent: go back to the supplier and get the GTIN. That is ordinary supplier data onboarding work. It pays for itself across every channel you sell on, not just this one.
Two disapprovals that come from your website, not your feed
The most common disapprovals we find on client accounts are not feed errors at all. They are consistency errors, and no amount of feed tooling fixes them.
Mismatched value (page crawl): price. Google compares the price attribute in your data source against the price on your landing page and in your structured data markup. Where they differ, Google’s help states that the product “may be disapproved”, and that repeated mismatches can lead to account suspension. Sale price windows are a frequent cause: the feed carries the sale price, the page has reverted, and nobody notices for a fortnight.
Mismatched value (page crawl): availability. The rule is that the value you submit and the information on your landing page “must be the same”. Google warns that too many products with incorrect availability can lead to account suspension. It also warns against a specific habit we see constantly. Do not set availability to out_of_stock to pause a product. Use the pause or excluded destination controls instead.
Both of these are latency problems dressed up as data problems. Your stock system updates hourly, your website caches for fifteen minutes, your feed regenerates overnight. The three views of the same SKU disagree for most of the day. Fixing that is an architecture decision, not a feed rule.
Disapproval, warning, or limited performance
Merchant Centre does not treat every problem the same way, and teams waste weeks on the wrong tier. Three levels are worth separating.
A disapproval removes the product from Shopping ads and free listings until it is fixed. It is the same hard stop that governs marketplace listings. Price and availability mismatches sit here. So do policy breaches. Google’s Shopping ads policies group into prohibited content, prohibited practices, restricted content, and site requirements covering editorial and technical standards. A policy disapproval is not a data problem and no attribute will fix it.
A warning leaves the product live but flags a risk. Incorrectly declaring that identifiers do not exist produces one of these.
Limited performance is the quietest and the most expensive. The product is approved. It simply competes badly, because Google cannot match it to a known product or a relevant query. Missing identifiers land here. So does a thin attribute set on a product whose competitors carry a full one.
The commercial mistake is to work the disapproval list until it hits zero and then stop. Zero disapprovals means nothing is blocked. It does not mean anything is competitive. We look at the limited performance tier first on most accounts. That is where the volume sits, and where a PIM changes the outcome.
What we look at in the first week
Four numbers tell you most of what you need before anyone touches a feed rule.
- The proportion of active SKUs carrying a valid GTIN, tested on check digit rather than on field population.
- The proportion carrying a brand value that is a real brand, not “Generic”, “N/A” or the supplier’s trading name.
- The count of distinct google_product_category values against the count of your own leaf categories. A large gap means the mapping is guesswork.
- The number of SKUs whose feed price differs from the price rendered on the page at the same moment.
None of those four require access to Merchant Centre. Three of them can be answered from a PIM export. That is usually the fastest way to show a board why the problem is upstream of the advertising team.
Category, taxonomy and the fields nobody fills in
Two attributes describe what a product is, and they do different jobs. Teams routinely fill in neither.
google_product_category maps your product to Google’s own taxonomy. It is optional per product, takes exactly one value, and accepts either the numeric ID or the full path, but not both. Google assigns a category automatically if you leave it blank. The reason to submit it is that the automatic assignment is sometimes wrong, and a wrong category means wrong category specific requirements and wrong comparisons.
product_type is your own categorisation, up to 750 characters, up to five values per product, with levels separated by a greater than sign. Only the first value organises bidding and reporting. This is the attribute that lets you structure campaigns around your own commercial hierarchy rather than Google’s. If your taxonomy is well built, populating it is a mapping exercise. If it is not, you find that out here.
We treat both as governed attributes rather than as feed logic. A mapping that lives in a feed rule is invisible to everyone except the person who wrote it. Getting the underlying tree right first is the whole argument for taxonomy and attribution work. Google’s feed is one of the places a weak tree shows up fastest.
Variants, images, shipping and the UK specifics
Three more areas where a Google Shopping feed fails for structural reasons.
Variants. item_group_id groups variants of the same product, up to 50 alphanumeric characters. It is required for free listings of variants in the UK. If your PIM has no product level above SKU, you cannot populate it correctly. You end up with forty near-identical listings competing with each other.
Images. image_link must accurately display the product, with no watermarks and no promotional text. Google’s specification sets a minimum of 500 by 500 pixels, and states that enforcement of that minimum begins on 31 January 2027. Supported formats are JPEG, WebP, PNG, GIF, BMP and TIFF. Most catalogues we audit have a long tail of supplier images below that threshold. Nobody knows which ones, because pixel dimensions are not held as an attribute.
Shipping. Shipping costs are required for Shopping ads and free listings in 28 countries. The UK is one of them. Where you submit postal codes, Google wants the outward code only. For N1C 4AG you submit N1C. Delivery to collection points in the UK is handled at account level rather than per product.
None of these three are copywriting problems. All three are data model problems, and they are the same ones that limit performance on marketplaces and on your own site.
Structured data is your second Google Shopping feed
This is the part most teams miss entirely. Google reads your product pages as well as your feed.
Google describes structured data markup as “a machine-readable representation of your product data directly on your site”. It is used to share that data with Merchant Centre, and Google puts it to two uses. Automatic item updates, which correct price, availability and condition mismatches from what the crawler finds on the page. And automated feeds, where Google builds the product data from a website crawl instead of a file.
Two constraints matter. Google states that “structured data must match the values that are shown to the customer”. And your landing page cannot vary by customer attributes such as geolocation based pricing, because then the crawler and the customer see different things.
Automatic item updates are worth switching on, but they are not a safety net. Google’s own guidance is direct about the limits. They address temporary problems for a small percentage of products, and they are not a replacement for keeping your product data current. If your feed is wrong at source, automatic updates will patch the symptom on a handful of SKUs and leave the rest disapproved.
The practical consequence is that price and availability need one owner and one source. If the feed comes from the PIM and the page comes from the ecommerce platform, they will disagree. Pick which system is authoritative for each attribute and make the other one read from it.
Where a Google Shopping feed tool stops
Feed management tools are good at one set of jobs and useless at another. Being clear about the boundary saves money.
A feed tool can rename fields, concatenate values, apply rules per channel, and split feeds by country. It can strip characters, truncate to a limit, and exclude products that fail a condition. That is real work and it is worth paying for.
A feed tool cannot invent a GTIN you do not hold. It cannot create the product level above SKU that item_group_id needs. It cannot tell you which supplier images are below 500 pixels, because it never sees the pixels. It cannot resolve a disagreement between your site’s price and your feed’s price, because it sits downstream of both.
That last point is worth labouring for anyone running a hosted storefront. When the platform owns price and stock and the PIM owns everything else, the feed inherits both. We deal with that split constantly on Shopify integrations, and the fix is always the same. Name the authoritative system per attribute and write it down.
The test we use is simple. If the problem can be solved by transforming a value you already hold, it is a feed tool job. If the value does not exist, is not trusted, or exists twice with two answers, it is a PIM job.
That distinction is why we push clients to fix the attribute model before they spend another quarter tuning feed rules. The feed rules get rewritten every time a channel changes. The attribute model does not.
Key takeaways
- Seven attributes are required for every product: id, title, description, link, image_link, availability and price. Brand is required for most new products.
- A bad GTIN check digit is an invalid value, not a warning. Google requires the checksum to be present and correct.
- identifier_exists set to no is for genuinely unidentified goods, not for suppressing warnings on branded stock.
- The two costliest disapprovals, price and availability mismatch, come from disagreement between your feed and your landing page.
- item_group_id needs a product level above SKU. If your data model has no such level, no feed tool can create one.
- Structured data markup is read by Google as well as your feed, and it has to match what the customer sees.
Most accounts we look at have three to six of these problems at once, and they interact. A weak taxonomy produces a wrong category. A wrong category produces missing category specific attributes. Those produce a partial listing nobody can filter to. Sorting the feed treats the last symptom in that chain, which is why it never sticks. It is also why product content performance stays flat for ecommerce teams that keep buying tools instead of fixing data.
If your disapproval count keeps coming back after every clean-up, book a thirty minute call. We will read your Merchant Centre diagnostics and tell you which are feed problems and which are data model problems.