How to Audit Your Own Listings for AI Agent Readiness

Introduction

"We have a product feed" and "our listings are agent-readable" are two different claims. The first describes a file you send somewhere. The second describes what an automated buyer encounters when it lands on your live product page, or reads the structured data behind it, and tries to answer a question: is this the product the shopper asked for, what does it cost right now, can it be bought where they are, and does that link still work.

Most brands can answer the first claim with a yes. Very few have measured the second. This post is about the measurement — how to score your existing live listings, where the failures actually cluster, and which fixes are cheap.

Two Actowiz pages already cover what an agent-facing feed should contain: data for AI agents and agentic commerce real-time product feeds sets out the field-level requirements, and AI shopping agent feeds covers delivery and refresh. This post assumes you have read those and now want to know what you currently have.

Why the feed and the listing diverge

A merchant feed is generated from your PIM or ERP on a schedule. A product detail page is rendered by a template that pulls from a CMS, a pricing service, an inventory service and a handful of merchandising overrides. Structured markup on that page is generated by a third system — often a plugin, sometimes a tag manager injection.

Three systems, three release cycles, three sets of owners. Divergence is the default state, not the exception.

As of late 2026, the pattern across agent implementations is that an agent will use whichever source it can reach and trust, and it will not reconcile disagreements for you. If the page says 249, the markup says 279, and the feed says 249 with a promotion flag, the agent picks one. You do not control which. So the audit question is not "is my data good" but "do my three surfaces agree, and does each one independently stand up".

Designing the sample, not auditing everything

Auditing a full catalogue is a project. Auditing a well-chosen sample is a week. You want the sample to reflect the structural variety in your catalogue, because failures are almost always template-shaped rather than SKU-shaped.

Stratify on the dimensions that map to different code paths:

Cap the total at something you can genuinely inspect — 300 to 600 listings is usually enough to find every template defect you have. Record the sampling frame, because next quarter's re-audit must be comparable. Once you know the defect classes, you can extrapolate the affected SKU count from your catalogue counts, which is more honest than claiming a catalogue-wide score you did not measure.

The scoring rubric

Score each listing on seven dimensions. Each dimension is pass, partial or fail, with an explicit pass condition. Vague conditions produce vague audits, so write the condition as something a script can check.

Collect the result as a row per listing per dimension, with the observed values, not just the verdict. [DATA: pass rate by dimension across the audited sample] and [DATA: share of audited listings passing all seven dimensions] are the two headline numbers, and the second is always far lower than readers expect.

The three-way consistency check

This is where most real failures live, and it is the part almost no internal audit does. For each sampled listing, capture three things at the same moment:

• The rendered page as an agent would see it, including JavaScript-rendered content.
• The structured markup extracted from that same render.
• The corresponding row from your merchant feed, at the version live at that moment.

Then compare field by field. Same-moment capture matters. If you pull the page today and the feed export from last night, every price change looks like a defect. Timestamp everything and compare within a tight window.

Record disagreements by field and direction:

Direction matters for diagnosis. Markup lagging the page points at a caching layer. The feed lagging both points at export frequency. The page lagging the feed usually means a CDN holding a stale render.

Weighting, so one bad dimension cannot hide

A simple average across seven dimensions is misleading. A listing that fails external identifier resolvability is not 86% agent-ready; it is largely invisible to any agent that resolves products by identifier. Two mechanics fix this.

First, gate. Define identity, identifier resolvability and purchase URL stability as gating dimensions. A fail on any gate caps the listing score, regardless of the other four. A cap in the 40s communicates the right thing without discarding the detail.

Second, weight the rest by the cost of getting it wrong. Price accuracy failures cause abandoned or disputed transactions. Attribute unit failures cause the product to be excluded from filtered comparisons, which is quieter but affects more queries.

Publish the weights with the score. An unexplained composite number invites argument; a weighted score with visible weights invites a conversation about the weights, which is the useful conversation.

Reading the output: cheap fixes versus catalogue work

Sort findings by fix cost, not by score. Two buckets behave very differently.

Template fixes. One change, catalogue-wide effect. Currency code missing from markup, price and unit concatenated into one string, session parameters in the canonical link, markup rendered from a cache with a longer TTL than the price component. These usually resolve in a sprint and move [DATA: composite score] materially.

Catalogue work. Per-SKU data entry or supplier chase. Missing or wrong GTINs, absent dimension attributes, variant-level identifiers that were never captured. This is quarters of work, so it needs prioritisation by revenue or by category competitiveness, not a blanket mandate.

The practical output is a two-column list: template defects with an owning engineering team, and catalogue gaps with an owning merchandising team and a SKU count. A single ranked list of 400 listings helps nobody.

Cadence and benchmarking

Re-audit the same stratified sample quarterly, and run the three-way consistency check monthly on a smaller subset, because that check catches regressions from unrelated releases. Re-audit within two weeks of any platform migration, PIM change or markup plugin update.

Your own score means little in isolation. If your identifier resolvability is [DATA: your pass rate] and the category median is [DATA: category median pass rate], you learn whether you are behind or whether the whole category is. Benchmarking means running the same rubric against a sample of competitor listings in the same categories — which is external collection work, and is exactly what digital shelf analytics coverage is for. Report your score as a position in the category distribution, not as an absolute.

Actowiz Solutions runs this audit as a measured exercise: stratified sampling across your live catalogue, same-moment capture of page, markup and feed, scored against the rubric above, with the same rubric applied to competitor listings for context.

We deliver the per-listing evidence rows alongside the scores, so every finding traces back to a captured observation rather than a judgement.

Request a free sample dataset →

FAQ

Does having a Google Merchant Center feed mean my listings are agent-ready?

No. A merchant feed is one surface. Agents also read the rendered product page and its structured markup, and those are generated by different systems on different release cycles. Agent readiness depends on all three surfaces being independently sound and in agreement with each other.

How many listings do I need to audit to get a useful result?

Enough to cover every structural variant in your catalogue. Stratify by template type, category, price state, availability state and market, then sample within each stratum. Most catalogues reveal all their template-level defects within 300 to 600 carefully chosen listings.

Which agent-readiness failures are quickest to fix?

Template-level ones: a missing currency code in markup, a price and unit concatenated into a single string, session parameters in the canonical URL, or markup served from a longer-lived cache than the price component. Each is one change with catalogue-wide effect. Missing or incorrect external identifiers are the slow category, because they require per-SKU work.

Conclusion

You can also reach us for all your mobile app scraping, data collection, web scraping, and instant data scraper service requirements!