Price Accuracy Violations in Google Merchant Center: Why "Misleading Price" Gets Flagged

What "Price Accuracy" Means Specifically

Google's price accuracy policy requires that the price attribute in your product feed match the price a shopper actually pays at checkout for the item alone, under normal purchase conditions, at the moment the feed data is live. This sounds simple, and most sellers assume they comply because their feed price and their product page's displayed price look identical when they check manually. But the policy is checked programmatically and continuously, at a much higher frequency and precision than a manual glance catches, and it accounts for scenarios a seller rarely thinks to test — like what happens to price when a specific promo code auto-applies at checkout, or what a shopper on a different account tier or membership status actually pays.

A price accuracy violation is issued at the product or account level when Google's crawlers detect a mismatch between the submitted feed price and the landing page price on a meaningful sample of checked products, not from a single one-off discrepancy.

How It Differs From General Misrepresentation

Sellers often conflate price accuracy violations with the broader misrepresentation policy, but they are tracked and enforced somewhat differently. Misrepresentation is Google's umbrella policy covering false claims about a business, product, or service — pricing is one subset of it, alongside false urgency claims, fake reviews, and misleading business identity. A price accuracy flag specifically targets the price field's correctness and is often caught earlier and more narrowly (sometimes as a product-level disapproval rather than a full account suspension) before it would escalate into a broader misrepresentation determination if left unresolved. Understanding this distinction matters because the fix for a narrow price accuracy flag is usually much faster and more contained than the fix required for a full misrepresentation suspension — catching it at the price-accuracy stage and resolving it quickly can prevent it from compounding into the more serious designation.

The Most Common Causes

• Stale cached feed data — your feed refresh cadence runs slower than your actual price change cadence, so Google's crawl catches a price that changed on your site an hour ago but has not yet propagated to the next feed fetch
• Membership or loyalty-tier pricing — your product page shows a lower price to logged-in loyalty members by default (via a cookie or account detection), while an anonymous crawler or a first-time shopper sees a higher price — the feed price must match what an anonymous, non-member shopper actually pays
• Auto-applied cart discounts — a sitewide cart-level discount that automatically applies at checkout but is not reflected in the per-unit price shown on the product page itself can create a mismatch depending on how Google's price-check crawls handle cart-stage versus product-page-stage pricing
• Geolocation-based pricing — showing different prices to shoppers by detected location without a matching feed structure per target country
• A/B testing pricing experiments — running a live pricing test that serves different prices to different site visitors without excluding Google's crawler traffic from the experiment

Tax and Shipping: The Silent Price Accuracy Killer

One of the most common causes we see is not actually about the item price at all — it is about what the policy allows to be excluded. Google's price accuracy policy generally expects the price attribute to reflect the item price, with tax and shipping handled through separate, dedicated feed attributes and settings rather than being folded into (or omitted from) the price field inconsistently. In regions or product categories where tax-inclusive pricing display is standard practice (some EU markets, for example), a feed configured with a tax-exclusive price while your site displays a tax-inclusive price to shoppers creates exactly the kind of mismatch this policy flags — even though from the seller's perspective, "the price is the price we always charge."

Setup	Risk level
Feed price = tax-exclusive; site displays tax-inclusive; no tax settings configured in Merchant Center	High — direct mismatch a crawler will catch
Feed price = tax-exclusive; Merchant Center tax settings correctly configured per region; site displays consistent with configured settings	Low — this is the compliant pattern in most markets
Feed price = tax-inclusive; site displays tax-inclusive uniformly; no separate tax field used	Low if consistent across the entire catalog and region

Sale Price and Strikethrough Pricing Rules

Sale pricing has its own specific accuracy requirements beyond the base price policy. The sale price effective date range in your feed must match the actual dates the discount is live on your site — a sale that ends on your site a day before the feed's sale_price_effective_date range says it ends will show shoppers an ad promising a discount that is no longer available, which is both a price accuracy issue and a poor shopper experience that generates the complaint volume Google's systems separately monitor. Strikethrough ("was $X, now $Y") pricing additionally requires that the "was" price reflect a genuine, recently-charged price, not an inflated reference price never actually charged — a practice regulators in several markets (including under EU and UK pricing transparency rules) have specifically targeted, and one Google's policy independently prohibits regardless of local regulation.

Currency and Multi-Region Pricing Issues

Multi-country sellers frequently trigger price accuracy flags not through actual pricing dishonesty but through currency and regional feed configuration gaps — submitting a single feed with one currency to a Merchant Center account targeting multiple countries whose sites actually display local currency pricing calculated by a live exchange-rate plugin. If your feed's static price does not account for daily exchange-rate fluctuation your site applies dynamically, a small but persistent mismatch accumulates that a crawler in a specific region will eventually catch, even though the discrepancy has nothing to do with intentional pricing manipulation.

Fix Checklist

Ongoing Monitoring to Prevent Recurrence

Because price accuracy issues are usually structural (a sync gap, a tax configuration, a pricing logic edge case) rather than one-time mistakes, a single fix without ongoing monitoring tends to recur. Set up a recurring automated spot-check — even a simple weekly script that pulls a random sample of live feed prices and compares them against the corresponding live product page prices — so a regression gets caught by your own monitoring before Google's crawlers catch it and issue a fresh disapproval.

Who Actually Runs the Price Check

Price accuracy enforcement is largely automated: Google operates crawlers that periodically visit the landing page linked from your feed's link attribute and compare the price rendered on that page against the feed's submitted price field, at a sampling frequency and scale far beyond what any manual QA process could replicate across a large catalog. This automation is worth keeping in mind for two reasons. First, it means a mismatch is not judged on intent — the system does not distinguish between a deliberate bait-and-price change and an honest sync delay, so the fix is the same regardless of cause: close the gap structurally, quickly. Second, it means the crawl can catch state-dependent or session-dependent pricing quirks (like a geolocation redirect, a first-visit popup discount, or a cookie-based returning-customer price) that a seller manually spot-checking their own site while logged in or from a familiar location and IP might never actually encounter themselves.

For that reason, testing your own price accuracy periodically from an incognito browser session, ideally from more than one region if you sell internationally, is a more reliable self-check than testing from your own logged-in, cookie-laden browser.

Frequently Asked Questions

How many mismatched products trigger an account-level flag versus a per-product disapproval? Google does not publish an exact threshold, and it varies by account history and severity, but a small number of isolated mismatches usually stays at the per-product disapproval level, while a pattern across many SKUs or a repeated violation after a prior warning is more likely to escalate to account-level review.

Does a temporary price-matching tool count as a violation? If the price-matching adjustment reflects what the shopper actually pays at checkout and your feed updates promptly to match, it is not a violation. The issue is only the lag or mismatch between what is submitted and what is charged.

How do I check my whole catalog at once? A manual per-SKU check does not scale past a small catalog. Our free scan at gmcunbanned.com checks feed-to-site pricing consistency patterns as part of a full compliance review.