A price mismatch in Google Merchant Center can start with something ordinary: a sale ends, one colour sells out, or your website updates before the product feed does. The customer sees one offer on Google and another when they reach your shop.
The useful fix is to trace one affected product through the whole buying journey. Check the data Google received, the exact product page, its structured data and the checkout. Then repair the process that made them disagree.
This guide covers online products in Shopping ads and free listings. Local inventory and in-store collection have separate requirements.
Start with the issue and an affected product
Open the Needs attention area in Merchant Center and establish whether the problem affects individual products or the account. Read the issue details and any warning deadline. Google’s review guidance explains where those issues appear.
For your investigation, record the affected item ID, its submitted URL, the relevant price or stock value and the data source supplying it. Add the time of your checks. This gives your shop manager, developer and advertising team a common example to work from.
Choose a small but varied sample: an ordinary product, a sale item, a product with variants and an unavailable item. These are practical test cases, rather than evidence that the rest of the catalogue is correct.
Compare four versions of the same offer
Use the exact URL submitted for that item. Opening the parent product page through your shop menu may select a different variant and conceal the problem.
| Checkpoint | What to record |
|---|---|
| Merchant Center | Processed product values, source and submitted link. |
| Landing page | Selected variant, visible price, currency and availability. |
| Structured data | Product identity and the machine-readable offer values. |
| Basket and checkout | The same variant’s purchase price and whether it can be ordered. |
Make these checks close together. If someone changes the catalogue halfway through, you are comparing different moments. A private browser window is also useful for checking the experience without your existing login or saved preferences.
Check UK pricing, tax and pack quantities
Google requires the submitted amount and currency to agree with the landing page and checkout. For the United Kingdom, its price specification requires any applicable VAT to be included. This applies to B2B-focused retailers too.
If your trade shop shows both net and gross prices, check which value the feed exports and which value the product markup describes. Make the required VAT-inclusive price clear throughout the journey.
Also check what the customer must actually buy. A compulsory pack needs the price of that pack; a minimum purchase quantity needs the price for that quantity. Delivery costs belong in Google’s delivery settings or delivery attribute, rather than the product price.
For troubleshooting, separate a wrong product price from a wrong delivery charge. They need different corrections, even though both can make the checkout total surprising.
Make each variant land on the right choice
A black bag and a tan bag may share a product page, but they are different offers when their prices or stock differ. Google explicitly identifies variant preselection as a possible cause of price mismatches in its price mismatch guidance.
Follow the submitted link for each affected variant. Does it open with the advertised colour and size already selected? Does its price match that specific choice? Can that choice be bought?
As a practical check, copy the URL into a fresh browser session instead of relying on a selection remembered from your previous visit. Ask your developer to inspect how the shop integration generates variant links if they all open the default option.
Review personalised products too. An image showing an engraved version should not lead to an offer whose submitted price excludes the engraving. The product being presented and the product being priced must agree.
Test both ends of a sale
During a sale, Google supports a separate sale_price alongside the normal price. Its sale price requirements say to keep submitting the normal price when using that attribute, show both prices on the landing page and keep the sale purchase price consistent at checkout.
Check when the discount begins and ends in your shop and product source. The sale price effective date supports a start and end time with a time zone. If the zone is omitted, Google defaults to UTC.
Our recommended test is to inspect one discounted product when the sale starts and again when it finishes. Confirm that the public page, checkout, structured offer and processed Merchant Center product all move to the appropriate price. A successful sale launch does not prove the return to normal pricing works.
Describe availability as an orderable offer
Availability needs to match the page, checkout, structured data and submitted product data. Google’s availability specification distinguishes the main states:
in_stock: you accept orders and can fulfil the purchase.out_of_stock: the product is unavailable for purchase or you are not accepting orders.preorder: you accept orders for a product that has not yet been released.backorder: an existing product is currently unavailable, but you accept orders for later dispatch.
Pre-orders and backorders require an availability date, with the relevant expected date visible on the landing page. Do not describe every product awaiting replenishment as a pre-order.
Check at variant level. Stock of the tan bag does not establish availability of the black one. As an operational test, follow an unavailable variant through to the basket and check whether your shop’s order behaviour agrees with the state you submit.
Inspect the data underneath the page
The visible page can look correct while its machine-readable offer is wrong. Ask your developer to compare the product’s structured data with the selected variant, current price, currency and availability.
Google’s Merchant Center structured data guidance says the markup must match what users see and be present in the HTML returned by the server. For this matching process, it must not depend on JavaScript adding it after the page loads. Where several offers appear, identifiers such as SKU or GTIN help match each offer to the submitted product.
Check who generates the markup. Your theme, shop software and an SEO extension may each contribute product information. If multiple offers conflict, ask the developer to establish which output is intended and correct its source.
Use Google’s Rich Results Test as part of that investigation, then inspect the actual values. Passing a technical validation check does not establish that the price reflects today’s offer or that the shop has stock.
Check whether product updates are reaching Google
Identify the route supplying your products: a scheduled file, a shop integration or custom software. Our recommendation is to check the last successful update and the values processed for the affected item, rather than assuming an enabled connection is working.
A current check for older API integrations
As checked on 4 October 2026, Google’s current sunset guidance confirms that Content API for Shopping reached sunset on 18 August 2026. From 1 September, requests without an active extension began failing intermittently with HTTP 410 Gone. This is a progressive degradation process, rather than proof that every connection stopped on the sunset date.
If custom software still uses that API, ask its maintainer to check logs, migration to Merchant API and any approved extension. For third-party ecommerce platforms, Google says the platform partner manages migration. Ask your provider about a failing sync before commissioning custom migration work.
Understand the limits of automatic updates
Merchant Center automations can use your website’s product information to correct some price, sale price, availability and condition discrepancies. Google’s automation guidance says they do not replace regular accurate product submissions. Frequent changes or widespread mismatches can still lead to disapprovals.
Treat repeated automatic corrections as a reason to inspect the source. If the website’s own markup is wrong, it is not a dependable fallback. Correct the shop data, markup and update route before relying on automation to bridge occasional gaps.
Verify the repair before requesting a review
Repeat your four-point comparison after the correction has reached Merchant Center. Test similar products that use the same template or update process. Keep a short record of the cause, the change and the checks performed.
Then follow the action offered for the specific issue. Google’s review instructions distinguish fixing an issue from disagreeing with a finding. A website check or review may be available; reviews can take up to seven working days. Unsuccessful attempts can trigger a cooldown, with its expiry shown in Needs attention.
A repair is ready for review when the customer journey and submitted offer agree. Repeatedly pressing the review button while the source remains inconsistent adds no useful evidence.
Assign an owner to the ongoing product sync and include sale endings, stock changes and variant links in routine shop checks. That makes the next investigation easier and helps keep the offer customers find aligned with what you can sell.
If product disapprovals keep returning, BuzzBoost can help investigate where your paid media, product data and website integrations meet. Tell us what Merchant Center is flagging, which shop platform you use and how products are supplied, and we can discuss the next step.
Featured image: AI-generated editorial artwork, not a photograph of a real BuzzBoost office, client or result.
