When a product is disapproved in Google Merchant Center, increasing advertising spend does not fix the cause. The problem may be an attribute, a mismatch with the store or a condition affecting the account. Start by identifying exactly what Google flagged and which offer is being assessed.
This diagnostic approach applies to PrestaShop, WooCommerce and other stores submitting product data. The principle is the same: the data source, the information processed by Merchant Center and the buying experience should describe the same offer. Fixing only one layer may temporarily remove a warning while allowing it to return with the next update.
1. Distinguish product, destination and account issues
Open the issue and record its exact name, affected products, country and destination, such as Shopping ads or free listings. A limitation in one destination does not necessarily mean disapproval everywhere. Account issues may require a review of business information or policies as well as product data corrections.
- Select an affected offer and record its stable ID, variant and submitted URL.
- Check the final processed value in Merchant Center, rather than only what the store module displays.
- Identify the source and rules that can change that value, including supplemental sources.
- Save the update time and evidence of the issue for comparison after the fix.
2. Build a comparison from observable data
Use a small comparison table: ID, reported attribute, source value, processed value, value visible on the page and structured data value, where available. Add availability and price during checkout. Choose one offer for each error pattern: promotion, combination, out-of-stock product or market. Sampling helps uncover a shared rule without assuming every product has the same cause.
Make the comparison within a short time window. A price observed this morning and a file generated yesterday may reveal a synchronisation delay. If two sources write the same attribute, check their precedence and the ID used to match records. Resubmitting the catalogue without understanding that order can apply the wrong value again.
3. Price: check the offer shown to the visitor
Google documents several causes of price mismatches, including unsynchronised promotions, different variants and inconsistent structured data. Check the currency, regular price, sale price, dates and applicable conditions. The product shown in the image and title should match the advertised price, including mandatory customisation or minimum quantities where applicable.
Open the exact submitted URL in a clean session and in the target market’s context. A page that automatically selects the cheapest version may not represent the advertised variant. Also check whether the cache retains an expired promotion. Avoid rules that show Google a different offer from the one available to buyers.
4. Availability: stock and the actual ability to buy
The availability attribute should match availability on the page and at checkout. Check stock for each product variant, the ability to order and delivery restrictions. An item visible in the catalogue may be unavailable in the selected variant or undeliverable to the configured area.
Distinguish out-of-stock, preorder and backorder according to the attribute’s rules. If you accept these orders, the required availability date must be consistent and visible. Do not mark all items out of stock simply to hide maintenance or a technical store problem: use the mechanisms appropriate to the situation.
5. GTIN: confirm the identifier rather than inventing one
Find the correct identifier from the manufacturer, packaging or supplier information. Confirm it belongs to the advertised product and combination; do not replace a GTIN with an internal reference or the code for a similar variant. A value with the expected length may still be wrong. Check whether leading zeroes were lost in a spreadsheet.
The GTIN attribute documentation advises against guessed values. Do not use identifier_exists=no to work around a missing identifier: that setting only applies to products genuinely without assigned identifiers under the specified conditions. In-house production or customisation does not automatically make every product an exception.
6. Variants: each offer must lead to the correct selection
A product family may share a page, but each advertised variant needs consistent identification. Check the distinguishing attributes, ID, image, price, stock and grouping. Where item_group_id applies, variants of the same product share the group while remaining separate offers. Do not reuse a group for unrelated products.
Test the variant URL without relying on a previous choice stored in cookies. The page should present the advertised option and retain the selection throughout the buying journey. A parameter exported by the module but ignored by the theme is useful evidence: the issue concerns the catalogue-to-page connection, not necessarily the price itself.
7. Landing pages and crawling: test access and content
Check 404 and 5xx errors, redirect loops, mobile loading and inaccessible images. Investigate robots.txt restrictions, firewalls and geographic rules with the hosting provider. A page that opens on the team’s computer may still be inaccessible to the crawler. Do not disable security indiscriminately: identify the specific rule and validate access in a controlled way.
Visitors should find the offer without needing authentication, making an unexpected geographic choice or encountering a screen that hides it. Also review business information, contact details and conditions required by applicable policies. Technical accessibility is necessary but does not remove product or account eligibility requirements.
8. Fix the source before requesting another review
Apply the fix where the value is generated: catalogue, integration, rule, theme or structured data. Update the source, confirm processing and revisit the comparison table. If a review request is needed, follow the procedure shown for the issue and gather evidence of the change. Do not promise an approval timescale or repeat requests while the mismatch remains.
Hypothetical example: correct price, wrong variant
Illustrative example only: the offer has the ID/reference CASACO-AZUL-L, size L. In Merchant Center, the processed value is price=79.90 EUR and availability=in_stock. The GTIN still needs confirmation from the manufacturer; no invented code or presumed exemption is presented here.
Opening the URL selects M, shows EUR 69.90 and indicates unavailability. The comparison is not between the same offer. First confirm the selection of L, its price, currency, stock and real identifier; then align the source, processed value, page and structured data. Changing every feed price does not fix preselection. This scenario does not describe a RedeShop account or results.
To request help, send the store address, the exact issue message and a few affected IDs, without credentials. RedeShop can assess the data source, integrations and pages, and propose a remediation plan with validation. The approval decision remains Google’s.
Sources and documentation
- Google Merchant Center: price mismatches
- Google Merchant Center: availability
- Google Merchant Center: GTIN
- Google Merchant Center: identifier_exists
- Google Merchant Center: incorrect identifiers
- Google Merchant Center: variant grouping
- Google Merchant Center: landing page requirements
- Google Merchant Center: product crawling issues