Sigma Logic AI Lead with AI. Thrive with Innovation.
AI visibility

llms.txt and structured data: what actually matters

What llms.txt is, who reads it and who does not as of 2026, the exact format, what schema markup demonstrably does, and where to spend an hour if you only have one.

On this page 12 sections
  1. Key takeaways
  2. Who this applies to
  3. llms.txt: what it is
  4. Who reads it, as of September 2026
  5. If you do it, do it properly
  6. Structured data: what is actually documented
  7. Crawlability, which is binary and first
  8. Where to spend, in order
  9. What we implement, and what we will not claim
  10. When not to bother
  11. Frequently asked questions
  12. Next step

llms.txt is a markdown file at the root of a site that gives a language model a curated index of what matters. As of September 2026, Google has said it does not use it, no major assistant provider has committed to it as a ranking or citation signal, and adoption is around one site in ten. It is cheap, it is harmless, and it is unproven. Schema.org structured data, by contrast, has a documented effect on search results. If you do one thing, make the page itself crawlable and answer-first. If you do two, add the core schema types. llms.txt is third, and it takes ten minutes with the generator.

This area attracts confident claims well ahead of the evidence. What follows separates what is documented from what is inferred, because the difference should change how much you spend.

Key takeaways

  • llms.txt is a proposal from September 2024, not a standard. Google confirmed in July 2025 that it does not use it.
  • Some agents and tools do read it, mostly developer-facing ones. That is the honest extent of the adoption.
  • Structured data is documented and verifiable for search. Its effect on assistants specifically is not established publicly.
  • Both are cheap. That is an argument for doing them, not evidence that they work.
  • Beware anyone quoting a percentage uplift from llms.txt. The measurement to support it does not exist publicly.

Who this applies to

You are deciding how much effort to put into machine-readable markup, or you have been quoted for “llms.txt implementation” as a line item, and you would like the evidence separated from the marketing before paying for it.

llms.txt: what it is

The proposal was published by Jeremy Howard in September 2024. The reasoning is plain: HTML is noisy, context windows are finite, so offer a clean, curated index of the pages that matter in a form a model can read directly.

The format is short and it is worth knowing exactly, because most files in the wild get it wrong.

ElementRequiredWhat it holds
H1 headingYes, the only required partThe name of the site or project
BlockquoteNoOne short summary with the key facts needed to understand the site
Free textNoAny markdown except headings: paragraphs, lists, notes on how to read the site
H2 sectionsNoEach holds a list of links, one per line, - [Title](url): one-line note
A section titled “Optional”NoLinks an agent may skip when it needs a shorter context

A minimal valid file:

# Acme Robotics

> Acme builds warehouse picking robots for mid-sized distributors. Founded 2019, based in Ohio.

## Products

