Back to Blog

By Dylan Hunt

June 9th, 2026

aiseo

llms.txt, Explained: The Format, How It Works, and Whether It Helps

llms.txt, Explained: The Format, How It Works, and Whether It Helps

An AI assistant arrives at your site with a short attention span and a tokenizer that hates your theme. It has a few seconds and a fixed context window to work out what you sell, which pages matter, and how to describe you to the person who asked. Almost everything it downloads is navigation, scripts, cookie banners, and markup written for browsers. The substance is in there somewhere, buried. llms.txt is one answer to that problem: a small file that hands the assistant a clean map instead of making it dig.

This is the long version of that idea. Where it came from, the exact format, how it differs from the files you already publish, what assistants actually do with it today, and whether it earns a place on your site. If you just want the Shopify-specific how-to, we covered that in What Is llms.txt, and Should Your Shopify Store Have One?. This piece is the reference underneath it.

Where llms.txt came from

The proposal came from Jeremy Howard, co-founder of Answer.AI and fast.ai, in September 2024, published at llmstxt.org. The motivation was simple. Language models read pages through a context window, and a typical web page spends most of that window on things a model does not need. A curated, Markdown index lets a model find the important content and read it cheaply.

It borrows its shape from two files every site already has. robots.txt tells crawlers what they are allowed to fetch. An XML sitemap lists what exists. llms.txt does neither of those jobs. It is a table of contents written for a reader that summarizes rather than ranks, with your own one line descriptions next to each link. The format is a proposal, not a ratified web standard, and that distinction matters when you weigh how much to invest in it.

What the file actually is

llms.txt is a plain Markdown file served at the root of your domain, at yourdomain.com/llms.txt, with a text/plain or text/markdown content type. The spec is short enough to hold in your head:

  • An H1 with the name of the site or project. This is the only required line.
  • An optional blockquote (>) with a one sentence summary.
  • Any amount of free Markdown after that: a paragraph or two of context, with no headings.
  • Zero or more H2 sections, each holding a bulleted list of links in the form - [name](url): optional note.
  • An optional section literally titled ## Optional. Links under it are the ones an assistant can safely skip when its context budget is tight.

A minimal file looks like this:

# Trailhead Outfitters

> Technical apparel for cold-weather running and hiking.

