Suspended for misrepresentation

Misrepresentation is the widest net Google casts, and it is the reason most merchants see. It is also the least specific: the notice tells you that your account misrepresents itself or your products, and then stops.

That vagueness is not laziness on Google’s part. The policy covers everything from a missing phone number to a feed that disagrees with your own pages, and the reviewer is not going to enumerate which of those applies to you.

What the policy actually requires

Google’s own wording is that you must accurately represent your business and your products, with up-to-date contact information and a clear explanation of what your company does. It classes violations as serious, and it allows suspension without prior warning.

Three things follow from that, and they are the ones worth acting on:

1. It is about consistency, not honesty. Almost no suspended merchant is lying. They have a shop that says one thing and a feed that says another, and an automated comparison found the gap.
2. Machine-readable data counts as a representation. Structured data on your pages and the fields in your feed are statements about your business, judged the same way as the visible text.
3. You cannot appeal your way out of it without fixing the cause. Appeals are read one at a time. Sending one before the underlying fault is corrected spends an attempt for nothing.

What usually causes it

These are classes of fault we have measured, anonymised. They are ordered by how often they turn out to be the real cause, not by how obvious they look.

The feed and the pages disagree about price

The single most common machine-provable cause. Google fetches your landing page and compares it against the row in your feed. When the amounts differ, that is a misrepresented offer by definition.

What makes this diagnosable rather than mysterious is the shape of the disagreement. Scattered differences across a handful of rows mean data entry. One constant ratio across many rows means a process — usually feed generation running under a different tax or currency context than the one the feed is configured for.

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 — which setting gives the feed that rate is for the owner to confirm.

Measured 17 August 2026 on a live store.

The trap here is assuming the cause is your pricing. It usually is not. The customer-facing price chain is often entirely correct, and the fault sits in a metadata export nobody looks at.

The feed describes a different business than the shop

Feed generation is rarely one system. Product text may come from a translation table, links from permalinks, and base URLs from whatever language or site context the generation run happened to inherit. Each subsystem decides independently, which is why the same file can be right in some fields and wrong in others.

Critical Feed check

Correct product links, wrong channel and image host

Merchant Center reads the feed as a description of one store. Naming another domain in the channel or image fields describes a business other than the one under review.

Evidence

product links

example-shop.dk  ← correct

channel

example-group.eu  ← wrong

image host

example-group.eu  ← wrong

Illustrative — constructed to show the shape of the fault. The numbers are not from a measured run.

If you run several country domains from one platform, this is worth checking first. A misconfiguration at the group level repeats across every domain that shares the generator.

The wrong file is connected

Not a fault in your data at all, and the most frustrating one: the file you have been fixing is not the file Merchant Center fetches. Old feeds left on a server after a migration are ordinary, and nothing on the outside says which one is live.

Nobody can determine this from outside your account. Any supplier who tells you which feed is connected without logging in is guessing.

Business identity that exists in two versions

The identity finding is almost never “the information is missing”. It is that your company name, registration number, address or contact details exist in two slightly different forms across your own pages — an old address in the terms, a new one in the footer.

To a reviewer checking whether you are who you say you are, two versions of the answer is worse than a plain one.

Language and locale that do not match the market

Meta descriptions in English on a local-language shop. Prices with a decimal point where the market uses a comma. Currency in structured data that does not match the country the domain trades in. Machine-translation artefacts — a word that is technically the right language and impossible in context.

Individually small. Together they read as a shop that is not really operating in the market it claims to serve.

Two mechanisms that explain most of it

The causes above look unrelated until you notice that a handful of them are the same mechanism wearing different clothes. Knowing which mechanism you are looking at changes what you fix, and in which order.

Context inheritance

Feed generation is almost never one program. Product text comes from one place, links from another, currency and tax from a third, base URLs from whatever language or site context the export run happened to start in. Each subsystem decides its own context independently, and none of them checks the others.

That is why the same file can be right in some fields and wrong in others — and why it is a mistake to read a partly-correct feed as “mostly fine”. A file that is right about product links and wrong about the channel is not 80 % correct. It is one subsystem inheriting the wrong context, and it will keep doing that on every run until something changes upstream.

