Most Merchant Center problems are not policy problems. They are consistency problems. The feed says one thing, the product page says another, and Google resolves the disagreement by removing the item rather than by guessing which version is true.
Once you see it that way, the diagnostics list stops being a wall of unrelated warnings and becomes one question repeated in different forms. Does the page confirm what the feed claims. Price, availability, identity, shipping, and the specific attributes for your category.
The stores that keep a clean account are not the ones with the best tooling. They are the ones who treat the account as a weekly job with a work queue, and who fix warnings before those warnings become disapprovals. Warnings are the more useful half of the list, because an item with a warning is still selling. An item with an error already stopped, and you already lost the sales.
Price and availability that do not match the page
This is the one we find most often and the one that costs the most, because it usually hits your best sellers first.
The cause is almost never a wrong price typed somewhere. It is timing and context. A sale starts, the feed updates on its own schedule, and for some hours the two disagree. A currency or tax display setting means the page shows a price that includes something the feed does not. A subscription option changes the displayed price to the discounted recurring rate while the feed sends the one-time price. A region-specific price shows to a visitor from one country and not another.
Stock has the same shape. The page says available while the feed still says in stock from an export made this morning, or a variant is sold out and the page defaults to it.
The fixes are mechanical. Use automatic item updates so Google can correct small drifts from your page. Keep the price the page shows to an anonymous visitor identical to what the feed sends. Be careful with apps that rewrite displayed prices, because the page a crawler sees is not the page your logged-in customer sees.
Warnings are the more useful half of the list, because an item with a warning is still selling.
Missing identifiers on products that need them
Identity attributes decide whether Google can match your item to a known product, and matching decides how competitive your listing is.
For manufactured goods with a barcode, the identifier is expected, and supplying it correctly usually improves visibility rather than merely avoiding a warning. Wrong identifiers are worse than missing ones, because a code copied from a similar item attaches your listing to the wrong product entirely.
For genuinely handmade or own-brand items with no barcode, the correct answer is to declare that the identifier does not exist rather than to invent one or leave the fields empty and hope.
Brand is the field stores most often get wrong. Retailers put their own store name in the brand field for products made by someone else, which breaks matching for every one of those items. The brand is whoever made the product.
The practical routine is a monthly export of items missing identity fields, sorted by how much revenue those items produce, so the work goes where it pays.
Images that fail for reasons nobody expects
Image rejections are the most confusing category because the image usually looks fine to a person.
The common causes are promotional overlays, watermarks, borders, and text baked into the picture. A badge saying free delivery, a sale flash, a logo in the corner, a size chart used as the main image. All of these are treated as promotional content rather than as a picture of the product.
Placeholder images and generic graphics fail too, as do images too small to be shown at the sizes Google needs, and images hosted somewhere that blocks automated fetching.
The fix is a discipline rather than a task. Keep one clean image per product as the main image, product only, on a plain background, no text, high enough resolution, and put every lifestyle or promotional variant into the additional image fields instead. If your theme or app generates the main image with a badge overlaid, send the underlying file to the feed rather than the rendered one.
This is worth doing well beyond compliance. The main image is most of your click-through rate in a results grid, and a cluttered image loses to a clear one.
Shipping and tax settings that quietly suppress items
A configuration gap here does not always look like an error. Sometimes items simply stop appearing in a region, which is much harder to notice than a red warning.
Shipping needs to be set up so that a cost can be calculated for every country you target, either as a rate table in the account or through settings that match your store's real rates. If the account cannot work out a shipping cost, it cannot show the item.
The cost you declare should match what a customer actually pays. A cheerfully low shipping figure that the checkout contradicts is the same consistency failure as a price mismatch, and it produces bad clicks even when it does not produce a disapproval.
Tax settings matter in markets where prices are shown without tax. Getting this wrong makes your prices look wrong rather than making them invalid, which is worse, because you will spend the budget and lose the sale at checkout.
And if you sell into more than one country, check each target separately. Accounts are frequently healthy in the home market and half broken in the second one.
The routine we run instead of firefighting
Fifteen minutes a week prevents almost all of this, and the routine matters more than the tooling.
Start with the item count. How many products are active and eligible, and is that number what you expect. A quiet drop is the earliest signal of every problem described above, and it is the check stores never build.
Then read warnings before errors. Warnings are the queue of tomorrow's disapprovals, and clearing them is cheap because nothing has stopped yet.
Then check the item-level view for your top sellers by name, because a store-wide health figure can look acceptable while the twenty products that pay the bills are the ones suspended.
Then confirm the feed schedule ran and that the last fetch has no drop in item count against the previous one.
When something is disapproved, fix the underlying data rather than requesting a review and hoping. A review that passes on a page you did not change will fail again next quarter, and by then nobody will remember what the original cause was.
