Disapproved products in Merchant Center: a repair plan
Disapproved products in Merchant Center? Compare your submitted offer with the product page, document repairs, request the applicable review, and verify status.

Disapproved products in Merchant Center: a repair plan
Disapproved products in Merchant Center need an item-level investigation before a broad catalog change. Capture the exact issue, compare the submitted offer with its destination, repair the inconsistency, and use the review route available for that issue.
Is this an item issue or an account problem?
Start by identifying the scope. Merchant Center holds the product information a retailer shares with Google. An item problem and an account suspension are not interchangeable. Record whether the notice concerns selected products or the account, and do not assume that a rejected item means every listing has stopped.
For product issues, open Products and find Needs attention. The Fix option beside an affected item leads to its details. Interface wording can vary by language and account. Your immediate goal is to capture the exact notice, the item identifier, and the destination it concerns, rather than make a broad guess about your advertising.
Imagine a small homeware retailer whose discounted lamps are affected while its storage boxes are not. That pattern suggests checking the promotion update process first. It does not prove that discounts caused the issue. Select one affected lamp and one comparable unaffected item to establish a useful investigation sample.
Keep advertising account notices separate. If Google Ads itself is suspended, use our Google Ads suspension guide. A shared incident note is useful, but the two services may require different actions. This article concerns product data diagnosis, not a promise to reinstate an entire merchant account.
Create an incident record before changing the catalog
A good incident record prevents a retailer and its agency from working on different versions of the problem. Save the notice text, item ID, product URL, and the time you checked it. Add the name of the data source and the person responsible for updating it. You do not need a new project management tool for this; a shared document can work.
A feed is the product information sent to the platform. It is distinct from the page customers see. Changing the storefront does not establish that the submitted record has changed too. Keep the storefront and the Merchant Center item details open side by side so that you can compare the actual offer rather than rely on memory.
Group items by observed issue, not merely by product category. Separate price inconsistencies from incorrect destinations. Investigating a representative item can expose a common process failure, but check the remaining items before claiming the whole group is fixed. Sample selection is an investigation technique, not a shortcut around verification.
Agree who can confirm the commercial truth. A developer can check an integration, but the retailer should confirm the intended price and variant. The marketer should record the platform status. One person may hold all three roles in a small shop; writing down the decisions still makes the handover clearer.
Compare the same offer across three places
For a price issue, compare the submitted record, the visible product page, and the page’s machine-readable product information. Structured data is information formatted for software to understand. Ask the site maintainer to check it if you cannot inspect it yourself. Do not assume that a visually correct page guarantees a consistent submitted offer.
Before comparing numbers, confirm the variant. A large gift set and a smaller refill can share a product name but have different prices. Note the size, color, quantity, and selected option in your incident record. The destination should present the offer associated with the submitted item, not leave the shopper to discover which variant the listing meant.
Google’s price guidance identifies promotion timing, variant selection, and inconsistent structured data as possible causes of mismatch. Use those as investigation prompts, not a declaration that they caused your particular rejection. A storefront sale may have ended while an earlier value remains in the product source. Check the actual records before assigning responsibility.
Availability deserves its own comparison. Look at the submitted availability and the shopping experience for the same variant. Record where an item becomes unavailable rather than rewriting every stock value. For later marketing attribution, our UTM tracking guide may help, but attribution cannot repair an inconsistent offer.
Inspect the destination as a customer would
Open the exact submitted URL outside your usual logged-in session. Check it on a phone as well as a desktop. The destination should be a specific product page, not a category or a search result. A URL that seems sensible in a spreadsheet can still open a different variant or an old page.
Google’s landing page requirements call for matching product information and a clear purchasing experience. Check the product, image, price, currency, availability, and purchase control. Watch for banners that obscure the essential information. This is a consistency check, not an invitation to make a page look different specifically for a reviewer.
Give the maintainer a reproducible observation: the URL you opened, the selected option, and what you saw. “The page is broken” is less useful than a note showing that a submitted large set opens with the small set selected. Screenshots help, but they should accompany the address and observation rather than replace them.
Also note automatic changes in language or currency that affect the submitted offer. Ask how a shopper arriving from that listing is meant to experience the page. Once the information is consistent, broader platform choice can be considered with our SEO versus Google Ads guide. Keep that commercial decision separate from the immediate rejection investigation.
Use a small, controlled repair plan
The following table is an operational template, not a complete catalog of Google policy issues. Begin with the actual notice in your account. If your inspection reveals a second problem, add it as a separate task rather than quietly changing the original diagnosis. This keeps everyone clear about what has and has not been established.
| Observation | First comparison | Evidence to retain |
|---|---|---|
| Prices differ | Variant and promotion values | Before and after records |
| Wrong product opens | Submitted destination URL | Correct product address |
| Availability differs | Storefront and submitted record | Update observation |
| Repair is not visible | Latest received product data | Synchronization result |
Repair one representative item, verify the change, then inspect the related group. Changing the storefront, connector, and campaign simultaneously makes it harder to understand which action mattered. Controlled changes will not guarantee approval, but they produce a more useful record for follow-up work.
Write the task in terms of the item, field, intended value, owner, and acceptance check. Do not simply ask an agency to “fix the feed.” If catalog changes also affect customer communication, coordinate the announcement separately. Our Instagram Shopping guide covers a different platform and should not be used as a Merchant Center eligibility rule.
Request review only after checking the repair
After the source and destination agree, inspect the review action available for that issue. Google may require a review in some cases. Applicable product details can offer Request review or Request website check. Follow the issue-specific instructions shown in the account rather than assume every item has the same button.
There is a difference between saying you fixed an issue and disputing the finding. Choose the route that reflects what happened. If disputing, retain evidence supporting your explanation. If repairing, retain the changed values and the observed result. Repeated requests without a clear explanation are not a sensible substitute for diagnosis.
The official review guidance says a review may take up to seven business days. Treat this as published guidance, not a guaranteed completion time for your account. Unsuccessful attempts can lead to a cooldown, and support cannot shorten that waiting period. Use the status and dates shown in the account to plan follow-up.
Keep an affected item out of the “resolved” column until you have checked its status. Increasing spend does not correct product data. If you are reconsidering channel allocation while waiting, our Google Ads versus Facebook ads comparison addresses that separate decision. Avoid treating a campaign budget change as evidence that the merchant issue is solved.
Prevent recurrence with a practical weekly check
Connect the person changing prices with the person maintaining the submitted data. Include a representative item check when a promotion begins and ends. After adding a variant, open its submitted destination. After changing a store theme, verify that important offer information remains visible. These are suggested operating habits, not additional Google policy requirements.
- Keep affected item IDs together with their notices.
- Compare the submitted offer with the destination.
- Record the repair owner and observed changes.
- Use the applicable review route when ready.
- Check the final status before closing the incident.
Do not turn the first rejection into a shopping project for new software. Establish where the existing process failed first. A small catalog might be manageable with a simple change log; a larger one needs clearer update ownership. The useful question is whether your team can see a failed or delayed update, not how sophisticated its dashboard looks.
Approval is not a sales guarantee. A consistent product can still have an unattractive offer or a poor delivery experience. Assess those questions after restoring reliable data. If you manage post-inquiry communication, our sales follow-up guide covers the later workflow. For this incident, success means a documented cause, a verified repair, and an observed platform status.
Should I delete and recreate the rejected item?
Identify the cause first. Recreating an item is not evidence that an inconsistency was repaired. Use the instructions applicable to the issue shown in your account.
Is fixing the visible price enough?
Check the submitted source and structured data too. Record whether the corrected offer has actually reached Merchant Center rather than assume a storefront edit completed the repair.
Why is the review button unavailable?
Availability depends on the issue and account state. Check for required steps and any cooldown shown in the account. Ask support if the specific reason remains unclear.
Does this guide establish country eligibility?
No. Verify the target country, program, and account requirements separately. Product repair instructions do not establish that every merchant feature is available in your market.
Does approval guarantee sales?
No. Product status and commercial performance are different questions. Offer quality, delivery, and the customer experience still need their own assessment.
Sources
Follow me on Instagram
Short notes, practical examples and daily digital strategy ideas.
I'm Anar Rustamli - a strategist, entrepreneur, and AI adoption leader working at the edge of growth, technology, and human thinking. Since 2016, my work has focused on helping businesses evolve in a rapidly changing digital landscape. I design growth systems, AI-powered workflows, and strategic frameworks that align performance with purpose. I believe real growth happens when strategy, data, and human insight work together - and my mission is to help businesses adopt AI in a way that strengthens both their results and their identity.

