01
What the proposal specifies
Applies to marketplace onlyown storefronthybrid
The proposal describes a Markdown file at the root path of a site, optionally at a subpath, whose stated purpose is to present site information in a form a language model can use inside a limited context window.1 It does not describe a feed, an access-control mechanism, a manifest of products, or a signal a named platform consumes.
Its structure is loose relative to other machine-readable formats. The proposal notes that it uses Markdown to structure the information rather than a classic structured format such as XML, and it makes one section mandatory: an H1 carrying the name of the project or site.1 A blockquote summary, explanatory paragraphs, lists of links under H2 headings, and a section marked Optional whose contents may be skipped when context is short are all described as optional.
02
Who published it, and what it can establish
Applies to marketplace onlyown storefronthybrid
The proposal was published in September 2024 by Jeremy Howard, and it describes itself as a proposal open for community input.1 Most other documents in this course are either a platform describing its own behavior, which is authoritative for that platform, or a specification published by a standards body through a review process. This document is a third kind.
It is first-party evidence of what it specifies. It is not evidence of adoption, of effect, or of any party consuming the file, and the table below sets out how the three kinds of document differ in what each supports.
| Document | What it can establish | What it cannot |
|---|---|---|
| A platform’s own documentation | That platform’s stated behavior and requirements | Another platform’s behavior |
| A published RFC | Conformant behavior for implementers who follow it | That a given operator follows it |
| llms.txt | What the file format is | That any system reads it |
03
What the current sources do not state
Applies to marketplace onlyown storefronthybrid
The proposal carries no statement of adoption or support by any search engine or AI provider.1 No other source in this course’s registry contains one either. Where a platform consumes a file in a way that affects merchants, the platform’s own documentation is where that appears, alongside its feed requirements and its crawler names, and the current source set does not include such a statement about this file.
The position that follows is a stated absence rather than a finding either way. As of this lesson’s review date, the cited sources do not establish that publishing llms.txt changes how a system treats a merchant’s products. That is a description of the source set, and it changes if a platform publishes documentation naming the file.
04
Cost and reversibility
Applies to marketplace onlyown storefronthybrid
The cost side is short. Writing an llms.txt for a small storefront is one Markdown file, it changes nothing about the listings, it is not part of the checkout path, and deleting it returns the site to its previous state. The described upside is that the file states what the site is and links to the pages that matter, which is information a system fetching the root would otherwise derive from navigation.
- It is additive: nothing else in the setup depends on it.
- It is reversible: deleting the file restores the prior state.
- It is legible: a person reviewing the site can read it in seconds.
- It is bounded: the ongoing cost is keeping the links accurate.
Separately, the documented surfaces publish their own requirements: accurate availability so a sold item stops being offered, condition evidence in a readable field, and a feed whose values match the item. Those requirements appear in the platforms’ own documentation, and this file does not appear there.
05
Writing one for a storefront that sells out
Applies to marketplace onlyown storefronthybrid
The proposal frames the file as useful at inference time, when something is answering a question about the site inside a limited context.1 A file listing two hundred links serves that framing differently from one listing eight, since the format is described as a selection.
- Name the site in the H1 — the one required element — using the name a person would recognize.
- Write one or two sentences stating what the business is, including that stock is one-of-one where that applies.
- Link the pages answering durable questions: shipping, returns, condition grading, and how to ask about an item.
- Link a small number of representative listings rather than the whole catalog, and expect them to sell.
- Place anything that may be skipped under the Optional section.
The fourth step is where unique stock differs from a replenishable catalog. Individual listings end by selling, so a file of item links becomes a file of ended pages within weeks. Either the links are to durable pages, or the file joins the set of things carrying a maintenance cadence.
06
Recording the decision
Applies to marketplace onlyown storefronthybrid
The decision is recorded in three lines: what was done, what was expected, and what would change it. Six months later, the question of whether the file helped resolves to “not established” unless what knowing would look like was written down first.
| Line | What the camera shop wrote | Why in this form |
|---|---|---|
| What we did | Published one file: H1, two sentences, six links to durable pages | Specific enough to be checked against the live site |
| What we expected | Nothing measurable; published because it is reversible and low-cost | An expectation recorded as such is not later read as a prediction |
| What would change our mind | A named platform publishing documentation that consumes the file | A checkable event rather than a date |
| Did it work | Not established, and it stays that way without a baseline that was not taken | The absent baseline is recorded rather than inferred later |
The fourth line records what the run cannot support. A citation or a change in traffic six months from now has several possible causes, and the row stating that no baseline was taken is what keeps that open rather than closed.
The review trigger is set on the evidence rather than on the calendar. The event is a platform publishing documentation naming the file, which is checkable, and it is the same standard this course applies elsewhere: read what the operator states about its own behavior.
07
The proposal and its current standing
Applies to marketplace onlyown storefronthybrid
The cited proposal specifies a Markdown file at a site’s root, requires one H1, marks everything else optional, and is published by a named individual as open for community input.1 It carries no statement of adoption or support by a search engine or AI provider.
What the sources do not state is whether any system reads the file, what a system would do with it, or how that would appear to a merchant. Those are the entries that would change if a platform documented consuming it.
08
Practice
Exercise
Draft an llms.txt and its decision record
- Write the file: one H1, a two-sentence description, and no more than eight links to durable pages.
- Check every link resolves and that none of them is a listing likely to sell this month.
- Write three lines recording what you published, what you expect, and the specific event that would make you revisit it.
Check yourself
What is the only required element of an llms.txt file?
An H1 carrying the name of the project or site. Everything else the proposal describes is optional, so conformance is separate from whether the file contains anything useful.
A vendor’s package is described as producing AI-search presence, and the deliverable is an llms.txt file. What can be checked?
Which platform documents consuming the file. The proposal itself carries no adoption statement, and a platform that consumed it would state so in the documentation where it states its feed requirements.
The file is published and three weeks later a system cites one of the site’s pages. What does that establish?
No attribution. One change was made in an environment where other things change, with no baseline and no control. The citation is an observation; its cause is not established by the file having been published.
Progress is saved in this browser only. No account, nothing sent anywhere.
09
Common questions
Is llms.txt a standard?
The proposal describes itself as a proposal open for community input, published by a named individual. It has not been through a standards body, and this course records it as a community proposal.
Does robots.txt do the same thing?
They address different questions. robots.txt is a published standard stating what conformant crawlers may fetch; llms.txt is a proposal describing site content for a reader. One concerns access and the other description.
Does publishing it affect anything else on the site?
The file is additive and sits outside the listing and checkout paths. The cost it does carry is the time it takes and the links it commits to keeping accurate.
Should every product be listed in it?
For one-of-one stock, item links end when the items sell. Either the file links durable pages and a small representative sample, or it carries a maintenance schedule.
10
Research and sources
Rules and platform policies change. These primary sources were reviewed on ; confirm the current position for your jurisdiction and account before acting.
Claim evidence
- The llms.txt proposal specifies a Markdown file at a site’s root path whose only required element is an H1 naming the project or site; every other section it describes is optional.
- technical requirement. Supported by The /llms.txt file .
- The llms.txt proposal is one named author’s proposal open for community input and carries no statement of adoption or support by any search engine or AI provider; no source here establishes an effect from publishing it.
- current external fact. Supported by The /llms.txt file .