How Do You Check If Your Product Feed Will Be Rejected?

Check your feed before you push it by separating two failure classes: items that will be rejected outright, and items that will be accepted but downranked. They have different causes, different costs, and only one of them is urgent.

Rejection is almost always a missing required field — no image, or no product identifier of any kind. Downranking comes from missing quality fields: no barcode, no product type, no description. Count both against your total before submitting, because Merchant Center and Commerce Manager only tell you afterwards.

What’s the difference between rejected and downranked?

Rejected items don’t appear at all. Downranked items appear and lose.

Rejected means the platform refuses the item. It won’t show in Shopping results, it can’t be used in a dynamic ad, and it doesn’t exist as far as your campaigns are concerned. The item is in your feed and invisible in the market. Two causes account for nearly all of it:

• No image. Both Google and Meta reject items with no image. There is no partial credit here — a product without a picture cannot be merchandised.
• No product identifier at all. If an item has no GTIN, no MPN and no brand, there’s nothing to identify it as a real product. Feeds flag this with identifier_exists=no, and the item is heavily penalised or excluded.

Downranked means the item is accepted and then loses to better-described competitors. Nothing errors. You get impressions, just fewer and worse ones, and diagnosing it is hard because the item looks fine in every dashboard. Common causes:

• No barcode (GTIN). Barcodes are how Google matches your listing to a known product, which affects both paid placement and free listings.
• No product type. Without a category, the platform has to guess what the item is, which weakens targeting.
• No description. Thin listings convert worse and can be flagged as low quality.
• Out of stock. Technically fine, genuinely present in the feed, and hidden from shoppers until restocked.

The distinction matters because it dictates order of work. Fixing 40 items with no image recovers 40 items that were earning nothing. Adding barcodes to 400 items improves performance that already exists. Both are worth doing; only the first is an emergency.

Why check before you push instead of after?

Because the platform’s own diagnostics are a post-mortem, and the feedback loop is slow enough to cost a launch.

The normal sequence is: push the feed, wait for a crawl, read the errors in Merchant Center, fix them in your store, wait for the next sync, re-check. Each cycle takes hours. If you’re launching a season or a new catalog, that’s the difference between campaigns starting on the day you planned and starting later with a fraction of the range live.

There’s a second reason that matters more over time. Merchant Center tells you about the items it rejected. It is much less insistent about the items it accepted and buried — those don’t appear as errors, because nothing went wrong. A pre-push check that counts both classes gives you the thing the platform’s own report is structurally bad at: the scale of your quality problem, before it becomes a performance problem you can’t explain.

What should you check, in order?

Five checks, ordered by consequence rather than by effort.

1. Items with no image. Count them. These are rejected, every one, on both platforms. This is the only check that is genuinely urgent.

2. Items with no identifier at all. Not “no GTIN” — no GTIN and no MPN and no brand. An item with a brand but no barcode is fine; an item with none of the three has nothing to identify it.

3. Items with no barcode, where one exists in the real world. A manufactured product with a GTIN you haven’t supplied is losing match quality for no reason. Custom and handmade goods legitimately have none, which is what MPN and brand are for.

4. Items with no product type. Cheap to fix in bulk, and it improves categorisation across the whole catalog rather than item by item.

5. Out-of-stock items. Not an error, but worth knowing as a share of the feed. A catalog that’s 30% out of stock is advertising a much smaller range than its product count suggests.

Do all five at the variant level, not the product level. Feeds are built per variant, and a product whose parent record looks complete can still have six variants missing images. Counting products flatters the number.

Why do Google and Meta disagree about the same feed?

Because their minimum requirements differ, so the same file can be in good shape for one and weak for the other.

The practical divergence is the identifier. Meta’s floor is essentially the image — an item with a picture and a price can be merchandised. Google wants an identifier as well, because its whole model depends on matching your listing to a known product so it can compare offers.

The consequence: an item with an image but no GTIN, MPN or brand can be perfectly usable on Meta and close to worthless on Google. If you’re running both from one feed — which is the normal setup, since the same file format serves both — a single “feed health” number will mislead you. You need readiness measured per destination.

How does PartialLeads check feed health?

By running the checks continuously against the synced catalog, at variant grain, and splitting readiness by destination — so you see the problem before the platform does.

Six checks, each with a severity. Missing image and missing identifier are marked as rejection-class. Out of stock, missing barcode, missing product type and missing description are marked as quality-class. Each carries a count and a plain-language explanation of the consequence, so the list is a work queue rather than a diagnostic dump.

Two readiness percentages, not one. Google-ready is measured as having an image and at least one of GTIN, MPN or brand. Meta-ready is measured as having an image. Reporting them separately is what stops a feed that’s fine for Meta from looking fine for Google.

A single health score out of 100, weighted so that rejection-class issues dominate and quality issues discount it — useful as a trend line rather than as a target.

Variant grain throughout. Counts are per variant, matching the grain the feeds are actually built at.

Catalog composition alongside the health data. Variant and product counts, in-stock versus out-of-stock, how much of the catalog is on sale and by how much, price minimum, maximum and average, a price-band distribution, your most common product types, and brand coverage. This is the context that makes a health number interpretable — 200 items missing barcodes reads differently on a 300-item catalog than on a 20,000-item one.

Ninety-day sales alongside it. Orders, revenue, how many products actually sold, how many didn’t, and the top sellers. Which turns “fix these 40 items” into “fix these 40 items, six of which sold last quarter.”

One feed URL for both platforms. The feed renders as RSS with Google’s namespace, which both Google Merchant Center and Meta Commerce Manager ingest, so there’s one URL to paste into both rather than two pipelines to keep in sync. It’s protected by an unguessable token in the URL, rotatable if it leaks, and the identifier flag is emitted automatically when an item has no GTIN, MPN or brand.

Honest boundaries — three, and they matter.

The checks test presence, not validity. They find fields that are empty. They do not validate that a price is correctly formatted, that a title is within length limits, that a landing page resolves, that an image meets resolution requirements, or that a product complies with policy. An item can pass every check here and still be rejected for a reason none of them looks at. This is a pre-flight for the most common and most mechanical failures, not a replacement for Merchant Center’s own diagnostics.

The feed-health panel currently covers Shopify catalogs. WooCommerce stores get the feed generation; the health scoring and composition analysis are Shopify-only today.

And the data is synced, not live — the catalog refreshes on a several-hour cadence with a short cache on top, so a fix you make in your store admin shows up on the next sync rather than instantly.

Sources

1. Google Merchant Center Help — Product data specification: https://support.google.com/merchants/answer/7052112
2. Shopify Dev Docs — Web Pixels API: https://shopify.dev/docs/api/web-pixels-api
3. Shopify Dev Docs — Webhooks: https://shopify.dev/docs/api/webhooks