Google Merchant Center fixes
Get disapproved products back into Shopping.
Diagnosis of disapprovals and account issues, corrections at the source data rather than in the feed export, and a resubmission with the evidence Google asks for. We built a monitoring app on top of this exact problem.
Fixed price
From $1,000
That covers the diagnosis and the data fixes on one account. A suspension, several feeds or a broken sync runs to $4,250. The number is fixed before the work starts, not billed by the hour.
Send the brief and get a number back.
Describe the projectThe products stopped showing and the reason is a code
Shopping impressions drop, the account shows a red banner, and the explanation is a phrase like misrepresentation or invalid value with no indication of which part of your store caused it. Meanwhile the campaigns keep spending on whatever survived, so the loss is partial and easy to misread as a bad week. The instinct is to open the feed and start editing attributes, which is where most of the wasted effort goes: a large share of these failures are not in the feed at all, they are on the storefront Google visited afterwards.
What the work covers
A diagnosis, not a list of error codes
Item-level and account-level issues are pulled through the Merchant API, grouped by cause rather than by product, and split into the two kinds that behave differently: data problems that clear themselves on the next crawl once fixed, and policy problems that need a human review. Knowing which one you have decides everything that follows.
Fixed at the source, not in the export
Corrections go into the product data in your store, into shipping and tax configuration, or onto the page itself. Patching values in the feed export makes the feed disagree with the landing page, and that mismatch is its own disapproval reason, so the quick fix creates the next ticket.
One review request, properly built
For policy and account issues the sequence is fix, evidence, then a single request. Attempts and cooldowns are limited, and a request sent before the cause is actually resolved burns one. The submission says what was wrong, what changed and where to verify it.
Why it is done this way
Misrepresentation is judged on your website
Google does not only read the feed. It visits the storefront and checks whether you look like a business it can send buyers to: reachable contact details, a refund and returns policy a person can find, prices and availability that match what the feed claims, and claims it can verify. Honest stores get caught by this constantly, and they keep looking for the fix in the feed, where it is not.
The engine is ours, so the diagnosis is not guesswork
Feed Guard, our own app, runs on the Merchant API and was built on exactly this problem: reading account and item issues, explaining them in plain language and watching for the next one. The same reading is what a diagnosis starts from here. What nobody can offer is a promise: approval and reinstatement are Google's decision, so no outcome is guaranteed and anyone guaranteeing one is selling something else.
How it runs
Read access to Merchant Center and to the store, or an export if access is not possible. You get the issue list grouped by cause with the product count behind each.
A written diagnosis: which issues are data and clear on a crawl, which are policy and need a review, which are structural and will cost real work, and which cannot be fixed at all.
The fixes land in the product data, the shipping and tax setup or the page itself, then wait for the crawl that confirms them rather than being declared done.
For policy and account cases, the review request goes in once, after the cause is verified as fixed, with the evidence attached.
A check after the re-crawl, plus a short list of what to watch monthly so the same class of failure does not come back unnoticed.
Background
How Merchant Center failures actually work
Disapproval, demotion and suspension are three different problems
A disapproval hides individual products while the rest of the catalogue keeps selling. A demotion is quieter: the listing still shows but ranks below competitors because an attribute is missing or weak, and nothing in the account calls it an error. A suspension is account-level and hides everything, usually after a warning. The three get treated as one thing called feed problems, which is why merchants fix attributes for a week while the actual cause sits on the storefront. The first useful question is not what is wrong with the feed, it is which of these three is happening.
Why the fix is usually not in the feed
The feed is a claim about your products. Google checks that claim against the page it links to. So the failures that keep coming back are the ones where the two disagree: a price that differs after a discount app renders, availability that says in stock on a sold-out variant, a landing page that redirects, a currency that changes between the feed and the presentment market. Editing the export to satisfy the validator makes the disagreement worse rather than better. The durable fix is the product data everything else is generated from.
Spend the first review request properly
Review requests are not unlimited and each one starts a cooldown. The common mistake is to send one immediately, because the banner is stressful and the button is right there, before the cause is actually resolved. Then the request is refused, the cooldown starts, and the second attempt goes in under time pressure. Data-level problems do not need a request at all: fix them and the next crawl clears them. Save the request for what genuinely needs a human, and send it with the fix already verifiable.
Where this knowledge comes from
Feed Guard, our own Shopify app, is built on the Merchant API and reads exactly these account and item issues, which is also why the blog here holds ten articles taking these failures one at a time: suspensions, misrepresentation, image rejections, missing GTIN and brand, price and availability mismatch, editorial requirements, re-review requests and the Merchant API migration. The service is the same reading done against your account, with the fixes carried out rather than described.
Describe the project
Tell us what you have and what should change. Within two working days you get a written calculation: the scope broken into parts with a price against each, or the questions needed to write one. No discovery call in between.
Questions
Merchant Center trouble, asked and answered
Data issues usually clear within days of the fix, on the next crawl, without any request. Policy and account cases run longer and depend on a review you do not control. Anyone quoting you a date for a reinstatement is quoting a date Google has not given them.
No. The decision is Google's and no part of this work changes that. What is in our control is that the cause is correctly identified, actually fixed, and presented with evidence, which is what makes a request worth submitting. If the honest read is that the account will not come back, you get told that instead of being billed for attempts.
That is the most common version of this case. Misrepresentation is rarely an accusation of fraud. It usually means Google could not verify something it expects to find: contact details, a clear returns policy, prices that match the landing page, or a business identity it can confirm. The work is making those verifiable rather than arguing about intent.
Rarely. Feed apps differ in how they map attributes, and a bad mapping does cause disapprovals, but the account-level failures and most repeated item failures come from the product data and the storefront underneath. Changing app while the source data is unchanged usually reproduces the same issues with new labels.
Only if something custom is syncing your products: a self-built script, an older integration, or an app that has not migrated. Standard Shopify and WooCommerce paths were moved by their vendors. If a custom job is in the chain, it stops returning data after the cutoff, and that is worth checking before it becomes an outage rather than after.