---
title: "llms.txt For Universities: What To Publish And What To Leave Out"
url: https://www.axelerant.com/blog/llms-txt-for-universities
published: 2026-09-03T09:30:00.000Z
author: "Neha Malik, Growth Marketer"
industries: Education
lenses: Experience, Data, Activation, Optimization
source: Axelerant Thinking
---

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

> Only 7 of 64 audited UK universities publish llms.txt. What to include, what to exclude, and how it differs from robots.txt and structured data.

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](/uk-highered-ai-discoverability), 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.

![Bar chart of machine-readability signals across 64 UK higher education websites: 92% name no AI crawler in robots.txt, 46% publish no structured data, 45% keep course fees out of rendered HTML, 11% publish llms.txt, 6% publish FAQPage data](/images/insights/llmstxt-highered-audit-findings.png)

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](/uk-highered-ai-discoverability) 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.

![Comparison of robots.txt for crawl permission, structured data for page meaning, and llms.txt for curation, all feeding an answer engine response](/images/insights/llmstxt-robots-schema-layers.png)

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](/what-we-do/engineering/platform) 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.

![Annotated example of a university llms.txt file alongside two lists: what to publish, including course indexes, fees, entry requirements and term dates, and what to leave out, including applicant portals, staff intranet, unapproved fee schedules and personal data](/images/insights/llmstxt-university-file-anatomy.png)

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](/blog/composable-dxp-content-operations), 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](/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.

## The prerequisite, seen at the University of East London

An llms.txt file is a pointer to canonical, machine readable facts. If those facts are not systematic, the file points at pages that disagree with each other. The University of East London engagement predates llms.txt, but it built exactly that prerequisite: automated updates for course data, fees, funding and application deadlines, delivered through reusable content blocks so one figure appears identically wherever it is used, on Drupal with Acquia underneath.

That is the sequence we would recommend before writing a line of llms.txt. Establish one owner page per course, feed it from a source that updates itself, then publish a pointer to it. Doing it the other way round advertises stale numbers with more confidence. The platform work is documented in the [University of East London case study](/case/dxp-for-university-of-east-london).

## 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](/ai-visibility-audit) or read the [full 64 institution report](/uk-highered-ai-discoverability). We also work with [higher education institutions](/industries/higher-ed) on the [discoverability](/what-we-do/revops-and-growth/discoverability) and [content design](/what-we-do/design/content-design) work that sits behind it, and you can always [talk to us](/contact) 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](/blog/structured-data-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](/blog/publish-course-facts-answer-engines) 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](/blog/ai-crawler-policy-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.

And the substrate underneath all of it: [WCAG 2.2 for university websites](/blog/wcag-2-2-university-websites), where the accessibility backlog and the AI readability backlog turn out to be the same list.

An llms.txt file decays for the same reason a compliance document does. [Accessibility statements in higher education](/blog/accessibility-statements-universities) covers the release triggers that keep either one accurate.

A file at the root cannot fix a template. [University website design](/blog/university-website-design) covers where a design decision actually lands, and [SEO for universities](/blog/seo-for-universities) reads the audit findings as a search backlog.

Three companion pieces take the same evidence into planning: [higher education digital strategy](/blog/higher-education-digital-strategy), [choosing a CMS for a university estate](/blog/university-cms-estate) and [student recruitment marketing](/blog/student-recruitment-marketing).

Working on a university estate rather than a single page? Our [higher education practice page](/industries/higher-ed) sets out how the strategy, design, engineering and marketing work runs as one team, and the [UK higher education AI discoverability report](/uk-highered-ai-discoverability) holds the audit data behind this series.

For the same audit read as a marketing diagnosis, see [higher education marketing: what an audit of 64 UK university websites reveals](/blog/higher-education-marketing).

---

Read on the web: https://www.axelerant.com/blog/llms-txt-for-universities