Merchant Center suspension: 19 days and three review requests

In August, every product in a personal care store we maintain became disapproved in Google Merchant Center within a few days. The reason on the account was “Misrepresentation”, at account level. That meant the Performance Max campaign had nothing to show, and the free listings on Google Shopping stopped too.

The suspension lasted 19 days and took three review requests. The first two were rejected, because each time there was something we had not seen. The last one passed in under 22 hours, and what changed that time was not inside the website. It was in Cloudflare, in front of the website, and it did not show up in any of our logs.

What the policy says, and why it does not help enough

Google’s Misrepresentation policy covers a lot: false identity or contact details, implied partnership with a brand when there is none, hidden fees, offers that are not available. It also says Google may review information from many sources, third parties included, and that an account review usually takes 7 business days.

The practical problem is that the notification does not tell you which item was at fault. We opened a case with support and the answer was that they cannot give specifics while a review is pending. Review requests are not unlimited either: the account showed up to three. So every request had to go out only after we had cleaned up everything we could find.

Round one: the holiday message

The likeliest trigger was a summer closure notice. For a few days the site said orders were not being fulfilled, while the feed showed products available to buy. To an automated check, that looks exactly like an offer that is not available. By the time we saw the suspension, the notice was already gone.

Before the first request we checked the footer, phone number, address and every policy page, and compared price and availability between feed and site on a sample of products. We also removed two feed entries that were not real products. Everything looked clean. The request was rejected six days later.

Round two: an old article and a robots.txt

Looking again, we found an article on the store’s blog, 17 months old, about a brand the store no longer worked with. It said the store carries the full range and gave a discount code that had never existed in the coupon system. The About page and the homepage said the store works exclusively with that same brand. The policy explicitly forbids implying a partnership that does not exist, or promoting an offer that is not active.

We rewrote the article as a general guide with a 301 from the old URL, and fixed the phrases on the other pages. We also added the company name, VAT number and registered address to the footer of every page. Until then they were on 2 of the 10 pages we checked.

The second check failed as well, and a new violation arrived with it: “landing page not working”. This one was on our side, on the server that hosts the site. The robots.txt was generated dynamically by WordPress. One morning, for about two hours, it answered with 503 and 508 errors: the product feed was rebuilding, an SEO plugin was running hundreds of background tasks, other scheduled jobs landed in the same minute, and the site’s account hit its memory limit. When robots.txt returns 5xx, Google treats the whole site as down.

We made robots.txt a static file, byte for byte identical to the dynamic one. We spread the jobs across different minutes, raised the account’s memory limit, and added a check every minute, straight on the server, for robots.txt, the homepage, one category and one product.

Round three: what the logs could not show

Before the last request, our side measured clean: eight days with no 5xx to Googlebot, Search Console without problems on the pages we checked, and the feed URLs answering 200 even with the Googlebot user agent. The issue remained, though, and Merchant Center had a detail we had not paid attention to: “detected through a non-automated review”. A person had looked at it.

So we looked at what happens before the request reaches the server. The site’s Cloudflare had a single firewall rule, from March 2025: a block for all traffic from India. A visitor from there saw a Cloudflare error page. Nothing reached the server, so there was nothing in the logs. And Google’s list for “landing page not working” explicitly requires that access is not restricted by location.

The second finding was in the same panel. Cloudflare’s email obfuscation was on. It replaces emails in the HTML with code that restores them using JavaScript, so bots cannot harvest them. Anyone reading the page without JavaScript saw “[email protected]” where the store’s email should be, four times on the contact page. To someone checking whether a store shows clearly how to reach it, that looks like a hidden element.

We switched off both, after keeping a copy of the settings. In the same pass we read the account straight from the Merchant API and found two more things: the customer service fields (email and contact page) were empty, and the account phone number was a mobile that appeared nowhere on the site. The mobile went on the contact page next to the landline, and the fields were filled in.

Before sending the final request we asked Search Console to re-read the contact page and waited for Googlebot to pass, so Google would have the new version and not the one with “[email protected]”. The landing page request was approved in 18 hours. The last one, for misrepresentation, went out on a Sunday at noon. On Monday morning the account had no issues.

What we know and what we do not

We cannot prove the India block was the cause. The rule had existed for 18 months, and for all that time Merchant Center worked normally. The explanation that holds up is that until August the checks were automated, and Googlebot does not come from India. The rule was harmless until the day a person looked at the store. We do not know where that review was run from. We know it was the one item on their list we had not cleaned, and that removing it cost nothing.

We did not open a second Merchant Center account to get the products unstuck. A new account for the same store while the first is suspended looks like an attempt to get around the system, and that is a worse problem than the suspension itself.

After the suspension lifted, a few products had issues of their own. A roll of aluminium foil for hair highlights had been flagged as a tobacco product, because its title never said it was for hairdressing. Instead of appealing, we changed the title and description, and later it cleared by itself. When an automatic classifier gets it wrong, giving it the words it was missing is often enough.

Checklist if your Merchant Center is suspended

• Automated or human review? If it says “non-automated review”, think about what a person from another country sees, possibly with JavaScript off.
• CDN rules. Firewall, country or network blocks, bot protection, email obfuscation. Whatever is cut there does not appear in your server logs.
• Raw HTML of the contact page (view-source), not only what the browser renders.
• Old content. Brands, discounts and codes in articles and pages that are no longer true. An article written a year ago counts as much as today’s homepage.
• Same details everywhere. Company name, VAT number, address and phone on every page, identical across the site, Merchant Center and Google Business Profile.
• Settings inside Merchant Center. Customer service fields, phone number, return policies.
• A static robots.txt. If it goes down even briefly, Google sees the whole site as down.
• Patience before the request. Wait until Google has seen the pages you changed. A rejected request is one of the few you have.
• No second account for the same store.

Merchant Center is among the integrations we run in production, alongside product feeds for marketplaces. We describe how we manage Google Ads, Shopping and Performance Max, with conversion tracking, on the Services page. If your store is suspended and you do not know where to start, write to us. We start from what the reviewer sees, not from what the server shows.