You opened Google Merchant Center to find a wall of products marked "disapproved," and the first button you reached for was "Request review." That impulse is exactly what stretches a three-minute fix into a three-week outage. The re-review button does not diagnose anything. It just puts the same bad data back in front of Google and waits for the same algorithm to reject it again.
What you'll take away
- Stop clicking re-review — Repeated review requests without fixing the underlying data do nothing and can flag your account for manual review.
- Trace every error to its source — A rejection for a wrong price usually starts in your store admin or your feed-management tool, not in Google Merchant Center.
- Fix the feed, not the product page — If you use an automated feed, manual edits inside Merchant Center get overwritten on the next sync, so correct the source data.
- Prevent the next batch — A feed-validation step that catches invalid data before it reaches Google is cheaper than chasing individual rejections.
Why does Google Merchant Center reject products in the first place?
Google Merchant Center rejects products when the data it receives violates a published rule in the Merchant Center product data specification or falls foul of one of Google's shopping ads policies. The rejection is not a penalty. It is Google refusing to show an ad or free listing that would mislead a shopper or break a legal requirement. The system that flags the violation runs automatically, so the disapproval appears within hours of the feed being processed.
Re-review is a submission, not a diagnostic tool. It tells Google you think the problem is gone, not that you have found it.
Every rejection comes with a reason code, visible in the Diagnostics section of Merchant Center. That reason code is the single most important piece of information on the page. The reason code tells you what rule was broken, and from there you can work backwards to which field in your data caused the breakage. Without reading the reason code, any fix you attempt is a guess.

