Smarter Sitemaps: The Role of llms.txt in the 2026 Discovery Loop

A practical look at how sitemaps, robots.txt and llms.txt actually affect discovery for AI systems, and why the difference matters for your next step.

Bittbuzz Team 13 min read

Short answer: sitemaps and robots.txt are the machinery that governs discovery, and they have been for years. llms.txt is a reasonable proposal that no major platform has committed to reading. Add it if you want to test something; do not build on it.

A dark composition of thin Teal filaments tracing paths through a grid, several of them converging on a single labelled point

The three files, and which ones do the work

FileWhat it isStatusWorth your time
sitemap.xmlA list of URLs you want indexed, with datesStandard, documented, workingYes
robots.txtPer-path crawl instructions per user agentConvention, widely honouredYes, deliberately
llms.txtProse summary of your important pages for language modelsProposal, not adoptedOptional experiment

Only the first two are infrastructure you should depend on.

sitemaps.xml

The format is deliberately boring: XML, a urlset, and inside it one url element per address with an optional lastmod. The protocol documentation is short and worth reading once, because most sitemap problems are misunderstandings of it rather than misconfiguration. [3]

Google’s guide to building and submitting one is the operational reference, and it is the right place to confirm the format before generating anything by hand. The detail that catches people out is lastmod: Google says to set it only when content meaningfully changed, and notes that setting it on every build trains crawlers to distrust the signal. An accurate lastmod is worth having. A wrong one is worse than none. [2]

For a site with a few dozen pages, this is a two-minute-per-month job, and most of it is noticing when a URL has moved.

robots.txt

Robots.txt is a convention, not a control. There is no enforcement; a crawler that ignores it is not violating anything, it is simply ignoring a file it has to fetch first. That matters for how you think about AI crawlers specifically, because they are not a single entity with one policy.

Google publishes its crawler user agents, including the ones it uses for AI features, and documents how to check what a given user agent has actually fetched through its crawl statistics. [4]

If you want to be found by systems that read these files, allow the relevant user agents. The blunt warning is that a Disallow: / aimed at all crawlers also removes you from anything built on those systems — and, for search, entirely. Ahrefs’ guide covers the practical side of writing directives that behave the way you intended. [5]

A schematic loop in Teal: an editor writes, a crawler reads, the outputs feed a model, the outputs point back at what is worth writing

llms.txt, stated honestly

llms.txt is a proposal for a plain-text file at the root of a domain, containing a title, a short summary, and a set of links with descriptions, intended to give language models an efficient way to learn what a site contains without parsing its HTML. It reached v2 while I was writing this.

What is true about it:

  • The proposal itself is published openly, and the current version is documented in enough detail to generate from — an H1, a blockquote summary, and a list of links each with a description. It is cheap to produce, and the format is legible by a human being. [1]
  • It removes a real inefficiency — parsing navigation, boilerplate and cookie banners to find the actual pages.
  • It is not adopted by any major platform as a requirement.

What is not yet true, and is worth being clear about rather than repeating:

  • That it improves citation rates. There is no published measurement of this.
  • That it is read by ChatGPT, Perplexity or Claude. Some may. None have said so.
  • That having one and not having one is a ranking distinction.

Treating an unadopted proposal as load-bearing infrastructure is the error here. Treating it as a twenty-minute experiment you run alongside everything else is not.

The more useful version of the same question

If you want a system to summarise your page well, the levers you actually control are boring: one clear claim, stated early, in words that survive being lifted out of the page. An assistant picking your page has to be able to extract a sentence that means something on its own. That is a writing constraint, not a file-format one.

So the honest sequencing is: fix the page first, then decide whether llms.txt adds anything for that page. Not the other way round.

A structured plain-text document rendered in Teal, each entry a title and a one-line description, with no decoration at all

