Publish Fees, Entry Requirements And Accommodation Costs So Answer Engines Can Read Them

Not one of the 64 UK universities we audited published weekly accommodation prices in crawlable HTML. Forty five percent kept course fees out of the server rendered response, and thirty four percent did the same with entry requirements. The pages existed. The numbers on them did not survive the trip to a machine.

This matters because those three facts are what applicants and parents actually ask an answer engine, in almost exactly those words: what does it cost, what grades do I need, what will a room cost me for a year. When the number is missing from the HTML, the engine answers anyway, from a league table, a student forum, or a competitor prospectus.

Figures here come from our audit of 64 UK higher education websites, run in August 2026. This piece is about publishing, not markup: how to get the number into the response in the first place. The markup layer that describes it once it is there is covered in structured data for university course pages.

Three fact families, three different failure rates

The three facts fail for different reasons, which is why a single fix rarely clears all three.

Fees usually fail on delivery. The number exists in a finance system, gets published to a fee table, and then the fee table is a script, a tab, or a linked PDF. Entry requirements usually fail on ownership: the grade profile lives with admissions, changes each cycle, and gets pasted into prose that no template can read as a field. Accommodation fails on estate boundaries. Residences sit on a separate site, often a separate CMS, sometimes a booking platform, and nobody in the marketing team owns its markup.

Same fee, four ways to publish it

Before anyone argues about schema, settle the delivery question. An answer engine reads the first server response. Everything that arrives later is optional as far as it is concerned.

The tab case is worth stating plainly, because it causes needless panic. Content hidden by CSS inside a tab or accordion is still in the HTML and is generally read. The problem is not visual hiding. The problem is absence.

The PDF case is worth stating too, because it is the most common workaround. A fee schedule PDF covering the whole institution cannot answer a question about one course. Even where it is parsed, the engine has no way to associate row 74 with the page an applicant is reading.

Course fees: publish the number, name the fee status

A fee is only quotable if the engine can tell which fee it is. Two numbers labelled in a graphic, or one number with a footnote about international status, both produce wrong answers.

• Put the annual fee in the page HTML as text, per fee status: home, international, and any placement or repeat year rate that differs.
• State the academic year the fee applies to on the same page. A fee without a year is a fee an engine will happily quote three cycles late.
• Keep the fee in a governed CMS field with an owner and a review date, so the number on the page is the number finance approved.
• Where the fee is genuinely not set yet, say so as text with the expected publication date. Silence reads as absence, not as pending.

Then describe it: an Offer inside the CourseInstance, with a price, a currency, and a category naming the fee status. That is the difference between a page that mentions money and a page an engine can quote a price from.

Entry requirements: a field, not a paragraph

Entry requirements are the most asked applicant question we see and the second most likely to be unreadable. The usual pattern is a long page of prose covering A levels, BTEC, Access, International Baccalaureate, and country by country equivalences, with the actual grade profile for this course buried inside it or moved to a separate qualifications page entirely.

• Publish the headline grade profile on the course page itself, in text, not only on a central qualifications hub.
• Structure the alternatives as discrete items rather than a paragraph, so each qualification route can be read independently.
• Give the English language requirement its own field. It is a separate question and it is asked separately.
• Mark the profile up as coursePrerequisites on the Course object, and state the award as educationalCredentialAwarded.

The operational point underneath this is a content operations point, not a technical one. If the grade profile changes each cycle and lives in prose, it will drift out of date on some pages and not others. As a field with an owner and a cycle review date, it changes once.

Accommodation costs: the zero of 64 finding

This is the cleanest gap in the whole audit, and the easiest to act on precisely because nobody has. Every institution we checked publishes accommodation pages. None of them published weekly room prices in a form a crawler could read: prices sat in image based rate cards, in booking systems behind a login, in a PDF, or in a filterable widget that loads after the page.

A single canonical page per academic year, with one server rendered row per room type, answers most of the living cost questions an engine gets asked. Keep the booking widget. Put the rate table underneath it in HTML.

• One row per room type, with the weekly price, the contract length in weeks, and the total that follows from it.
• Catered or self catered stated as a field, not implied in a description.
• Distance to a named campus in walking minutes, because that is how the question is asked.
• The academic year the rates apply to, stated on the page and in the URL if you version by year.

Then use Accommodation with an Offer where a genuine bookable rate exists. Where you cannot model it cleanly, publishing the table is still the larger half of the win. Markup describes a fact. It cannot invent one.

