A rejected or partly accepted product feed makes your ads disappear without you noticing straight away. The rejection reasons are few in number, though, and almost all of them are fixed in the catalogue.
The required attributes
Six attributes are required for every product.
The identifier, unique and stable over time. This is your internal reference, and it must not change between two updates, or the performance history is lost.
The title, which describes the product.
The description.
The link to the product page, as an absolute and secure address.
The image link for the main image.
The availability and the price.
Two further attributes are required depending on the case. The brand, mandatory for most new products. And the product identifiers, including the barcode, mandatory wherever they exist for the product.
The question of product identifiers
This is the most frequent rejection reason and the most misunderstood.
A product manufactured by a brand and sold by several resellers has a barcode. It must be supplied.
Three practical situations.
You know the barcode. Supply it, checking that it is valid: the length and the check digit are verified, and an invented code will be rejected.
The product has none, because you make it yourself or it is made to order. You can then explicitly declare that the identifier does not exist, supplying the brand and your internal reference.
You do not know it. That is the problem case: the product has one, you have not recorded it. The only solution is to get it from your supplier.
A point to watch: the same barcode on several of your products produces an error. That typically happens when a value has been copied by default across a whole range.
Google Shopping PrestaShop Module — Merchant Center Feed, AI & Multi-ChannelThe Google Shopping feed that fixes itself Original price was: €219.00.€149.00Current price is: €149.00.
The title, which decides distribution
The feed title does not have to be the one on your product page. It is a field to build.
A structure that works: brand, product type, distinguishing feature, size or colour.
Four rules.
Important information first, because the display truncates.
No promotional text. Mentions of discounts, free delivery, or capitals for emphasis are a rejection reason.
No store name in the product title.
The variant in the title where one exists, which avoids several identical listings.
One remark: the title is the field that most influences matching with searches. Reworking the wording on your first hundred products produces a measurable effect.
Variants
A structural point that decides the quality of your feed.
Every purchasable combination must be a separate entry, with its own identifier, price, availability and image.
Three attributes tie them together. The item group id, shared by every variant of the same model. And the variation attributes, size and colour in particular, which distinguish them.
Two frequent errors. Sending only the parent product, which hides the available variants. Or sending the variants with no item group id, which makes them appear as unrelated products.
On colours, a useful clarification: the value must be an understandable colour name, not your marketing reference. “Midnight blue” passes, “Deep Ocean 47B” will be misread.
Availability and price
These two fields are checked automatically against your product page. A discrepancy leads to suspension.
Four frequent causes of discrepancy.
Update lag. Your feed is generated once a day and your price changes between two generations.
Tax. The feed price must match the one displayed on your page, tax included in markets where consumer prices are shown that way.
Promotions. A reduction applied as a cart rule does not appear in the feed, which creates a gap between the advertised price and the one seen in the basket.
Customer group pricing. If your page shows a different price depending on the visitor, the automatic check sees the public price.
On availability the check is the same: a product declared in stock in the feed and shown as sold out on the page is grounds for suspension.
Images
Five rules.
The product fills most of the frame, on a plain background preferably.
No added text on the image: no promotional banner, no watermark logo, no price mention.
No overlaid elements, no decorative frame.
The image matches the declared variant. A “red shoe” entry with the image of the blue model will be rejected or penalised.
Sufficient resolution, with no blurry or undersized image.
A practical point: on PrestaShop, the image sent must be the thumbnail at the right dimension, not the multi-megabyte original. A feed pointing at very heavy images slows processing and can produce fetch errors.
Categories
Two distinct fields, often confused.
The product category from the platform taxonomy, chosen from a closed list. It determines how your product is classified and which additional attributes are expected.
The product type, which is your own tree structure, free-form.
The first is not mandatory in every case but it clearly improves distribution, particularly in categories where specific attributes are expected: size, shoe size, gender, age group in apparel.
A common error: choosing too general a category. The more precise the category, the better the matching.
The most frequent rejection reasons
Six causes covering most cases.
Missing or invalid product identifiers.
Price discrepancy between the feed and the page.
Availability discrepancy.
Non-compliant image, usually text embedded in it.
Unreachable product page, often a redirect or an error page on an obsolete address.
Missing required information on the site: delivery terms, returns policy, contact details, payment methods. These requirements apply to the site, not the feed, and they block the entire account.
That last point is the one that surprises most: your feed can be perfect and your account suspended because your returns policy is not explicit enough.
The correction method
Four steps, in this order.
Handle account-level problems first, since they block everything: site information, compliance of the required pages.
Then the blocking feed errors, which prevent the affected products from being shown.
Then the warnings, which do not prevent distribution but degrade it.
Finally the improvement suggestions, on optional attributes.
A point of method: correct in the catalogue, not in the feed. A fix applied at feed generation has to be redone at every change, and it creates a gap between your real data and what you declare.
Update frequency
Three recommendations.
A full daily generation at minimum, more often if your catalogue moves.
A fast price and stock update alongside it, which avoids discrepancies on the volatile data.
A weekly check of the number of active products against the number sent. A widening gap signals errors accumulating.
The Google Shopping module for PrestaShop generates this feed on PrestaShop 8 and 9: mapping of the required attributes with barcode validity checking, variant handling with item group id and variation attributes, configurable title construction, and price and stock updates independent of the full generation.