Generated llms.txt file
Built programmatically from your route registry rather than typed by hand, so the canonical link list reflects what actually exists on the live site.

AEO service
llms.txt is a plain text summary at the root of your site telling assistants what you do and which pages are worth reading. It is useful and it is not magic. We treat it like generated output, not a static document someone forgets to update.
llms.txt is a proposed convention, not a formal web standard, and it is worth being honest about that up front. It is a plain markdown file served at the root of a domain, typically at /llms.txt, containing a short description of the organization plus a curated list of links to the pages most worth an assistant's attention. Some assistant providers say they consult it, some do not confirm either way, and none of them treat it as a ranking factor. Its value is as a low-cost, high-signal shortcut, not a guarantee.
What belongs in it is deliberately narrow. A concise statement of what the organization does and for whom. A short list of the canonical pages that represent the site's actual substance, service pages, key resources, an about or contact page, grouped and labeled clearly. What does not belong is a dump of every URL on the site, marketing copy dressed up as documentation, or content duplicated wholesale from the pages it links to. The file works as a map, and a map crowded with every street loses its usefulness.
It is also not a substitute for anything else in an AEO program. It does not make uncrawlable pages crawlable. It does not fix a site that only renders after JavaScript executes, since the file itself is just a pointer to pages that still have to be reachable and readable on their own. It does not replace structured data, entity consistency, or answer-first content structure. Publishing one on a site that fails at the basics is a five-minute task that changes nothing.
This site runs its own at /llms.txt, generated the same way we build one for clients: from the actual route registry, not typed by hand into a text file that quietly goes stale the next time a page gets added or retired.
What it is
Structurally, llms.txt is markdown with a small set of conventions: an H1 with the organization name, a short blockquote summary, and a series of H2 sections grouping links by category, each link carrying a brief description of what it leads to. There is no schema to validate against and no submission process, which means the discipline in building one comes entirely from curation, not from following a spec.
The core judgment call is what counts as canonical. A site with hundreds of blog posts should not list all of them. It should list the pillar and category pages that represent its actual expertise, plus a small number of genuinely load-bearing resources, and let internal linking from those pages carry an assistant the rest of the way if it chooses to go deeper.
The most common mistake is treating the file as a one-time deliverable. A site that adds, renames, or retires pages every month and never touches its llms.txt again ends up pointing assistants at dead links and omitting the newest, most relevant content, which defeats the purpose entirely. The file needs an owner and a refresh cadence the same way a sitemap does, and in practice it needs one more than a sitemap does, because nobody notices a stale llms.txt through a search console warning.
Our approach is to generate the file from the same route registry that defines the site's actual pages, so the list of canonical URLs is always a live reflection of what exists rather than a manually maintained guess. When a page is added to the registry with the right metadata, it becomes eligible for inclusion automatically. When one is removed, it drops out. That removes the single biggest reason these files go stale within a quarter of being published.
Fit
We would rather say no early than sell a program that cannot work.
Deliverables
A generated file wired into your build, plus the judgment calls documented so it stays useful.
Built programmatically from your route registry rather than typed by hand, so the canonical link list reflects what actually exists on the live site.
A documented policy for what qualifies as a canonical link, so future pages get included or excluded consistently instead of by ad hoc judgment.
The file regenerates as part of your deploy process, the same way a sitemap does, so new and removed pages are reflected automatically.
We confirm the linked pages are actually reachable by assistant crawlers before publishing, since a file pointing at blocked or unrendered pages is worse than no file.
A clear owner and review schedule so the file gets revisited on a cycle, not forgotten the day after launch.
A manual review confirming the markdown renders cleanly, links resolve, and descriptions accurately represent the destination pages.
How we run it
The file is the last step, not the first. We check the fundamentals before we publish anything.
We confirm the pages worth linking are actually crawlable and server-rendered, since an llms.txt pointing at unreachable content accomplishes nothing.
We identify the pillar, category, and resource pages that represent your real substance, and set explicit rules for what earns a place in the list.
The file gets built from the same source of truth as your site's routes, so it inherits new and removed pages automatically going forward.
We confirm the file serves correctly at the root path, renders cleanly, and every link resolves before calling the rollout complete.
A recurring check confirms the curation rules still make sense as the site grows, not just that the mechanics still run.
llms.txt is a plain text file at your site's root summarizing what your organization does and linking to your most important pages, meant to give AI assistants a quick, curated entry point. It is genuinely useful as a low-cost addition, but it is not a ranking factor and adoption across assistants is not universal or confirmed.
It works alongside the rest of an AEO program rather than replacing any part of it, and it only helps if the pages it links to are already crawlable and well structured.
No. It has no confirmed effect on search rankings and no guaranteed effect on whether an assistant cites you. It is a curated map that may make discovery slightly easier for systems that choose to read it, nothing more, and treating it as a shortcut around real content and access work is a mistake.
Where this connects
The file only helps if the fundamentals it points to are already in place.
This is one of six programs inside the AEO pillar and it is deliberately one of the smaller ones, since it depends on the others to matter at all.
The pages an llms.txt links to only get cited if they clear the retrieval and chunking bar covered in AI search visibility so we address that before curating a link list.
A canonical link list is a weaker signal than machine-readable data confirming who and what a page is, which is the job of schema markup layered onto every linked page.
Once the file is live, whether it correlates with any change in citation behavior gets tracked under AI citation tracking so the claim of impact stays honest.
None of this is reachable by a crawler in the first place unless the site renders on the first request, which is the guarantee behind application frontends built with server rendering rather than client-only JavaScript.
Questions
We generate it from your routes, not from a text editor someone forgets to reopen.