Products from PrestaShop rejected in Merchant Center: price, availability and variants

When Merchant Center rejects a product due to price or availability, compare the same variant in three places: the data processed by Google, the public feed, and the store page. Also record the retrieval time. An XML file generated before a promotion may be a valid file but still contain an outdated offer. On the other hand, an up-to-date feed will not help if the link opens a different size or the store shows the crawler a different price.

This guide is intended for people running campaigns and managing a PrestaShop catalog. It focuses on price, availability, and variants. Rejections related to account policies, business verification, or sales restrictions require separate handling.

1. First, record the specific issue and the offer ID

Open the details of the rejected offer in Merchant Center and note the message text, ID, country, language, and data source. The names of panel sections may change; what matters is the data of the selected offer, not the location of the button in a screenshot.

Do not start by exporting the entire store with new IDs. First determine whether the issue affects one combination, promotional products, or the entire feed. If all rejected items share the same currency or come from one source, that is a useful clue. However, it does not determine the cause.

• Search by the full ID, including the prefix and combination number.
• Check which values Google actually processed, not only what the file currently contains.
• Open the exact feed URL fetched by Merchant Center and note the generation date.
• Check supplemental sources and rules that may modify the data after import.

The meaning of fields and the conditions for their use are described in the official product data specification. Use it to identify the requirements for your assortment, country, and the way the offer is presented.

2. Compare the specific variant, not just the product name

Demonstration example: the store sells a T-shirt in sizes M and L. The product has ID 812, with combinations 41 and 42 respectively. Size M costs PLN 129 and is available. Size L costs PLN 139 and is sold out. The feed contains a separate offer for each combination.

Here, the correct group ID does not fix the three other discrepancies. You need to correct the price, availability, and link. Google requires the landing page to present the variant corresponding to the submitted offer; the details are described in the landing page requirements.

3. Price: promotion, currency, and customer context

Compare prices in the same context: country, currency, and conditions available to the buyer. A price visible after logging in to a privileged customer group does not have to be the price for an anonymous user. Likewise, a net value from the admin panel is not the correct comparison point when the offer requires a tax-inclusive price.

For a promotion, check the base price price, the promotional price sale_price, and the possible range sale_price_effective_date. Make sure the discount is valid at the moment the page is opened and does not depend on a condition that the offer does not disclose. Do not simply enter a lower number in the XML if the cart still charges more. Price rules: Google — price attribute; promotion rules: Google — sale_price attribute.

If the source of the problem is the supplier price list, correct the input data and the rules for updating it. The existing guide on updating prices from CSV will be helpful. Only then refresh the feed and check whether the change has reached Google.

4. Availability: zero stock does not explain the entire configuration

Check the status of the specific combination, the ability to purchase when out of stock, and the message on the page. What matters is the actual offer for the buyer. A positive stock level stored in the database is not enough if the product is inactive or cannot be added to the cart.

in_stock, out_of_stock, preorder and backorder have specific meanings. Do not use preorder as a way to hide shortages. For preorders and orders awaiting availability, check the requirements regarding timing and the consistency of information on the page. The current rules are included in the availability attribute documentation.

If inventory data comes from an external source, monitor the entire chain: source update → import into the store → feed generation → retrieval by Google. Enabling more frequent feed fetching will not speed up a wholesaler that publishes new stock once a day. See also the guide on stock from CSV.

5. What should the XML fragment look like?

Below are two demonstration item elements for the same model. This is a fragment for comparing ID, price, availability, and size, not a complete feed ready for submission. The addresses in the example.com domain are examples. In your store, use links that actually open the correct combinations, as well as all required attributes for the given product.

<item xmlns:g="http://base.google.com/ns/1.0">
  <g:id>ps_812-41</g:id>
  <g:item_group_id>812</g:item_group_id>
  <g:title>Olive T-shirt, M</g:title>
  <g:link>https://example.com/koszulka?variant=41</g:link>
  <g:price>129.00 PLN</g:price>
  <g:availability>in_stock</g:availability>
  <g:color>olive</g:color>
  <g:size>M</g:size>