## Collections
- [Base Layers](https://store.com/collections/base-layers): 200gsm merino crews and zips.
- [Insulated Jackets](https://store.com/collections/jackets): Synthetic and down for sub-zero days.

## Help
- [Shipping and Returns](https://store.com/policies/shipping): Free returns within 30 days.
- [Sizing Guide](https://store.com/pages/sizing): Fit notes by product type.

## Optional
- [About the Founders](https://store.com/pages/about)

There is also a companion convention, usually called llms-full.txt, that inlines the full text of those pages into one long Markdown file. The short llms.txt is the map. The full file is the territory, for assistants that want the depth in a single fetch and have the context to hold it. You can publish one, both, or just the short version.

How it differs from the files you already have

This is where most of the confusion lives. llms.txt does not replace anything. It sits alongside files that answer different questions.

FileQuestion it answersAudience
robots.txtWhat am I allowed to crawl?Any crawler
sitemap.xmlWhat URLs exist, and when did they change?Search crawlers
Schema.org JSON-LDWhat are the precise facts on this page?Search and AI parsers
llms.txtWhich pages matter, and what is each one about?Language models

Structured data and llms.txt are complements, not substitutes. JSON-LD puts machine-readable facts inside a page: a price, a rating, a return window. llms.txt works one level up, at the site, telling an assistant which pages are worth reading at all and describing them in your words. If your product facts are not in your HTML or your structured data, an index file pointing at those pages will not invent them. Get the structured data right first. The index is the last mile, not the road.

How assistants actually use it today

Here is the honest state of play, because there is a lot of overstatement in circulation.

llms.txt is not a ranking factor. Publishing one does not push you up in ChatGPT or Google the way a title tag nudges a search result. Google has said publicly that it does not use llms.txt for Search. No major assistant has confirmed that it fetches the file at crawl time as a routine input, and you should not plan as if one does.

Where it is genuinely used today is narrower and more practical. Developer tools and documentation platforms have adopted it quickly, because feeding a model a clean llms.txt or llms-full.txt is a reliable way to give it accurate context about a library or product. When a person pastes your file into an assistant, or a tool fetches it on their behalf to answer a question about you, the curation pays off immediately. The model reads what you chose, described the way you described it, instead of guessing from theme markup.

So the value is real but bounded. You are lowering the cost for a machine to understand you correctly, and you are stating in your own words what each page is about, which cuts down on confident misdescriptions. You are also placing a low cost bet on a convention that is still gaining ground. None of that is a placement lever. Treat anyone who sells it as one with suspicion.

What a good file looks like for a store

A store has an obvious set of pages an assistant wants: the collections that organize the catalog, the policies that answer shipping and return questions, the sizing and care pages, and any buying guides. A fuller file, in the shape we generate for stores, adds a couple of useful conventions on top of the bare spec:

# Store: Trailhead Outfitters

> Technical apparel for cold-weather running and hiking, shipped from Oregon.

License: CC-BY-NC-SA 4.0
Last-Updated: 2026-06-09

## Collections
- [Base Layers](https://store.com/collections/base-layers)
- [Insulated Jackets](https://store.com/collections/jackets)

## Products
- [Merino 200 Crew](https://store.com/products/merino-200-crew): 200gsm merino base layer, 6 colors.
- [Summit Down Hooded Jacket](https://store.com/products/summit-down): 800-fill down, packs to 1L.

## Pages
- [Sizing Guide](https://store.com/pages/sizing): Fit notes and measurements by product type.

## Policies
- [Returns](https://store.com/policies/refund-policy): Free returns within 30 days.
- [Shipping](https://store.com/policies/shipping-policy): Free over $75, 2 to 5 day transit.

## Verified profiles
- [Instagram](https://instagram.com/trailheadoutfitters)
- [YouTube](https://youtube.com/@trailheadoutfitters)

---
Generated by AgentReady (store.com)

Two of those additions earn their place. A Last-Updated line tells an assistant how much to trust the file, and a License line states how the content may be reused. The Verified profiles section is a trust signal in the spirit of Schema.org sameAs: it connects the store to the social accounts that confirm it is real. The rest is the standard spec, with one line descriptions doing the heavy lifting.

One thing to leave out: links to checkout.shopify.com policy pages or any other host that is not your storefront. Those are not pages a shopper or an assistant should treat as yours. Point only at canonical URLs on your own domain.

How to generate and maintain one

For a small site, you write it by hand. The format is trivial and the whole file fits on a screen. The hard part is not the syntax. It is keeping the file true.

A stale index is worse than no index, because it teaches an assistant something false with full confidence. New collections, retired products, renamed pages, and changed policies all have to flow into the file. Do that by hand on a ten page site and it is a five minute chore. Do it by hand on a catalog that changes weekly and it will drift, and the drift is invisible until an assistant repeats an old price or links a dead page.

That is the case for generating it from your catalog instead of maintaining it by hand. A generator reads your current products, collections, pages, and policies, curates them down to what matters, writes your descriptions, and regenerates whenever the catalog changes so the file never goes out of sync. That is exactly what AgentReady does for Shopify stores, and we treat our own help center the same way. The discipline a generator enforces is not the formatting. It is the freshness.

Hosting it at the domain root on Shopify has its own wrinkles, since the platform does not let you drop arbitrary files at /. We walk through the options, an app route, a proxy, or a dedicated page, in the Shopify-specific guide.

Common mistakes

  • Treating it as a sitemap. It is curation, not a dump of every URL. If the file lists a thousand links, a model cannot tell which five matter, and you have recreated the problem you were solving.
  • Letting it go stale. Put it on the same update path as your catalog, or generate it, or do not bother.
  • Blocking the assistants you are courting. Publishing llms.txt while your robots.txt blocks the AI crawlers is working against yourself. Decide who you want reading the file, then let them.
  • Skipping the fundamentals. If the facts are not in your HTML and your structured data, the index has nothing true to point at.
  • Pointing at non-canonical URLs. Hosted policy pages and off-domain links dilute the trust the file is supposed to build.

So, does it help?

For most sites, publishing llms.txt is a low cost, no downside move with a modest, real upside. It will not lift your ranking, and it is not consumed everywhere yet. What it does today is make the assistants and tools that do read it understand you faster and describe you more accurately, in your own words, and it positions you for a convention that keeps gaining adoption. The only way to get it wrong is to treat it as magic and skip the structured data and crawlability work underneath, or to let it rot.

For the wider picture of how assistants discover and buy from a store, the index file is one piece. We cover the rest in How AI Shopping Assistants Find Your Shopify Store and the complete guide to Shopify agentic commerce.

Do the fundamentals first. Then add the index on top, and keep it true. If you would rather not maintain it by hand, AgentReady keeps an llms.txt current for your store automatically, regenerating it as your catalog changes so it never drifts out of sync.

Make your store agent-ready

Get found and recommended by AI shopping assistants.

AgentReady adds Schema.org structured data, an llms.txt directory, and an AI-readability audit to your Shopify store, so ChatGPT, Perplexity, and Google can understand and recommend your products. Free for stores under 500 products.

ShareXLinkedInFacebook

Written by Dylan Hunt, Founder, Caffeine and Commerce. We build Shopify stores that rank and that AI agents can read. Have a project? Get in touch.