BLOG
eCommerce Insights
Your store works, but Google does not trust it: investigating a Merchant Center suspension
A functioning store can still face a Merchant Center restriction. Learn how to investigate conflicting information and prepare verified corrections.
A store owner has done what appears to be everything necessary: published products, configured payments, and added contact details and a returns policy. There is a supplier, a real business, and a website that accepts orders. Yet Google Merchant Center reports misrepresentation. The notice does not make it clear what needs changing.
It is easy to start arguing with the platform. If the company exists and can fulfil an order, why is it being treated as untrustworthy? I understand the question. Behind it are the work of preparing the store, the cost of launching it, and a sales channel the owner was counting on.
Before requesting another review, however, I would ask a different question: do a customer and an external system see the same business its owner sees? This is often where a gap emerges between the reality of a company and the way it presents itself online.
What the discussion actually establishes
In an October Shopify Community thread, an owner describes prolonged attempts to resolve a restriction. Participants identify conflicting business details and unfinished policy templates. The owner reports making changes, but the available discussion through 6 October 2026 does not confirm reinstatement. [1]
That distinction matters to me. A documented inconsistency is a reason to make a correction. Without access to Merchant Center and the review outcome, it cannot be declared the sole cause of the suspension.
The owner asks for specifics and receives advice of varying depth, from checking contact information to assumptions about fulfilment. Some suggestions are useful; others need scrutiny. Treating every confident reply as a mandatory action can consume time while making the business description less accurate.
A real business also needs an understandable identity
Google's policy addresses truthful representation of the seller and the offer. Assessment can involve several sources, including the website, listings, accounts, and information elsewhere online. A working checkout alone therefore does not establish compliance. [2]
Consider a hypothetical store. Its header uses a trading name, its terms name the legal seller, its contact page lists an office, and returns go to a warehouse in another city. That can describe a legitimate operation. But without an explanation of those relationships, a reader has to guess who sells the product and who handles a problem.
I would not reduce the investigation to copying one address everywhere. Different addresses can serve different purposes. The task is to remove errors, explain each address, and reconcile the information with the account settings. Making a real business fit an invented, simpler story is more dangerous than explaining how it operates.
Google also recommends transparency about the business model, clear policies, accessible contacts, and the removal of unfinished placeholders. These are useful areas to examine, rather than a published approval formula with a known weight for every signal. [3]
Why adding a policy page may change nothing
From the owner's perspective, the task looks complete: the page exists and the footer links to it. I would check the next level—whether customers can actually use the information.
Someone seeking a return should be able to work out where to write, when to submit a request, who pays for shipping, and what restrictions apply. Where delivery has several stages, processing time and transit time should be distinguishable. A store selling internationally should not leave customers with the impression of local dispatch when that is not how it operates.
This is my practical diagnostic model: follow the customer's journey and identify questions the store answers inconsistently or leaves unanswered. It does not reveal Google's internal assessment process. It helps turn the formal presence of documents into understandable purchase conditions.
I would also avoid replacing legal terms with someone else's template purely for moderation. The owner confirms the actual operating model; terms affected by local law may need review by an appropriate specialist. Our role is to identify discrepancies and implement the agreed information correctly in the store.
One product page can tell several different stories
Customers see a product and a price on the storefront. Merchant Center receives information through a data source, such as an integration or product feed. The page may separately contain structured data: a machine-readable description of the offer.
These representations deserve comparison. I would start with a few informative product variants: a standard offer, a discounted one, and one temporarily unavailable. For each, I would record the exact URL, variant, market, and time of inspection. Otherwise, it is easy to compare different configurations or information intended for different countries.
Google requires the key offer details on the landing page to align with the submitted product data. The selected variant, price, currency, and purchase availability matter; location-based changes must not substitute a different offer for the one advertised. [4]
Suppose a new theme updates the visible price correctly while an old structured-data block still outputs the previous value. This is a hypothetical mechanism, not an established explanation for the suspension in the discussion. Adding an About page would not resolve that discrepancy: the source of the outdated value needs correction.
This is why I treat Google Merchant Center setup for Shopify as work on the catalogue and its exchange with an external system. Connecting an account is only one part of that work.
Advice I would not follow without testing it
Simple explanations can sound particularly convincing in forum discussions: remove references to production on demand, prevent large quantities in the cart, change the address, and the problem will disappear. Each proposed action still needs a verifiable reason.
I would not hide how products are made. Manufacturing after an order and being unable to fulfil a promise are different situations. Describe the timing honestly and check the requirements applicable to the offer. Google supports different availability statuses, with conditions and dates for preorder and backorder. That does not make every status appropriate for every product. [5]
Being able to add an unusually large quantity to the cart also calls for investigation, rather than an instant diagnosis. The store may allow sales beyond tracked stock; quantity may be controlled elsewhere. Establish whether the business can fulfil the order within its stated times and which limits it actually needs.
Nor would I change an accurate address or open another account in the hope of bypassing the issue. A correction should make the business representation more truthful. If the changes require concealing the seller or dispatch location, the investigation is heading in the wrong direction.
How I would organise the investigation
My first task would be to establish the scope of the restriction: an individual product, a group of offers, or the entire account. I would retain the notification, available issue details, previous review dates, and a record of changes already made.
Then I would prepare a working table. This is our diagnostic approach, not an official Google checklist.
| Area | What we compare | Required outcome |
|---|---|---|
| Seller identity | Brand name, seller information, contacts, and account details | Errors corrected; the brand-to-seller relationship explained |
| Purchase promises | Product page, shipping, returns, and actual fulfilment | Customers can understand the terms before payment |
| Submitted information | Shopify variant, data source, and Merchant Center record | Specific discrepancies identified and corrected |
| System-visible information | Page, markup, language, currency, and target market | The same offer tested in a defined context |
| Changes | Verified defect, responsible person, and retest method | Every change has a reason and a verifiable outcome |
Change history is particularly useful. A restriction appearing after catalogue migration or an app installation helps direct the investigation. Timing alone remains a hypothesis until the error mechanism has been demonstrated.
I would separate findings into verified defects, probable causes, and questions for which evidence is insufficient. That gives the owner a usable plan and prevents the developer from having to implement every suggestion in turn.
Testing a few products must not be presented as an audit of the entire catalogue. A sample can expose a recurring mechanism; we then agree how to examine the remaining affected offers. This keeps the effort, timing, and cost within understandable boundaries.
When to request another review
I would request review after verifying the agreed corrections, rather than immediately after finding the first flaw. The changes need to reach the data source and be visible wherever the discrepancy occurred.
Use the available Merchant Center route for fixing an issue or disagreeing with a decision. Complete identity verification if requested. Google specifies up to seven business days for review; unsuccessful attempts can lead to a cooldown that support cannot shorten. [6]
I would therefore prepare a concise account of verified work: what was found, what changed, where the changes can be inspected, and what evidence supports the actual business activity. If the cause has not been disclosed, do not claim it has been proved. Explain which discrepancies have been resolved and request clarification about any remaining restriction.
After the response, check both the account and the affected product statuses. Submitting a form, obtaining approval, and receiving impressions are different stages. Our work cannot be represented as successful solely because a request was sent.
What we offer at IceStoreGroup
Our capabilities in Shopify, product data, themes, integrations, and technical optimisation allow us to investigate the connected process: where information originates, how it is transferred, and what the external system receives.
The starting point can be a store diagnostic. Where standard corrections have already failed, an agreed investigation of one specific issue may be more useful. The owner receives the evidence behind findings, priorities, the boundaries of remediation, and a retest method. Implementation and ongoing support are agreed following the analysis.
We take responsibility for the quality of the investigation, the agreed changes, and verification that those changes were completed. Google retains the approval decision. If the evidence does not support an exact conclusion, that limitation should be visible in the report rather than concealed by a guaranteed-reinstatement promise.
For ongoing catalogue development, this work can be connected with SEO and GEO optimisation. Merchant Center status and ordinary search indexing still need separate checks: one cannot be used to diagnose the other. Our practical SEO guide for Shopify store owners discusses the foundations of search visibility.
I arrive at a straightforward working principle: reconstruct the facts, resolve verified contradictions, and then request reconsideration. An owner does not need to become a specialist in every system. They should understand what they are paying for: which questions were investigated, which changes were completed, and which outcome still depends on the external platform.
The value of that approach survives the Merchant Center case itself. The store gains a clearer business identity, a consistent catalogue, and a process for noticing new discrepancies before another restriction occurs.