</item>
<item xmlns:g="http://base.google.com/ns/1.0">
  <g:id>ps_812-42</g:id>
  <g:item_group_id>812</g:item_group_id>
  <g:title>Olive T-shirt, L</g:title>
  <g:link>https://example.com/koszulka?variant=42</g:link>
  <g:price>139.00 PLN</g:price>
  <g:availability>out_of_stock</g:availability>
  <g:color>olive</g:color>
  <g:size>L</g:size>
</item>

Variants have different id values and a shared item_group_id. The store ID itself does not have to be a GTIN number. Do not enter a made-up EAN or replace the offer ID with it. The grouping rules are described in Google — item_group_id.

6. Check the result after re-fetching

1. Correct the data or configuration responsible for the discrepancy.
2. Generate the feed and retrieve it from its public URL.
3. Check whether the server returns XML, not an error page, login screen, or protection blocking crawlers.
4. After the source is fetched in Merchant Center, check the processing time and the values of the same offer.
5. Open the link without a privileged customer session and verify the variant, price, and ability to purchase.
6. Return to the issue status. If it remains, read the current message instead of assuming it concerns the previous cause.

Automatic product updates may reduce some discrepancies, but they do not replace maintaining a correct source. Additionally, verify the price and availability in the page’s structured data: Google — supported structured data.

7. Real test: variant link in the PrestaDev feed

On 27 September 2026, we checked a saved copy of the public file google-merchant_id-1.xml from before the fix (header Last-Modified: 26.09.2026, 18:54:27 GMT) and opened the landing pages without logging in. The copy contained 360 offers and 181 different links. For 166 links, several variants had different prices in the feed. This was a signal to verify those URLs, not the number of confirmed rejections in Merchant Center. The current file at the given address was later regenerated.

In this test, the product URL with id_product_attribute=409 returned HTTP 200, selected the extension option, and showed PLN 247 both in the visible price and in the price metadata. The URL for 408 selected the full license and PLN 492. The values were read from the initial HTML; no purchase was made.

Conclusion from the test: correct g:id, g:item_group_id, and price are not enough when g:link does not select the sold variant. Google recommends preselecting the correct variant in the link and matching the price visible on the landing page with the offer data. g:canonical_link may still point to the base product URL without variant selection.

Result after the fix on 27.09: we updated the generator to version 2.11.1 and regenerated the same public feed. It retained 360 offer IDs, and each of the 346 variants now has its own link with the combination ID. A repeated anonymous check of six offers, including 60-408 and 60-409, confirmed the selected option as well as the visible price and the page metadata price; for 60-409 this is PLN 247. The canonical URL still points to the base product page. This confirms the public XML and the verified pages, but it does not indicate whether Merchant Center has already fetched the new file or whether the offer data has been accepted there. Check the status of the same IDs in your account after the next source processing.

Update on 27.09 after excluding the commission item: The non-module product 144 (“Commission for payment via PayPal”) with variants 144-476 and 144-477 was removed from the file. The current public XML has 358 offers and 344 variants with a separate link. The figures 360/346 above describe the test state before this exclusion. Reading the XML alone still does not confirm retrieval or source acceptance in Merchant Center.

When is Google Shopping Pro useful?

Google Shopping Pro generates product data from PrestaShop. In the verified code of version 2.11.1, there are export paths for combinations, group IDs, prices, and promotional prices. It is a tool for preparing the source; it does not resolve all Merchant Center account issues and does not guarantee product approval.

Need a well-structured feed? Check Google Shopping Pro. If the problem also involves the page, combinations, or data from integrations, prepare the sample offer ID, the exact message, and the three compared values for the store integration analysis.

Substantive verification: 27 September 2026. The T-shirt example and its XML are demonstrational. The 60-408/60-409 test includes a copy of the PrestaDev file from before the fix as well as the new file and pages read on 27.09; it does not confirm rejection or acceptance in the Merchant Center account. The module scope was verified in the code and public XML, and the meaning of attributes in Google documentation.