What a disapproval means
A product disapproval means that product cannot show in the affected Google destination until the issue is resolved and the product is approved. A warning can allow the product to remain visible with limited performance or indicate a risk that may become more serious. An account-level suspension can disable all products in the affected account or destination.
Do not treat those states as interchangeable. Google’s current Merchant Center issues guide distinguishes product-level warnings and disapprovals from account-level warnings and suspensions. Status can also differ by country and marketing method.
Capture the evidence before editing
- Open Products & store → Products → Needs attention.
- Open the issue detail and record its exact name, scope, country and destination.
- Download the complete affected-product list, including warnings.
- Inspect two or three examples and the submitted versus processed values.
- Record the source responsible for each field before changing anything.
Join the item IDs to recent revenue or priority. Fix account-level policy and setup problems first, then product issues affecting the most commercially important inventory. A count of affected items alone can be misleading.
Diagnose by root cause, not only the error label
| Issue family | Common root cause | Evidence to compare |
|---|---|---|
| Price mismatch | Stale source, variant ambiguity, currency/tax or sale timing | Feed, processed value, page, structured data and checkout |
| Availability mismatch | Parent stock, delayed sync, preorder handling | Exact variant state through checkout |
| Invalid or missing identifier | Invented GTIN, wrong check digit, identifier omitted | Manufacturer packaging or authoritative product record |
| Image issue | Overlay, placeholder, crawl block, wrong variant | Fetched image URL and image requirements |
| Landing-page issue | 404/5xx, redirect, login wall, crawler block | Unauthenticated mobile and crawler-accessible URL |
| Policy issue | Prohibited/restricted product or site trust problem | Exact policy, site, account details and affected offers |
Fix the source of truth
Correct the ecommerce platform, ERP or primary feed transformation whenever possible. A manual Merchant Center edit that is overwritten at the next sync is not a fix. After updating, resubmit or allow the scheduled source to process, then inspect the processed value on an affected product.
For price and availability, make the feed, visible page, product structured data and checkout agree. Google supports automatic item updates for some temporary discrepancies, but warns that they do not replace regular accurate submissions. Use a faster update mechanism when stock or price changes frequently.
Need help tracing a Merchant Center issue?
Upscale can isolate the affected source, document the correction and prepare the account for the appropriate review path.
Book My Free Ad AuditCommon product disapprovals
Price or availability mismatch
Test the exact submitted variant without cookies or a login. Check sale periods, VAT, currency, quantity pricing, member pricing and any geolocation logic. If the page contains multiple offers, ensure structured data identifies the correct variant. Do not use automatic updates to mask a systematically stale feed.
GTIN and identifier issues
Submit the manufacturer-assigned GTIN where required and available. Do not create one, use an internal SKU or borrow an identifier from a similar product. For genuinely custom products without assigned identifiers, follow the product data specification for brand, MPN and identifier_exists rather than applying one rule to the whole catalogue.
Image problems
Remove promotional overlays, placeholders and borders that breach image requirements; confirm the image shows the submitted product and variant. Make the URL crawlable and stable. If Merchant Center offers an automatic image improvement for the specific issue, inspect the proposed result rather than assuming it preserves the intended image.
Landing-page failures
Resolve 404, server error, redirect loop, login wall, bot block and generic-category redirects. The product must be purchasable and the advertised price and availability must remain consistent. Use Google’s landing-page requirements as the baseline.
Account-level issues require a site-wide review
An account warning or suspension is not merely a feed-row problem. Review the exact policy named in Merchant Center, business identity, contact information, payment process, shipping and returns, domain security and the full product range. Fix all instances, not only the examples Google supplied.
Preserve evidence: screenshots, test orders, source exports and a dated change log. Do not create a replacement Merchant Center account to evade enforcement. If you disagree with the finding, prepare specific evidence tied to the policy rather than a generic appeal.
Request a review carefully
Use the review option shown for the issue after the correction is live and verified. Google’s review-request guidance distinguishes “I fixed the issue” from “I disagree with the issue”. Some cases require additional actions, such as identity verification, before review is available.
A review request does not guarantee approval or reinstatement. Google states that reviews can take up to seven business days, that unsuccessful attempts can lead to a cool-down period, and that support cannot bypass that period. Do not burn a review request on an unverified change. If the option is unavailable, follow the status and instructions shown in the account.
Verify the outcome
Approval is the first check, not the last. Confirm affected products are eligible in the intended country and destination, present in the relevant listing or product groups and receiving impressions. Reconcile the number approved with the exported affected list. Watch for the same issue returning after the next scheduled feed.
For a bulk correction, track approved product count, revenue-weighted coverage, recurrence rate and time from source fix to processed approval. If the issue recurs, revisit the source and update frequency instead of repeating manual corrections.
Prevention controls
- Alert on failed or delayed source processing.
- Compare high-velocity price and stock values between source and page.
- Validate product structured data and keep variant identifiers aligned.
- Monitor Needs attention after releases and catalogue imports.
- Test shipping, returns and checkout by target country.
- Keep stable item and image URLs; document feed-rule ownership.
Merchant Center should be operated as a production system. The aim is not to become fast at requesting reviews; it is to prevent inaccurate product data from reaching customers and Google in the first place.
Worked example: price mismatch on variants
A hypothetical shoe retailer submits a navy UK 8 variant at £110. The product link opens a parent page where UK 5 is preselected at £90; the JSON-LD Offer also reports £90, while selecting UK 8 changes the visible price to £110. Merchant Center flags a mismatch.
The correction is not to change every variant to £90. The team should make the submitted variant identifiable to the page, ensure the visible selection and structured offer report £110, and keep the same price through checkout. It should then refresh the source, inspect Merchant Center’s processed value and request a review only if the issue workflow requires one and the correction has been verified.
Acceptance evidence includes the exact item ID, fetched landing-page URL, selected variant, visible and structured price, checkout total, source timestamp and processed Merchant Center value. If another variant family uses the same template, test it before assuming the fault is isolated.
Worked example: identifier problem
A reseller receives a “limited performance due to missing GTIN” issue on branded appliances. The catalogue contains internal SKUs but no manufacturer identifiers. Setting identifier_exists to false across the category would be wrong because the appliances have manufacturer-assigned GTINs.
The team should obtain GTINs from packaging, the supplier or an authoritative product record, validate their format and check digit, preserve leading zeros and map them to the exact variant. Products that genuinely lack assigned identifiers need their own documented treatment. The measurement is complete, accurate identifier coverage and changed product status, not an assumed percentage lift in clicks.
Review-request checklist
- The exact issue and policy have been read in the account.
- All affected products or site instances have been examined, not only examples.
- The correction is live in the responsible source and survives a refresh.
- Processed values, landing pages and checkout have been tested.
- Required identity or business-verification actions are complete.
- Evidence and change dates are retained.
- The team understands that review does not guarantee approval.
When the account is in a cool-down period, use the time to verify the complete implementation. Do not attempt to bypass the status with a new account. For wider preventive controls, see the Merchant Center optimisation guide.
Keep a recurrence log by issue family and responsible source. If price mismatches reappear after every promotion, the incident is not closed merely because one review succeeded; the promotion-to-feed workflow remains defective. Set an internal service level for detecting and owning recurrence.
Do not promise a reinstatement date to stakeholders. Communicate what is controlled internally, such as correction, evidence and submission, separately from Google’s review decision and timing. That distinction matters for launch planning and paid-media forecasts.
Where products target several markets, verify resolution separately for each affected country and marketing method. A product approved for free listings in one country may still be ineligible for Shopping ads elsewhere. Retain the issue export so the final coverage check uses the same item set that entered remediation.