Sector research
64 UK institutions · audited August 2026
The state of AI discoverability in UK higher education
Prospective students are asking ChatGPT, Gemini and Perplexity about universities before they ever visit a university website. We tested whether 64 UK institutions can actually be read by those systems. Most cannot, and almost none of them chose that.
Axelerant · Independent research, produced without vendor sponsorship. Every finding is reproducible, and the method is published in full at the end.
- 92%
- name no AI crawler at all
- 46%
- publish no structured data
- 45%
- no fees in rendered HTML
- 11%
- block AI at the edge, invisibly
Read it end to end, or jump to the chapter you own
- 00A decision that nobody madeWe went looking for universities blocking AI. We found almost no decisions at all.
- 01The policy that was never written92% name no AI crawler in robots.txt. Four institutions have stated a position.
- 02The invisible block11% turn answer engines away at the network edge, and nothing in the CMS says so.
- 03Nothing to extract46% publish no structured data. Only 6% publish FAQPage.
- 04The questions applicants actually ask45% keep fees out of server-rendered HTML. Nobody publishes room prices in HTML.
- 05Early, and mostly done badlySeven institutions publish one. One shipped unedited model output.
- 06The platform landscapeTerminalFour leads. Higher-ed-specific platforms fail at the same rate.
- 07One institution got this rightHand-written, commented, dated. The differentiator was ownership, not budget.
- 08Delivery evidenceUniversity of East London and Regent's University London, named with permission.
- 09What to do about itSeven actions in order, with honest effort estimates and an owner for each.
- 10All 64 institutionsAnonymized results across seven checks, filterable by region.
- 11What we did, and could not doSeven read-only checks, stated denominators, and the bias in our coverage gap.
This report is about a decision that nobody made.
In short
- Applicants now ask assistants about fees, entry requirements and accommodation before they visit a university website.
- We ran the same seven technical checks against 64 UK institutions in August 2026.
- We expected to find deliberate blocking. We found an accountability gap instead.
Over the past two years, the first place a prospective student asks about a university has quietly moved. Not entirely, and not for everyone, but enough that it now matters commercially. They ask an assistant. They ask it what they can study, what the entry requirements are, what it costs, and whether they will be sharing a bathroom. And the assistant answers, whether or not the university is in a position to supply that answer.
We wanted to know how well UK higher education is positioned for that. So we ran the same seven technical checks against 64 UK institutions, the band where most of the sector actually sits.
The result is not the one we expected. We went looking for institutions blocking AI. We found something duller and more consequential: almost none of them have made any decision at all.
92%
of institutions do not name a single AI crawler in their robots.txt, neither to allow one nor to block one.
Forty-eight of the fifty-two institutions whose robots.txt we could read mention no AI crawler whatsoever. Not GPTBot, not OAI-SearchBot, not PerplexityBot. The file has been left as it was written for a search landscape that no longer exists on its own.
That is not negligence. It is an accountability gap. Nobody in the sector was ever asked to own this, so nobody did.
Eight numbers from 64 institutions
92%
name no AI crawler at all
46%
publish no structured data whatsoever
20%
have Course schema on course pages
6%
have FAQPage schema
11%
block AI crawlers at the edge, invisibly
11%
publish an llms.txt
45%
no course fees in server-rendered HTML
0%
block AI search crawlers in robots.txt
- Names no AI crawler in robots.txt
- 92%
- Publishes no structured data
- 46%
- No course fees in rendered HTML
- 45%
- No entry requirements in rendered HTML
- 34%
- Blocks AI crawlers at the edge
- 11%
- Publishes an llms.txt
- 11%
- Has FAQPage schema
- 6%
- Blocks AI search crawlers in robots.txt
- 0%
Each figure is calculated against the institutions where that check returned a verifiable answer. Orange bars are gaps, grey bars are positive or deliberate states. Source: Axelerant audit, August 2026.
The finding we did not expect
Not one institution in the sample blocks AI search crawlers in robots.txt. Zero out of fifty-two. The narrative that universities are deliberately shutting answer engines out is simply not true.
What we found instead
The blocking that does exist is accidental, sits at the network edge rather than in robots.txt, and is invisible to the people who would care about it most.
The policy that was never written
In short
- 48 of the 52 readable robots.txt files name no AI crawler, in either direction.
- Not one institution blocks AI search crawlers in robots.txt. The blocking narrative is wrong.
- Four institutions have stated a position, and only one separates training, answer-engine and user-fetch crawlers.
- The cause is ownership: the file sits between marketing and IT, so nobody edits it.
A robots.txt file is where a website states which automated systems may read it. It is a public declaration, trivially editable, and it takes a few minutes to change.
Of the 52 institutions whose file we could read, four name an AI crawler. The other 48 do not. In practice this means every AI vendor applies its own default, and those defaults change without notice, without consultation, and without anyone at the institution being told.
The four who have made a decision are worth examining, because they show the range.
| Approach | What they did | Our read |
|---|---|---|
| Deliberate and correct | Blocks seven training crawlers, while leaving all five answer-engine and user-fetch agents reachable. The file is commented and dated. | This is the model. It protects training data without sacrificing discoverability, and someone clearly thought about it. |
| Partial | Blocks only ClaudeBot and anthropic-ai, leaving everything else unmentioned. | A decision about one vendor, not a policy. |
| Path restrictions only | Names three AI agents but only restricts specific directories. | Reasonable. Content remains reachable. |
| Training blocked, search untouched | Blocks six training crawlers, plus a Content-Signal: ai-train=no header. | Defensible, but the pattern strongly suggests a vendor dashboard toggle rather than an authored policy. |
Why this file, of all files, goes unowned
When we take on a university engagement, robots.txt is almost never in anyone's job description. Marketing assumes it is technical and therefore IT's. IT assumes it is about content and therefore marketing's. It usually sits in a repository that marketing cannot edit and that IT has no reason to open.
So the file ages in place. The last person to touch it was often an agency, on a project that closed years ago. That is the mechanism, and it is worth naming because the fix is organizational before it is technical: somebody has to be told this is theirs.
The distinction almost nobody is making
Training crawlers
GPTBot, ClaudeBot and CCBot collect content to train models. Blocking them is a legitimate institutional position with a real argument behind it, and it costs very little in recruitment terms.
Answer-engine crawlers
OAI-SearchBot and PerplexityBot are what put you in a live answer when a student asks a question today. Blocking these removes you from the conversation entirely.
User-fetch agents
ChatGPT-User fetches a page because a human explicitly asked about it. Blocking these means that even when an applicant pastes your own link into ChatGPT, the assistant cannot read your page.
One institution in 64 has separated these three categories in writing.
The invisible block
In short
- Six institutions, 11% of the valid sample, return errors to AI crawlers while serving browsers and Googlebot normally.
- None of it appears in robots.txt, so marketing teams have no way of seeing it.
- A challenge page reads as "nothing to say", not as "declined to participate".
- The fix is hours of bot-management configuration, not a project.
Six institutions, 11% of those we could validly test, return an error to AI crawlers at the network edge while serving ordinary browsers and Googlebot perfectly normally. None of it appears in their robots.txt.
Four of the six block every major agent we tested. For those four institutions, every significant answer engine is looking at a challenge page.
These sites look completely healthy in Google. Their marketing teams have no way of knowing, because nothing in the CMS, the analytics or the robots.txt reveals it.
This is almost always a bot-management setting: a firewall rule, or a "block AI scrapers" toggle in a CDN dashboard, enabled at some point by somebody in IT or security acting entirely reasonably on the information available to them. Nobody involved was thinking about student recruitment, because that was not their job.
It is also the single cheapest thing in this report to fix. It is a configuration change measured in hours.
Why an edge block is worse than a robots.txt block
A crawler that reads robots.txt and finds itself disallowed goes away cleanly. A crawler that receives a JavaScript challenge page receives what looks like a valid response containing no content. Answer engines do not solve challenges and do not retry.
The practical result is not "this university declined to participate." It is "this university appears to have nothing to say." The assistant then answers from league tables, forum posts and third-party ranking sites instead.
What fixing it actually involves
The correction is narrower than people expect, and the wording matters. You do not want to switch bot management off, because it is doing real work against scrapers and credential stuffing. You want the answer-engine agents moved onto the verified-bot allow list, with rate limits rather than challenges applied to them.
That distinction is the whole fix. A rate limit slows a crawler down. A challenge returns a page with no content in it. One costs you nothing, the other costs you the answer. Then replay the request with each user-agent afterwards to confirm the rule behaves as intended. We have seen allow-list entries that silently failed because the agent string did not match.
The bigger problem: nothing to extract
In short
- 46% of readable institutions publish no JSON-LD at all.
- Only 20% carry Course schema, and only 6% carry FAQPage, the type answer engines lean on most.
- One institution's course schema is invalid because the type is lowercase.
- Schema belongs in the course template, and it has to be validated after deployment.
Blocking is dramatic but rare. The structural gap is neither, and it affects far more institutions.
Answer engines prefer facts they can attribute with confidence. Structured data is how a page states unambiguously that it describes a course, who provides it, when it runs and what it costs.
Nearly half of the institutions we could read publish no JSON-LD whatsoever. Only three institutions in the entire sample, 6%, publish FAQPage, which is the schema type answer engines draw on most directly for question-shaped queries. Student queries are almost entirely question-shaped.
One institution publishes course schema that is invalid: the type is written in lowercase, and Schema.org types are case-sensitive. The markup exists, someone built it, and it validates as nothing at all.
Only one institution in five publishes course structured data
- Course schema
- 20%
- Some schema, no Course type
- 34%
- No structured data at all
- 46%
Base: 54 institutions where the page could be read. Source: Axelerant audit, August 2026.
- No structured data at all
- 25 · 46%
- Some schema, no Course type
- 18 · 34%
- Course schema present
- 11 · 20%
Only three institutions in the whole sample, 6%, publish FAQPage. Source: Axelerant audit, August 2026.
Why schema decays, and where to put it
Schema added page by page does not survive. Schema added to a course template does, because it inherits from the content model rather than depending on an editor remembering. That is the difference between a fix that holds for three years and one that degrades the first time somebody launches a new programme.
The step almost everyone skips is validation after deployment. The invalid lowercase type we found in this sample is exactly what that omission produces: markup that exists, was paid for, and does nothing. It takes minutes to catch and nobody looks.
The questions applicants actually ask
In short
- 45% do not have course fees in server-rendered HTML, and 34% are missing entry requirements.
- Not one institution publishes weekly accommodation prices in crawlable HTML.
- Seven split their course estate across a second domain.
- Fees go missing for an organizational reason: a different team owns them on a different cycle.
We took one representative course page per institution and checked whether the facts an applicant needs are present in the server-rendered HTML, meaning the version a crawler sees rather than the version a human sees after JavaScript has run.
| What a prospective student asks | Not answerable from raw HTML |
|---|---|
| What does this course cost? | 24 of 53 · 45% |
| What are the entry requirements? | 18 of 53 · 34% |
| Where do I even find the courses? | 7 institutions split their course estate across a second domain |
- Weekly accommodation prices
- 0 institutions publish them
- Course fees
- 24 of 53 · 45%
- Entry requirements
- 18 of 53 · 34%
- Course estate on a second domain
- 7 institutions
Bars show the share of institutions where the fact is not readable by a crawler. Source: Axelerant audit, August 2026.
Fees are the single most common question in the UK admissions funnel and the most likely to be missing. Where fees do appear, they are frequently in a tabbed component, a downloadable PDF, or a fees table on an entirely separate page from the course.
Accommodation is worse. We looked at accommodation pages across the sample and could not find one publishing weekly room prices in crawlable HTML. Whether a room is en-suite or has shared bathrooms, a question that genuinely decides offers, is routinely locked in a PDF or behind a booking portal login.
A student can ask an assistant whether they will be sharing a bathroom. No institution in this sample is in a position to have that answered from their own website.
Why fees in particular go missing
There is a consistent organizational reason for this, and it is not carelessness. Fees are almost always owned by a different team than course content, finance or admissions rather than marketing, and they change on a different cycle. So they get published where their owner can control them: a central fees table, a PDF, or a tab loaded from another system. Each of those decisions is locally sensible and collectively fatal.
This is also where discoverability and conversion stop being separate problems. When we baseline an admissions funnel, the drop between viewing a programme and starting an application is consistently one of the largest in the journey, and unclear cost is consistently among the reasons. The same fact being unreachable by a crawler is unreachable by a hesitant applicant at 11pm. One change addresses both.
llms.txt, early and mostly done badly
In short
- Seven institutions in 64 publish an llms.txt, which is ahead of the curve for a convention this young.
- One of the seven shipped unedited model output, citation artefacts included.
- No vendor is obliged to honor the file, so treat it as cheap insurance rather than a fix.
- The real value is the internal argument about which thirty pages represent the institution.
An llms.txt file is an emerging convention: a short curated map of the pages you would like an assistant to rely on. No vendor is obliged to honor it, and some do not. It is cheap insurance rather than a fix.
Seven institutions in 64 publish one. That is 11%, which for a convention this young is arguably ahead of the curve.
But one of the seven pasted theirs directly out of ChatGPT without reading it. The file is live, in production, and still contains the model's own citation artefacts, eight times over.
We are not naming them, and we do not think it is embarrassing. It is the most honest artefact in this research: somebody understood the problem, moved faster than their review process, and shipped. That is a better failure than not trying.
The reason we recommend it anyway has little to do with the vendors. Writing one forces an institution to decide which thirty pages actually represent it, and that argument, held between marketing, admissions and faculty, is more valuable than the file. Every time we have run it, something surfaced that nobody realized was still live.
The platform landscape
In short
- TerminalFour is the most common platform at 30% of the readable sample.
- Institutions on higher-ed-specific platforms fail these checks at broadly the same rate as everyone else.
- AI discoverability is a content-structure and configuration discipline, not a CMS feature.
- None of the findings in this report require a replatform.
Platform is context rather than cause. Every finding in this report is fixable on the platform the institution already runs. But the distribution is worth recording, because it tells you where fixes have to land.
One primary platform per institution, so the column sums to the readable sample of 54. A further 10 institutions could not be read at all. "Not identifiable" means the page was readable but carried no platform signature we could match, which is common on bespoke builds and on heavily proxied estates.
- TerminalFour
- 16 · 30%
- Not identifiable from public markers
- 15 · 28%
- Contensis
- 8 · 15%
- WordPress
- 4 · 7%
- Sitecore
- 3 · 6%
- Acquia Cloud
- 3 · 6%
- Craft CMS
- 2 · 4%
- Squiz Matrix, Drupal, Optimizely
- 3 · 6%
One primary platform per institution. A further 10 institutions could not be read at all.
Higher-ed-specific platforms are not solving this
TerminalFour is the most common platform in the sample by a wide margin, and it is built specifically for universities. Institutions running it fail these checks at broadly the same rate as institutions running general-purpose systems.
That is not a criticism of any vendor. It is evidence that AI discoverability is not a CMS feature. It is a content-structure and configuration discipline, and no platform ships it switched on.
When modernization is the answer, and when it is not
We do platform migrations for a living, so it is worth being straight about this: none of the findings in this report require one. Every one of them is a configuration change, a template change, or a content change on the platform an institution already runs.
Where modernization genuinely earns its place is when the constraint is structural rather than cosmetic: a content model that cannot express a course as a course, so no amount of schema will describe it properly; an estate fragmented across a dozen systems where each one needs fixing separately and forever; or a platform whose vendor has stopped shipping the standards the work depends on. Those are real, and they are a different conversation from this report.
If somebody responds to a discoverability problem by quoting you a replatform, ask them which of the seven checks in this report the new platform fixes on its own. The honest answer is none of them.
What good looks like
In short
- One institution has a hand-written, commented, dated robots.txt with a review date.
- It states a separate position on training, answer-engine, user-fetch and analytics agents.
- No large budget was involved. The difference is that one person was made accountable.
One institution in this research has clearly thought the whole problem through, and it is worth describing precisely because it proves this is achievable by an ordinary university team without a large budget.
Their robots.txt is hand-written and commented. It carries a review date. It separates AI crawlers into categories and states a position on each: training crawlers blocked, answer-engine and user-fetch crawlers allowed, traditional search engines allowed, analytics tools named individually.
Somebody sat down, worked out what the categories were, decided what the institution wanted, and wrote it down where it takes effect. That is the entire intervention. It is not expensive and it is not technically difficult. It is simply owned.
The gap between the best institution in this sample and the median is not budget, headcount or platform. It is that one person was made responsible.
What it is worth fixing
In short
- This is delivery evidence from our own client work, not a sector benchmark. Both institutions agreed to be named.
- University of East London: +73% applications and +32% enrolments after a platform rebuild plus a funnel programme.
- Regent's University London: answer-engine visibility inside a single content migration cycle, and still in flight.
- We are explicit about attribution. Neither number is the return on discoverability work alone.
We are deliberately careful here, because this is a discoverability study and we do not hold conversion data for the 64 institutions in it. Nobody does. What follows is evidence from our own delivery work in the sector, offered as an indication of scale rather than a sector benchmark. Both institutions have agreed to be named.
Delivery evidence
University of East London
UEL was losing students, and their website was working against them. We rebuilt the platform, moving from Sitecore to Drupal on Acquia Cloud, and then ran a structured conversion programme across the admissions funnel.
The rebuild was the smaller half. The programme that followed mapped every drop-off point between the homepage and a submitted application, established a baseline for each step, and then scored every candidate fix by impact, effort and value before anyone wrote code. Geo-personalization served more than 17,000 students across 100 countries.
- +73%
- applications
- +32%
- enrolments
- +30%
- relevant traffic
- 3x
- faster publishing
Accessibility moved to WCAG 2.1 AA compliance across the estate, and a centralized editorial workflow replaced a fragmented one. The full case study is published here.
To be clear about attribution: those numbers came from platform work, funnel optimization and content governance together. It would be dishonest to present them as the return on discoverability work alone. The narrower point is that the admissions funnel responds to deliberate, measured attention, and the numbers involved are material rather than marginal.
Delivery evidence
Regent's University London
The second engagement is more directly relevant to this report, and it is currently in flight.
Regent's is a premium boutique university in central London, part of the Galileo Global Education group. It engaged us to move its website from an informational estate to a conversion-focused one, with SEO and generative-engine optimization designed into the content migration rather than bolted on afterwards. The work includes a full information architecture rebuild, a differentiated content framework by course type, and a post-launch conversion programme contracted from the outset.
The institution's own framing of the starting point, from discovery, was that SEO had not historically been a focus and there was no cohesive SEO and generative-engine strategy. Their marketing team had been formalized only in late 2024, a small group covering design, video and content.
During the engagement, Regent's was observed ranking on Gemini and Google AI for a competitive undergraduate business course query, the kind of high-intent question a prospective student actually asks. Not from a separate AI project, and not from a platform change, but from structured content work done by a team of a handful of people.
Why we mention it while it is unfinished
Because early is the honest way to present it. The rebuild launches as an MVP ahead of the January 2027 intake, the conversion programme has not yet run, and we are not going to imply a completed transformation. What has been demonstrated is narrower and still worth saying: content migration done with generative-engine optimization designed in produced measurable answer-engine visibility inside a single project cycle.
On the ranking specifically, generative search results are volatile in a way traditional rankings are not. That observation was made during the engagement and we are reporting it as such, rather than as a guaranteed current state. Anyone is welcome to check it, including us.
What to do about it
In short
- Clear edge blocking first, or every later fix becomes unattributable.
- Write an actual AI crawler policy, and decide separately on training, answer-engine and user-fetch agents.
- Then get fees and entry requirements into server-rendered HTML and schema into course templates.
- Four of the seven actions take minutes to hours and need no procurement.
In the order we would actually do them, with honest effort estimates.
| # | Action | Effort | Who owns it |
|---|---|---|---|
| 1 | Check whether your edge is blocking answer engines. Request your own homepage with an OAI-SearchBot user-agent and compare the response to a browser. If it differs, someone has made a recruitment decision inside a security tool. | Minutes | IT |
| 2 | Write an actual AI crawler policy. Decide separately on training, answer-engine and user-fetch crawlers. Put it in robots.txt, comment it, and date it. | Hours | Marketing, with IT |
| 3 | Put fees and entry requirements in server-rendered HTML. Not a tab that loads on click, not a PDF, not a separate fees table three clicks away. | Weeks | Web and content |
| 4 | Add Course, CourseInstance, Offer and FAQPage schema to course templates. Template-level work, done once, applies everywhere. Validate it afterwards. | Weeks | Development |
| 5 | Get accommodation detail out of PDFs. Room types, bathroom arrangements and weekly prices as HTML pages, with the PDF as a download rather than the source of truth. | Weeks | Accommodation, with web |
| 6 | Publish an llms.txt. Cheap, and it forces a genuinely useful internal argument about which thirty pages actually represent the institution. Read it before you ship it. | Hours | Marketing |
| 7 | Give it an owner. The single largest differentiator in this research was not budget or platform. It was whether one named person was accountable. | One conversation | Executive |
One note on sequence
Do items 1 and 2 before anything else, and not because they are quickest. Adding schema to a site whose edge is challenging answer engines produces no measurable change at all, and the team that did the work concludes structured data does not matter. We have watched that happen. Clear the blocking first, so everything after it can be attributed.
The reassuring part
Items 1, 2, 6 and 7 are between minutes and hours of work, and require no procurement, no replatform and no capital expenditure. In a sector where roughly 45% of English providers are projecting deficits for 2025-26, that matters: the highest-severity findings in this report are also the cheapest to fix.
92%
Name no AI crawler in robots.txt
48 of 52 · robots.txt readable
0%
Block AI search crawlers in robots.txt
0 of 52 · robots.txt readable
11%
Block AI crawlers at the network edge
6 of 54 · valid browser control obtained
46%
Publish no JSON-LD at all
25 of 54 · page readable
20%
Have Course schema on course pages
11 of 54 · page readable
6%
Have FAQPage schema
3 of 54 · page readable
45%
No course fees in server-rendered HTML
24 of 53 · course page identified
34%
No entry requirements in server-rendered HTML
18 of 53 · course page identified
11%
Publish an llms.txt
7 of 64 · all institutions
13%
Split course estate across a second domain
7 of 54 · page readable
0%
Weekly accommodation prices in crawlable HTML
0 of 64 · all checked
Check 1
AI crawler policy
- robots.txt readable
- 52 of 64 · 81%
- Names no AI crawler at all
- 48 of 52 · 92%
- Names at least one
- 4 of 52
- Blocks AI search crawlers
- 0 of 52
Of the four who stated a position: one blocked seven training crawlers and deliberately left all five answer-engine and user-fetch agents reachable. One named two Anthropic agents only. One used path restrictions across three named agents. One blocked six training crawlers plus a Content-Signal ai-train=no header, and left the answer engines untouched.
Check 2
Edge and WAF behaviour
- Valid browser control obtained
- 54 of 64 · 84%
- No valid control, cannot conclude
- 10 of 64 · 16%
- Edge-blocking at least one AI crawler
- 6 of 54 · 11%
- Blocking all five agents tested
- 4 institutions
Agents blocked across the six affected institutions: GPTBot, OAI-SearchBot, ChatGPT-User, PerplexityBot, ClaudeBot. One blocks ClaudeBot only. One blocks OAI-SearchBot, PerplexityBot and ClaudeBot but serves GPTBot, which is the opposite of a stated policy.
Check 3
Structured data
- No JSON-LD at all
- 25 of 54 · 46%
- Schema present but no Course type
- 18 of 54 · 34%
- Course schema present
- 11 of 54 · 20%
- FAQPage present
- 3 of 54 · 6%
- Structurally invalid schema
- 1 institution
The invalid case used a lowercase @type, which validates as nothing at all.
Check 4
Course page extractability
- Course page identified
- 53 of 54 · 98%
- No fees in raw HTML
- 24 of 53 · 45%
- No entry requirements in raw HTML
- 18 of 53 · 34%
- Course content JavaScript-injected
- 0 of 53
- Course estate on a second domain
- 7 institutions
JavaScript is not the villain here. The facts are simply not on the page.
Check 5
PDF dependency
- Weekly accommodation prices in crawlable HTML
- 0 institutions
Key applicant information is routinely held in PDFs rather than HTML. Accommodation pricing is the clearest case: not one institution in the sample published weekly room prices in a form an assistant can read.
Check 6
llms.txt
- Publishing one
- 7 of 64 · 11%
- Of those, containing unedited AI output
- 1
Check 7
Platform fingerprint
- TerminalFour
- 16 · 30%
- Not identifiable from public markers
- 15 · 28%
- Contensis
- 8 · 15%
- WordPress
- 4 · 7%
- Sitecore
- 3 · 6%
- Acquia Cloud
- 3 · 6%
- Craft CMS
- 2 · 4%
- Squiz Matrix, Drupal, Optimizely
- 3 · 6%
Primary platform, one per institution, across the readable sample of 54.
- Critical
- 7
- High
- 120
- Medium
- 46
- Low
- 47
220 findings across 64 institutions.
- No AI crawler policy stated
- 48 institutions
- No llms.txt
- 47 institutions
- Course facts missing from server-rendered HTML
- 28 institutions
- No FAQPage schema
- 26 institutions
- No structured data at all
- 25 institutions
- Schema present but no Course type
- 18 institutions
- Could not be read, reported unverified
- 10 institutions
- Course estate split across domains
- 7 institutions
Base: 64 institutions.
| Institution | Region | AI policy | Edge | JSON-LD | Course | FAQPage | Course facts | llms.txt | Platform |
|---|---|---|---|---|---|---|---|---|---|
| Institution 01 | North & Midlands | none stated | clear | yes | no | no | both present | no | not identified |
| Institution 02 | North & Midlands | none stated | BLOCKS 5 | no | no | no | both present | no | Craft CMS |
| Institution 03 | North & Midlands | none stated | clear | yes | no | no | both present | no | not identified |
| Institution 04 | North & Midlands | stated | clear | yes | no | no | missing entry+fees | no | not identified |
| Institution 05 | North & Midlands | none stated | clear | yes | no | no | missing entry+fees | yes | TerminalFour |
| Institution 06 | North & Midlands | none stated | clear | yes | yes | no | both present | yes | not identified |
| Institution 07 | North & Midlands | none stated | BLOCKS 1 | no | no | no | missing fees | no | TerminalFour |
| Institution 08 | North & Midlands | none stated | clear | yes | no | no | missing entry | no | Contensis |
| Institution 09 | North & Midlands | unverified | clear | yes | no | no | both present | no | WordPress |
| Institution 10 | North & Midlands | none stated | clear | no | no | no | missing fees | no | not identified |
| Institution 11 | North & Midlands | none stated | clear | no | no | no | missing entry+fees | no | not identified |
| Institution 12 | North & Midlands | none stated | clear | no | no | no | missing entry+fees | no | TerminalFour |
| Institution 13 | North & Midlands | none stated | clear | yes | yes | no | both present | no | Contensis |
| Institution 14 | North & Midlands | none stated | clear | no | no | no | missing entry | no | TerminalFour |
| Institution 15 | North & Midlands | none stated | clear | yes | no | no | missing fees | no | Sitecore |
| Institution 16 | North & Midlands | unverified | clear | no | no | no | both present | no | TerminalFour |
| Institution 17 | North & Midlands | none stated | clear | no | no | no | missing entry+fees | yes | TerminalFour |
| Institution 18 | North & Midlands | stated | clear | yes | no | no | both present | yes | Sitecore |
| Institution 19 | North & Midlands | unverified | unverified | unverified | unverified | unverified | unverified | no | unverified |
| Institution 20 | North & Midlands | none stated | clear | yes | yes | yes | both present | no | WordPress |
| Institution 21 | North & Midlands | none stated | clear | yes | no | no | both present | no | Acquia Cloud |
| Institution 22 | North & Midlands | none stated | clear | no | no | no | both present | no | Contensis |
| Institution 23 | North & Midlands | none stated | clear | yes | no | no | missing entry+fees | no | Contensis |
| Institution 24 | North & Midlands | none stated | clear | no | no | no | both present | no | not identified |
| Institution 25 | North & Midlands | none stated | clear | yes | no | no | both present | no | not identified |
| Institution 26 | North & Midlands | none stated | BLOCKS 5 | yes | yes | no | both present | no | not identified |
| Institution 27 | North & Midlands | none stated | BLOCKS 3 | yes | no | no | missing fees | yes | TerminalFour |
| Institution 28 | North & Midlands | none stated | clear | no | no | no | missing fees | no | Contensis |
| Institution 29 | North & Midlands | none stated | clear | no | no | no | unverified | no | TerminalFour |
| Institution 30 | Scotland, Wales & NI | none stated | clear | no | no | no | missing entry+fees | no | not identified |
| Institution 31 | Scotland, Wales & NI | none stated | clear | yes | no | no | missing entry+fees | no | not identified |
| Institution 32 | Scotland, Wales & NI | none stated | clear | no | no | no | both present | no | Acquia Cloud |
| Institution 33 | Scotland, Wales & NI | none stated | clear | no | no | no | both present | no | TerminalFour |
| Institution 34 | Scotland, Wales & NI | unverified | unverified | unverified | unverified | unverified | unverified | no | unverified |
| Institution 35 | Scotland, Wales & NI | none stated | clear | no | no | no | missing fees | no | not identified |
| Institution 36 | Scotland, Wales & NI | none stated | clear | no | no | no | missing entry+fees | no | Sitecore |
| Institution 37 | Scotland, Wales & NI | none stated | clear | no | no | no | missing entry+fees | no | not identified |
| Institution 38 | Scotland, Wales & NI | none stated | clear | no | no | no | missing entry+fees | no | WordPress |
| Institution 39 | Scotland, Wales & NI | none stated | clear | yes | no | no | missing entry+fees | no | not identified |
| Institution 40 | Scotland, Wales & NI | unverified | unverified | unverified | unverified | unverified | unverified | no | unverified |
| Institution 41 | Scotland, Wales & NI | none stated | clear | yes | no | no | missing fees | no | TerminalFour |
| Institution 42 | Scotland, Wales & NI | unverified | unverified | unverified | unverified | unverified | unverified | no | unverified |
| Institution 43 | Scotland, Wales & NI | none stated | BLOCKS 5 | yes | no | no | both present | no | WordPress |
| Institution 44 | Scotland, Wales & NI | unverified | clear | no | no | no | missing entry+fees | no | TerminalFour |
| Institution 45 | Scotland, Wales & NI | unverified | unverified | unverified | unverified | unverified | unverified | no | unverified |
| Institution 46 | Scotland, Wales & NI | none stated | clear | yes | yes | no | missing entry | no | Squiz Matrix |
| Institution 47 | Scotland, Wales & NI | unverified | unverified | unverified | unverified | unverified | unverified | no | unverified |
| Institution 48 | Scotland, Wales & NI | unverified | clear | no | no | no | both present | no | TerminalFour |
| Institution 49 | South & London | none stated | BLOCKS 4 | yes | yes | no | missing entry+fees | no | Craft CMS |
| Institution 50 | South & London | stated | clear | no | no | no | missing entry | no | TerminalFour |
| Institution 51 | South & London | none stated | clear | yes | yes | no | both present | no | Contensis |
| Institution 52 | South & London | none stated | clear | yes | yes | yes | both present | no | Acquia Cloud |
| Institution 53 | South & London | unverified | unverified | unverified | unverified | unverified | unverified | no | unverified |
| Institution 54 | South & London | unverified | unverified | unverified | unverified | unverified | unverified | no | unverified |
| Institution 55 | South & London | none stated | unverified | unverified | unverified | unverified | unverified | no | unverified |
| Institution 56 | South & London | none stated | clear | no | no | no | missing fees | no | TerminalFour |
| Institution 57 | South & London | none stated | clear | yes | yes | no | both present | yes | TerminalFour |
| Institution 58 | South & London | none stated | clear | no | no | no | missing fees | no | Drupal |
| Institution 59 | South & London | none stated | clear | yes | yes | no | both present | no | Optimizely |
| Institution 60 | South & London | none stated | clear | yes | yes | no | both present | no | Contensis |
| Institution 61 | South & London | none stated | clear | yes | no | no | both present | no | Contensis |
| Institution 62 | South & London | none stated | clear | yes | no | yes | both present | yes | TerminalFour |
| Institution 63 | South & London | stated | unverified | unverified | unverified | unverified | unverified | no | unverified |
| Institution 64 | South & London | none stated | clear | no | no | no | missing fees | no | not identified |
AI policy · "none stated" means robots.txt names no AI crawler at all.
Edge · "BLOCKS n" means n AI agents received an error while a browser control succeeded.
Course facts · whether entry requirements and fees appear in server-rendered HTML.
unverified · the check could not be completed. That is distinct from a negative finding.
What we did, and what we could not do
In short
- 64 UK institutions, seven read-only checks, all from public endpoints, August 2026.
- 54 were fully readable. Percentages state their own denominator, and we never infer absence from a failed request.
- The ten we could not read skew toward aggressive bot management, so this likely understates blocking.
- No audited institution is named, and every check is reproducible at axelerant.com/check.
Sample
64 UK institutions, meaning universities, university colleges and specialist institutions below roughly £250M turnover, across southern England and London, northern England and the Midlands, Scotland, Wales and Northern Ireland. Russell Group and larger civic universities were deliberately excluded, because their resourcing and their problems are different. Turnover was verified from published financial statements where available. Some institutions publish only in non-machine-readable formats and are included on segment classification rather than a verified figure.
What we did
Seven checks per institution, all from public endpoints and all read-only: AI crawler policy from robots.txt; edge behaviour by requesting the homepage with each AI crawler user-agent and comparing against a browser and Googlebot control; structured data by extracting and parsing JSON-LD; course discovery via sitemap and homepage links; course extractability by measuring server-rendered HTML; PDF dependency; and llms.txt presence. We requested public pages only, at a rate-limited pace, and submitted no forms.
Coverage, stated plainly
54 of 64 institutions were fully readable from our infrastructure. Ten were not, because their bot management challenged our requests. Percentages in this report are calculated against the number of institutions where the relevant check returned a verifiable answer, and each figure states its own denominator. We have not inferred absence from a request that failed.
The bias in that gap
The ten institutions we could not fully read are, almost by definition, the ones with more aggressive bot management. That is a systematic rather than random exclusion, and it likely means this report understates how much AI blocking exists in the sector. We would rather say that than quietly drop them from the denominator.
Edge probes and their limits
Edge findings are reported only where a browser control returned successfully. Without a working control, differential blocking cannot be distinguished from our own vantage point being filtered. Probes ran from datacentre addresses using published user-agent strings, whereas production crawlers also arrive from vendor-published IP ranges. Each agent was requested at least twice and reported as blocked only when attempts agreed. We treat these as strong evidence of a rule rather than proof of one.
Anonymity
No institution in the audited sample is named. The purpose of this report is to describe a sector-wide gap, not to embarrass individual universities for a configuration nobody asked them to own. The two institutions named in section eight are our own clients, cited with permission as delivery evidence, and were not part of the 64-institution sample.
Reproducibility
Every check here can be run against any domain, by anyone, in about a minute, using the free tool at axelerant.com/check. We would rather you verified this than believed it.
Axelerant
Axelerant is a digital engineering agency of roughly 150 people across 12 countries. We work on content platforms, conversion and discoverability, and higher education is one of the sectors we work in most.
Why we ran this study. We kept finding the same problems in individual university engagements, an unowned robots.txt, course facts trapped behind JavaScript, accommodation detail in PDFs, and had no way of knowing whether they were specific to our clients or general to the sector. This report is the answer to that question. It turned out to be general.
What we do about it. The fixes in section nine are the work: AI crawler policy, structured data in course templates, getting fees and entry requirements into server-rendered HTML, accommodation content out of PDFs, and the funnel programme that follows once a site can actually be read. We do this on whatever platform an institution already runs. The sample in section six includes eight, and every finding in this report is fixable on all of them.
Our declared interest, stated plainly. We are a commercial agency and we would be pleased to help. We are also an Acquia Elite Partner, which is relevant context for a reader assessing this report: three of the 64 institutions here run Acquia. Nothing in our recommendations requires an institution to change platform, and we have deliberately not made a platform argument anywhere in this document, because the data does not support one. Section six shows purpose-built higher education platforms failing these checks at the same rate as general-purpose ones.
Your institution is in this report
All 64 institutions in this study have a section: the specific findings for your domain, the evidence behind each one, and the prioritized list of what to fix. We would rather you had it before anyone else reads this than after.
The state of AI discoverability in UK higher education, 2026. Published by Axelerant, August 2026. Independent research, produced without vendor sponsorship. Sector financial context from the House of Commons Education Committee and Universities UK. AI search behaviour data from EAB, 2026, US sample, cited as a behavioural signal rather than a UK figure. Institutional financial data from published statements, HESA and the Office for Students.