Disapproved for a price mismatch: find the cause and fix it for good

The pattern of disapproved products reveals the cause

When products are disapproved for a price mismatch, do not start by correcting the price in Merchant Center. First export the affected products and look at what they have in common. In my view, the pattern narrows down the cause faster than any individual check, and it decides whether you are repairing a feed, a template or a promotion schedule. You get the list in Merchant Center under Products, in the "Needs attention" tab, as a CSV download.

The table is my assessment, and every match remains a hypothesis until a single product confirms it. With only a handful of affected products, a pattern tells you little, so go straight to checking them one by one.

How does Google check the price?

Googlebot compares the price attribute with the prices on the landing page and in the markup, and any mismatch can lead to disapproval. It reads the HTML that the web server returns. According to Google, data that only arrives via JavaScript after the page has loaded triggers an error. So this can happen: you see the right price in your browser because a script inserted it, while the crawler reads a different one.

The order of checks for an affected product

Take one product from the pattern, ideally one with a large price gap to the default, and work from the feed row to the page:

1. Save the feed row. Note the ID, price, sale price, currency and the value of link. Google checks exactly this URL, parameters included, not the page you reach through the navigation.
2. Read the server HTML. Open the URL in a private window and use "View page source", not the developer tools, because they show the result after JavaScript has run. Search for the amount from the feed and for any other price.
3. Compare the markup. The price in the structured data must match the most prominent price on the page, and for variants it must also match the variant displayed.
4. Test what the bot sees. For differences between the price shown to users and the price crawled by bots, Google points to the Rich Results Test. If it shows a different price or currency from your browser, the problem lies in how the page is served. A matching price there does not replace step 2.
5. Name the wrong source and change it there. If only the feed differs, the correction belongs in the data source. If the page differs, it belongs in the shop or the template.

Whether the problem comes back depends on the last step. Overwriting the price by hand in Merchant Center treats a symptom, in my view: the next upload or sync brings the disapproval back because the cause was left untouched. A manual correction only makes sense if the feed really was wrong just once.

What role do variants play?

According to Google, three rules apply to variants together. The feed price must match the variant that is pre-selected when the page loads, the submitted URL must select that variant automatically, and the markup must match the visible variant. If one of them fails, your feed is correct and the product is still disapproved.

Such cases also turn up in retailer forums, for example an export that always linked to the main variant, or variant URLs with the price of the first variant in the source code. Both reports concern old shop versions, but the place to check is the same.

Always test the variant with the largest price gap to the default. Variants at the same price hide the error, because incorrect markup happens to show the right amount there. How to set up variants in the feed is covered in the article on colours and sizes in the feed.

What about caching and tiered prices?

Google does not address either explicitly; what follows is my own deduction. If a page cache serves old HTML and a script in the browser inserts the new price, every human sees the right value and the crawler probably sees the old one. The test is simple: change the price of a test item and fetch the source code without logging in, once straight away and once after the feed run. If the old amount is still there, the cache has to be cleared whenever prices change, and before the feed export. If the order is the other way round, every price change opens a short window with a mismatch.

With tiered prices, the feed price has to match the most prominent price. If the page says "from €8" in large type and the feed says €10, you have created the conflict yourself. I advise showing the price for a single unit as the main price, using the same value in the markup and placing the tiers in a table below. For a minimum order quantity, the rule is clear: submit the price for the minimum quantity, not the unit price. Suppose a shop sells screws in quantities of 100 or more at €0.20 each: the feed says €20, and the page may show the minimum quantity plus the unit price.

According to Google, member prices belong not in price but in the loyalty_program attribute. If the target country requires prices including VAT, VAT must also be included on the landing page and at checkout. According to Google, IP detection is against its guidelines and can interfere with the crawler. If you run several prices across the DACH region (Germany, Austria and Switzerland), in my view they belong on separate country URLs with the matching currency and their own feed, not on a switch based on IP.

Why automatic updates do not solve the problem

According to Google, timing is a common reason: the shop changes the price and Merchant Center does not know about it yet. For frequent changes, Google recommends scheduled uploads or the Merchant API. With promotions, there is also the sale period, where even a wrong start date or time zone leads to an incorrect price. Suppose your promotion ends at midnight and the feed runs at 6 am: that leaves a six-hour gap, and a crawl during that time finds the mismatch. Set the period in the feed rather than waiting for the next run. There is more on this under sale prices and strikethrough prices.

Automatic item updates are no substitute. According to Google, they fix sporadic mismatches for a small share of products and may not work for products whose price changes more than once a day. The product can then be disapproved instead of updated, and with many mismatches Google can stop the updates. If there are several strikethrough prices on the product page, Google advises against automatic price updates. I see them as a safety net for individual cases, not as a plan for dynamic pricing. If your export solution cannot reach the frequency you need, that is an argument in the comparison of shop plugin or feed tool.

How long does reapproval take?

According to Google's help page, Googlebot recrawls disapproved products over the following hours or days and reapproves them once the prices match. A requested website review can take up to 12 hours, you cannot submit a new request during that time, and the number of reviews may be limited. If the domain is at capacity, crawling can take longer.

So only request the review once the order of checks runs cleanly on several products. A request on a hunch costs you up to 12 hours and, in the worst case, one of a limited number of attempts. Also check the timestamp of the notification first: Google reports the state at a specific point in time, and the product may have been approved again since. Information as of November 2026; menu names may differ.

The order in which to work through the list

Sort the CSV by revenue, not by number of errors. Suppose 400 products are disapproved and 30 of them bring in 70% of Shopping revenue: if the cause is a template, you fix them all at once, and the sorting only decides which products you spot-check. If the causes are individual, those 30 are today's job and the rest comes afterwards.

Waiting is the more expensive option, because the risk does not end with the individual product. According to Google, price mismatches of this kind can lead to account suspension, and then the entire range is offline, not just part of it. What to do in that case is described in the article on Merchant Center suspension. If the number of disapprovals is growing instead of falling, I would put everything else on the feed on hold until the cause is found. How the topic fits into the wider system is shown in the guide to Shopping and Merchant Center.

If your feed runs through a third-party platform, correction and review request may be handled there rather than in Merchant Center. Checking the server HTML remains your own job either way.