Google Merchant Centre: 10 feed errors that cause your products to be rejected

A product rejected by Google Merchant Centre appears to cost nothing: no invoice, no blocking alerts. It simply disappears from Shopping ads and free listings. With just a few weeks to go before the peak sales period, this silence comes at a high price. Google’s documentation states that it takes 24 to 72 hours for corrections to be processed after a resubmission: between the rejection, its detection and reprocessing, a product listing remains invisible for several days. Here are the ten most common reasons for rejection, what they mean in terms of product data, and why a lasting correction is made in the product database rather than in the feed.

Product identification: rejections originating upstream

Google builds an offer’s identity based on four attributes: id, gtin, mpn and brand. Three of the ten rejections stem from this block, almost always because the data is already missing from the source catalogue.

1. Non-unique or reused product identifier

• Symptom— the product is flagged with a ‘Duplicate identifier’ error, or several listings are merged and only one remains live.
• Data-side cause— the attribute id (maximum 50 characters ) must remain unique within the account and consistent over time. It is often generated on the fly by the export script, based on a non-standardised supplier reference, a technical identifier from the shop, or worse still, a line number. When the database is re-imported, the identifier changes.
• Correction in the repository— the Merchant Centre identifier must be a product attribute in the PIM, not a value calculated by the feed: an internal key generated when the product record is created and never reused.

2. Invalid barcode, or missing without declaration

• Symptom— errors such as ‘Invalid value [gtin]’, ‘Invalid GTIN in unsupported format’, ‘Incorrect identifier: GTIN [gtin]’ or ‘Duplicate GTIN’.
• Data-side cause— Google’s documentation specifies that a GTIN consists of 8, 12, 13 or 14 digits. Common causes of failure include: leading zeros lost by a spreadsheet programme, an incorrect check digit, a code from another product copied onto a variant, or even the same code being reused across two variants.
• Correction in the product database— barcode validation must be carried out during import, not export. The EAN Manager module in Pixee PIM checks the format and check digit, detects duplicates and flags suspicious codes before they reach any sales channel.
• Legitimate cases— a bespoke or vintage product may have no identifier. Google therefore provides identifier_exists to no. The documentation specifies that products for which this attribute is set to no even though an identifier exists receive a warning: this is a declaration, not a workaround.

3. Missing brand or manufacturer reference

• Symptom— rejection due to a missing attribute on brand, or request to mpn on products without a GTIN.
• Data-side cause— brand (maximum 70 characters) is required for most new products, and mpn becomes necessary when the product does not have a GTIN assigned by the manufacturer. At a retailer, the brand is often included within the supplier description rather than being a separate field.
• Correction in the product database— the brand must be an entity in the catalogue, linked to the product record, and not a freely entered string. Variations in the spelling of the same brand are resolved once, not in every data feed.

Prices, availability and costs by country

This section accounts for the most costly rejections: they affect products that have already been approved and are currently being distributed.

4. Price in the feed differs from the price on the page

• Symptom— a rejection at item level labelled ‘Mismatched value (page crawl) [price]’. Google crawls the destination page and compares it with the value sent.
• Data-side cause— most often, a synchronisation delay. The price changes in the shop, the feed is regenerated later, and the crawl falls in between. Added to this are structural discrepancies: a promotional price sent in price instead of sale_price, or different rounding between the export and the shop.
• Correction in the repository— a single reference price in the PIM, distributed to the shop and to Merchant Centre in the same cycle. As long as the two have separate sources, discrepancies are inevitable.

5. Incorrect availability

• Symptom— ‘Mismatched value (page crawl) [availability]’, or availability deemed inaccurate compared to the landing page.
• Data-side cause— the attribute availability only accepts in_stock, out_of_stock, preorder and backorder, with availability_date being mandatory for the latter two. Custom values (“made to order”, “3 to 5 days”) are rejected, and a daily feed cannot keep pace with a November catalogue.
• Correction in the repository— stock is managed in the PIM, with an explicit mapping between your internal statuses and the four permitted values, and a more frequent synchronisation schedule ahead of the peak season.

6. Missing delivery charges or tax depending on the country

• Symptom— ‘Missing shipping costs’ error, or missing sub-attribute on shipping (typically country) or on tax.
• Data-side cause— charges are defined at account level or per product via shipping ; Google recommends setting this at account level, with a product surcharge only where necessary (bulky or fragile items). Rejections occur when a targeted country has no rule, or when a surcharge is incomplete. Regarding tax, the rule depends on the market: for the US and Canada, the documentation specifies that VAT and sales tax should not be included in price.
• Correction in the product database— weight, dimensions and logistics category must be mandatory attributes per product family. This ensures that shipping rules are applied without exception, and allows a country to be enabled without having to go through each product listing individually.

Content and images

7. Non-compliant image