What is the first step when a product gets disapproved?
The first step is to open the Diagnostics tab in Google Merchant Center and read the exact reason code attached to the rejected product. Do not request a review yet. Do not edit the product in Merchant Center yet. Read the reason, identify which product is affected, and note the specific attribute Google flagged. That reason code is your entire troubleshooting map for the rest of the process.
Google's diagnostics page sorts issues into two categories. Item-level issues affect individual products and are usually caused by a missing or invalid attribute value. Account-level issues affect everything in your feed and are typically policy or setup problems. If a single product is rejected, you are dealing with an item-level issue. If your entire catalog is rejected, check the account-level warnings first, because no amount of product-data fixing will resolve a suspended account.
Read the reason code before touching any data
Merchant Center gives you the issue name, the affected item count, and the attribute involved. If the reason is "Missing GTIN," you know to check your GTIN field. If the reason is "Price mismatch," you know to compare your feed price against your landing page. The reason code narrows the search from your entire catalog to one field.
How do you find where the rejected data is coming from?
You find the source of the rejected data by tracing the flagged attribute back through your feed pipeline to its origin. Google Merchant Center is the destination, not the source. The value it holds came from somewhere else, and you need to find that somewhere else before you change anything. The pipeline typically has three layers: your store platform, your feed-management tool, and Merchant Center itself.
For each rejection type, a different layer is usually responsible. A price mismatch means your feed and your landing page disagree, so you check the landing page and the store price. A missing GTIN means the value never made it into the feed, so you check the feed tool's mapping and the store platform's barcode field. A wrong product category means your Google product taxonomy mapping is off, so you check the feed tool's category rules.
What are the most common reasons products get rejected?
The most common rejection reasons fall into four categories: mismatched data between feed and landing page, missing required identifiers, policy violations, and landing-page issues. Google publishes a full list in its product data specification, but a handful of reasons account for most rejections in practice.
| Rejection reason | What it means | Where to fix it |
|---|---|---|
| Price mismatch | Feed price differs from landing page price | Store platform or feed tool |
| Missing GTIN | No valid barcode for a product that requires one | Store platform product data |
| Missing identifiers | Brand or MPN absent for a variant product | Store platform product data |
| Wrong category | Google product category missing or inaccurate | Feed tool category mapping |
| Image policy | Image too small, has watermarks, or is a placeholder | Store platform image field |
| Landing page error | Page returns 404, requires login, or is down | Store platform or server |
Price mismatch is particularly common because it happens silently. Your store runs a sale, the landing page updates immediately, but the feed tool syncs on a schedule. For those hours between the page update and the next feed sync, Google sees two different prices and rejects the product. The fix is not to change the feed price. The fix is to make sure the feed sync frequency matches how often your prices change.
How do you fix the source data without losing your changes?
You fix the source data by editing the product in your store platform or your feed-management tool, not by editing it directly inside Google Merchant Center. The reason matters: if your feed is automated, any manual edit in Merchant Center gets overwritten the next time the feed syncs. You fix the product, the sync runs, and the bad value comes right back.
Manual Merchant Center edits get overwritten by automated feeds
If your feed is generated by an app or a scheduled fetch, editing the product directly in Merchant Center is temporary. The next sync replaces your fix with the original bad value, and the product gets rejected again. Fix the source so the correct value flows through automatically every time.
The source-data fix sequence
For stores using automated feeds from Shopify or WooCommerce, the store platform is almost always the source layer. The feed tool pulls directly from product data in your store admin. If a GTIN is missing, you add it to the product's barcode field in Shopify. If a title is too short, you rewrite it in the product's title field. The feed tool picks up the change on the next sync.
Before · 14 characters
Blue T-Shirt M
After · 68 characters
Gildan Men's Short Sleeve T-Shirt, Cotton, Navy, Medium
When should you request a review after fixing a product?
You request a review only after the corrected data has synced to Google Merchant Center and the Diagnostics tab still shows the rejection. For most feed-driven rejections, the disapproval clears automatically once the fixed value is processed. You do not need to request a review for a price mismatch or a missing GTIN. The system re-evaluates the product on the next feed fetch.
Review requests exist for situations where a human reviewer at Google flagged a policy violation. If a product was disapproved for a misleading claim, a prohibited item, or a restricted category, a human reviewer needs to look at it again. In those cases, you fix the underlying issue, wait for the feed to sync, and then submit a review request from the Diagnostics tab. Google's policy is to process review requests within 72 hours, though complex cases can take longer.
Repeated review requests without fixes can trigger account scrutiny
Google tracks how many times you request a review without changing the underlying data. Submitting multiple requests for the same rejected product without fixing anything signals to Google that you are not addressing data quality. In some cases, this leads to account-level reviews that can suspend your entire Merchant Center account.
How do you prevent rejections across a large catalog?
You prevent catalog-wide rejections by adding a validation step between your store and Google Merchant Center. A feed validator checks your data against Google's specification before the feed reaches Google, so you catch missing GTINs, short titles, mismatched prices, and wrong categories at the source. The validator flags the problem. You fix it. Then the clean feed goes to Google.
For large catalogs, prevention is not optional. A 10,000-product store with a 2% rejection rate has 200 products to fix manually every week. A validation step that catches those 200 before they reach Google saves the time and preserves your account's data-quality score. Google tracks rejection rates across your account, and a persistently high rate can affect how your listings perform in free listings and Shopping ads.
A feed-management process that validates data before it reaches Google is the difference between chasing rejections and preventing them. The tools that do this range from built-in validators in feed-management apps to standalone feed validators that check a URL against Google's specification. The principle is the same: if you find the error before Google does, the rejection never happens.
Common questions
Why does my Google Merchant Center keep rejecting the same products?
Your Google Merchant Center keeps rejecting the same products because the source data feeding into Merchant Center has not changed. If you use an automated feed from Shopify or another platform, the sync overwrites any manual fix you made in Merchant Center. You need to correct the product data in your store platform so the next sync carries the correct value to Google automatically.
How long does it take for a fixed product to be approved in Google Merchant Center?
Most fixed products are approved within a few hours of the corrected feed syncing to Google Merchant Center. The system re-evaluates products automatically on the next feed fetch, so you do not need to request a review for standard data issues like price mismatches or missing GTINs. Policy-based rejections that require human review take up to 72 hours after you submit the request.
Can I request a review for a product that was rejected for a policy violation?
Yes, you can and should request a review for products rejected for policy violations after you have fixed the underlying issue. Policy rejections require a human reviewer to re-evaluate the product, unlike data-specification rejections which clear automatically. Fix the issue in your source data, sync the feed, then submit the review request from the Diagnostics tab in Merchant Center.
Do I need a GTIN for every product in my Google Shopping feed?
Google requires a GTIN for products that have a GTIN assigned by the manufacturer, which covers most branded products sold at retail. Custom or handmade products that do not have a manufacturer-assigned GTIN can be exempt, but you must still provide a brand and an MPN. If your product has a barcode and you leave the GTIN field empty, Google will reject it.
What happens if I keep requesting reviews without fixing the product?
Repeated review requests without fixing the underlying product data can trigger account-level scrutiny from Google. The system treats multiple unfixed requests as a signal that you are not maintaining data quality. This can lead to a manual review of your entire Merchant Center account and, in serious cases, a suspension that stops all your Shopping ads and free listings until the issues are resolved.