Check a Google Shopping feed against the Google Merchant Center specification. Every row, entirely in your own browser.
A shopping feed audit that goes past compliance: it also checks the conversational and AI-readiness attributes, including UCP (Universal Commerce Protocol), that decide whether your products surface in AI shopping.
link and price are well-formed, but cannot verify the feed price matches the price at checkout. Mismatches are a leading cause of automated item disapproval, and only a live crawl catches them.A product feed audit is a systematic check of the product data file you send to Google Merchant Center: titles, prices, images, identifiers and the attributes that decide eligibility. It checks them against the specification Google actually enforces. A good audit separates three different things: the rows that will be disapproved, the rows that will serve but underperform, and the attributes that are missing entirely. Treating all three as one list of errors is the most common reason feed audits are ignored.
This is what the tool above checks on every row of your file, grouped the way it reports them.
id, title, description, link, image_link, price, availability, branditem_group_idgoogle_product_category, which is optional, but it makes category-specific requirements deterministic rather than inferredgtin and mpn where they genuinely applyproduct_highlight and product_detail, the structured attributes AI surfaces read to understand what a product actually isquestion_and_answer, related_product and document_link, weighted by whether they genuinely apply to your categoriesitem_group_title and variant_option, which let conversational agents describe a product familyNo audit that reads only a file can verify that the feed price matches the price at checkout, measure image resolution or detect promotional overlays, see your Merchant Center account state, or identify zombie products. Those get impressions but no clicks, which is a performance question needing Merchant Center or Ads data. The tool says so explicitly rather than scoring what it cannot see.
Feed readiness is not one thing, and the layers are checked by different tools. Confusing them is how a catalogue ends up optimised on paper and invisible in practice.
The most common cause of disapprovals spans two layers, which is why no single tool fully catches it. The feed and the live page must agree on title, price, sale price, availability, brand, variant information and imagery. A feed saying ‘in stock’ at £49 while the page shows ‘out of stock’ at £59 invites disapproval, erodes trust and confuses AI retrieval. An audit of the file can confirm your values are well formed; it cannot confirm they match the live page, because it never fetches the page. Closing that gap is an operational discipline, keeping inventory and pricing synchronised across feed, site and Merchant Center, rather than a one-off fix.
A rough benchmark for how complete a competitive catalogue looks. Treat these as direction rather than gospel: the right targets vary by category.
| Attribute | Suggested coverage |
|---|---|
| Brand | 100% |
| GTIN (where one exists) | 95%+ |
| Product type | 100% |
| Colour and size (apparel) | 100% |
| Material | 95%+ |
| Availability | 100% |
| Product highlights | 95%+ |
| Product details | 90%+ |
| Question and answer | Top sellers first |
| Related products | Top sellers first |
The ‘where one exists’ qualifier on GTIN matters. Chasing 95% coverage is the wrong goal for own-label or custom products that genuinely have no GTIN. For those, identifier_exists: false is the correct answer, not a fabricated number.
If you are starting from scratch, work in this order.
Steps two and three are what this tool covers. Steps one, four and five need Merchant Center, a structured-data tester and a crawler respectively.
Most free feed audits ask you to hand something over first: a form, read access to your Merchant Center account, or the feed file itself uploaded to a vendor’s server. For anyone working on a real retail catalogue, that is usually where the evaluation stops. Granting a third party access to commercial product data is a procurement conversation, not a five-minute decision.
Your feeds also routinely carry data that should not leave your estate. Real catalogues have been found shipping cost and margin columns to Google on every product row, because nobody audited what was in the file.
No. The audit runs entirely in your browser using a Web Worker. Your feed file is read from disk by the page you already have open. It is never sent to HB Freelance, to Google, or to any third party. Nothing is stored and there is no server to store it on.
Neither. There is no account, no form and no OAuth grant. You do not connect Merchant Center, and the tool never contacts Google. It reads the file you give it and nothing else.
CSV, TSV, TXT and XML product feeds, including Google Shopping XML with the g: namespace and Atom-style feeds. Delimiter and character encoding are detected automatically, including UTF-8 and UTF-16 byte order marks.
There is no size limit. The file is streamed in chunks rather than loaded into memory, so feed size does not determine memory use. A 770 MB feed of more than 270,000 products has been audited in the browser, with a whole-file field scan completing in around 18 seconds.
No, and no file-based audit can. A zombie product is one that gets impressions but no clicks or conversions, which is a performance judgement that needs Merchant Center or Google Ads data. A feed audit finds structural and data-quality problems in the file itself. The two are complementary, not substitutes.
No. Merchant Center reports what Google has already decided about products it has processed, including account-level policy state. This audit checks the file before it gets there, and covers attributes Merchant Center does not report on at all: the conversational and AI-readiness fields that affect whether products surface in AI shopping.
Specifications last reviewed: . The rule packs and their versions are listed on every audit you run.
The AI Product Feed Readiness Checker is a free, browser-based product feed audit. It covers Google Shopping and UCP feed validation against the Google Merchant Center specification, including the conversational and AI-readiness attributes that increasingly determine whether products surface in AI-driven shopping experiences. It runs entirely in your browser: no feed data is ever uploaded.
Shopping is shifting from keyword search to conversational and agentic discovery.
For years a product feed only had to be compliant, with correct identifiers, prices and availability, to serve in Google Shopping. That bar still matters, but it is no longer sufficient. As AI-driven surfaces (AI Mode in Search, conversational assistants, agentic shopping agents) begin to mediate product discovery, they draw on a richer set of signals: structured product details, question-and-answer content, variant relationships, popularity, and document links. A feed can be 100% compliant and still be almost invisible to these surfaces.
This tool measures both: traditional compliance and AI-readiness, side by side, so retailers and the teams who serve them can see exactly where a catalogue stands and what to do next.
The checklist above is what gets checked. This is how. All of it client-side, on feeds of any size, tested past 380 MB and 140,000+ products.
Accepts CSV, TSV, TXT and Google Shopping XML (RSS 2.0 / Atom). Auto-detects the delimiter (comma, tab, semicolon, pipe) with manual override, handles UTF-8 and UTF-8/UTF-16 BOM encodings, mixed line endings, quoted fields, escaped quotes, embedded line breaks, CDATA, XML entities and repeated tags.
Before validating, it profiles the file: detected format, size, row count, column count, encoding and line endings, plus a header-mapping table showing how each feed column maps to a Google specification attribute (including alias and g:-prefix resolution) and a first-rows preview.
Feed-level checks (missing columns, duplicate headers, structure), row-level checks (presence, enums, formats, price, URLs, GTIN checksums, cross-field conditions) and variant-level checks across product groups. Every row is evaluated against all loaded rule packs.
Validates image URL format, supported file types and extension matching, and flags unstable timestamped URLs. Image-content requirements that can't be read from a feed file, such as resolution (including the 500×500px minimum enforced from 31 January 2027), promotional overlays, and AI-generation metadata, are surfaced as clearly-labelled advisories rather than false pass/fail results.
Groups products by item_group_id and checks each group for brand and category consistency, duplicate colour+size combinations, attribute completeness, shared images across colours, and conversational coverage (item_group_title, variant_option).
A target-market selector (UK, US, Brazil, France, Germany, Japan, or other) adjusts the conditional apparel attributes colour, size, gender and age group, which Google treats as strictly required only in certain markets. Non-strict markets see them as recommendations, not compliance errors, so the score reflects the retailer's actual market.
Eight readiness scores, each fully traceable: click any score to open its ledger and see exactly which rules moved it, by how many points, and why. No black-box numbers.
A "what to fix first" list ranked by a blend of score impact and ease, so high-coverage, low-effort fixes (a single-value find-and-replace affecting every row) rise to the top, flagged as quick wins.
Every issue generates a structured Markdown ticket (problem, fix, acceptance criteria, affected products) ready to paste into Jira, Linear, GitHub or Asana, plus per-issue affected-row CSVs (SKU, row, id, title, offending value), an all-tickets bundle, an issues CSV and a printable client report.
All parsing and validation runs in a Web Worker with streaming chunked reads, live progress, ETA, pause, resume and cancel. Memory stays flat regardless of file size, and the browser tab never freezes.
For very large feeds, scan the first 25%, 50%, 75% or the full file. A partial scan gives a fast representative read; results are clearly badged as a partial sample, and every export and ticket is stamped "partial sample, not a complete list" so no one mistakes it for a full audit.
Each score is 0–100 and computed from a transparent ledger of rule contributions.
| Score | What it measures |
|---|---|
| Overall Readiness | A weighted blend of the seven dimensions below. The single headline number. |
| Compliance | Required-attribute rules, feed structure and hard failures against the Google specification. |
| Feed Health | Parsing integrity: corrupt-row recovery, encoding, duplicate headers, title uniqueness. |
| AI Readiness | Content richness, structured-attribute density, conversational and enrichment signals combined. |
| Conversational Commerce | The six conversational attributes (Q&A, document links, related products, variant titles and options, popularity) by presence, coverage and quality. |
| Product Enrichment | Recommended attributes, description richness, image depth and optional-attribute coverage. |
| Variant Readiness | Variant grouping coverage, group completeness and cross-variant consistency. |
| AI Retrieval | Identifier completeness (GTIN/MPN/brand), category depth, attribute density and title/description uniqueness. |
Score floors and ceilings keep the numbers honest: a material share of products failing a core field caps Compliance; AI scores are capped until genuine conversational content is present, so a feed can't appear AI-ready on structure alone.
The report is built to be actioned, not just read.
Each finding can be exported as a self-contained Markdown ticket containing the severity, the exact number of affected rows or variant groups, a reference to the specific Google specification rule, a plain-English problem statement, the recommended fix, checkable acceptance criteria, and a table of affected products. For large issues, the full affected-product list exports as a CSV carrying, for every affected row, its Product ID (g:id), Item Group ID (g:item_group_id), title, product URL and brand alongside the offending value, so a developer or merchandising team can locate each product in the source feed. An "export all tickets" option bundles everything into a single Markdown file with a summary table.
Every ticket and report carries a footer reminder of what file-based validation cannot confirm (see below), so expectations stay accurate when work is handed over.
link and price are well-formed, but cannot verify the feed price matches the price at checkout. That is a leading cause of automated disapproval, and only a live crawl catches it.A product feed is the foundation the new commerce protocols build on, and that foundation is exactly what this tool audits.
Two standards govern how products reach AI-driven shopping. UCP (Universal Commerce Protocol) is Google’s, powering transactions in Search AI Mode and Gemini. ACP (Agentic Commerce Protocol) is OpenAI and Stripe’s, powering Instant Checkout in ChatGPT. Both have a feed layer describing your products and a checkout layer completing the transaction.
The practical point: UCP introduces no new feed format. It rides on the Google Merchant Center product specification, so auditing here is the UCP feed work. There is no separate task. Select UCP mode and the attributes UCP makes transaction-critical, shipping and return policy, move from optional to required, because a buying agent needs them to complete a purchase.
It does not audit the checkout layer of either protocol: REST session endpoints, payment handlers, profile publication, identity linking, order webhooks. Those live in your backend and Merchant Center account, not in a feed file. ACP’s feed is a distinct schema with its own required fields; dedicated ACP validation is on the roadmap.
No feed data is ever uploaded
The tool is a static page. Your feed file is read and validated inside your own browser tab using Web Workers and local processing. It is never sent to any server, and the page makes no network calls about your products. After the rule packs load on first visit, the tool works with the network disconnected. This is a deliberate design choice: it is both a privacy guarantee for commercially sensitive catalogues and the reason the tool defines its scope the way it does.
Validation logic lives in versioned, human-readable rule packs, not buried in code.
Rules are extracted from official Google Merchant Center documentation and stored as versioned JSON, and the engine only ever reads those packs, so the tool can be extended to a new standard by adding a pack, not by changing the engine. The tables below are generated from the manifest the tool actually loaded, so they cannot drift from the rules that ran on your feed.
Loading rule packs…
Sources: Google Merchant Center Product Data Specification and Conversational Attributes documentation. Each pack records its version, effective date and last-reviewed date. When Google updates its documentation a new versioned pack is produced, and the change is reviewed before going live.