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