The order that holds

• Clear the edge first. Eleven percent of institutions block at least one answer engine at the network layer while robots.txt appears to allow it, so perfect content is never fetched.
• Move fees, entry grades, start dates, and room rates into governed CMS fields with named owners and review dates.
• Server render those fields, including on pages that currently hydrate them client side.
• Emit Course, CourseInstance, Offer, and Accommodation from templates, so markup is a property of the template rather than a per page chore.
• List the canonical fee, entry, and accommodation pages in llms.txt once they read cleanly.

Steps two and three are the ones programs stall on, because they are operating model questions wearing technical clothes. We wrote about that pattern in composable DXP programs, and it applies here almost word for word. The content design and discoverability work sits at exactly this seam, and clearing the edge is platform engineering work.

How to check your own estate in an afternoon

• Fetch one course page without JavaScript and search the response for the fee, the grade profile, and the year. Absence here outranks every other finding.
• Do the same for one accommodation page and search for a weekly price.
• Ask ChatGPT, Gemini, and Perplexity the fee, entry, and room cost questions for a named course, and record who gets cited.
• Note where each number originates. If the answer is a spreadsheet emailed each July, that is the real finding.

Our AI visibility audit runs the render, edge, and citation checks against a domain together, which is what tells you whether the problem is the number, the markup, or the fetch.

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.

Fees, funding and deadlines were the exact fields that broke there, for the reason they break everywhere: they were maintained by hand, in documents, by people whose job is not the website. The engagement automated updates for course data, fees, funding and application deadlines, then delivered them through reusable content blocks so the same figure appeared identically wherever it was used.

The effect on answer engines is mechanical. A machine can only quote what is present as text on a page it is allowed to read. When the figure lives in a PDF, a portal, or a table rendered after the fact, the engine reaches for a league table site instead, and your institution loses control of its own number.

Two supporting pieces mattered as much as the automation: a unified data layer joining analytics, CRM and form data, so the team could see which facts prospective students actually looked for, and search that could surface them internally. The whole platform is described in the University of East London case study.

Frequently asked questions

Will publishing fees in HTML help our search rankings?

The output we track is citation and referral, not position. Publishing the number makes your page the source an answer engine can quote instead of an aggregator, and it makes course rich results possible at all. Those are different mechanisms from ranking, and they move first.

Is content inside a tab or accordion invisible to AI crawlers?

Generally no. If the text is in the server rendered HTML, hiding it visually with CSS does not remove it. What removes it is fetching it with JavaScript after load, or putting it in an image or a PDF.

Should we publish fees if they are not confirmed yet?

Publish the status as text with an expected date, and keep the previous year clearly labelled with its year. An engine given nothing will quote something else. An engine given a labelled prior year figure with a note has a good chance of reporting it accurately.

Is there a schema type for accommodation pricing?

Accommodation with a nested Offer covers the common case, and unitText carries the weekly basis. It is a less mature area than Course, which is exactly why publishing the table in HTML matters more here than the markup does.

Our residences sit on a different domain. Does that break it?

It weakens it. Thirteen percent of institutions we audited split the course estate across a second domain, and the effect is the same for accommodation: facts on an unlinked domain are harder to associate with the institution. Cross link both ways, keep one canonical version, and list the pages in llms.txt.

Where to start

Pick five high volume courses and one accommodation page, get the numbers into the HTML with a year label and an owner, then re ask the engines a fortnight later. If you want the current picture first, read the full 64 institution report, then the markup guide and the llms.txt guide in that order. We work with higher education institutions on this chain end to end, and you can talk to us about your own estate.

Read next

Clearing the fetch comes first. AI crawler policy for higher education covers robots.txt, the four layers that can refuse a crawler, and the 11 percent of audited institutions blocking answer engines by accident.

The markup layer that describes these facts once they are on the page: structured data for university course pages. The curation layer on top: llms.txt for universities.

Moving these facts into server rendered HTML also closes accessibility defects: WCAG 2.2 for university websites covers the overlap and where to fix a defect once rather than on every page.

Once those facts are in HTML, say so publicly and honestly: accessibility statements in higher education covers the known issues list, the review date, and who owns both.

The same facts decide search results. SEO for universities covers the ranking side of the estate, and university website design covers the templates that carry the facts in the first place.

The same facts decide recruitment conversion, as covered in student recruitment marketing, and the plan that funds the work is in higher education digital strategy.

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: Choosing a CMS for a university estate.

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