The tell is consistency. Scattered wrong values across a few rows mean data entry. One wrong value applied uniformly across every affected row means a process, and a process is a much better thing to find: there is one place to fix rather than four hundred.

The auto-update ghost

The other mechanism is the one that makes people think a fix did not work.

Old feed files left on a server after a migration are ordinary. What is less obvious is that the export jobs that wrote them are often still running. Delete the file and it is back tomorrow, with the same wrong channel and the same wrong image host, because nothing turned off the job that generates it.

The same shape appears elsewhere: a plugin setting corrected in one place and overwritten at the next update, a translation table that re-translates a brand name after it has been fixed by hand, a theme change that restores an old policy page nobody remembered was still generated.

This is why every recipe card we write ends with a verification step that is carried out later — logged out, after a cache purge — rather than immediately after the change. A fix that is confirmed only at the moment it is made is a fix that has not been tested against the thing most likely to undo it.

What the free Quick Scan can see of this

The Quick Scan is an automatic first look at your public storefront — the same checks, whoever you are. It is useful to be precise about which of the causes above it can actually reach, because the difference decides whether we are the right instrument for you at all.

Measurable from outside, without any access:

• Whether Google can fetch your pages at all, without cookies and without JavaScript — redirect loops, pages that are empty without JavaScript, links to your own pages that return 404.
• The currency, price format and language your product pages declare in their structured data, and whether those three agree with each other.
• Your policy pages: how many versions of each exist, whether they contradict each other on the return window, and whether they are reachable from the footer.
• Your business identity as your own pages state it — company name, registration number, address, contact route — and whether the versions match.
• Any product feed that is served publicly, including files that are reachable but not connected. Row by row against the matching pages: price, currency, availability, title.

Not measurable from outside, by anyone:

• Which feed file Merchant Center actually fetches. That is visible inside the account and nowhere else. A supplier who tells you which feed is connected without logging in is guessing.
• Your account history, and whether this account has been suspended before. Accounts with history are judged differently.
• Whether checkout completes, and what a reviewer saw when they looked.
• Anything a reviewer noted and did not write down in the notice.

Those go back to you as a checklist, each with what to check and why it matters, and they are never quietly folded in as if we had measured them. The run on 17 August 2026 produced 11 of them alongside its findings.

An example of what a corrected fault looks like afterwards

Anonymised, from a dated run on a real store. The fault was the one described above: product pages declaring one currency in structured data while the page’s other price fields and the feed declared another.

	Before	After
Product pages carrying the contradiction	59 of 59	0 of 59

The fix was a single setting in a currency plugin — the option that decides whether structured data reports the shop’s active currency or the plugin’s base currency. One switch, applied across every country domain in the network.

Two things are worth taking from that. The first is that the customer-facing price chain had been correct the whole time: shoppers saw the local currency, paid in it, and were never charged a different amount than they were shown. The fault lived entirely in machine-readable metadata that only Google was reading. The second is that the after-measurement exists at all. A before number without an after number is a complaint; the pair is what a reviewer can check.

How to find which one applies to you

In this order, because each step is meaningless if the one before it failed:

1. Confirm Google can fetch your pages at all. Without cookies and without JavaScript, which is how Googlebot meets them. Redirect loops, pages that are empty without JavaScript, and links to pages that no longer exist all make everything downstream unmeasurable.
2. Compare your connected feed against your own pages, row by row. Price, currency, availability, title. Look at the shape of the differences, not just the count.
3. Inventory your own policy pages. Every version of them. Duplicates with contradicting return windows are common after a theme change and are invisible until someone lists them all side by side.
4. Extract your business identity from every page that carries it and compare the versions against each other.
5. Check locale consistency — currency, decimal separator, language of meta text, translated brand names.
6. Only then write the appeal, with a before and after measurement and a date on every claim in it.

What we do

We run exactly those steps, produce the evidence for each finding, and give you recipe cards for the fixes plus a dossier for the appeal. What Google decides afterwards is Google’s decision — the reviewer is theirs, and nobody outside the company can tell you in advance what they will conclude.

The Quick Scan is free and is also our triage. If your case is one of the ones above that no external tool can see, we would rather tell you that than sell you a diagnosis of something else.