How do I fix price mismatch errors in Merchant Center?

Merchant Center compares the price you submitted in the feed against the price it finds when it visits the landing page. When they differ, the item is flagged and can be disapproved until they agree.

This matters more than it looks. It is not a formatting complaint. The point of the check is that a shopper clicking your listing should find the price they were shown, so a mismatch is treated as a broken promise rather than a data error.

The crawler reads the page in a few ways: the structured data on the page, and the visible price in the markup. Where these disagree with each other, or with the feed, you get the flag. So there are three prices in play, not two, and all three have to agree.

Start by finding out which one is wrong. Open the flagged product's landing page in a private window, from the country the feed targets, and compare what you see against the feed value. Then check the page's structured data. Nine times out of ten this narrows it immediately, and it saves you from fixing a feed that was correct all along.

A stale feed is the most common. The price changed on the site and the feed has not refreshed since. On a store that runs frequent promotions, a daily feed is not enough, and a sale launched in the morning will produce mismatches until the next update.

Tax handling is second. Prices shown including tax to one audience and excluding it to another, or a feed submitted with one convention while the page displays the other. Requirements differ by country, so this is easy to get wrong on a store selling into several.

Currency is third. A store with a currency selector where the feed states one currency and the page displays another to the crawler. This also covers rounding, where a converted price is displayed slightly differently from the value submitted.

Discount timing is fourth. A discount applied in the cart rather than on the product page means the page price and the eventual price differ, and the feed may carry either.

Then the smaller ones: a compare-at price being read instead of the sale price, member or logged-in pricing that the crawler never sees, prices that include or exclude shipping inconsistently, and rounding differences between systems.

A surprising share of mismatches are not mismatches at all. The crawler could not read the price, so it fell back to something else or found nothing.

Check three things. First, whether the landing page is accessible to automated visits. Bot protection, rate limiting, geographic blocking or a rule in your robots file can prevent the page being fetched properly, and the symptom looks like a price problem.

Second, whether the price is present in the page as delivered, or only added afterwards by scripts. A price that only appears after a script runs may not be read reliably. The structured data block is the safeguard here, because it states the price in a form that does not depend on rendering.

Third, whether the structured data is correct. A product block with a stale price, a wrong currency, or a price taken from the first variant rather than the one the page shows will actively mislead the check. Validate a few products and compare each field against the visible page.

If your site shows different prices by visitor location, make sure the version served to an automated visit from the target country matches the feed for that country.

Once the causes are fixed, the lasting solution is a feed that updates fast enough that the two cannot drift apart.

Increase the refresh frequency to match how often your prices change. A store that runs occasional promotions can live with a daily update. A store changing prices through the day cannot, and needs a connection that pushes changes as they happen rather than a scheduled file fetch.

Where your platform supports it, use the mechanism that lets Merchant Center update price and availability from the page automatically between scheduled feed fetches. It is a safety net rather than a substitute for a good feed, and it reduces the window where a mismatch can exist.

Then build a check into your promotion process. Before a sale goes live, know how the price will reach the feed and how long that takes. Most mismatch incidents happen on the first morning of a promotion, and they are entirely predictable.

And watch for the reverse case at the end of a sale, where the site returns to full price and the feed still carries the discount. That version produces a worse shopper experience and is the one most likely to be flagged quickly.

Selling into several markets multiplies the ways a price can disagree with itself, and it is where mismatch errors become persistent rather than occasional.

Each target country needs its own feed data with the right currency and the right tax convention for that market. Submitting one feed with one price and hoping it works everywhere produces mismatches in every market except the one it was written for.

Check what the crawler sees per country. If your store redirects visitors to a local storefront based on location, an automated visit from the target country needs to arrive on the version of the page whose price matches that country's feed. Redirect logic that sends everything to a default storefront is a common cause of persistent mismatches on secondary markets.

Watch rounding and conversion. Prices generated by a live currency converter can shift between the moment the feed is built and the moment the page is read. Fixed local prices are more stable and easier to keep consistent, and they usually look better to shoppers as well.

Finally, keep shipping and tax settings at account level accurate per country, since these affect the total a shopper is shown.