Merchant Center suspended you for misrepresentation — and the half of the policy nobody checks is your product data

Short answer. Google suspends a Merchant Center account for misrepresentation without a warning period and without naming the offending product. The answers that rank for it send you to your contact page and your refund policy — real requirements, worth checking. But the same policy also forbids offering products you cannot deliver, and points you at the availability and price attributes in Google's product data specification. On a Shopify store, that is the half that breaks quietly.

There is a particular flavour of panic to this one. Nothing on your store changed. Then Shopping ads and free listings stop at once, and the notice tells you the account violated a policy called Misrepresentation, which sounds like an accusation of fraud and gives you nothing to act on. A Shopify Community thread opened on 28 February 2026 and still running in June puts it plainly: Google "continues to flag my account for 'Misrepresentation' without providing specific details on what's wrong or how to fix it."

Why there is no warning and no example

Most Merchant Center problems arrive politely. Google's documentation on warnings and suspensions describes a warning period during which "your products will continue to appear across Google, however their performance may be limited", with emails carrying examples of what to fix. Misrepresentation does not work that way. Its policy page classes violations as egregious and states that "your Google accounts will be suspended upon detection and without prior warning". Shopify's own page on Google disapprovals and warnings lists "Unacceptable business practices" — the section heading under which misrepresentation's rules sit — among the violations that trigger immediate suspension, and notes that "Deadline extensions aren't granted for any violation."

So the missing example is not a gap in your notification settings — it is the shape of an enforcement designed to act first. Which leaves you reading the policy itself, and that is worth doing carefully, because it is longer than the part everyone quotes.

The half of the policy everyone answers

We ran the obvious searches for this suspension in August 2026, and what holds those results is Shopify Community threads and Google's own policy pages, almost all of them pointed at business identity: add a contact page, publish a refund policy, put your real business name at checkout, prove you are a real company. That advice is correct and it maps onto real requirements. Shopify's requirements page for the Google & YouTube channel states that "You need to add a Refund Policy and Terms of Service to your online store" and that "These policies must be available in your footer menu", plus contact information "visible to customers" with "at least one contact method such as email address, phone number, mailing address, or a contact form."

Check all of that, and if any of it is missing fix it first — it is cheap and it is documented. The problem is what happens when it is all already in place, which is the situation the long forum threads are full of.

Want to see what your product pages are actually claiming right now? We read every product page in your catalog and compare the availability and price in your markup against your live store — read-only, no admin access, about 2 minutes. → free scan

The half nobody answers

Google's misrepresentation policy lists a set of unacceptable business practices. One of them is not about your identity at all:

• "Offer products that you don't have or can't deliver"

And under unavailable offers, the policy forbids "Promising products or promotional offers that aren't available for users", giving as examples "Promoting products that aren't stocked, promoting a deal that's no longer active, or including a call-to-action in promotion that isn't easily achievable from the landing page."

Then it does something the identity advice never mentions: it tells you where to go next, referring you to the "Product data specification attributes on availability and price for specific guidelines to comply with this policy." Google is pointing, in its own policy text, at two feed attributes.

Follow the pointer and the requirement gets specific. The product data specification asks you to "accurately submit the product's availability and match the availability from your landing page, checkout pages, and structured data", and to "accurately submit the product's price and currency, and match with the price from your landing page, structured data, and at checkout."

Four surfaces have to agree, then — feed, landing page, the structured data on that page, and checkout — and they have to agree with your actual ability to ship the thing. On a Shopify store those four are produced by four different mechanisms, and nothing reconciles them.

Where a Shopify store breaks that agreement

These are mechanisms, not verdicts. Google does not publish which signal triggered a particular suspension, and anyone who tells you otherwise is guessing. What follows is the list of places where a Shopify store can stop satisfying the requirement Google's own policy sends you to.

1. Continue selling when out of stock

Shopify's documentation on selling out-of-stock products describes the setting plainly: choose "Continue selling when out of stock" from the Inventory section of a product or variant, and customers can buy items at zero inventory or below. Shopify calls the practice overselling and treats it as a normal choice — for stock arriving next week, for inventory tracked in another system.

It is a normal choice. It also makes every surface agree on the wrong answer: the page offers the item, the add-to-cart works, the markup reports it available, the feed says in stock. Nothing is inconsistent — the store is simply promising goods it does not hold. This is the one case where internal consistency will not save you, because the specification asks you to submit availability accurately, not merely coherently.

And the setting is per variant. Enable it during a stockout, sell through, restock, and it stays on — silently, on that one variant.

2. Markup that says in stock when nothing is left

Shopify generates product markup through the Liquid structured_data filter, whose documented offer output carries six properties, availability among them:

