Rejected items in Merchant Center: how to interpret the diagnostics
Merchant Center diagnostics is read on three levels: account, data source and individual product. A disapproved product is a product excluded from display — it does not take part in the auction and the ad for it does not exist, however much budget you have. Reading starts from the level of the error, not from the list of products, because one account-level problem can stop the whole catalogue at once. In the shops I review, most disapprovals come from four recurring causes: a discrepancy between the price in the feed and on the website, missing delivery or returns information, a missing unique identifier and images with overlaid text. Each of them is fixed once and, with a consistent feed, does not come back.
My name is Hristiyan Panov — a performance marketing consultant with over 5 years’ experience and over €2 000 000 managed advertising budget for over 90 companies on Google and Meta. Below is how to read the diagnostics and in what order to work.
Where do you look and what do the levels mean?
В Merchant Center → Products → Diagnostics. The screen reads from top to bottom: first the status of the account, then of the data source, and finally of the individual item. The problems fall into three levels:
- Rejected — the item is not shown and does not take part in the auction. This is fixed first.
- Warning — it is shown, but with restrictions or in a weaker position.
- Recommendation — it works, but could be better.
Next to each error you will see the number of affected items and a link to their list. Open the list, export it and check it against the revenue of those products in the store — that shows which problem costs money and which one merely looks big. The order of work is by the number of affected items relative to their revenue, not by the alphabetical order of the errors.
Also look at the date of the last feed crawl. Until the feed has been fetched again, the fix is not registered and the status in diagnostics still shows the old state.
Discrepancy between the price on the website and in the feed
The most common cause. It arises when the website shows a promotional price while the feed submits the regular one — or the other way round. Google checks the page and disapproves on a mismatch.
The check is manual and takes a minute: open the URL from the feed in an incognito window and compare the visible price with the price field and with the sale price field. A mismatch usually comes from one of the following: the promotion only appears in the cart, the price depends on the selected variant, the page is served from a cache with an old value, or the structured data on the page gives a different number from the visible one. A sale price also requires a valid period — an expired promotion left in the feed produces the same rejection.
Check both the currency and whether the price includes tax in the way your settings require. The product price does not include shipping — that is described separately. For stores in transition between currencies this is also the most common source of error: rounding during conversion leaves a small difference between the two values, and that is enough for a rejection.
Missing delivery and returns information
Google requires clear terms — either as a setting in the account or on the website. Their absence disapproves whole groups of products at once, which looks like a big collapse but is one setting.
Shipping is described per country: a price or a table of prices, order processing time, transit time and the working days on which you dispatch. If you have bulky goods with a separate rate, they get their own rule rather than the general value for the whole catalogue. Return conditions require a time limit and a statement of who bears the cost of the return.
The second check is for consistency. What is set in the account and what is written on the website must say the same thing. When the page announces one delivery time and the setting submits another, the items pass, but the buyer receives a promise the store does not keep, and this comes back as a refusal on delivery. That is why the conditions are reviewed whenever the courier or the rates change.
Unique identifiers
GTIN, brand and manufacturer part number. The GTIN is the barcode on the packaging and is obtained from the manufacturer or the supplier — it is not made up and is not replaced with your internal stock number. For branded goods a missing GTIN usually means rejection. For your own production, you state explicitly that the item has no GTIN — this is valid, but it must be declared.
Every variant — size, colour — needs its own identifier. Merged variants damage both the advertising and the statistics: a sold-out size stops the whole listing, and the sales data gets mixed together. The variants themselves are linked through the group field, so that they do not compete as separate products in the same result.
Also check for repeated identifiers across different products — a duplicated number confuses matching. Once set, the identifier is kept stable: if it changes, the item starts as a new one and the accumulated history disappears.
Images that do not pass
Overlaid text, watermarks, frames, collages and images of too low resolution. The rule is simple: the image shows the product, nothing more.
Promotional text on the image is the most common violation — what works on social media gets the item rejected here. A logo placed over the product, artificial frames and arrows are also out, as are placeholder images such as “photo coming soon”. The frame shows what the buyer receives, without accessories and decoration that are not included in the price.
Separately from the content, the image URL is checked too. It must be publicly accessible, must not be behind a block and must not change with every catalogue update, because after each change the image goes through a fresh check. Additional shots go into the additional images field and are not merged into a single collage. The variant image shows exactly that variant — the colour in the feed and the colour in the frame must match, otherwise a rejection follows even for a product that is otherwise in order.
Problems with access to the page
If the server returns an error or blocks Google’s crawler during the check, the product drops out. Check that the address in the feed is the correct one, that it works without a redirect and that it is not behind a firewall block.
The review list is short: the rule in robots.txt, the validity of the certificate, the server response to a request from a foreign address and the behaviour with a deleted or hidden product. It also checks how the page opens on a phone, because the check runs on the mobile version as well. A separate subgroup is pages that return a normal response but no longer contain a product — to the check they look functional, while to the buyer they are empty.
The URL in the feed points straight to the product, with no intermediate redirect and no tracking parameters pasted into the field itself. This is also why mass rejections happen right after a change in hosting or in the website’s protection: a rule raised against bots stops Google’s crawling together with them.
How do you stop the same errors coming back?
- The feed should be fetched automatically on a schedule, not uploaded manually.
- A rule in the feed for every recurring problem, instead of correcting a product by hand.
- Check the diagnostics once a week and always after every change to the website.
- Email notifications from Merchant Center — switched on and reaching a person who will act on them.
- Fix it at the source of the data where possible — a rule in the feed is a patch, not a solution.
- A short note on which problem was solved and how, so that it is not searched for from scratch next time.
A change of theme, plugin, hosting or pricing logic is a reason for a dedicated check the next day, not at the end of the month. The fetch schedule is set after the hour at which the store updates prices and stock — otherwise the feed supplies yesterday’s data and the mismatch with the price on the website appears by itself.
FAQ — Frequently asked questions about disapproved products
How quickly does a product recover after a fix?
Usually after the next crawl of the feed — from a few hours to a few days, depending on the schedule.
Can I request a review?
For policy violations — yes, once the problem has been fixed. For technical errors it is not needed; it passes automatically.
Why is only some of the variants disapproved?
Usually because only they have a missing field — most often an identifier, size or image.
Do disapproved products affect the rest?
Not directly. Indirectly yes, because with a high share of disapprovals the account may receive a warning at shop level.
Who should fix the feed?
Whoever is responsible for the product data. A large part of the fixes are in the shop’s system, not in the ad account.
Conclusion
Merchant Center diagnostics is the most underrated work in Shopping. It does not require a strategy — it requires someone to open it regularly and fix things in order of the revenue affected.
If part of your range is not being advertised and you do not know why, start with an independent review.
Request a quote for a digital audit →
Related articles: Merchant Center checklist · Google Shopping in Bulgaria: status · Google Shopping for an online shop · Performance Max · product page
