Merchant Center · focused work
Merchant Center diagnostics
The issue list in Merchant Center is a work queue, not a report card. Some entries stop a product appearing at all, some reduce where it can appear, and some are suggestions that add eligibility. Working through them in the order the interface lists them wastes weeks. Working through them in the order of revenue at risk does not.
This is the right work if
- Thousands of item issues exist and nobody can say which of them cost money
- Impressions have fallen and the issue list looks the same as it did last week
- The same issue is corrected in the interface every month and comes back each time
- Products are approved but reported as limited and nobody has read the reason
- Images fail to update and nothing on the site looks wrong when a person checks
What it is
How issues are triaged and traced
There are three tiers. A disapproval removes the product from the surfaces entirely. A limitation or demotion leaves it eligible but reduces where and how often it can show, usually because a recommended attribute is missing or a value is unclear. A recommendation adds eligibility if acted on. Treating all three with the same urgency is the commonest reason a large catalog never gets clean, because thousands of low-consequence entries hide the handful that are costing real money.
Tracing is the other half. Item issues cluster: a catalog with thousands of affected products usually has a handful of causes behind them, such as images the crawler cannot fetch, a price that disagrees with the page because of tax or currency handling, availability that lags the store, an identifier missing from a whole brand, an invalid value in a structured attribute, or a landing page that behaves differently for a bot than for a person. That last group is why diagnosis has to reproduce what the crawler sees rather than what an employee sees in a logged-in browser. Robots rules, geographic redirects, cookie walls, rate limiting and image hotlink protection cause issues that are completely invisible from inside the office.
How it is done
The work, in order
What changes
- The queue is worked in the order of what the store stands to lose
- Fixes go into the source and survive the next scheduled run
- Crawler access problems are found by reproducing them rather than by guessing
- A new class of issue is noticed within days instead of at the end of a month
Order the queue by revenue at risk
Export the affected product identifiers and join them to the store's own sales data, then sort by the revenue attached to the products involved. A single disapproved best seller outranks a thousand recommendations on items that have never sold.
Group by cause, not by product
Cluster the issues by the underlying reason rather than working item by item. Most large lists collapse into a few causes, and fixing one of those clears hundreds of rows at once, which changes the size of the job entirely.
Reproduce what the crawler sees
Fetch the landing page and the image URLs the way a bot would, from the country being targeted, and check robots rules, geographic redirects, consent walls, rate limiting and hotlink protection. Many image and page issues exist only for automated requests.
Fix at the source
Correct the store data, the feed rule or the site behaviour that produced the value. Editing a value in the interface fixes the display until the next scheduled run replaces it, which is exactly why the same issue appears to return every month.
Verify across a full cycle
Wait for the data to be fetched again and the page or image to be re-crawled, then confirm the item's status has actually changed. Marking a fix complete on the day it shipped is how a store discovers three weeks later that nothing moved.
Monitor rather than inspect
Pull the issue list on a schedule, track counts by cause over time, and raise an alert when a new class of issue appears or a count jumps. The point is to notice a problem within days rather than when a performance report finally shows the loss.
Platform notes
Shopify
Images are served from the platform's image service and are rarely blocked, so image issues here usually trace to an app rewriting the URL or to a product whose image was replaced without the feed being refreshed.
WooCommerce
Hotlink protection, security plugins and aggressive caching are the usual causes of images and landing pages that work in a browser and fail for an automated fetch, so the server configuration is the first place to look.
What separates a disapproval from a limited status?
A disapproval means the product is not shown until the problem is fixed. A limited status means it can still appear but in fewer places or less often, typically because a recommended attribute is missing or a value is ambiguous. The first is urgent; the second is a steady drag worth clearing in batches.
Why do image problems appear when the images load fine in a browser?
Because the fetch is different. An automated request may be blocked by hotlink protection, rate limited by a security layer, redirected by geography rules, or served an error while a cached copy is still shown to people. Testing with the same kind of request is the only reliable check.
How quickly should a fix show up?
After the data is fetched again and, where the page or image is involved, after a re-crawl, which is generally days rather than hours. Raising the update frequency helps for price and availability, and nothing speeds up a re-crawl except making sure the resource is reachable.
Is it ever right to fix an issue in the interface?
As a temporary measure while the real fix is being made, and only with a note recording it. Anything longer creates an override that disagrees with the store, and eventually somebody spends an afternoon working out why the interface and the catalog show different values.
Related work and answers
Find the leak.
A free Growth Analysis ranks what your store should fix first, by revenue at stake.