Structured Data For University Course Pages: The Schema Answer Engines Read

Forty six percent of the 64 UK universities we audited publish no structured data at all on the pages an applicant lands on. Of the ones that do, most publish an Organization block and stop, which tells an answer engine who you are and nothing about what you teach, what it costs, or when it starts.

That gap is why a chatbot answering "how much is a BSc Computer Science at a UK university" so often quotes a league table site rather than the university that sets the fee. The aggregator marks up its data. The university does not.

This is the practical version: which schema types to use, how to nest them, where the chain breaks, and how to check it. Figures come from our audit of 64 UK higher education websites, run in August 2026.

Why structured data matters more than llms.txt

We wrote separately about llms.txt for universities, and the honest conclusion there was that no major answer engine has committed to reading it. Structured data is different. Google, Bing, and the retrieval layers behind ChatGPT and Perplexity all parse JSON-LD, and course results in search have relied on it for years.

So the order is not a matter of taste. Markup earns quotable facts today. llms.txt is a curation layer you add afterwards, pointing at pages you have already made readable.

Which schema type answers which applicant question

Start from the question, not the vocabulary. Applicants ask five things about a course, and each one maps to a specific type and a specific set of properties.

Two of those five carry most of the value. Fees are the most searched course fact in the UK, and entry requirements are the most asked question in the applicant journeys we see. Both are also the two most likely to be missing from the HTML.

One course page, three nested objects

The mistake we see most is flat markup: a Course object with a name and a description and nothing else, sitting next to a fees table that no machine can associate with it. Nesting is what makes a fee quotable.

Three rules that survive most CMS platforms:

• Publish Organization once, site wide, and reference it as the provider on every course page. Repeating a different legal name per faculty is a common and avoidable inconsistency.
• One canonical Course page per course. If a PDF prospectus duplicates it, the PDF should not be the canonical version and should not be listed as an alternative.
• Home and international fees are separate offers with a category, not one number with a footnote. An answer engine that cannot tell which fee status applies will usually pick the wrong one, or pick a third party.

Add FAQPage only where a genuine question and answer pair exists on the page. Marking up marketing copy as an FAQ is the fastest way to lose the markup entirely.

Where the chain breaks

Markup rarely fails because someone wrote the wrong property. It fails because four different teams own four different stages, and nobody owns the chain.

The third stage is the one that shows up in our data. Forty five percent of audited institutions keep course fees out of the server rendered HTML: a widget fetches them after the page loads, or they sit inside a PDF. An agent that reads the initial HTML response sees a page about a course with no price on it.

The fourth stage is quieter still. Eleven percent block at least one answer engine at the edge while robots.txt appears to allow it, so the markup is perfect and never fetched. That is platform engineering work, not marketing work, and it has to be cleared first.

The implementation order that holds

• Reconcile the edge with robots.txt, so the agents you intend to allow can actually fetch a page.
• Move fees, entry requirements, start dates, and accommodation prices into governed CMS fields with a named owner and a review date.
• Server render those fields. If the platform hydrates them client side, render them in the initial response as well.
• Emit Course, CourseInstance, and Offer from the course template, so the markup is a property of the template rather than a per page task.
• Add Organization site wide and FAQPage only where real question and answer content exists.
• Then publish llms.txt, pointing at the pages you have just made readable.

Steps two and three are where programs stall, because they are content operations questions dressed as technical ones. That is the same failure pattern we described in composable DXP programs: the architecture is fine and the operating model never ships the facts. The content design and discoverability work sits exactly here.

How to check it, in about ten minutes

• Fetch a course page the way an agent does, without JavaScript, and search the response for the fee and the entry grades. If they are absent, nothing else on this list matters yet.
• Run the page through Google's Rich Results Test and the Schema Markup Validator. The first tells you what Google will use, the second tells you what is valid.
• Check Search Console for the Courses report, which shows the pages Google recognizes and the ones it rejects.
• Ask ChatGPT, Gemini, and Perplexity the fee question for a named course, and note whether the answer cites you or an aggregator.

Our AI visibility audit runs the first and last of those against a domain and returns the markup, render, and edge findings together, which is the combination that tells you where the chain actually breaks.

What this looked like at the University of East London

The University of East London moved off Sitecore onto Drupal on Acquia with us, and rebuilt the estate as one platform rather than a set of pages. It is the closest reference point we have for this problem at full institutional scale, 125 years of content, students from 156 countries, and five distinct audiences reading the same site for different reasons.

Schema is only as good as the fields behind it, and this is where most institutions stall. Marking up a fee that a person retyped from a spreadsheet last cycle produces confident, wrong structured data. At UEL the fix ran under the markup: automated updates for course data, fees, funding and application deadlines, drawn into modular content blocks that every course page reuses.

Once fields are systematic, three things become possible that hand maintained pages cannot sustain: consistent Course and CourseInstance properties across hundreds of pages, a single owner page per course to attach them to, and markup that stays true through a cycle without a manual sweep.

That is the sequence we would recommend anywhere: fix the source of the fact, put it on the page as text, then describe it in schema. Reversing the order produces validation passes and wrong answers. The build is documented in the University of East London case study.

Frequently asked questions

Does structured data improve rankings?

Not directly. It improves eligibility for rich results and it makes your facts extractable, which is what decides whether an answer engine quotes you or a third party. The output we track is citation and referral, not position.

Course or EducationalOccupationalProgram?

Use Course for a taught course page. EducationalOccupationalProgram fits a program of study with an occupational outcome, such as a degree apprenticeship, and the two can coexist across a course and program page pair.

Do we need CourseInstance for every intake?

For every intake you want quoted. September and January starts with different fees and modes are two instances. One instance with a vague start date invites a wrong answer.

Is JSON-LD better than microdata?

For a university estate, yes. JSON-LD sits in a script block that a template can emit from CMS fields, which means the markup survives a redesign. Microdata is woven into markup and dies with it.

What about accommodation and living costs?

There is no clean type for accommodation pricing, which is why it so often disappears. Publish it as a server rendered table on a canonical page, use Offer where an actual bookable rate exists, and list the page in llms.txt.

Where to start

Pick your five highest volume courses and treat them as the pilot. Get the fee and entry grades into the HTML, emit Course, CourseInstance, and Offer from the template, then check what the engines say a fortnight later. If you want the current picture first, run the AI visibility audit, read the full 64 institution report, or start with the llms.txt guide if the curation layer is what you are being asked about. We work with higher education institutions on this chain end to end, and you can always talk to us.

Read next

Markup can only describe a fact that is already on the page. Publish fees, entry requirements and accommodation costs so answer engines can read them covers the layer underneath this one, and llms.txt for universities covers the curation layer above it. Both draw on the same audit of 64 UK higher education websites.

And before any of it: AI crawler policy for higher education, because markup on a page an answer engine was refused at the edge is never seen.

The same defects fail a second audience. WCAG 2.2 for university websites maps each pattern to the criterion it fails and the fact an answer engine loses.

Scope is the recurring problem across an estate. Accessibility statements in higher education shows how much of the applicant journey sits outside the domain a single statement names.

Markup mirrors what the template chose to show. University website design covers that choice, and SEO for universities covers the duplicate URLs that split the value of getting it right.

Whether markup is a default or a per page task is decided by the platform: choosing a CMS for a university estate.

Working on a university estate rather than a single page? Our higher education practice page sets out how the strategy, design, engineering and marketing work runs as one team, and the UK higher education AI discoverability report holds the audit data behind this series. Also worth reading: Student recruitment marketing, Higher education digital strategy.

For the same audit read as a marketing diagnosis, see higher education marketing: what an audit of 64 UK university websites reveals.