The Shopify structured data bug that gets clients suspended

TL;DR

• Merchant Center suspends an account for "Misrepresentation" without naming a product and without a warning period; Google's own policy states accounts are "suspended upon detection and without prior warning."
• The policy has a clause unrelated to business identity: it forbids offering products you can't deliver and points directly at the availability and price attributes in Google's product data specification.
• On a Shopify build, those two attributes come from four separate mechanisms (theme, the structured_data Liquid filter, any app injecting its own markup, and the feed), and nothing forces them to agree.

If you build or maintain Shopify stores for clients, this is the bug report you never get. Merchant Center suspends an account for "Misrepresentation," with no product name, no line item, no warning period, just Shopping ads and free listings dropping to zero. Most of what ranks for this error points at business identity: refund policy, contact page, real business name at checkout. Worth checking, genuinely required, and not the whole story.

The same policy also forbids offering products a shopper can't actually buy, and it refers directly to two feed attributes: availability and price. On a Shopify build those values come from four different places, and nothing reconciles them automatically. This piece covers where that agreement breaks in a typical Shopify build, how to audit a client's store for it in a few minutes, and what to fix before requesting Google's re-review.

Why doesn't Merchant Center name the product that broke the rule?

Most Merchant Center issues arrive with a warning period and specific examples. Google's documentation on warnings and suspensions describes products continuing to appear "however their performance may be limited," with emails pointing at what to fix. Misrepresentation doesn't work that way. Its policy page classifies these violations as egregious and states that accounts "will be suspended upon detection and without prior warning." Shopify's own page on Google disapprovals and warnings lists this under "Unacceptable business practices" and notes that "Deadline extensions aren't granted for any violation."

So there's no missing notification setting to find. The enforcement acts first and explains later, which leaves you reading the policy text itself instead of an email with an example. A Shopify Community thread opened in February 2026 and still active months later captures it directly: Google "continues to flag my account for 'Misrepresentation' without providing specific details on what's wrong or how to fix it."

What does the misrepresentation policy actually require?

Most guides for this suspension point at business identity. Shopify's requirements page for the Google & YouTube channel spells it out: refund policy and terms of service "available in your footer menu," plus contact information "visible to customers" via "at least one contact method such as email address, phone number, mailing address, or a contact form." Check that first, it's cheap and well documented.

But the policy has a second clause with nothing to do with identity: "Offer products that you don't have or can't deliver" is listed as an unacceptable business practice, and the unavailable-offers section forbids "Promising products or promotional offers that aren't available for users" (examples: promoting unstocked products, expired deals, or a call-to-action that "isn't easily achievable from the landing page"). The policy then refers you to the product data specification's availability and price attributes for "specific guidelines to comply with this policy."

That specification asks you to "accurately submit the product's availability and match the availability from your landing page, checkout pages, and structured data," and the same for price. Four surfaces (feed, landing page, structured data, checkout) have to agree with each other and with what you can actually ship. On a Shopify store those four are produced by four different mechanisms, and nothing reconciles them.

Where does a Shopify build break that requirement?

These are mechanisms that can make the four surfaces disagree, not proof of what triggered any specific suspension. Google doesn't publish which signal caused a given account action.

Continue selling when out of stock

Shopify's docs on selling out-of-stock products describe this setting plainly: enable it in the Inventory section of a product or variant, and customers can buy at zero inventory or below. It's a legitimate setting for stock arriving soon or inventory tracked elsewhere, but with it on, every surface agrees on the wrong answer. The page offers the item, add-to-cart works, the structured data reports it available, the feed says in stock. Nothing is internally inconsistent, the store is just promising goods it doesn't hold, and the spec asks for availability that's accurate, not merely consistent.

The setting is per-variant, too. Toggle it on during a stockout, sell through, restock, and it stays on for that one variant with nobody noticing.

Duplicate or stale structured data

Shopify generates Product markup through the Liquid structured_data filter, which emits an offer object like this:

"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 availability value tracks the variant correctly. It breaks the moment a second Product block enters the page, from a review app, a rich-snippet app, or a theme section with a hardcoded InStock value, and Google reads a claim the store never intended to make. This is the account-level version of a mismatch covered in more detail at the item level, in the availability mismatch between Shopify and Google Shopping.

One offer, many prices

The structured_data filter emits a single offer, for a single variant, with a single price. A product whose variants span a wide range declares only one of those prices in its markup. A shopper landing on a different variant sees a different number than the one Google received, and the spec requires price to match the landing page, structured data, and checkout. Related failure modes: the on-page price mismatch trap and a price of zero reaching Google.

Redirects on discontinued product URLs

The unavailable-offers clause also covers the landing page itself: a call-to-action that "isn't easily achievable from the landing page." On Shopify this usually means an out-of-stock or discontinued product URL redirecting to a collection or the homepage instead of returning the product page, so a shopper who clicks through from a listing can't reach the item at all. More detail on that failure mode: when a product page redirects to your homepage.

How do you audit a client's store in five minutes?

1. Copy the exact issue name from the policy area of Merchant Center. An account-level misrepresentation issue reads differently from a product-level disapproval, and the fix differs too.
2. Pick five out-of-stock products and compare four surfaces for each: what the feed reports, what the page shows, the availability value in the page's JSON-LD, and what happens on add-to-cart.
3. Check the Continue selling setting on the Inventory section of each product or variant.
4. View source on a product with a wide variant range and read the price inside the offers object; compare it to the cheapest and most expensive variant.
5. Open a discontinued product's URL directly and check whether it redirects instead of returning the product page.

How do you fix each issue?

Overselling. Decide deliberately which products may oversell, and turn the setting off everywhere else. For products that genuinely ship later, use the spec's preorder or backorder availability values instead of claiming stock that isn't there.

Duplicate markup. Find the second Product block before editing the first. It's usually coming from an app, and removing the app's block is easier than trying to make the theme's output match it.

Price coverage. If variants span a wide range, the real fix is markup that declares the range instead of a single figure. Until that's built, know which products are affected before touching the theme.

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

Then request the review, not before. Google's docs and Shopify's both give the same figure: reviews "can take up to 7 days to complete." A re-review on a store that hasn't actually changed spends a week to land back where it started.

Why does this bug keep coming back after launch?

Every mechanism above comes from ordinary work, not a code review failure. A stockout on a Friday turns on Continue selling, and the restock doesn't turn it back off. A new reviews app adds a second markup block. A supplier drops a line and someone redirects the URL to keep things tidy. A variant gets added well above the price sitting in the markup. None of it throws an error in Shopify admin, and none of it throws one in Merchant Center either, because for this policy Google doesn't warn, it suspends.

It's worth being precise about what an automated scan can actually tell you here. The misrepresentation policy covers business identity, intent, and whether a merchant can really ship what's listed, none of which is readable from public pages. What is readable is the product-data half the policy points at: a page whose markup claims InStock while every variant shows sold out, or a page whose declared price contradicts what the page itself renders. That's one input into an account-level judgment, not the judgment itself. Treat anything sold to you as a "misrepresentation checker" with the same skepticism.

Have you shipped a Shopify feature that quietly broke a client's availability or price data without throwing an error? What caught it: an audit, a client complaint, or a Merchant Center suspension?

The full version of this article — with screenshots and ongoing updates — lives on the StoreCanary blog.