Most AI readiness assessments are workshops. Someone scores your organisation out of five on culture, skills and governance, then hands over a heat map. It tells you nothing about whether an assistant can answer a question about your products. This diagnostic does. It runs against your own catalogue. It takes five working days of one person’s time. It ends with a number you can put in front of a board.
What AI readiness means for a catalogue
Two different questions get called AI readiness. The first is organisational: do we have the skills, the budget, the governance. The second is the one nobody runs: can a machine that has never seen our website resolve, filter and quote our products correctly. This diagnostic is about the second question only.
There are two routes into an AI answer and your catalogue has to survive both. The first is the feed route. Google’s Shopping Graph holds over 50 billion product listings. Sundar Pichai said in January 2026 that more than 2 billion of them are refreshed every hour. OpenAI takes merchant feeds through the Agentic Commerce Protocol, and Shopify and Etsy sellers are already integrated. The second route is the page route. OpenAI describes shopping research results as organic and based on publicly available retail sites, reading product pages directly and citing sources.
Feed data and page data come out of the same catalogue. When the catalogue is thin, both routes are thin. That is why our applied AI work almost always starts with a data diagnostic rather than a tool selection. The tool is rarely the constraint.
Before day one: pull four things
You cannot run this against a slide deck. Get these first.
- A full item export from your PIM or ERP for one representative category. Every attribute, not the twelve marketing uses. Two to five thousand SKUs is enough.
- Every outbound product feed you currently send. The Google Merchant Center primary feed, the marketplace feeds, whatever your platform pushes.
- Twenty live product pages saved as raw HTML with JavaScript turned off. Use curl or the browser’s view-source, not the rendered DOM.
- Your robots.txt.
If step one takes more than an hour, write that down. It is a finding.
Day one: can a machine reach your products at all
Purpose. Establish whether your products are present on the surfaces that answer product questions, and whether the crawlers that feed them are allowed in.
Check 1: feed coverage. Count sellable SKUs in the category. Count how many appear in each outbound feed. Coverage is rarely 100 per cent and almost nobody knows the real figure. Discontinued lines, gated trade-only products and anything missing a required field drop out silently.
Check 2: crawler access. Open robots.txt and look for the retrieval agents, not just the training ones. OpenAI documents three: GPTBot for model training, ChatGPT-User for user-initiated fetches, and OAI-SearchBot for search. OpenAI is explicit on two points. ChatGPT-User is not used to decide whether content appears in search. OAI-SearchBot is the agent to manage in robots.txt. Blocking GPTBot is a legitimate content decision. Blocking OAI-SearchBot removes you from ChatGPT search answers.
Also check Search Console. Google rolled out a control in June 2026, starting with a subset of UK site owners. It lets you decide whether your content appears in and grounds generative AI Search features. Google says sites that opt out get no traffic or impressions from those features. Someone may have flipped it.
Common mistake. Treating the robots.txt line as an SEO detail. It is a commercial decision and it usually gets made by whoever last patched the file.
Day two: can a machine tell which product this is
Purpose. Test entity resolution. An assistant has to decide that your listing and the thing the shopper named are the same object.
Check 3: identifier coverage. Count blank GTINs across sellable items. Then look for reuse, where one identifier is attached to more than one product record over time. Check MPN coverage separately, because in industrial and automotive catalogues the MPN carries more weight than the GTIN.
Check 4: brand as a record, not a string. Look at the brand column in the raw export. If “Bosch”, “BOSCH” and “Robert Bosch Ltd” all appear, you do not have an entity, you have free text. Own-label items where the actual manufacturer is not recorded at all are the same failure in a different costume.
Check 5: title construction. Take twenty titles. Can a stranger say what the product is, who makes it and which variant it is, from the title alone. Internal shorthand, supplier codes and marketing names that omit the product type all fail this.
Common mistake. Assuming the PIM is the problem. Usually the identifiers live in the ERP or the finance system and get re-keyed by hand.
Day three: does the catalogue hold the facts people ask about
Purpose. Test whether the things shoppers filter on exist as fields rather than as sentences.
Check 6: attribute coverage against real questions. Take the top fifty search queries for the category from Search Console and your own site search. For each one, ask whether the concept is a populated attribute in the export. “Cordless”, “IP66”, “suitable for outdoor use” and “fits a 2018 Transit” are attributes in a good catalogue and adjectives in a bad one.
Google now accepts conversational attributes in Google Merchant Center specifically to help AI systems understand product nuances, including a question and answer attribute. Google Merchant Center also has a product detail attribute for technical specifications. It is structured as section name, attribute name and attribute value, repeatable up to 100 times per product. Those fields have to be populated from somewhere. That somewhere is your attribute schema.
Check 7: typed values and units. Sample a hundred numeric attributes. Count how many hold a number and a separate unit, versus a string like “1200mm approx”. Mixed units inside one column is the most common fail we see, and it makes every range filter and every comparison unreliable. Our piece on product attributes covers the schema side of this in more depth.
Common mistake. Scoring completeness as “percentage of fields filled”. A filled field holding “See datasheet” scores the same as a real value and tells you nothing.
Day four: variants, price and availability
Purpose. Test whether the structure and the commercial facts hold up under a machine reading them.
Check 8: the variant model. In the export, can you tell a parent from a child, and name the axes that vary. Then look at the page markup. Google’s variant structured data uses ProductGroup with a productGroupID, hasVariant, and a variesBy list. Google supports six variant axes: colour, size, suggested age, suggested gender, material and pattern (schema.org spells several of those the American way). If your size options are a dropdown with no underlying data structure, an assistant cannot answer “do you have it in a 42”.
Check 9: price and availability agreement. Pick twenty SKUs. Compare the price and stock status in the feed, in the page’s structured data, and in the visible page text. Google’s structured data policies require markup to be a true representation of the page content. They also prohibit marking up content that is not visible to readers. Three different numbers is a common outcome, usually caused by caching.
Common mistake. Fixing the markup and leaving the feed. The feed is refreshed on a schedule and the page is refreshed on a deploy. They drift.
Day five: rendering, then score your AI readiness
Purpose. Confirm the content actually exists in the HTML, then convert everything into a number.
Check 10: rendering. Open the twenty JavaScript-free HTML files. Are the specification table, the price and the stock status present as text. Vercel and MERJ published server-log analysis in December 2024. They found that major AI crawlers fetch JavaScript files but do not execute them. Client-side rendered content is not readable to them. Googlebot renders, and Google’s Gemini uses Googlebot’s infrastructure. The others largely do not. A spec tab that populates on click is invisible to them.
Scoring
Score each check 0, 1 or 2. Zero means the check fails outright. One means partial. Two means it holds across the sample. Twenty points available.
| Check | Scores 2 when |
|---|---|
| 1. Feed coverage | Every sellable SKU appears in every feed you intend to run |
| 2. Crawler access | Retrieval agents allowed, training agents a deliberate choice |
| 3. Identifiers | GTIN or MPN present, unique, never reused |
| 4. Brand entity | Brand and legal manufacturer are controlled references |
| 5. Titles | Type, brand and variant readable from the title alone |
| 6. Attribute coverage | Top fifty query concepts all exist as populated fields |
| 7. Typed values | Numbers and units held separately, one unit per column |
| 8. Variant model | Parent and child expressed in data and in markup |
| 9. Price and stock | Feed, markup and visible text agree on the same day |
| 10. Rendering | Specs, price and stock present in raw HTML |
Below 10, your problem is structural and no amount of content rewriting will help. Between 10 and 15, you have a remediation project with a known shape. Above 15, the gap is usually attribute depth in two or three categories, not the whole catalogue.
What a board actually wants from this
Not the score. Three things.
Where the gap is. Name the two checks scoring zero. Those are the programme.
What it costs to close. Attribute schema work and enrichment against a defined category set can be sized. Identifier remediation can be sized. “Getting AI ready” cannot.
What you are not claiming. This is the part that earns you credibility in the room. The score measures whether your data can be read and resolved. It does not promise placement in anyone’s answer.
We run these same checks at the start of product content enrichment engagements. They decide the sequence of the work. Fixing descriptions before fixing identifiers is money spent in the wrong order.
What this AI readiness diagnostic will not tell you
Three honest limits, and they matter more than the score.
It will not tell you how any specific assistant ranks. OpenAI says merchants are ranked on factors including availability, price, quality and whether they are the maker or primary seller. It also says that is expected to evolve. Google says there are no additional technical requirements and no special structured data needed to appear in AI Overviews or AI Mode. Neither publishes a weighting. Anyone selling you one is guessing.
It will not tell you about traffic. Search Console now has a generative AI performance report, and Merchant Center has AI performance insights in pilot. Measurement of AI-surface visibility is still early and partial. Treat any vendor claiming a complete picture with suspicion.
It will not settle by market. Agentic checkout availability, merchant programmes and eligibility differ by country and are moving quarter to quarter. What is true for a US seller today may not be true for a UK one, and vice versa.
Key takeaways
- AI readiness for a catalogue is a data question, not a culture question. Run it against real exports.
- Two routes matter: the feed route and the page route. Both are fed by the same catalogue, so both fail together.
- Identity comes before content. Fixing descriptions before fixing GTINs, brands and titles is the wrong order.
- Attributes beat prose. If the concept a shopper filters on is not a field, no rewrite rescues it.
- Client-side rendered specifications are invisible to most AI crawlers, on the evidence available.
- Score out of 20, then name the two zeros. That is the programme, and it is what a board can fund.
Five days of one person’s time is a cheap way to find out where you stand. If you would rather have a second pair of eyes, we run this diagnostic as a fixed-scope exercise against a live catalogue. You get the scored findings back with a remediation sequence. A thirty minute call is enough to tell whether it is worth doing. Get in touch. Or read how we think about AI in product data, and where applied AI work pays back first.