Start
Services
SEO & Positioning Free AEO/GEO audit Web Development UX/UI Design Paid Media SEOMOS AI CRM New Us Blog
Digital marketing

Disapproved Merchant Center products: what to check

Diagnose Merchant Center product disapprovals: scope, price, availability, store data and checks before requesting another review.

Professional comparing a physical product with its online store listing.

To recover disapproved Merchant Center products, start with the exact issue and its scope. A price mismatch, an availability discrepancy and an account-level problem require different responses. Random title changes or another feed upload may leave the cause in place and make the investigation harder to follow.

The goal is a straightforward evidence chain: what Google received, what the shopper sees and which setting creates the difference. Correct the responsible source, confirm the update and follow the applicable review process. Google controls final approval; no agency can guarantee it.

Distinguish products, destinations and account issues first

Open the issue details before editing. The Merchant Center issue details page brings together the problem, affected products and available guidance. Record country, data source and destination when shown: the scope can differ from what a general alert suggests.

What you see What to check What to avoid
A few disapproved products IDs, variants, country and specific attributes. Changing the whole catalogue to solve an isolated issue.
Many products with the same error Templates, integrations, feed rules and shared data. Fixing rows individually without repairing the common source.
Account warning or suspension The account issue, website and cited policies. Assuming a new product upload removes an account issue.
Different price or stock Feed, variant, landing page, structured data and update timing. Requesting review before the correction is visible.

Google distinguishes product and account enforcement in its data quality documentation. Preserve that scope in your incident log: one excluded variant and a suspension affecting account participation are different situations.

Investigating a mismatched price

Select one affected ID and open its submitted URL for the correct variant and market. Compare price, currency and conditions with the processed Merchant Center data. Check whether an integration sends an expired sale price, another variant or a currency that changes with visitor location.

Google’s price mismatch guidance explains the correction and the need for consistent, accessible page information. A JavaScript display change may not resolve a discrepancy if initial HTML or structured data still contains another amount. Coordinate the correction with whoever maintains the store.

Check the complete data chain

  1. Identify the system holding the correct price: an ERP, ecommerce platform or another source.
  2. Review how the value is transformed for the feed and when it updates.
  3. Check the landing page, selected variant and structured data.
  4. Correct the source creating the discrepancy.
  5. Verify the processed value and retain a before-and-after example.

Automatic updates can help with certain discrepancies, but they do not replace a consistent integration. If each synchronisation sends the old price again, a manual correction at one point is only temporary.

For availability issues, review variants and timing

A product can exist in the store while being unavailable for the submitted variant or country. Compare the affected ID’s stock, page, purchasing conditions and update frequency. A template that marks everything available can fail even when the internal inventory is correct.

The official availability mismatch guide covers correction and review. An alert remaining immediately after a fix does not prove the correction failed: processing or another check may still be needed. Verify the sequence and status before stacking more changes on top.

A hypothetical promotion that ends on the website

A retailer ends a promotion on Monday. The website restores the usual price, but a scheduled task continues generating the feed with the sale value. Some variants become disapproved. The team identifies the source field and task, repairs the logic and checks a sample of affected IDs before extending validation to the rest.

A review request without repairing the task would not remove the cause: the next synchronisation would reintroduce it. This is a hypothetical example, not a SEOMOS case or outcome. It illustrates the difference between fixing a data process and merely uploading the file again.

What to document before requesting review

  • The exact issue and its scope.
  • Sample IDs and URLs for affected variants.
  • The changed source, owner and update date.
  • Evidence that processed data, landing page and purchase conditions agree.
  • Any related issues still unresolved.

Request a review only when available and after fixing the indicated problem. Waiting periods or request limits can apply; follow the status shown in the account. Do not promise sales staff an approval date or change the entire catalogue while a specific correction is being evaluated.

When the advertising campaign also needs review

Approval does not guarantee impressions or sales. After resolving Merchant Center, review account linking, product selection and the relevant campaign configuration. Keep this separate from the disapproval diagnosis so you do not change bids or budgets while the inventory is ineligible.

Our Google Ads for ecommerce service considers the catalogue, measurement and profitability together. An audit can identify where to investigate; changes to store integrations are agreed according to scope and available access.

Build a sample that represents the issue

Do not investigate only the first product in the list. When an issue affects different variants, markets or sources, choose a sample covering those differences. Include an affected product and an apparently correct one where possible. Comparing them helps determine whether the problem belongs to a shared rule or an individual value.

For each sample, preserve the exact ID, submitted URL, selected variant, market and displayed issue. Record when you observed it. Comparing yesterday’s feed with a page changed minutes ago can create an apparent contradiction. Evidence should allow another person to repeat the check without guessing which version you inspected.

Separate the source system from its transformations

