How to make AI agents find your catalogue

More and more people start their shopping by asking an assistant instead of typing into a search engine. "Where can I buy a 28 cm cast iron pan that isn't ridiculously expensive?" The assistant answers, and in that answer some stores appear and others don't.

This post is about what it takes to be among the ones that appear. And it starts with a warning almost nobody includes: none of this is measured.

First, the honest part

There are no reliable figures for how much sales comes from AI assistants today. The ones in circulation nearly always come from companies selling something related, with no published methodology. We don't have any either.

What can be said without inventing anything is more modest and more useful: the three layers an agent needs in order to use your catalogue are the same ones classic SEO has needed for years, and almost no store has them right. So the work pays off even if the agent promise takes its time.

With that out of the way, here goes.

Layer 1: being readable

It looks like the basics and it's where most people fail.

Look at your robots.txt. Plenty of stores blocked AI crawlers at some point, sometimes as a decision and sometimes because it came in a template. It's a legitimate decision, but it should be a decision: if you block them, you won't appear, full stop. Assistant crawlers identify themselves by name and can be allowed or denied one by one.

Check that your content is in the HTML. If the price, the stock or the description only appear after JavaScript runs, there are agents that won't see them. The test takes ten seconds: open a product page, view the source, and search for the price. If it isn't there, you have a problem you also have with Google.

And check whether your bot protection is being over-enthusiastic. It's easy to end up blocking anything that doesn't look like a browser, and things you did want through get caught in that.

Layer 2: being understood

Being readable isn't enough: you have to say what you sell in a format nobody has to guess at.

Structured product data. This is what actually gets used today, and it's the same thing Google has been asking for for years: name, price, currency, availability, product code, brand. If your platform already emits it, check on it now and then: it breaks with template changes and nobody notices.

The two fields people forget most are the ones worth most here: availability, because an agent that recommends something out of stock stops recommending that store, and the product code, because it's what makes it possible to know that your pan and another store's pan are the same pan.

An llms.txt file. It's a text file at the root of your domain summarising what you are and which pages to go to. It's a young convention and its real adoption isn't proven: we say that plainly. That said, it costs an afternoon and breaks nothing, so the ratio between what it costs and what it might give is good. We publish ours at findalo.io/llms.txt, in case you want to copy the structure.

What a store's should carry: what you sell and to whom, how the catalogue is organised, where the shipping and returns terms are, and which pages to go to for each thing. No marketing. A file full of adjectives is a useless file.

Layer 3: being able to answer with your data

This is where the interesting things are happening and where almost nobody has done anything.

An agent helping someone buy needs specifics: whether something is in stock right now, which sizes are left, what shipping costs to a given place. That isn't on a marketing page; it's in your store, and it has to be askable.

The three pieces you can prepare today:

• A correct, up-to-date product feed. The same one you use for comparison sites. If you already have it right, you're halfway there.
• Terms pages that can be read. Shipping, timescales, returns, warranty. In text, not in an image and not in a PDF. These are the questions any shopping assistant gets most.
• Internal search that works. It sounds self-serving and it isn't: when an agent lands on your store and wants to find something specific, it uses your search. If your search can't find it, the agent concludes you don't stock it.

What we do about this

Two things, neither of them magic.

The first, on our own site: we publish llms.txt and a longer version with the facts concentrated in a single file, so that a model citing us does so with correct data rather than with what it inferred from a pricing page.

The second, in the product: search can be configured from an agent. Synonyms, rules, relevance, design. The agent proposes changes and a person approves them in the dashboard, or it applies them itself if the merchant has enabled that, always with a way back. The logic is the same as this post's: if your team is going to work with assistants, the tools have to let themselves be operated by them.

How to measure whether any of this works

Without measurement, all of the above is faith. Two things you can look at from today:

• Visits arriving from assistants. They show up in your analytics as referrals from their domains. Today it's usually little; what matters is the trend, not this month's number.
• Ask them yourself. Take two or three assistants and ask them the question one of your customers would ask. Do you come up? Does your competition? Is what they say about you correct? It's a crude method and it's vastly better than nothing.

If they describe you wrongly, it's nearly always layer 2: something on your site is saying something that isn't true any more.

Where to start

If you're only going to do one thing this month, make it checking that price and availability are in the HTML of your product pages and in the structured data. That serves you for Google, for comparison sites, for agents and for your own search.

If you're going to do two, write the llms.txt.

And if you have an afternoon spare, fix your internal search: it's the one everyone who arrives will use, human or not. We have fifteen checks for finding out what state it's in.