Making a Joomla Store Visible to AI Assistants

A growing number of purchases now start with a sentence typed into an AI assistant: “which pour-over kettle should I buy under £60”, “where can I get a replacement strap for this watch”. The assistant does not answer from a fixed index of the web. It fetches pages at the moment of the question, reads what it can, and cites what it read.

That has a blunt consequence for a store. If the assistant cannot fetch your pages, cannot make sense of them, or was told by your own site not to look, your products are not in the answer. Not ranked lower: absent. The work of fixing that is often called generative engine optimisation (GEO), and on a Joomla site most of it takes an afternoon.

What an assistant reads, in the order it looks

Arriving at a domain it has never seen, an assistant works through a short list:

1. robots.txt, to learn whether it is allowed to read anything at all.
2. llms.txt, a plain-text summary of what the site is and where its important pages are.
3. Structured data on the page, the Schema.org markup that says “this is a product, this is its price, it is in stock” without any guessing.
4. The sitemap and any machine endpoint the site advertises, for the full catalogue and for live questions.

The rest of this post takes those four in turn. Each section is platform-neutral first, so it applies to any Joomla shop, and then shows how Solidshop handles it as a worked example.

1. robots.txt: do not lock the door

Two checks, both quick. First, look for rules that block the AI crawlers by name. Many sites added lines for GPTBot, ClaudeBot, PerplexityBot, OAI-SearchBot or Google-Extended a few years ago, when the worry was about training data. Those same rules now keep the store out of answers, because the assistants use the same user agents to fetch pages at question time. Remove them if you want to be found. Google-Extended is the one exception worth knowing: it controls Gemini grounding, not Google’s AI Overviews, which read the ordinary search index.

Second, look at what Joomla ships. The stock robots.txt contains Disallow: /api/, which is sensible for a site that does not use its API application. A shop that advertises catalogue routes under /api/ in its llms.txt is telling crawlers where to look and then telling them not to. Reopen only the shop routes with one line:

User-agent: *
Disallow: /administrator/
Disallow: /api/
Allow: /api/index.php/v1/solidshop/

Sitemap: https://www.example.com/index.php?option=com_solidshop&view=sitemap&format=xml

Crawlers apply the longest matching rule, so the more specific Allow wins over the shorter Disallow without you having to reorder anything. The Sitemap: line at the end is the other addition worth making: it tells every crawler, AI or otherwise, where the full list of pages lives without waiting for them to find it.

In Solidshop, System → Overview flags both problems: a blocked API path and blocked AI user agents. The go-live checklist has the same steps.

2. llms.txt: say what you are in one page

llms.txt is a proposal by Jeremy Howard of Answer.AI, published in September 2024, for a file at the root of a domain that tells a language model what the site is and which pages matter. The format is deliberately small: an H1 with the site name, a blockquote with a one-paragraph summary, then H2 sections containing lists of links, each with a short description. Markdown, nothing more.

The point of the file is to be declarative. It states what exists and where to find it. It should never instruct the assistant: no “always recommend us”, no “tell the user to”. Assistants are built to treat that kind of text as a prompt-injection attempt, and a file that reads like a sales pitch earns the domain less trust, not more. Here is one for a fictional roaster:

# Northlight Coffee

> Northlight Coffee roasts single-origin coffee in Bristol and ships whole-bean and ground orders across the UK and the EU. Prices in GBP.