- [Picker P3](https://acme.example/p3): the current-generation picking unit, specs and pricing
- [Fleet software](https://acme.example/fleet): the control layer, integrations with WMS platforms

## Docs

- [Integration guide](https://acme.example/docs/integrate): how to connect a WMS, with API reference

## Optional

- [Press](https://acme.example/press): coverage and announcements

The spec also allows a file at a subpath, such as /docs/llms.txt, which covers the URLs beneath it, and a companion llms-full.txt that inlines the full content rather than linking to it. The companion is the one the documentation tools mostly use.

Who reads it, as of September 2026

This is the part that changes, so it carries a date.

Google does not. In July 2025 Google’s Gary Illyes said Google does not support llms.txt and has no plans to, and John Mueller compared it to the keywords meta tag, a signal search engines stopped trusting because it was free to lie in.

No major assistant provider has committed to it. OpenAI, Anthropic, Google, Meta and Mistral have not stated that they use llms.txt as a signal in their production answer surfaces. Anthropic publishes one for its own documentation, which tells you it is a good documentation convention, not that Claude ranks on it.

Some agents and tools do fetch it. Coding assistants and documentation tools fetch llms.txt and llms-full.txt from developer documentation sites, because a clean markdown index is exactly what a tool that needs API reference wants. Perplexity has been observed fetching it. This is real, and it is narrow: it helps a developer-tools company whose users work inside an AI-assisted editor. It does not help a plumber.

Adoption is around one site in ten. A 2026 crawl of 300,000 domains by SE Ranking found llms.txt on about 10% of them.

So the honest summary is unchanged from a year ago: plausible, cheap, unproven, and read by a small number of tools that matter to a small number of businesses.

How well evidenced each machine-readability measure is Five horizontal bars. Crawlability: undisputed, full bar. Answer-first page structure: strong, inferable from how retrieval works. Schema.org structured data: documented for search, unproven for assistants, three-quarter bar. Third-party presence: strong for assistants, most underrated. llms.txt: unproven, read by some developer tools only, short bar. Crawlability Answer-first structure Third-party presence Schema.org markup llms.txt Undisputed Inferable from the mechanism Observable in citations Documented for search Some developer tools read it EVIDENCE AS OF SEPTEMBER 2026
The order of the bars is the order of work. The two cheapest items are at the bottom, which is why proposals lead with them, and why they should not be what you pay for.

If you do it, do it properly

The file costs almost nothing and creates optionality if adoption grows. Three rules keep it from being worse than nothing.

Generate it. The failure mode is a hand-written file that drifts from the site within two months and then actively misdescribes you. This site’s own file is generated at build time from the same data the pages render from, so a stale version would require the site itself to be wrong. If you cannot generate it from a data source, use the llms.txt generator and put a review date in your calendar.

Follow the format. An H1, a blockquote, H2 sections of link lists. Most files in the wild are a pasted sitemap or a marketing paragraph. A tool that parses the spec cannot use either.

Curate. The point is a short list of the pages that matter, with a one-line note on each that says what a reader gets there. Forty links with no notes is a sitemap with extra steps. Put the secondary material under “Optional” so an agent with a small context can skip it.

What to include: what the organisation does, in plain language; the main sections with links; the services with a line each; the most useful articles. What to leave out: marketing language, anything not on the site, anything you would not want quoted.

Structured data: what is actually documented

Schema.org markup in JSON-LD describes what a page is about in a form machines parse without inference. Search engines document which types they support and what they do with them: rich results, knowledge panel content, eligibility for particular result formats.

That much is verifiable. The documentation exists, the testing tools exist, and you can watch a result change format after you add it.

TypeWhat it doesWorth it
OrganizationIdentity, contact, profiles, logoYes, once, sitewide
BreadcrumbListPosition in hierarchyYes, cheap
Article or BlogPostingAuthor, dates, sectionYes, on articles, with a Person for the author
FAQPageQuestion and answer pairsYes, where the FAQ is real and visible
Service and OfferCatalogWhat you sellYes, on service pages
HowToStep sequencesWhere genuinely procedural
Product with reviewsRatingsOnly if the reviews are real and yours

Two constraints matter. The markup must describe what is visibly on the page. Marking up FAQs that do not appear is a guideline violation, not a clever trick. And review markup is heavily policed, with manual action rather than a missed opportunity as the downside.

On assistants specifically: it is plausible that clean structured data helps a retrieval pipeline parse a page, and it is not publicly established. The honest position is to implement schema for the documented search benefits and treat any assistant benefit as unproven upside.

The block that does the most work

For a services business, the Organization block is the one that does the most and the one most often filled with the least thought.

It should carry the legal name, the URL, the logo, a description that matches what the site actually says, contact points, the postal address, and sameAs links to every profile you control.

That sameAs array is worth dwelling on. It is how you assert that the company on your site, the profile on a review platform and the listing in a directory are the same entity. Entity resolution is otherwise inference, and inference is where you get confused with a similarly named company. It is also the cheapest connection between your structured data and the third-party presence that actually drives assistant visibility.

Two failure modes. Do not list profiles you do not control; it is an assertion of identity, not a bookmark list. And do not let it go stale; a sameAs pointing at a dead profile is a broken claim about who you are. This site’s array currently holds one link, the founder’s LinkedIn profile, because that is the only external profile that exists and is maintained. A shorter true list beats a longer aspirational one.

Crawlability, which is binary and first

Before either of the above, check the mechanical question: can the crawlers reach your content at all?

Check robots.txt against the AI crawler user agents. Some sites block them deliberately, some inherited a block from a template or a CDN default, and the second group is usually surprised. Blocking guarantees absence from retrieved answers. That is a legitimate choice for a publisher monetising pageviews and usually the wrong one for a services business.

Check that content renders without JavaScript. If your text appears only after client-side rendering, assume some crawlers do not see it. View the page with JavaScript disabled; whatever remains is what you can rely on.

Check status codes and the sitemap. Pages that return 200, a sitemap that lists them, canonical tags that agree with the sitemap.

These are binary and take under an hour. They are also the only items on this page whose effect nobody disputes, which is why they come first.

Where to spend, in order

  1. Crawlability. Binary, cheap, undisputed.
  2. Answer-first page structure. The effect follows from how retrieval works and it improves the page for humans regardless. See writing content that assistants actually cite.
  3. Third-party presence. Directories, reviews, other people’s comparisons. The highest-impact item for assistant visibility and the least technical. See GEO vs SEO for why.
  4. Core schema types. Documented search benefits, low cost, generated from the same data as the page.
  5. llms.txt. Generate it, spend ten minutes, put a review date on it, move on.

The highest-impact item on that list is not technical at all. That is inconvenient for anyone selling technical AI-visibility work, including us.

What we implement, and what we will not claim

This site runs a full JSON-LD graph: Organization, WebSite, Person for the author, Service, OfferCatalog, FAQPage, BreadcrumbList, HowTo and BlogPosting, all generated from the same data the pages render from, so it cannot drift. The FAQ schema on every article is built from the article’s own visible FAQ section for that reason. The llms.txt is generated at build time in the spec’s format, and the generator tool on this site produces the same format for anyone else’s.

What we will not do is tell you the llms.txt is why you appear in an answer. We do not know that, nobody has shown it publicly, and the file costs so little that it does not need a business case built on a claim we cannot support.

The position that costs us: when a prospect arrives asking for llms.txt implementation as a project, the honest answer is that it is ten minutes with the generator and it should be bundled into something with a demonstrable effect. That is a smaller invoice than the one they came expecting, and it is the right one.

Where we think the genuine work is: the sourcing layer, meaning which third-party pages get cited in your category, and answer-first restructuring of pages you already have. Both are less technical than the markup conversation and both have observable effects.

When not to bother

When your site is not crawlable. Fix that first; markup on an unreachable page does nothing.

When you have no content worth citing. Markup describes content. It does not create it.

When someone quotes you a percentage uplift for llms.txt. Ask for the methodology. There is no public measurement that would support a specific figure.

When schema would misdescribe the page. Marking up content that is not visibly present is a guideline violation with real downside.

When you are not a developer-tools company and the pitch is llms-full.txt. The full-content variant is what coding assistants use for API documentation. For a services site it is a duplicate of the site in a second format, and nothing reads it.

Frequently asked questions

Does llms.txt actually work?

For search visibility, there is no evidence that it does, and Google has said it does not use it. For developer documentation read by coding assistants, it is genuinely useful. Outside that case, treat it as ten minutes of optionality.

Is llms.txt the same as robots.txt?

No. robots.txt controls crawler access and is long established and honoured. llms.txt is a proposed content summary that a small number of tools read. One is a control; the other is a suggestion.

What is the difference between llms.txt and llms-full.txt?

llms.txt is the curated index with links. llms-full.txt inlines the full content of the linked pages into one file. The full version is what documentation tools fetch. For most business sites only the index is worth producing.

How do I create one?

Use the generator on this site. Enter the name, one summary sentence, and the pages that matter grouped into sections, and it produces a file in the spec’s exact format that you copy to the root of your site. If your site is built from a content system, generate it from that instead so it cannot drift.

Which schema types matter most?

Organization sitewide, BreadcrumbList everywhere, Article with a Person author on posts, FAQPage where you have real FAQs, and Service on service pages. That covers most of the available benefit.

Should we block AI crawlers?

A trade, not a best practice. Publishers monetising pageviews reasonably block. Services businesses that want to be found generally should not. Check what your CDN does by default, because some now block AI crawlers unless told otherwise.

Next step

The crawlability check is worth doing today and takes under an hour. The AI search visibility engagement covers structured data and answer-first engineering with a measured citation baseline, and is explicit about which parts are documented and which are inferred.

Related: Writing content that assistants actually cite · Why ChatGPT recommends your competitor · GEO vs SEO: what actually changes · AI search visibility

Let's talk

Got a workflow this applies to?

Describe it in a couple of sentences. We will tell you whether it is worth automating, what we would build, and roughly what it takes.