Skip to content

How do I fix Google Merchant Center disapprovals?

By cartscaling Reviewed 4 min read

The short answer

Sort the issues first. Item-level disapprovals are fixed in the feed or on the product page and clear when the data is next fetched. Account-level problems need the site changed before a review is worth requesting. Most item-level cases come down to price, availability or missing required attributes.

Sort the issues before fixing anything: item level or account level

The diagnostics view in Merchant Center groups problems by issue rather than by product, and that grouping is the fastest way to plan the work. Two kinds exist and they need different responses.

Item level issues affect specific products. A missing attribute, a price that does not match the landing page, an image that cannot be fetched, a product marked in stock when the page says otherwise. These are fixed in the feed or on the page, and they clear on their own once the corrected data is fetched.

Account level issues affect everything. They usually relate to policy or to the site as a whole, and no amount of feed editing will clear them. The fix is on the website, and afterwards you request a review.

Sort by the number of products affected before you start. One rule usually explains hundreds of disapprovals, so fixing the biggest group first clears most of the catalogue in one change. Working product by product from the top of a list is the slowest possible route.

Write down what each issue is actually complaining about in plain words before you edit. A surprising share of wasted work comes from guessing at the meaning of an issue name and changing the wrong field, which then takes another fetch cycle to disprove.

Mismatch issues: make the feed and the page agree exactly

The most common disapprovals come from the feed and the landing page disagreeing. Google checks the page it is sending shoppers to, and if the price or availability there differs from what you submitted, the product is pulled.

Price mismatches usually come from currency, tax display or timing. A price sent excluding tax while the page shows it including tax will mismatch. So will a sale that starts on the site before the feed is refreshed. Check that the value in the feed matches what a shopper sees on the page for the country you target, to the cent, including the currency code.

Availability mismatches follow the same pattern. If the store shows sold out while the feed still says in stock, the product goes. This is why the sync schedule matters as much as the values: a feed fetched once a day on a store with fast moving stock will always be behind.

Missing attributes are the other big group. Identifiers, brand, condition, and for clothing the size, colour, age group and gender values. Where the product genuinely has no identifier, there is a way to say so rather than leaving the field empty.

Images get pulled too, usually because the file cannot be fetched, is too small, contains promotional text or a watermark, or is a placeholder. Fix the source image rather than the feed entry, because the same image usually appears on many products.

Policy disapprovals: change the site first, then ask for the review

Policy problems are not data problems, and resubmitting the same feed will not clear them. Something about the product or the site does not meet the rules, and it has to change first.

Start with the site basics, because these cause account wide trouble. Working contact information, a clear returns and refund policy, terms that a shopper can find before buying, a checkout that completes without errors, and prices that do not change between the product page and the payment step. If a shopper cannot complete a purchase, the account has a problem no feed will fix.

Product level policy issues are about what you are selling and how you describe it. Some categories are restricted or not allowed at all, and some are allowed only with extra requirements. If your category sits near one of those lines, read the specific policy rather than working from memory, because these rules change and they differ by country.

When the change is made, request a review and then leave it alone. Requesting again immediately does not speed anything up, and repeated requests on an unchanged site are how a warning becomes a suspension.

While you wait, do not delete the affected products and re add them under new identifiers to dodge the issue. That is treated as a way around the rules and it makes the outcome worse.

Stop them recurring with feed rules and a weekly check

Clearing a list of disapprovals is a one off. Keeping the list empty is a process, and it takes about fifteen minutes a week.

Most recurring issues come from the source data rather than the feed itself. If products are created without a brand, or without size and colour values, every new product will disapprove the same way. Fix the template people use to add products, and the problem stops arriving.

Where the platform cannot express something, feed rules can fill the gap. Setting a default condition, mapping your internal categories to the right product categories, appending a size to a title, or supplying a value for products without an identifier. Rules are also the right place to handle exceptions, so that one odd product does not require a manual edit forever.

A supplemental feed is worth using when the fix belongs to a subset of products, because it lets you patch specific fields without rebuilding the main feed.

Then set the routine. Once a week, open diagnostics, look at new issues only, and check whether the count of active products matches what you expect to be selling. A catalogue that quietly loses a tenth of its products to a new issue is invisible in revenue for a week or two, and very visible after that.

Worked example, not a result

One rule fixing most of a disapproved catalogue

Products in feed
4,000
Products disapproved
1,200
Issue: missing size for apparel
800
Issue: price mismatch on sale items
300
Issue: image too small
100
Fixes needed
3
Products cleared by the first fix
800

Worked example, not a result

Related questions

It depends on when the corrected data is next fetched and reviewed. Data fixes usually clear within a day or two of the next fetch, while policy reviews take longer because a person may be involved.

Yes, while the issues are item level. If the account itself is suspended, nothing serves, which is why account level problems always get worked on first.

No. Removing them hides the issue rather than solving it, and the product returns disapproved as soon as it is added back. Fix the data, or the page, and let it clear.

Keep reading

Want this answered for your store?

Send it. The plan looks at your numbers, not the general case.

Store, name, email and phone. A person replies from a real inbox. Privacy

Get your free growth plan