A correct price in the product feed is not enough if Google finds a different price in structured data, a preselected variant or a cached product page. This article explains how to trace the discrepancy and define the requirements for a solution before products disappear from ads and free listings.
A product may show the correct promotional price in both the product feed and the browser yet still be blocked because the preselected variant, outdated JSON-LD code or a customer-specific price gives Google a different answer. When you encounter a Google Merchant Center price mismatch, the issue is therefore rarely just the amount stored in the business system. The key question is which price is actually published for the correct product, variant, market and currency at every stage Google can access.
The commercial consequences can quickly become significant. Disapproved products may disappear from Google Shopping ads and free product listings, while the team spends time changing feeds that may not be the actual source of the problem. For an ecommerce business in 2026, checking what the admin interface displays is not enough. Troubleshooting must follow the price from the processed product data in Merchant Center through to the structured data, rendered page and shopping cart.
This is how we would approach the problem: isolate one disapproved item, restrict the test to a specific variant and market, and then compare what each system actually outputs. This makes it possible to distinguish a data error from a variant issue, rendering problem or delayed cache without making broad changes based on guesswork.
A Google Merchant Center price mismatch can arise after the feed has been submitted
The product feed is not the definitive source of truth but one of several price signals. Google can compare the price and sale_price attributes with structured product data, visible content on the landing page and the page that remains after JavaScript has run. The currency, market and selected variant must also correspond. A single outdated price signal may therefore be enough to create an inconsistency, even when the underlying value in the ecommerce platform is correct.
The first thing we examine is the processed item value in Merchant Center, not only the export file from WordPress, WooCommerce, Shopify, an ERP system or a separate feed generator. Between the export and the final value, supplemental data sources, feed rules, scheduled imports and automated processing may have affected the price. If the source file shows one value but the product details in Merchant Center show another, the problem is likely in the intermediate data layer. Changing the product page template will not help in that case.
This difference is easy to overlook when several systems use plausible names for the same thing. The platform’s “current price” may become price in one feed, while a feed rule simultaneously adds a promotional value to sale_price. The landing page may display the promotional price prominently, while the JSON-LD code contains only the regular price in Offer.price. The page looks correct to the customer. To a machine, there are two competing statements about the offer’s actual price.
A sale price must tell a consistent story. When sale_price is active, it should match the price at which the visitor can clearly purchase the item, while the regular price may be displayed for comparison. At the same time, the offer in the structured data must describe the current purchasable price. If only the struck-through regular price is machine-readable, Google may interpret the landing page as more expensive than the product data, even though the visual promotional price is correct.
The currency is just as important as the amount itself. The feed’s currency code must match priceCurrency in the JSON-LD and the currency displayed at the URL Google receives. The same type of discrepancy can occur if the product feed contains a consumer price including VAT while the page initially displays a different price format, or if a currency selector changes the market after the page loads. An amount without the correct market context is not the same offer.
Outdated caches make the chain more difficult to interpret. The ecommerce platform may have published the new price while a page cache still serves old HTML and a CDN continues to distribute that version. A separate cache for structured data may also lag behind the visible interface. As a result, the administrator, customer and Google encounter different generations of the same product page.
To assess the scope, the business should track metrics such as the number of affected product IDs, the markets and variants involved, how long the price takes to move from the source system to processed product data, and which data source deviates most often. It is also useful to connect this information to the products’ actual contribution to sales in your own analytics. This ensures that priority is given not only to the easiest errors but also to the discrepancies with the greatest potential impact on revenue.
Product variants cause price mismatches when the URL and preselected option do not correspond
The variant is often the actual purchasable item, while the product page is merely a shell that brings several options together. Size, colour, material, subscription length or pack size may have different prices and availability. If each variant is submitted as a separate entry, the feed ID, link, price and availability must describe the same option all the way through to the purchase button.
The most common flaw we see in the setup itself is that every feed entry points to a generic product URL. The feed may refer to a black variant, for example, while the page opens with blue selected by default. If the prices differ, Google will compare the landing page’s preselected price with the feed entry for the black variant. A shared item_group_id can help group the variants, but it does not correct a landing page that selects the wrong item.
A variant parameter in the URL is useful only if the page actually responds to it. The address may contain ?color=black&size=l while the interface component uses its own default selection. This can happen when the server reads the parameter but a React component resets the state after the page has loaded. In WooCommerce, a similar problem can occur if the variation form finds a saved browser selection and prioritises it over the URL parameter.
The correct variant must control more than the visual selection. The variant ID, visible price, availability, SKU and JSON-LD offer should all update together. If the interface shows black in size L while the structured data still describes the default variant, the discrepancy remains beneath the surface. Simply changing the colour name next to the product image is therefore not enough.
Redirects also deserve attention. A promotional link or market-specific URL may initially contain the correct variant parameter but then redirect to a clean product address where the parameter disappears. The page then selects its default variant before setting the price. Check the final address after every redirect, not just the link listed in the export file.
The test should be performed in a clean browser session without a customer account, previous cookies, local storage or a saved variant selection. This more closely resembles the impersonal environment a crawler may encounter. Open the exact URL shown for the processed product in Merchant Center and note which variant is selected before clicking anywhere. If the page requires a manual selection to reach the feed price, the link does not identify the advertised variant clearly enough.
Variant logic can also create a misleading range. A generic page may publish lowPrice and highPrice for the entire product family, while the feed advertises the exact price of a specific variant. The lowest price for another size does not prove that the current variant costs the same. For variant entries, a clear connection between the URL, selected variant and a specific Offer is often easier to troubleshoot than a generic price range.
The commercial impact is greater than a technical warning message. An incorrect default variant can affect many entries that share the same template and therefore harm both ads and free listings. At the same time, customers risk landing on a different product from the one they were promised. The technical correction therefore improves both Google’s data quality and the customer’s path to purchase.
The rendered price can differ from both the HTML source and the customer’s view
Which price is actually on the page? The answer depends on when, where and with which session it is read. The original HTML source is the server’s initial response. The rendered DOM is the page document after JavaScript has modified the content, and this is often the version that contains a price retrieved through an API or the value of a newly selected variant. The customer’s final visual state may also be affected by cookies, account details and location.
Start by searching for price, lowPrice, highPrice and priceCurrency in the page source. It may contain a JSON-LD block, embedded product data for JavaScript or a fallback price that is never visually displayed. Then use the browser’s Elements panel and run the same search after the page has rendered. If the values differ, a script has overwritten or supplemented the original information.
Outdated structured product data is particularly deceptive because customers do not need to see it. The product template may have updated the price field in the interface while leaving an older application/ld+json block unchanged. Google explains how offers and prices should be represented in its product structured data documentation. Rich Results Test can be used to see which Offer the tool extracts, although the test does not replace checking Merchant Center’s own diagnostics.
When the price comes from an API, the Network panel in Chrome DevTools must connect the page request to the response that actually sets the price. A late request may return the default variant’s price after the correct variant was initially shown. Another request may change the market or currency. By clearing storage, disabling the browser cache during testing and preserving the network log, you can see the sequence of events rather than only observing the final result.
The default state must also be stable. A crawler should not encounter an empty price, a placeholder or a value from the wrong market while the page waits for client-side code. If a business-critical price is available only after several dependencies have loaded, the page becomes vulnerable to blocked scripts, slow API responses and consent logic. A server-rendered or otherwise robust default value reduces the risk that a temporary technical issue will appear to be a genuine price discrepancy.
Consent management can affect this even when the pricing script should not depend on marketing cookies. If incorrect categorisation blocks the product API until the visitor has made a choice, Google’s renderer may encounter the fallback state. Geolocation creates a similar risk when the page automatically changes the country or currency based on the IP address. Market-specific URLs and consistent default values provide a clearer connection between the feed and page than an address that changes the offer depending on who opens it.
Signed-in customer prices, member prices and corporate agreements must be kept separate from the generally available offer. A store owner testing with their usual account may see a special price that an anonymous visitor never receives. If that price is accidentally submitted in the feed or structured data, it will differ from the public page. Conversely, the customer account may hide the fact that the anonymous page displays an outdated default price.
Google Search Console’s URL Inspection provides another view of how Google may read a page, while Rich Results Test focuses on extracted structured data. Merchant Center’s product details and diagnostics then show which offer is actually affected. The tools answer different questions and should therefore be compared rather than treated as interchangeable. A successful Rich Results Test, for example, proves that the syntax can be read but not that the variant price matches the feed entry.
Useful metrics for ongoing monitoring include how many product URLs open the correct variant in a clean session, how often the structured price differs from the rendered price and how old the price values are in each cache layer. Also monitor failed API requests and errors by market. These metrics identify systematic weaknesses without requiring the business to wait for the next round of product disapprovals.
Troubleshoot in a defined order before requesting another review
When an item has been disapproved, requesting another review is not the first step. It will not produce a lasting result if the same conflicting values are still being published. Instead, start with the disapproved product’s exact ID, target market, language, currency and landing page URL. This prevents you from troubleshooting a related variant that happens to look identical in the admin interface.
This is how we would follow the chain: first check the processed value in Merchant Center after all rules and data sources, then the final address and preselected variant in a clean session. Next, check the visible price and structured data, followed by the rendered DOM and any API requests that can change the offer. Test the shopping cart last. The cart price reveals whether the advertised offer can actually be purchased or whether additional conditions and charges change the amount.
This sequence also reveals where the correction belongs. If Merchant Center’s processed price differs from the platform export, review supplemental feeds, rules and import history. If the exact URL opens the wrong variant, the problem lies in linking, redirects or the frontend state. If the interface is correct but the JSON-LD differs, the product template or the plugin generating the structured data must be corrected.
Caches should be cleared in the same direction in which the information is published. A price change normally starts in the ERP system or ecommerce platform, passes through the feed generator and any supplemental rules, and then reaches the platform cache, CDN and the page’s structured data. Merely clearing the browser cache will not affect an outdated feed rule. Merely fetching the feed again will not affect an obsolete JSON-LD block that the CDN continues to serve.
Document every check during the same test session. The table below is an illustrative working example; the product IDs and prices are fictional and demonstrate how a troubleshooting matrix can be used. They are not measurement data from a real store.
| Product ID | Variant | Country | URL | Processed feed price | Visible price | JSON-LD price | Cart price | Currency | Test point | Status |
|---|---|---|---|---|---|---|---|---|---|---|
| DEMO-JACKA-BLA-L | Blue, L | Sweden | /jacka?color=blue&size=l |
799 SEK | 799 SEK | 999 SEK | 799 SEK | SEK | After template deployment | Old regular price remains in the JSON-LD |
| DEMO-PAKET-12 | 12-pack | Sweden | /produktpaket?pack=12 |
249 SEK | 199 SEK | 199 SEK | 199 SEK | SEK | Clean session after page load | The URL specifies the 12-pack, but the interface selects the default pack |
| DEMO-LAMPA-SVART | Black | Sweden | /lampa?color=black |
549 SEK | 599 SEK | 599 SEK | 599 SEK | SEK | After processed feed import | An outdated supplemental feed rule overwrites the platform price |
The matrix makes the discrepancy tangible. The first row points to the structured data template, the second to variant initialisation and the third to Merchant Center’s data processing. Without this breakdown, all three errors could incorrectly be described as a “Merchant Center price mismatch”, even though they require entirely different solutions.
Once the correction has been published, the entire chain must be tested again from the beginning. Confirm that the source system shows the correct price, the export contains the same value, Merchant Center’s processed product data is not overwritten and the public URL still selects the correct variant without a stored session. The visible price, JSON-LD, rendered DOM and shopping cart should then all match.
A new fetch or review comes last, once the public page and processed product data describe the same purchasable variant. This reduces the risk of the same discrepancy being detected again and gives the team a reproducible method for future price changes, promotional launches and market adaptations.
Why Google finds a different product price from the one you submit
The product feed is only one of several price signals
Google can compare the product data with the landing page’s visible price, structured data and content that becomes available after rendering. The information may also be read at different times, making synchronisation part of the problem. A new value in the feed does not mean that an old value has disappeared from the HTML, JSON-LD or CDN cache. Troubleshooting should therefore record both the value and timestamp for each source. The difference between the sources reveals more than an isolated check of whether the promotional price looks correct in the browser.
Example: Rich Results Test may extract the regular price from Offer.price while the product feed and the page’s prominent visual price field show the promotional price. In that case, the structure is readable but the content is outdated.
The variant URL must open the same option that the price refers to
A separate feed entry for each variant works only if the link unambiguously recreates the variant described by that entry. The URL parameter must initialise the interface, update the variant ID and set the correct offer in the structured data. Cookies or JavaScript must not reset the page to another default option. The technical reason is that Google compares a specific product entry with the content at the URL specified by that entry; a generic product page does not automatically provide the correct context simply because it contains the relevant variant somewhere.
Example: A feed entry for the black colour links to ?color=black, but the client-side code resets the selection to blue when the component starts. The final DOM then describes the blue variant’s price even though the address bar still specifies black.
The rendered DOM, HTML source and customer view can provide three different answers
View Source reveals the server’s initial response but not every subsequent change. JavaScript may replace the price after an inventory check, market selection or API request, while a signed-in customer may also receive a personalised value. Google’s environment normally lacks the usual customer’s session history, making the anonymous default state commercially critical. A stable page should present a correct general offer even without saved selections and then allow legitimate variant changes to update every price source together.
Example: Chrome DevTools with cleared storage may show that the correct variant price is rendered first but later replaced when a network request returns data for the default variant. The error then lies in the response handling or API parameters, not in the original HTML source.
A new review should be the final step, not the first
A review tests what has been published, not the intended correction in the admin interface. The product ID, market, currency, final URL, preselected variant, structured data, DOM and shopping cart must therefore be checked before the product data is fetched again. Caches and late API responses must also have been updated. This discipline saves troubleshooting time because a continued rejection will not be confused with a known error that has not yet been published.
Example: A practical sequence is Merchant Center diagnostics, the exact feed URL in a clean session, Rich Results Test, Chrome DevTools and the shopping cart. Only when the same offer appears at every relevant stage is there a stable basis for another fetch or review.
Ask yourself these questions before changing the product feed
Do the product feed, structured data and visible product page show exactly the same price and currency?
Do not compare only how the amounts look; consider the role of each amount. A struck-through regular price, active sale price, member price and starting price describe different offers. Check the processed Merchant Center entry, Offer.price, priceCurrency and the price displayed next to the purchase button. If one source uses another currency or shows the regular price while the others show the promotional price, you have probably found the boundary between an updated and an outdated system. Test the shopping cart as well, because a visually correct price does not help if the purchase continues at a different amount.
Does the price in the feed apply to the correct product variant?
Start with the variant’s unique ID and follow it through the export, Merchant Center and landing page. A colour or size in the product name is not enough if the same URL still opens another selection. The variant parameter should affect the interface, SKU, availability and structured product data. Check this without an account or saved browser data. If the correct price appears only after you manually select the variant, Google has received a link to a product family rather than the specific offer described by the feed entry.
Can the customer actually purchase the product at the advertised price without special conditions?
An amount that requires a discount code, membership, a particular customer type, minimum quantity or manual market selection is not necessarily the same price encountered by an anonymous visitor. Follow the journey through to the shopping cart and note which conditions must be met. If the general price differs from the feed value, the problem is not always technical synchronisation; the offer may need to be presented or submitted differently. Keep publicly purchasable prices separate from personalised contract prices and temporary discounts that become available only later in the purchase journey.
Is the price updated at the same time in the store, feed and Merchant Center?
Promotional launches and scheduled price changes often pass through several queues. The ERP system may publish first, the feed generator may run later and Merchant Center may process the data after that, while the page cache and CDN still display the previous version. Compare timestamps and the most recently processed values for the disapproved item. The goal is not for every technical event to occur at exactly the same moment, but for the transition to be managed so that the feed and landing page do not describe different offers for an extended period. Once the delay can be measured, it can also be monitored.
Does the price change depending on country, currency, VAT display or the visitor’s location?
The same URL may return different results when a currency selector, language switcher or geolocation controls the content. Check which market the feed entry targets and open the exact link without a previous market selection. The feed currency must match the JSON-LD and the visible purchasable price. If the visitor is automatically sent to another country version, the redirect and Merchant Center configuration must be analysed together. Clear market-specific URLs make it easier to ensure that Google, the customer and the product data encounter the same offer.
Start with a single disapproved product and follow the price from the product database through the feed and structured data to what the customer actually sees and pays. Once the source of the error has been identified, you can determine whether the solution belongs in the ecommerce platform, feed tool or Merchant Center configuration. If Google Merchant Center price mismatches recur across several variants, an experienced technical team such as FLAR AB can coordinate troubleshooting across data sources, the frontend, caches and the product feed without changing more components than the problem requires.