A store can hold the correct price in its platform while generating an incorrect final file. Rules, connectors, caches and scheduled jobs may sit between the two. Draw the chain with specific names: commercial system, integration, submitted source and processed value. Then find the first point where the difference appears.

Do not change every link in the chain merely to make one sample agree. A manual file repair may be undone by the next connector update. Changing the store to fit an incorrect feed may damage the actual offer. Repair the responsible source while preserving the valid commercial reference.

Assign an owner to each stage. Advertising staff may identify the discrepancy and its scope, development may correct a transformation, and operations may confirm price or inventory. Without that separation, several people can edit the same value using different assumptions. A short decision log prevents one repair from creating another issue.

Inspect variants rather than only the initial page

A product with sizes, colours or packages needs checking against the affected ID. Open the submitted destination and note which variant is selected. Check whether price, image and availability refer to that combination. A generic product page can appear correct while the submitted variant remains inconsistent.

Check the experience without an existing session as well. A cookie, previously chosen location or saved preference may change what you see. Do not assume Google or a new shopper receives the same version as your usual browser. Record the context and conditions, and provide a reproducible way to reach the correct variant.

Use an evidence record for each issue

Field What to record Decision it supports
Scope Reason, country, destination and affected products Prioritise a shared cause before editing rows
Processed data Value and date visible in Merchant Center Establish what information the platform received
Shopping experience URL, variant and observed conditions Locate the discrepancy encountered by a customer
Correction Changed source and responsible owner Avoid contradictory or temporary repairs
Validation Completed and pending checks Decide whether a review request is appropriate

The record should not become a store of sensitive information. Keep only necessary samples and use access controls. A summary with IDs, statuses and links is usually sufficient for coordination. Before sharing screenshots, remove customer orders, personal data and access details that do not help investigate the issue.

Prioritise by cause and ability to repair

Affected product count matters, but it is not the only criterion. A rule changing an entire catalogue may deserve attention ahead of isolated errors. Consider which products belong to the current offer and which team can repair the source. Document the priority so each new alert does not interrupt work already underway.

Commercial urgency is not a reason to claim a complete repair prematurely. If you checked only a sample, explain what it represents and what remains. With a template change, examine other cases using that template. With an individual value, avoid extending the correction to products with different conditions.

A hypothetical catalogue updated by two connectors

Imagine an integration sending current inventory while an old scheduled job republishes an earlier file overnight. During the day the product appears correct; at the next check the error returns. The team might interpret this alternation as a review failure when two sources are actually trying to maintain the same value.

The investigation compares schedules, sources and affected IDs. The team identifies the process that should own the data, then corrects or retires the redundant flow with agreed validation. Uploading the correct file every morning does not solve the underlying issue. This fictional scenario does not establish another account’s cause; it demonstrates why chronology belongs in the investigation.

Document the expected state after each update. For example, note which source should be responsible, when its refresh normally runs and which sample will confirm the outcome. This gives the next operator a concrete check instead of a vague instruction to watch the account. If ownership remains unclear, resolve that operational question before making more overlapping changes.

Prepare commercial activity after the correction

Once the issue is resolved, verify that the offer is still serviceable: stock is available, the page works and checkout conditions remain consistent. If campaigns or products were paused during the work, record who decides whether to reactivate them. Removing an alert does not automatically authorise additional spend or a new commercial strategy.

Keep a follow-up check after the next normal data update. This tests whether the source reintroduces the problem. Record the signal that would reveal a regression and who will handle it. Closing an incident usefully means preserving the corrected cause, evidence and maintenance check alongside the Merchant Center status.

Share an understandable handover with sales and operations. State what changed, which products are included and which questions remain open. Avoid translating a technical correction into a promise of immediate orders. Advertising performance still depends on demand, campaign eligibility, the offer and the buying experience after the catalogue becomes usable again.

Before handing the incident back to routine management, confirm who owns the next source update. A technical fix without an assigned maintenance owner can leave the same underlying dependency unmanaged, even when the current product sample is correct.

Your first Google Ads audit is free. Let’s review what limits your account and what to improve first. Request my free audit.

Frequently asked questions

Should I delete and upload disapproved products again?

Not as the first step. Identify the cause and correct the source. Uploading again may repeat the error if the integration or landing page still supplies inconsistent data.

How long does Google take to approve a correction?

It depends on the issue, processing and applicable review process. Follow Merchant Center status; no approval date can be guaranteed for every case.

Does a product disapproval mean the account is suspended?

Not necessarily. An issue can affect specific products or the account. Check the reason and affected items in the issue details.

Can SEOMOS review the issue for free?

Your first Google Ads audit is free and can identify which account or catalogue area needs investigation. Repairs and integrations are agreed according to scope.

Keep reading

WhatsApp