Feed audit tools are easy to build badly. Reading a Shopify catalog, checking each field against the Google Shopping specification and printing a list of warnings takes an afternoon — and produces a report that looks thorough while missing most of what is actually costing the store money.
The following seven criteria are what separates an audit that changes decisions from one that just generates a spreadsheet. They work equally well to evaluate a paid tool, an app from the Shopify store, or an internal script.
The 7 criteria
Audit against Google’s verdict, not just against the spec
Field validation tells you what might be wrong. The productstatuses endpoint of the Content API tells you what Google has actually disapproved, with the exact reason and the IDs of the affected items. A scan run purely on the store side flags products Google has no problem with, and misses precisely the ones it does: a price that does not match the product page, a landing page Google cannot reach, image crawl errors. None of that ever shows up in Shopify data.
Prioritize by money, not by volume
"412 products missing a GTIN" is not actionable: it is a scary number that says nothing about where to start. "These 9 products are 60% of the traffic you are losing" is. Even with no Google Ads data connected, ranking issues by price multiplied by availability already beats a flat list sorted by product code.
Go down to variant level
Most Shopify feed problems live in the variant, not in the product: the item_group_id that groups variants together, the ?variant= link that points to the specific one, and the image and price each variant carries. An audit that reports at product level hides exactly where the problem is and forces a manual hunt inside the listing.
Separate account issues from product issues
A merchant whose account is suspended for misrepresentation does not need a GTIN report. They need to be told, in the first line, that the account is what is blocking everything and that no amount of product data fixing will bring the ads back. Mixing both layers into the same issue list is the fastest way for a tool to lose the user’s trust.
Respect the GTIN exceptions
Declaring identifier_exists: no is legitimate for handmade, vintage and made-to-order products: they simply have no global trade identifier. Flagging them as errors produces hundreds of false positives and teaches the merchant something worse than not auditing at all: to ignore the whole report because "it always flags the same thing and it is never true".
A report that needs no explanation
The useful format is a single screen with three numbers: how many products are blocked, how much revenue is at risk, and the top three causes. Everything else (the breakdown by reason, the full listing, the exceptions) sits one click away. If the first screen needs an explanation, it does not get read, and the audit never turns into an action.
Monitor change, not just today’s status
The value of an audit is not in the first scan, which is usually read once and filed away. It is in the alert on the day 200 products drop at once after a theme update, a new app or a change in how listings are built. That is the moment the merchant can still undo the cause before losing weeks of visibility.
Seven questions to ask before paying for a tool
The same criteria, turned into questions a merchant can put to any vendor — or to the developer building the tool in-house. A tool that answers no to the first one is validating a spec, not auditing a catalog.
- Does it read the real Merchant Center statuses (productstatuses), or only validate my catalog against the spec?
- Does it rank results by what each problem costs me, or by the number of products affected?
- Does the report reach variant level: item_group_id, the ?variant= link, per-variant image and price?
- Does it separate account issues from product issues and tell me which one is blocking everything?
- Does it treat identifier_exists: no as a legitimate case rather than an error to fix?
- Can I understand the first screen of the report without anyone explaining it to me?
- Does it alert me when something changes, or only when I launch a scan myself?
Where Girofeeds stands
Girofeeds is built around these criteria: it works from the CMS and against the real Merchant Center statuses, so what it reports is what Google has actually disapproved, and the fixes land in the source data instead of in a copy of the feed. That is the same reason a fix does not come back with the next catalog sync — the logic is explained in the comparison with traditional feed managers and in catalog optimization.
Frequently asked questions
Is a spec-only feed validation worth anything?
It works as a first filter to catch empty or malformed fields before anything is sent to Google. What it cannot do is confirm what is actually blocked: only Merchant Center knows that, and several disapproval reasons (price mismatch, unreachable landing page, uncrawlable image) are invisible from store-side data.
What exactly is productstatuses?
It is the Content API resource that returns, item by item, the status of a product inside Merchant Center and the issues attached to it, including the reason and the destination affected. It is the source that turns "this might fail" into "this is disapproved for this specific reason".
Why does variant level matter so much on Shopify?
Because on Shopify price, stock, image and the ?variant= link are variant attributes, not product attributes. A product can be approved in five variants and disapproved in two, and a product-level report will show one ambiguous line instead of the two variants that actually need fixing.
Can a feed audit detect an account suspension?
It can read the account status and warn that a suspension is active, which is exactly what needs to be known before touching anything else. What it cannot do is solve it from the feed: policy suspensions such as misrepresentation are fixed in the store and in the account information, not by changing product attributes.
How often should a feed be audited?
A one-off scan is only useful as a starting point. What prevents losses is continuous checking, because big drops usually come from a change in the store (theme, app, listing structure) rather than from a gradual decay of the catalog.
Related: product images and content · all Shopify articles .