llms.txt For Universities: What To Publish And What To Leave Out

Seven of the 64 UK universities we audited publish an llms.txt file. Five of those seven run the same content platform, which suggests the file arrived with a template rather than a decision.

That is the honest starting point for this question. llms.txt is not yet a ranking factor, and no major answer engine has committed to reading it. It is still worth publishing, for a reason that has nothing to do with the file itself: writing one forces an institution to decide which pages are the authoritative answer to an applicant's question. Most universities have never made that decision, and it shows in what ChatGPT, Gemini, and Perplexity say about them.

This is a practical guide: what the file is, what to put in it, what to keep out, and where it sits relative to the two things that matter more. The numbers throughout come from our audit of 64 UK higher education websites, run in August 2026.

What is llms.txt?

llms.txt is a single plain text file at the root of a domain, at example.ac.uk/llms.txt, written in Markdown. It gives a large language model a short, curated map of the pages that carry the authoritative version of your key facts, with a one line description of the institution at the top.

It is not a sitemap. A sitemap lists everything you have; llms.txt lists what you want quoted. It is not an access control either. Nothing in the file grants or withholds permission, and no answer engine is obliged to fetch it.

llms.txt is a curation layer. robots.txt controls permission, structured data carries meaning, and llms.txt says where the authoritative version lives.

What the audit found across 64 UK institutions

We checked every institution for the signals an answer engine relies on when it composes a response about courses, fees, and entry requirements. The pattern is consistent, and it is not a pattern of universities blocking AI. It is a pattern of nobody having decided anything.

Read the bottom two bars against the top three. Publishing llms.txt while fees sit in a client rendered widget or a PDF gives an answer engine a signpost pointing at a page it cannot read. The file is the last step in the sequence, not the first.

The full institution by institution table, the platform breakdown, and the regional splits are in the state of AI discoverability in UK higher education report.

Where llms.txt sits relative to robots.txt and structured data

Three files, three different jobs. Teams tend to treat them as alternatives, and then wonder why an answer engine still quotes a third party ranking site for their own tuition fees.

The failure we saw most often is the first card. An institution allows AI agents in robots.txt while the CDN or bot management layer turns those same agents away, so the policy in the repository and the behaviour at the edge disagree. Eleven percent of the institutions we audited block at least one answer engine at the edge, and in every case nothing in the CMS said so.

That is a platform question before it is a content question, which is why we treat it as platform engineering work rather than an SEO task.

What to publish in a university llms.txt

Keep it short enough that a person can read the whole file in a minute. If it grows past roughly 50 links, it has stopped being a curation layer.

Publish the pages an applicant asks about, in the order they ask:

• A one line description of the institution: type, location, scale, and the entry year the file covers.
• Course index pages, split into undergraduate and postgraduate, each linking on to individual course pages.
• Tuition fees for home and international students, accommodation prices, and funding or scholarship pages.
• Entry requirements, including international qualification equivalences, which is the single most asked question we see in applicant journeys.
• Term dates, Clearing information, and how to apply.
• The canonical contact route for applicant enquiries, so an answer engine does not surface a departmental inbox.

What to leave out

The exclusions matter more than the inclusions, because a curated file that leaks the wrong page is worse than no file at all.

• Anything behind a login: applicant portals, the student record system, the VLE.
• Staff intranet pages and internal policy libraries. These are often crawlable by accident, and listing them makes that worse.
• Fee schedules and course pages not yet approved for publication. A file at the domain root is a publication, and it will be read as one.
• Any page carrying personal data about students, staff, or applicants.
• Embargoed research and pre publication material.
• Duplicate PDFs of pages you have already listed. Point at the HTML version, always.

The sequence that actually changes what answer engines say

Publishing the file is a half day of work. The sequence around it is where the outputs move. In the order we run it:

• Reconcile the edge with the policy. Check what your CDN and bot management actually do with GPTBot, ClaudeBot, PerplexityBot, and Google-Extended, then make robots.txt say the same thing.
• Server render the facts. Fees, entry grades, accommodation prices, and term dates need to exist in the HTML an agent receives, not in a widget that loads afterwards.
• Mark up what is there. Course, Organization, and FAQPage structured data on the pages that answer applicant questions. Only 6% of the institutions we audited publish FAQPage data anywhere.
• Then publish llms.txt, pointing at the pages you have just made readable.
• Put a review date on it. A rebrand, a course catalogue change, or a fee update makes the file wrong, and a stale llms.txt is a confident wrong answer.

Steps two and three are content and platform work, not marketing work, which is why they usually stall. We wrote about why that sequencing keeps breaking in composable DXP programs, and the same dependency chain applies here: the operating model decides whether the markup ever ships.

How to tell whether it is working

Answer engines do not report impressions, so the measurement has to be behavioural. Three things worth tracking:

• Ask the engines directly, on a schedule, using the questions applicants ask: fees for a named course, entry requirements from a named qualification, accommodation costs. Record whether the answer cites you or a ranking aggregator.
• Watch referral traffic from chatgpt.com, perplexity.ai, and Gemini in your analytics, segmented to course and fees pages.
• Watch the shape of enquiries. When answer engines start quoting your own fee pages, the questions arriving at admissions get more specific.

Our AI visibility audit runs the first of those three against your domain and returns what each engine currently says about your institution, alongside the crawl, markup, and edge findings behind it.

Frequently asked questions

Does ChatGPT read llms.txt?

There is no public commitment from OpenAI, Anthropic, Google, or Perplexity to fetch llms.txt, and we have seen no evidence of it in server logs. Publish it as cheap insurance and as a forcing function for the curation decision, not as the intervention that changes your visibility.

Is llms.txt a replacement for robots.txt?

No. robots.txt is the only one of the three that carries a permission signal, and it is the one that needs to match what your edge actually does.

Where does the file go?

At the domain root, as example.ac.uk/llms.txt, served as text/plain. If your institution runs separate subdomains for research or a business school, each subdomain needs its own file.

How long should a university llms.txt be?

Short. A page or two of Markdown, structured under a handful of headings. If it lists every course page individually it has become a sitemap, and it will go stale on the next catalogue update.

Who should own it?

Digital or web team, with admissions signing off on which pages are authoritative. Treat it like the homepage: a small number of people can change it, and every change is reviewed.

Start with what the engines already say

The file is the easy part. The decision underneath it, which page is the authoritative answer to each applicant question, is the part that improves how answer engines describe your institution. If you want the current picture for your own domain, run the AI visibility audit or read the full 64 institution report. We also work with higher education institutions on the discoverability and content design work that sits behind it, and you can always talk to us about where your estate stands.

Read next

llms.txt is the curation layer. The layer underneath it is the markup that makes each page quotable in the first place: structured data for university course pages covers which schema types answer applicant questions about fees, entry grades, and start dates, and the four places that chain breaks.

And before either layer: the numbers themselves. Publish fees, entry requirements and accommodation costs so answer engines can read them covers the delivery problem underneath all of this, including the finding that none of the 64 institutions published weekly room prices in crawlable HTML.

None of it is read if the fetch is refused first. AI crawler policy for higher education covers the layer above all three: 92 percent of audited institutions name no AI crawler in robots.txt, and 11 percent block answer engines at the network edge without deciding to.