"offers": {
  "@id": "/products/crocodile-tears?variant=39888242344001#offer",
  "@type": "Offer",
  "availability": "http://schema.org/OutOfStock",
  "price": "56.00",
  "priceCurrency": "CAD",
  "url": "https://…/products/crocodile-tears?variant=39888242344001"
}

On a stock theme that value tracks the variant, and it is right. It stops being right when a second block enters the page — a review app, a rich-snippet app, a theme section with a hardcoded InStock — and Google reads a claim the store never made. We wrote the item-level version of this failure up separately, as the availability mismatch between Shopify and Google Shopping; that page covers what it costs you per product. This one is about the same gap read at account level, against the requirement in the specification.

3. One offer, many prices

Look again at the block above and note what it is: a single offer, for a single variant, carrying a single price. A product whose variants run from a small size to a much larger one declares one of those prices in its markup. A shopper who arrives on the higher variant sees a different number from the one Google was given — and the specification asks the price to match the landing page, the structured data and checkout.

This is a close cousin of the disapproval we covered in the on-page price mismatch trap, where the page, the JSON-LD and the Open Graph tags disagree with each other, and to a price of zero reaching Google. Different error strings, same underlying requirement.

4. A landing page that cannot honour the listing

The unavailable-offers clause covers the destination as well as the goods: a call-to-action that "isn't easily achievable from the landing page". The Shopify version is familiar — an out-of-stock or discontinued product whose URL redirects to a collection or the homepage, so a shopper who clicks a listing for a specific item lands somewhere they cannot buy it. That mechanism, and the Merchant Center disapproval that usually arrives first, is in the redirect-to-homepage article.

How to check your own store in 5 minutes

1. Copy the exact issue name. Open the policy area of Merchant Center and read the issue as written. An account-level misrepresentation issue and a product-level disapproval are different problems with different fixes, and the words differ.
2. Take five out-of-stock products and compare four surfaces. For each: what the feed reports, what the page shows a shopper, what the availability value in the page's JSON-LD says, and what actually happens when you add it to the cart. Any product where those four do not tell the same story is worth writing down.
3. Check the Continue selling setting. In the Inventory section of the product or variant. Anything enabled there with zero inventory is a product your store is offering and cannot currently ship.
4. Read the price in your own markup. View source on a product with a wide variant range and find the price inside offers. Compare it against the cheapest and the dearest variant a shopper can select.
5. Open a discontinued product URL. If it redirects rather than returning the product page, note where it lands and whether the item is buyable there.

Fixing each one

Overselling. Decide deliberately which products may oversell, and turn the setting off everywhere else. If a product genuinely ships later, that is what the preorder and backorder availability values exist for — the specification lists four accepted values, in_stock, out_of_stock, preorder and backorder, and using the accurate one is a better answer than claiming stock you do not have.

Contradictory markup. Find the second block before editing the first. A page carrying two Product entities has one of them coming from an app or a theme section, and removing the app's block is usually easier than making the theme match it.

Price coverage. If your variants span a wide range, the honest fix is markup that declares the range rather than a single figure — and until then, knowing which products are affected is worth more than a blanket theme edit.

Redirects. Let a product that no longer sells keep returning its own page, out of stock and priced, instead of redirecting away. The specification notes that when a product is out of stock "the price must still be clearly visible on the landing page", which is only possible if the page still exists.

Then request the review, and not before. Google's documentation states that reviews "can take up to 7 days to complete", and Shopify's page gives the same figure. A re-review requested on a store you have not actually changed spends a week to arrive back where you started.

Why this one comes back

Every mechanism above is produced by ordinary work. A stockout on a Friday turns on Continue selling; the restock does not turn it off. A new reviews app adds a second markup block. A supplier drops a line and someone redirects the URL to keep the link tidy. A variant is added well above the price sitting in the markup. None of it produces a warning in Shopify admin, and none of it produces one in Merchant Center either — because for this policy Google does not warn, it suspends. The store that gets caught is rarely the store that did something wrong once; it is the store where a gap opened months ago and nothing was watching the four surfaces drift apart.

We should be exact about our own part in that, because the temptation to overclaim here is obvious. StoreCanary does not detect misrepresentation. The policy covers business identity, intent and whether you can actually ship what you listed, and none of that is readable from your public pages. What we do read is the product-data side Google's policy points at: our scan flags a page whose markup says InStock while every variant is sold out, and a page whose declared price contradicts what the page itself publishes, as critical findings. That is one input into an account-level judgement, not the judgement itself — and it is worth being suspicious of anything described to you as a misrepresentation checker, ours included.