Suspended for price mismatch

This is the least mysterious suspension reason and the most useful one to receive, because the cause is almost always provable rather than arguable. Google fetched your landing page, compared it against the row in your feed, and the two numbers were different. That is a misrepresented offer by definition, and no amount of explanation changes the comparison.

The useful question is not whether they differ. It is how.

What the policy actually requires

The price and availability a shopper sees when they arrive must match what the advert promised. Google enforces this by fetching the landing page and comparing it against your feed — the same comparison anyone can run, which is why this cause is diagnosable rather than a matter of opinion.

The requirement extends further than the headline price:

• Currency counts. A page that declares one currency in its structured data and another in its feed row is a mismatch even when the digits agree.
• Availability counts. A row that says in stock against a page that says sold out is the same class of fault.
• Sale pricing counts. A sale price identical to the regular price is a promotion that does not exist.

Two consequences that merchants routinely miss:

1. Google checks the page, not your database. Whatever your admin screen says is irrelevant. What matters is the number rendered to a visitor who arrives without cookies, without a chosen country, and without a session.
2. A mismatch on a minority of rows still suspends the account. The check is per product, but the enforcement is per account.

Read the shape, not the count

This is the part worth slowing down for, because it decides what you fix.

Scattered differences across a handful of rows mean data entry, a stale cache, or a price change that has not propagated yet. You fix rows.

One constant ratio across every affected row means a process. Something is applying a systematic transformation — a tax rate, a currency conversion, a margin — at the moment the feed is generated. You fix one setting, and every row follows.

Critical Feed check

A single constant ratio across every affected row

A systematic factor reads as a pricing practice rather than a mistake, and it means one process is wrong rather than many rows.

Evidence

page

126.79

feed

107.52

ratio

1.17925 — identical on all 53 compared rows

(1 + 25 %) ÷ (1 + 6 %) = 1.17925. The page charges one VAT rate and the feed calculates with another. Several countries can share the same rate, so the ratio names the mechanism but not the country.

Measured 17 August 2026 on a live store.

A constant ratio is the giveaway. Data entry mistakes scatter; arithmetic does not.

The trap is assuming the cause is your pricing. It usually is not. The customer-facing chain is often entirely correct — shoppers see the right amount, pay it, and are never charged something else — while the fault sits in a metadata export nobody looks at.

What usually lies behind it

The wrong tax or currency context at generation time

The single most common mechanism. Feed generation runs under a context — a country, a currency, a tax class — and inherits the wrong one. Everything downstream is consistently wrong, which is precisely what makes it findable.

Live currency conversion instead of prices set for the market

The tell is the cents. Prices set by a human cluster on round endings. Prices converted at a live rate scatter across every possible cent value. One shop showed conversion artefacts on 90 % of its prices, measured 17 August 2026 — a number that says “nobody set these” more clearly than any single row could.

Sale prices that expired in one system and not the other

The shop’s campaign ended. The feed was generated before it ended, or caches a value that is no longer served. Every product that was on sale now advertises a price the page will not honour.

A price off by a factor of ten

Rarer, and usually a decimal separator read as a thousands separator somewhere in the export chain. Worth checking separately because it hits high-value articles hardest and is easy to miss in an eyeball scan of a long file.

A thousands separator the parser does not expect

Only affects your most expensive products, which is exactly why it survives so long. One file carried it on 0.55 % of rows — 22 of 3,965, every one of them high-value, measured 17 August 2026.

Rounding applied in one place only

The page rounds to whole units for display while the feed submits two decimals, or the reverse. Small, systematic, and enough to fail an exact comparison.

A sale price equal to the regular price

A promotion that is not a promotion. Often a plugin writing the sale field unconditionally. In the EU this also touches the Omnibus rules on prior-price claims, which is a separate exposure from the Merchant Center one.

Rows pointing at pages that no longer exist

Not a price mismatch strictly, but it lands in the same family: the comparison cannot be made, and a row whose landing page 404s is an offer that cannot be honoured.

What the free Quick Scan can see of this

Measurable from outside, without any access:

• Any product feed served publicly on your domain, parsed row by row.
• Each row’s price, currency, availability and title compared against the structured data on the matching landing page.
• Whether the differences are scattered or systematic, stated as the ratio.
• The share of prices carrying live-conversion artefacts.
• Decimal and thousands separators against the market’s norm.
• Sale prices identical to regular prices.
• Rows whose landing pages return 404.

Not measurable from outside:

• Which of the files we found is the connected one.
• What Merchant Center’s own price and availability data currently holds, and when it last fetched.
• Whether a reviewer saw a state that no longer exists.

How to narrow it down yourself

1. Find every feed file your server responds to, not just the one you think is connected.
2. Open the connected one in Merchant Center and note its URL exactly. This is the step that decides whether the rest is meaningful.
3. Take twenty rows and compare them by hand against the pages, logged out. Twenty is enough to see whether the difference is scattered or constant.
4. If it is constant, divide. The ratio is the quotient of two VAT rates, not a rate itself: 1.17925 is (1 + 25 %) ÷ (1 + 6 %), and 1.05042 is (1 + 25 %) ÷ (1 + 19 %). Anything near a currency pair is a conversion instead.
5. Fix the process, then regenerate once — not four times as you go.
6. Re-measure after the regeneration has run, logged out and after a cache purge. This is the number the appeal needs.

What we do

We compare your feed against your pages row by row, separate scattered differences from systematic ones, and name the factor when there is one. Every finding carries the two amounts, the ratio, and the policy clause. Where a fix needs a settings change we write the click-steps; where it needs code, the card carries the complete block with the backup step before it.

Then, once you have done the work, we re-run the same comparison so the appeal carries a before number, an after number and the date each was measured.

Finding out whether this is your cause

The free Quick Scan fetches your storefront the way Googlebot meets it and, when a feed is served publicly, compares the rows against the pages. If a constant ratio is present, it appears with both numbers and the factor between them.

It runs while you wait, and it costs nothing — including when it tells you the cause is somewhere we cannot see.