Ecommerce / Practical guide
Google Merchant Center products disapproved: how I diagnose the cause
A disapproval is a symptom. I trace it back to the product, the data source or the account before recommending changes.
1. Separate the product problem from the account problem
When a store owner tells me that Google Shopping has stopped working, I first ask for the issue wording, affected country and a few product IDs. An individual variant with a price mismatch needs a different investigation from an account-wide policy issue. Editing every title before making that distinction can create more work without addressing the cause.
In Merchant Center, I review the Needs attention area and record the affected products and destinations. I also note the first observed date and recent changes: a new feed app, currency setting, sale, theme release or inventory import. Google’s review guidance explains where product and account issues appear and which review options may be available.
My first deliverable is a short issue list with an owner for each fix. A developer should not have to interpret a vague instruction such as “improve the feed”. I want them to know the product ID, the incorrect value, where it came from and what should replace it.

2. Follow one product from the feed to checkout
I choose an affected item that represents the problem, then open its submitted URL as a customer would. I check the selected size or colour, visible price, currency, stock message and purchase path. Next, I compare those details with the processed product data and the page’s structured data. A correct value in the store admin does not prove that the public page or export is correct.
| Check | What I look for | Likely owner |
|---|---|---|
| Variant | The URL selects the submitted size and colour. | Feed or development team |
| Price | The offer and currency agree with the customer-facing page. | Ecommerce team |
| Availability | The item can be purchased as described. | Inventory team |
| Page access | The product loads without a broken link or forced login. | Development team |
Google publishes separate requirements for price and availability. I use the requirement relevant to the reported issue, rather than treating every disapproval as the same checklist.
3. Fix the source, not just the exported value
Suppose a sale ends on the website at midnight, but the feed still contains yesterday’s sale price the next morning. This is an illustrative example, not a client result. Manually changing one item may make it look correct until the next scheduled import restores the stale price. The useful fix is to check sale dates, export timing and the source field used by the integration.
I test another item from the same group and one unaffected item before approving a wider change. For a large catalogue, I group issues by shared cause: the same supplier import, product template or currency configuration. That is more manageable than asking someone to repair hundreds of products independently.
This is where Merchant Center management and product feed optimisation connect with the store itself. A Shopify catalogue and a WooCommerce store may send similar fields, but their apps, variant URLs and update schedules need separate checks.
Which issue and products?
What does the customer see?
Did the underlying fix hold?
4. Prepare a useful review request
Before a review, I retain the original issue message, the affected examples and a brief change log. I check that the corrected values are actually processed, not merely saved in a spreadsheet. If the issue concerns the business or website, I review that scope rather than assuming a product edit resolves it.
Use the review option provided for the issue after resolving it, or supply supporting information if you disagree with the finding. Repeated unsuccessful requests can trigger a cooldown. The account’s current instructions matter more than a promised turnaround copied from an old tutorial. The official review process is the reference I use.
I do not recommend opening replacement accounts to avoid an unresolved policy problem. I would rather give the business a clear explanation of the remaining issue and the information needed to address it.
5. Check recovery separately from sales performance
Once the status changes, I check whether the intended products and markets are eligible again. I then review visibility, clicks and purchases as separate outcomes. Approval does not establish that a product is competitive, well photographed or easy to buy.
My follow-up list covers feed freshness, recurring errors, high-priority products and purchase tracking. For paid traffic, I review the connected Google Ads campaigns separately. For free listings, I look for product-level evidence before assuming that every approved item will receive traffic.
AI can help group error messages or flag unusual data, but I still verify the product against the store. An automated suggestion should never invent an identifier, stock position or product claim just to fill an empty field.
Common questions
Should I delete and upload all products again?
Not as my starting point. I first identify the cause and preserve product IDs where appropriate. Re-uploading unchanged information can repeat the same problem and make the investigation harder.
Does a disapproval mean my whole website has an SEO penalty?
No. A Merchant Center issue and a Google Search manual action are different systems. I check the actual notification and affected destination before describing the problem.
Can you help if my feed is managed by an app?
Yes. I review the app mapping, source catalogue and processed data together. Some fixes belong in the store or integration rather than inside Merchant Center.
What should I send for an initial review?
Send your store URL, the exact issue message, affected country, feed platform and two or three product IDs. Do not send passwords; account access can be arranged with the appropriate permissions.
For the wider store journey, compare this with Google Shopping management and BigCommerce product SEO.