• Symptom— ‘Image too small’, ‘Text on image’, ‘Promotional overlay on image [image_link]’, or image deemed generic.
• Data-related cause— the specification prohibits any overlaid elements: watermarks, logos, brand names, calls to action, references to prices or free delivery, borders, placeholder images or visuals that do not show the product. Regarding size, the minimum threshold has increased to 500 x 500 pixels, with warnings issued from July 2026 and due to come into effect on 31 January 2027; until then, the previous thresholds remain tolerated (250 x 250 pixels for clothing, 100 x 100 for everything else).
• Correction to the guidelines— separate marketing images (promotional banners, packshots with labelling) from publishable images in the media library, and check dimensions upon import. Many catalogues still contain supplier images of 200 or 300 pixels: these are currently acceptable, but will no longer be after January 2027.

8. Poor title or description, or one crammed with keywords

• Symptom— product data quality warning, particularly regarding excessive use of capital letters; or listings published but underperforming.
• Data-side cause— title accepts 150 characters, description up to 5,000, and the latter must match the landing page. A supplier’s title is typically either too short (‘18V drill’), or a string of keywords separated by hyphens. Both fail, for opposite reasons.
• Correction in the repository— a title is constructed from structured attributes (brand, range, distinguishing feature, capacity), not a free-form string. As soon as these attributes exist in the PIM, the title becomes a rule applied to an entire product family, and the completenessscore identifies the product records that do not yet meet this rule.

Classification and variants

9. Incorrectly populated product category

• Symptom— ‘Invalid product category’, or products published but missing from relevant comparisons.
• Data-side cause— google_product_category expects either the numerical identifier of the Google taxonomy or the full path: sending the last segment on its own causes an error. Not to be confused with product_type, your own tree structure, which remains flexible.
• Correction in the repository— the mapping to the Google taxonomy is defined once, at category level, not on a product-by-product basis. Any new listing classified under it inherits this mapping.

10. Variants declared without a parent item ID

• Symptom— variants treated as duplicates, or an issue with missing attributes on grouped variants.
• Data-side cause— item_group_id (maximum 50 characters) is required for variants in several countries, including France. And simply providing this information is not enough: each product sharing the same item_group_id must have a distinct value for at least one variation attribute (size, color, material, pattern…). Otherwise, Google treats them as identical listings.
• Correction in the repository— this is the classic scenario where the feed cannot rectify the issue: if the data model does not distinguish between the parent and its variants, no export script will be able to recreate the information. The PIM must contain the parent/variants structure and the variation axes declared at family level.

Fix the feed or fix the data

The common thread running through these ten rejections: the faulty data already existed in the catalogue before the export. The feed merely made it visible. This is why the corrections applied in the output file — forced default values, exclusion of products with errors — are ineffective: they treat the symptom in one channel, and the problem reappears on Amazon, in the shop, and in the PDF catalogue.

Three mechanisms shift the checks to an earlier stage:

• Mandatory attributes by product family— a television and a screw do not have the same required fields. Declaring these requirements makes any omissions visible at the time of entry or import, not three weeks later in Merchant Centre.
• Quality control before export— the completeness score is configured per channel. A product record below the threshold set for Google Shopping is not exported: it goes into the list of records to be completed, with missing attributes detailed.
• Feed generated from theproductdatabase— the Google Merchant Centre connector is one of Pixee PIM’s 15 native e-commerce connectors, alongside the other channels available in the integrations catalogue. Mapping to Google attributes is configured once, and the same data feeds the other channels, without the need to maintain a separate export script.

Priority order ahead of the fourth quarter: identifiers, prices and availability, which block publication; then images, for which the threshold changes on 31 January 2027; and finally titles and categories, which have a greater impact on performance than on eligibility.

Frequently asked questions

How long does it take for a corrected product to become eligible again?

Google’s documentation states that you should allow 24 to 72 hours after a resubmission for the updates to be processed, plus your own processing time. It is this cumulative delay that makes the corrective approach costly during peak season.

Do the error messages listed here match what I see in my account?

The error messages listed here are taken from Google’s English documentation; the French interface translates them — ‘Image too small’ becomes ‘image trop petite’. The names of attributes, however, do not change from one language to another: you should search for them in the documentation.

Can I correct these errors using feed rules in Merchant Centre?

Partly: a rule can standardise a format or apply a default value, but it does not create missing data. A missing GTIN, a non-existent variant structure or a 200-pixel image can only be rectified in the source catalogue. And each rule widens the gap between what Google sees and what you believe you are publishing.

Is the Google Merchant Centre connector included in all plans?

The Google Merchant Centre connector is included from theStarter planonwards, which covers one connector. Higher-tier plans increase the number of connectors that can be activated simultaneously, to push the same product data to Google Shopping, the shop and marketplaces.