What a file cannot tell us

Your live pages

Whether the price on your landing page still matches the price in the feed, whether the page redirects, loads on mobile, or opens on the right variant, needs a crawl of your shop rather than a read of your file. The same is true of schema.org markup that disagrees with the feed. These are real and worth building, and none of them are possible from an uploaded file. A random sample of 25 pages would be a demonstration, not coverage, so we do not present one as though it were.

What Google actually decided

We tell you what your data says. Merchant Center tells you what Google did with it, and those are different questions. Per-country product status, issue codes, account-level problems, conflicts between data sources, and any rule that silently overwrites a correction, all of that needs account access. We do not ask for it, and we do not claim to have it. This is the most valuable thing on the list, because it would close the loop and show us our own misses, and it belongs to a version of the product that has accounts and an OAuth connection. Today's product is upload-only, and saying so plainly is better than leaving the question hanging.

History

A product count that dropped overnight, a column that quietly disappeared, an id that changed between uploads, a mass switch to out of stock: these are only visible to something watching every upload over time. We see one file, once. This kind of monitoring is genuinely valuable and genuinely impossible for a tool that does not keep watching, and it arrives with scheduled fetching or not at all.

Judgement

Whether a well-formed barcode actually belongs to this particular product, whether the accessory in the photograph is included in the price, whether a shop's returns policy is credible: these are review work and they stay review work. Some of them can be checked against an outside service, GS1 for who owns a barcode, the public EPREL database for an energy registration, and those are worth doing when there is a reason to. Inventing a value is never in question. Verifying a supplied one sometimes is, and that is a later feature, not a claim we make today.

What we could add, and have not

A review of the coverage proposed a good deal more, and most of it is right and sits outside a single uploaded file. Recording the decision matters more than the list, because "not yet" and "never" are different answers, and the difference is exactly what we are allowed to charge for.

• Needs your website: landing-page reachability beyond a status code, redirect loops, login walls, add-to-basket failures, feed-against-shop comparison. Deferred to a separate website audit rather than folded into a feed fix.
• Needs Merchant Center access: the processed verdict and account health. Deferred to a version of the product with accounts.
• Needs history: stability and drift between uploads. Arrives with scheduled fetching.
• Another channel entirely: everything here is Google-specific. A feed Google accepts is not automatically valid for Microsoft, whose limits differ. If this is ever sold as a general product-feed checker rather than a Google one, that has to be asked at upload rather than assumed.

What we deliberately do not report

Google can automatically update price, sale price, availability and condition on some products, and can apply some image improvements. Those automations are a temporary compensation, not a substitute for correct source data, and they do not cover every product. So we still report the defect in the file and note where Google may be papering over it in the meantime, because suppressing the finding would hide a real problem behind someone else's patch.

The tax and tax_category attributes are deprecated in the Merchant API and absent from the current product data specification. They survive in the legacy Content API during the transition. We do not validate them.

The things we do check, we check thoroughly. That is the other page, and the free scan shows you which of them your file trips.