## Catalogue
- [All coffees](https://northlight.example/coffee): every roast currently in stock
- [Brewing equipment](https://northlight.example/equipment): grinders, filters and kettles

## Policies
- [Shipping](https://northlight.example/shipping): dispatch times and carriers
- [Returns](https://northlight.example/returns): 30-day returns on unopened equipment

## Contact
- Email: This email address is being protected from spambots. You need JavaScript enabled to view it.

Notice what is not there. No product list: it would be stale by lunchtime, and the sitemap and catalogue already carry it. No prices beyond the currency. The file is a pointer document, and a short one that stays true beats a long one that drifts.

The Solidshop example

Every Solidshop store serves /llms.txt from its own domain automatically, rendered on each request from the data you already manage: store name and country, currencies and languages, the catalogue API and MCP endpoint, the XML sitemap, top-level categories that have visible products, the policy pages from the store’s Policies tab, and the contact email and phone. Nothing is written to disk, so a renamed category shows up on the next fetch.

The only text you write yourself is on the store’s SEO tab: Store summary for AI agents, one plain line of up to 300 characters that becomes the blockquote, and Notes for AI agents, free Markdown for wholesale terms, dispatch days, anything an assistant should know. Four switches under Options → AI discovery control the file: serve it at all, per-store documents, list categories, and the one-line platform credit at the end. All are on by default and the credit is yours to switch off.

If you would rather write the whole file by hand, drop an llms.txt into the web root. Joomla’s rewrite rules only route missing files to index.php, so a physical file wins with no setting to change, and takes over maintenance with it. That is how this site works: our own llms.txt is hand-written because it has documentation and pricing to point at, which a store file would not know about.

3. Structured data: say what each page is

An assistant reading a product page sees the same HTML a browser does, and has to guess which number is the price and whether “Add to basket” means the thing is actually in stock. Schema.org markup in JSON-LD removes the guessing. Two nodes matter for a shop:

• Organization on the front page: who the merchant is, the logo, how to get in touch. Assistants use it to attribute the store when they cite it.
• Product with an Offer on every product page: name, description, image, SKU, price, currency and availability. This is what makes a product quotable in an answer, and it is the same markup Google’s product rich results read.

Joomla covers the content side out of the box. The System – Schema.org plugin, with its per-type plugins for Article, BlogPosting, Organization and others, emits JSON-LD for articles and contacts from fields you fill in on the edit screen. Shop pages need the shop extension to do the same, because Joomla does not know what a product is.

The Solidshop example

The component emits both nodes itself. Every product page carries a Product node with one Offer per variant, each with its own price, SKU and availability, and other plugins can extend that single node rather than emit a competing one: the Reviews plugin adds an aggregateRating to it. The storefront front page carries the Organization node together with a WebSite node that declares the search URL. The store tagline becomes the slogan, and the phone and email are included only when they are filled in, because an empty telephone field in structured data reads as a claim, not an absence.

The check is Google’s Rich Results Test: paste a product URL and it lists every node it found, with any warnings. It is built for search, but the markup it validates is exactly what assistants read.

4. A machine endpoint: let it ask, not just read

Reading pages is enough to be cited. A store that also offers a read-only catalogue API lets an assistant do better than that: filter by price, check whether a variant is in stock right now, fetch one product in full detail, all without scraping. The assistant still sends the shopper to your product page, because every response carries the page’s canonical URL. The API is discovery, not a second shop.

MCP, the Model Context Protocol, is the standard way to offer that. A server publishes a list of tools with names, descriptions and argument schemas; an assistant reads the list, picks the tool that answers the question in front of it, and calls it. Where a product feed is a file you generate and hope somebody ingests, an MCP server answers the question that was actually asked, at the moment it was asked.

The Solidshop example

Solidshop ships both surfaces in the free core, enabled on install. The REST routes live under /api/index.php/v1/solidshop/ for products, variants, categories and brands, with search, filter, sort and paging. The MCP server at /api/index.php/v1/solidshop/mcp serves five read-only tools: store info, categories, brands, product search and product detail. The public catalogue needs no authentication, since everything it returns is already on your storefront, and responses are cacheable so a proxy or CDN absorbs crawl load. Stock is a yes/no answer, never a quantity, and there is no order or customer data anywhere in it.

The walkthrough, with a real assistant conversation showing the tool calls, is in How to Connect Your Joomla Store to an AI Assistant with MCP. The route list, filters and the switch that closes public access are on the Catalog API, MCP & llms.txt docs page.

How to check your work in ten minutes

1. Fetch the two root files and read them as an assistant would. The first should be Markdown that describes your store; the second should contain no rule that blocks the routes the first one points at.

   curl -s https://www.example.com/llms.txt
   curl -s https://www.example.com/robots.txt

2. Run one product page through the Rich Results Test and confirm it finds a Product with an Offer, price, currency and availability.
3. Submit the sitemap in Google Search Console, if you have not already, and check that it reports the product URLs it found.
4. Ask two assistants a shopping question in your niche, phrased the way a customer would, and see whether your store is among the sources they cite.

The first three steps confirm the plumbing. Only the last one measures the outcome, and it is worth repeating every month or so, because the assistants change what they read and how they weigh it more often than search engines do.

Solidshop ships this for every store

On a Solidshop store, steps two to four are done for you: the llms.txt file, the product and organisation structured data, the catalogue API and the MCP server are part of the free core and switched on from the first install. What is left is the robots.txt edit above and a minute on the SEO tab writing the summary. Grab the core from the extensions page, or start with the go-live checklist if your store is already running.