Fix Google Merchant Center Price Mismatches in PrestaShop
A Google Merchant Center price mismatch means the offer in your product data does not agree with the offer Google finds on your store. Correcting one number without tracing its source can make the warning disappear temporarily while the next export recreates the problem.
In 2026, the same catalogue may support conventional Shopping placements and newer AI shopping experiences. A reliable offer record remains essential: the customer should reach the advertised variant at the advertised price.
Use this guide to trace one affected item through the feed, public product page, structured data and cart. The examples describe a diagnostic process; exact menus and export controls depend on your feed module.
1. Save the Affected Offer Before Changing Anything
Record the Merchant Center item ID, reported issue, target country, language, currency and landing-page URL. Keep the notification time and the time of your investigation separately.
Export or copy the relevant product-data row through your normal tools. Also record the source system and when the feed was generated, uploaded and processed.
A warning observed today may describe yesterday's data. Keeping the timestamps prevents a team from changing a price that is already correct while overlooking a recurring scheduling problem.
Google's mismatched-price guidance explains that submitted prices are checked against the landing page and that re-evaluation can take time. Do not repeatedly change correct data simply because the status has not updated immediately.
2. Confirm the Exact Product and Combination
Match the item ID to the PrestaShop product and, where relevant, its combination. Include the variant reference and any pack quantity in the investigation.
Use a concrete example: the feed advertises a blue 500 ml bottle for €24, but its URL opens the default 750 ml bottle at €29. Both prices can be individually correct while the advertised offer is still inconsistent.
| Checkpoint | Value to record |
|---|---|
| Feed item | External ID and exact variant |
| Landing URL | Full URL including selection parameters |
| Product editor | Internal product and combination references |
| Public selection | Variant initially selected for a new visitor |
| Cart line | Reference and quantity actually added |
Correct the mapping at its source. Editing the visible title to mention 500 ml does not solve a URL that continues selecting 750 ml.
If identifiers are inconsistent across channels, use the AI catalogue readiness guide to establish one maintained product map before repairing individual exports.
3. Compare the Four Prices in the Same Context
Open the actual landing URL in a clean browser session. Record the prominently displayed price, currency and selected variant before interacting with the page.
Inspect the offer information in structured data with appropriate developer or validation tools, then add the item to the cart. Compare those results with the submitted feed row.
Keep the context stable: destination, language, currency, tax presentation and customer status. A logged-in trade customer may see a price that differs from the public offer used by the listing.
Google's price attribute specification describes the channel's price requirements. Use those requirements when deciding what to submit, rather than assuming a back-office base price is always the correct advertised amount.
Write the comparison as four values with timestamps. A record such as “feed €24; page €29; markup €24; cart €29” immediately narrows the investigation.
4. Identify Which System Is Wrong
Assign ownership to each surface. The feed exporter, theme, promotion module and cached product page may produce their values independently.
If the public page and cart agree but the feed differs, inspect the exporter and its schedule. If the visible page differs from its structured data, ask the theme or module owner to trace both render paths.
If the cart differs from the product page, investigate the commercial configuration before making an advertising-only correction. Customers need a consistent purchase price, not just a clean diagnostic panel.
Avoid changing several components at once. Make one controlled correction, rebuild the affected output and repeat the same comparison so you can identify what actually resolved the mismatch.
Keep a short decision log: observed inconsistency, responsible component, change made and resulting values. It becomes a useful reference when the next campaign changes prices again.
5. Check Sale Timing and Customer Conditions
Review the offer at the start and end of a promotion. A correctly scheduled shop discount can still disagree with a feed generated before the campaign began.
Record the timezone used by the shop, the feed data and any campaign scheduling tool. A one-hour difference can matter at a short promotion's boundary.
Distinguish a public product price from a conditional benefit that requires a code, membership or a particular basket. Do not submit a conditional result as an ordinary unconditional price without checking the channel's supported treatment.
The Merchant Center inconsistency guide identifies common causes including variant selection, sale timing and offer differences. Use it to classify the issue, then trace the actual values in your installation.
For the promotion itself, refer to the existing Black Friday discount guide. A valid margin calculation and accurate channel representation are separate checks.
6. Inspect Cache and Dynamic Rendering Behaviour
Ask the technical owner to inspect what a fresh request receives before client-side interactions. A value corrected only after a script runs may not match the data observed by the channel's crawler.
Compare a freshly generated page with any cached version served to visitors. Check whether a price change invalidates the relevant product, combination and language variants.
Do not clear every cache repeatedly without identifying the missing invalidation. A temporary correction that returns after the next price update is evidence that the update path still needs work.
Record the test without introducing crawler-specific prices. The purpose is to present the same truthful offer consistently, not to create a special version solely for approval.
Use the existing PrestaShop performance guide when coordinating caching changes so the fix also respects the store's operational requirements.
7. Correct the Source and Submit a Controlled Update
Update the field, mapping or schedule responsible for the mismatch. Generate a small sample export and inspect the affected row before sending a complete catalogue update.
Reopen the public page and cart after the change. Save the four-value comparison again so the team can show that the submitted and purchasable offers now agree.
Submit the update through the feed's supported process and check the current Merchant Center status after processing. Record a pending review as pending, not as a failed fix or guaranteed approval.
If a review option is available for the specific issue, follow the current instructions shown in the account. Do not guess a menu path or resubmit unrelated items repeatedly.
Escalate with the item ID, URL, timestamps and comparison evidence if the issue persists. Those details are more useful than a screenshot saying only that the account has a warning.
8. Add a Small Recurring Offer Audit
Choose representative products for a repeatable comparison after catalogue and promotion changes. Include variants, discounted items, minimum quantities and different supported currencies where relevant.
Define an alert threshold for the number of affected offers or the commercial importance of a single failure. A mismatch on a major advertised product may deserve attention before a larger group of inactive items.
Keep export success separate from offer accuracy. A file can upload successfully while containing the wrong price for every variant.
Review the update schedule when price frequency changes. A daily feed process may no longer fit a catalogue whose promotions now change several times within a day.
9. Common Mismatch Problems and Fixes
| Problem | Likely cause | What to check or change |
|---|---|---|
| Advertised price belongs to another size | Landing URL opens a default combination | Correct the variant URL and ID mapping |
| Sale starts correctly but feed stays old | Export timing is disconnected from promotion timing | Coordinate updates and inspect timestamps |
| Markup differs from the visible price | Two components calculate or cache the offer separately | Trace both rendering paths |
| Admin sees the right price but customers do not | Customer context differs | Test the public URL with the intended market settings |
| Warning returns after each update | A manual edit is overwritten by the source feed | Repair the upstream value or mapping |
10. Offer Consistency Checklist
- The affected item ID and notification time are saved.
- The exact product, variant and quantity are identified.
- Feed, page, structured data and cart were compared together.
- Currency, market and customer context are consistent.
- Sale schedules and timezones have been checked.
- The correction was made in the responsible source.
- The new export and public offer were inspected.
- Recurring checks cover representative complex offers.
Frequently Asked Questions
Should I edit the price directly in Merchant Center?
Only if that is the intended source-management process for the offer. If a connected feed owns the value, a manual edit may be overwritten, so identify and correct the upstream cause.
Why can two correct prices still produce a mismatch?
They may describe different variants, quantities or customer conditions. The listing and its landing page must represent the same offer, not merely two valid prices from the catalogue.
Does clearing the cache solve the issue permanently?
Only if the underlying update process then keeps the relevant output current. If the mismatch returns after another price change, investigate invalidation and generation rather than repeating a temporary workaround.
How quickly will an affected product be approved again?
Processing and rechecking take time and depend on the issue and account state. Follow the current status and instructions in Merchant Center without promising an exact approval time to the marketing team.
Can the feed upload succeed while product data is wrong?
Yes. Successful transmission proves that data reached the service, not that every offer matches the storefront. Keep content validation as a separate check.
What should I include when asking a developer for help?
Provide the item ID, exact URL, product and combination references, market context, timestamps and the four compared values. Include reproducible steps and identify which component currently supplies each value.