Doing this without an afternoon of yak-shaving

  1. Confirm your sitemap is accurate. Every URL resolves, returns 200, and no longer redirects.
  2. Keep lastmod honest. Change it when the content changes, not when you deploy.
  3. Read your robots.txt and decide deliberately what each directive is for. Most blanket blocks are cargo-culted.
  4. Check it against reality, not intention — Google’s crawl stats will tell you whether the agents you allow are the ones arriving.
  5. Optionally generate llms.txt from your existing page frontmatter. If you already have a title and description on each page, this is a build step rather than a writing project.

An objection worth taking seriously

The strongest argument against llms.txt is that it optimises for machines reading your site and not for people reading it. There is something to that. The counter is that it costs almost nothing if generated and never costs readers anything, because no reader will be harmed by a file they never see.

That asymmetry is the whole decision. Cheap, reversible, unreported: worth trying. Load-bearing: no.

Which is also why the version of this article that told you the 2026 discovery loop now required llms.txt was worth rewriting. A dependency on an unadopted file is a dependency on someone else’s roadmap, and it is the kind of thing that looks like diligence right up until it becomes the reason nothing else got done.

How this connects

Key Takeaways

  • llms.txt is a proposal, not a standard. It was published as a v2 proposal and is not adopted by any major platform as a requirement, so building a discovery strategy that depends on it is building on a file nobody has committed to reading.
  • Sitemaps and robots.txt are what actually govern discovery. They have been the mechanism for years, they are documented, and they work for crawlers that also index the web for search.
  • The interesting question is not whether to add llms.txt but whether your pages are worth summarising. A crawler that honours a file listing twenty weak pages has not helped you.
  • Do llms.txt as a low-cost experiment if you want it — it takes an afternoon. Do not delay anything else on it.

References

  1. The /llms.txt file, v2 — llmstxt.org. llmstxt.org
  2. Build and submit a sitemap — Google Search Central. developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap
  3. Sitemaps.org Protocol — sitemaps.org. www.sitemaps.org/protocol.html
  4. Google Crawler (User Agent) Overview — Google Search Central. developers.google.com/search/docs/crawling-indexing/overview-google-crawlers
  5. Robots.txt and SEO: Everything You Need to Know — Ahrefs. ahrefs.com/blog/robots-txt

Frequently Asked Questions

Quick answers to common questions about this topic.

No, and no major platform requires one. The proposal is published and evolving, which is a fair description of most good ideas at the stage llms.txt is at. It is cheap to add and costs nothing to test, so if you want to, add it. Just do not treat it as infrastructure your traffic depends on, and do not skip a sitemap because you have one.

There is no evidence it does. There is a plausible mechanism — a plain-text summary that is easy for a system to read without parsing — and no published measurement of the effect. Until there is a measurement, treat it as a hypothesis you can test rather than a technique that works. The more reliable version of the same goal is making each page's central claim quotable, which is a content problem, not a file-format problem.

The URLs you want indexed, each with a lastmod date you keep accurate, and nothing you want hidden. Google documents the format as XML with a urlset of url elements, and notes that a lastmod should only be set when the content meaningfully changed — setting it on every build trains crawlers to ignore it. Include your pages, exclude redirect and 404 URLs, and keep it under the 50,000 URL / 50 MB limits.

It depends on the crawler, because robots.txt is a convention rather than an enforcement mechanism. Google's documentation lists its own crawler user agents, and other systems publish their own — some honour robots.txt, some use it, some do not. Google's advice for sites wanting to be crawled for its AI features is to allow the relevant user agents, and to be aware that blocking all crawlers also blocks you from appearing in results built on those systems.

A sitemap, yes. llms.txt, if you want the experiment. They are not competing files and they do not conflict — one is a list of URLs with dates, the other is prose. Note that a sitemap listing a URL tells a crawler it exists; it does not tell them it is worth citing.

Less than you think. Sitemaps are for discovery, not for signalling freshness, and a sitemap that has not needed changing because your URL set has not changed is a sitemap doing its job. The thing to check is whether the URLs in it still resolve and still return 200. A stale sitemap full of redirects is worth rebuilding.

Ready to Strengthen Your Online Presence?

Every business is different. If you'd like practical advice tailored to your business, we'd love to learn more about your goals.

Let's Talk