Making your website AI-Ready
A guide to JSON-LD Structured Data in Terminalfour
You've put enormous effort into your university websites. You've created carefully written course descriptions, faculty profiles, event listings, and research pages. But there's a growing challenge: the way people find information online is changing rapidly, and your website may not be keeping up.
Search engines have always used automated programmes called "crawlers" to read and index websites. In recent years, AI-powered tools (including chatbots like ChatGPT and Gemini, and AI-enhanced search engines) have started using their own crawlers to gather information. These tools don't just look at the words on your page; they try to understand what your content means and how it relates to real-world things like courses, people, and events.
What's the problem?
Most web pages are written for human readers, not machines. A human visiting your Events page instantly understands that a block of text describes a seminar, knows who's speaking, when it is, and where to register. An AI crawler, however, may struggle to reliably extract that same information. Not because the content is unclear, but because there's no standardized, machine-readable way for it to identify what each piece of information represents.
Why does this matter?
Universities have a lot to lose if their content is misunderstood or overlooked by AI tools. Prospective students are increasingly using AI assistants to research courses and universities. Researchers and academics expect to find up-to-date information quickly. Journalists and the public rely on accurate, trustworthy information about your institution.
If an AI tool can't reliably read your course pages, it might present outdated or incorrect information to someone asking "What undergraduate courses does [your university] offer in engineering?". At best, that's a missed opportunity. At worst, it's a reputational problem.
The good news is there's a widely-adopted, straightforward solution: structured data, and specifically a format called JSON-LD. By adding a small, invisible block of structured information to your web pages, you can help both search engines and AI crawlers understand your content far more reliably.
What is JSON-LD and how does it work?
JSON-LD stands for JavaScript Object Notation for Linked Data. In practice, it's much simpler than it sounds.
At its core, JSON-LD is a small, standardized snippet of code that you add to the <head> section of a web page (the part of the page that browsers and crawlers read, but that visitors don't see). This snippet doesn't change how your page looks or behaves. It purely exists to give machines a clear, structured description of what's on the page.
Where does the vocabulary come from?
JSON-LD uses a shared vocabulary called Schema.org: a project created and maintained by Google, Microsoft, Yahoo, and other major technology organizations. Schema.org defines a common language for describing things like people, events, courses, organizations, and much more.
Because Schema.org is an agreed-upon standard, any crawler (whether it's Google's search bot, an AI tool, or a specialist academic index) knows exactly what your structured data means. It aims to remove any ambiguity.
A simple example
Here's what a JSON-LD block might look like for a university event:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Event",
"name": "Annual Research Showcase 2026",
"startDate": "2026-03-14T10:00:00",
"endDate": "2026-03-14T16:00:00",
"location": {
"@type": "Place",
"name": "Main Campus Auditorium",
"address": "University Road, Dublin"
},
"description": "A showcase of cutting-edge research projects...",
"organizer": {
"@type": "Organization",
"name": "University Research Office"
}
}
</script>
Notice a few things about this example. The "@type" field tells the machine exactly what kind of thing this is: an Event. Each field (name, startDate, location) uses standardized property names from Schema.org, so every crawler reading it knows precisely what each value means. The data mirrors what's already on your page. It's just presented in a machine-friendly format alongside the human-friendly version.
How does this help with AI?
When an AI crawler visits a page with JSON-LD, it doesn't have to "guess" what things mean by reading and interpreting normal text. The structured data acts as a clear, authoritative source of truth. This means AI tools are more likely to correctly represent your content and attribute it back to your institution. This can help ensure your data is what an AI shows to users in AI summaries of search results. It can also help ensure that when users interact with an AI like ChatGPT and Gemini, that your data helps inform the responses.
Major search engines like Google also reward well-structured pages with enhanced search results (sometimes called "rich results"), such as event listings or course details appearing directly in search results pages. This is an immediate, practical benefit alongside the longer-term AI readiness advantage.
Which pages on your site should have JSON-LD?
Not every page on your site needs structured data. But certain page types are particularly valuable to mark up because they contain structured, factual information that AI tools and search engines are actively looking for. Here are the highest-priority page types that we recommend have JSON-LD for most universities.
| Page Type | Examples | Schema.org Type |
|---|---|---|
| Course and Program Pages | Undergraduate degrees, postgraduate programmes, short courses | Course |
| Event Pages | Open days, public lectures, conferences, graduation ceremonies | Event |
| People / Staff Profiles | Academic staff, researchers, professional services staff | Person |
| Research Projects | Research center pages, funded project descriptions | ResearchProject |
| News Articles | Press releases, institutional announcements | NewsArticle |
| FAQs | Admissions FAQs, student services FAQs | FAQPage |
| Location / Campus | Campus maps, building directories, department locations | Place / CollegeOrUniversity |
| Organization Pages | Faculties, departments, research centres | Organization / CollegeOrUniversity / EducationalOrganization |
Course Pages: The highest priority
For most universities, course pages are the single most important target for structured data. Prospective students ask AI tools questions like "What are the entry requirements for a computer science degree at [university]?" If your course pages have JSON-LD, the AI has authoritative, structured data to draw from. If they don't, it's guessing from your page text. And may get it wrong!
The Course schema type lets you specify the course name, description, provider, mode of study, duration, prerequisites, and much more. A well-marked-up course page gives AI tools and search engines everything they need to accurately represent your offering.
Event Pages: high visibility benefit
Events are one of the most well-supported schema types across all major search engines and AI tools. Google has long shown event structured data directly in search results including dates, times, and registration links. For a university running open days, public lectures, or conferences, this is an immediate benefit.
People and Staff Profiles
Academic staff profiles are often complex pages with a mix of biographical information, research interests, publications, and contact details. Adding structured data to these pages helps AI tools correctly identify your staff members and their areas of expertise. This can be valuable for things like media enquiries and research collaboration.
Implementing JSON-LD in Terminalfour
One of the key advantages of managing your website through Terminalfour is that structured data can be built into your Content Types as a standard part of your pages meaning your content editors don't need to write any code manually. Once the implementation is in place, JSON-LD is generated automatically from the content that editors already enter.
Start by deciding which content types are your highest priority. For most universities, this will be courses and events. Map out the existing fields in each content type and identify which Schema.org properties they correspond to.
The schema.org website includes the full specification for every type of structured data. They include great examples of how the data should be structured in many formats, including JSON-LD (which is what we're interested in).
It's fine if not every Schema.org property has a matching field in your Content type. Partial structured data is still valuable.
In this example we'll show you how to create JSON-LD output for an Event. But the same approach can be used for any schema.org type you want to output.
Use a dedicated Content Layout
We recommend creating a dedicated content layout for each Content Type that will output this structured data.
Stick with a standard content layout name across all Content Types for JSON-LD. We recommend text/json-ld. Take this same approach whether your Content is output in a standard section or if using Fulltext (we'll cover some more detail about fulltext later in the guide).
Use handlebars to ensure data is correctly output
We recommend Handlebars to create your JSON-LD layouts. It includes helpers to ensure that data can be output safely in JSON. This ensures data entered by content editors doesn't unintentionally break the layout by using invalid characters.
Be sure to update the Handlebars expressions below to reference the appropriate elements in your Event Content Type.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Event",
"name": "{{jsonString (publish element="Event Title")}}",
"startDate": "{{dateFormat (dateElement element="Event Start Date") "YYYY-MM-dd'T'HH:mm" }}",
"endDate": "{{dateFormat (dateElement element="Event End Date") "YYYY-MM-dd'T'HH:mm" }}",
"location": {
"@type": "Place",
"name": "{{jsonString (publish element="Event Location")}}",
"address": "{{jsonString (publish element="Event Address")}}"
},
"description": "{{{jsonString (publish element="Event Description")}}}",
"organizer": {
"@type": "Organization",
"name": "{{jsonString (publish element="Organizer")}}"
}
}
</script>
The same approach can be taken for News, Staff Profiles etc.
Adding it to Page Layouts
Now we've defined the text/json-ld layout on our Content Type we need to output it into our Page Layout(s).
For this example we'll continue to assume we're working with the Handlebars processor.
Edit your Page Layout and look in the "Header code" tab. Look for the closing </head> tag. Immediately before that closing tag, add the following:
{{#try}}
{{#each (contentInSection)}}
{{embed layout="text/json-ld"}}
{{/each}}
{{/try}}This will check every content item in your section to look for a JSON-LD layout. If it exists, it'll output it. The "try" block ensures that if a content type doesn't have the layout, no error will be thrown.
We recommend that your page only have a single JSON-LD snippet. We're checking every Content Item in the section to try and find it but the expectation is that only one Content Type in the section will contain it.
Another approach to ensure only one content item is ever output could be to use a Navigation Object like Top Content to ensure only one item is ever returned.
Handling fulltext pages
If you use fulltext to output your News or Events you'll need a slightly different approach for outputting the JSON-LD in those pages.
{{#fulltext}}
{{#try}}
{{embed layout="text/json-ld"}}
{{/try}}
{{/fulltext}}The above ensures that we only output the JSON-LD on fulltext pages.
There's no right or wrong approach. Whichever one you take depends on the specifics of your implementation.
Before going live
The implementation is complete and you may be itching to publish out all your new changes. However, we strongly recommend taking the time to perform the following actions.
Test and validate
Before rolling out structured data site-wide, it's important to test and validate the output. Google provides a free tool called the Rich Results Test that lets you paste a page URL or raw code and immediately see whether the structured data is valid, what type it represents, and whether any required fields are missing. There are other validation tools out there that you can search for to check it's working as you expect.
Schema.org itself also provides documentation on required versus recommended properties for each type. It's worth reviewing this for each content type you implement to make sure you're including the most valuable fields.
Ensure that it can be maintained
Structured data is only as good as the content it draws from. If content editors are inconsistent about filling in certain fields, the structured data may be incomplete. As part of your implementation, consider updating your editorial guidelines to flag which fields are important for AI and search engine visibility.
Review your content elements that you're outputting with JSON-LD and decide whether they should be required or not.
Conclusion
AI is changing how people discover and interact with information on the web. By implementing JSON-LD structured data in Terminalfour, you can ensure your course pages, events, staff profiles, and other content are accurately understood and represented by AI tools and search engines alike.
The investment is modest. Structured data works within your existing content, is invisible to users, and (once configured in your Content Types and Page Layouts) requires no ongoing effort from content editors. The return is a website that speaks clearly to both human visitors and the AI-powered tools they increasingly rely on.
Back to top