:format()//media/CourseFinder-solutions-huddersfield-university-terminalfour-RQ.png)
Why your Course Finder might be the most important page on your website…
and the hardest to get right!
Ask any higher education web team what their most complex, most politically loaded, most technically fraught page is, and you'll often hear the same answer: the course finder.
It's the page every prospective student reaches eventually, and where browsing often turns into serious consideration.
It’s also often where students decide to spend the next three years of their lives…and it either gets clearer… or gets abandoned.
And yet, for many institutions, course finders are also the place most likely to be running on an old architecture, held together by thousands of lines of custom code, and pulling data from different source systems that were never designed to talk to each other.
University of Huddersfield knew this issue well, and last year, they decided to fix this issue properly, not just on the surface, but at the architectural level.
The team flipped the model: instead of treating Terminalfour as a system to pull content from, they made it the hub.
They rebuilt CourseFinder by putting Terminalfour at the centre of its ecosystem.
The result is a completely rebuilt and mission-critical CourseFinder, with structured content models, automated data pipelines, reusable components, governed workflows, and a dedicated course search experience.
Here’s what the web team did.
The problem with most course finders
Course finders are a common pain point.
The typical legacy setup looks something like this: a CMS/DXP handles marketing content, a student records system holds official module and course data, and somewhere in between sits a complex web application that ingests from both, transforms the data, and serves it out to the website.
Every time a source system changes, things can go wrong.
Every time you want to redesign a page layout, integrations get messy.
Every time a new course is added or a module description changes, someone has to manually reconcile information across multiple platforms.
It's fragile, and it’s expensive to maintain.
And…it's also slow… which is the last thing you want when prospective students are comparing your course pages with another university’s.
Flipping the model
Huddersfield's team made a decision that sounds simple but has significant implications: rather than extracting content from Terminalfour as a presentation layer sitting on top of other systems, they made Terminalfour the authoritative hub that everything publishes into.
Data still comes from the student records system, the research records system, and marketing-managed content.
But instead of that data flowing through a complex application layer before hitting the website, it's processed upstream and fed directly into Terminalfour via the API, where it becomes the structured source of truth.
From there, Terminalfour publishes out fast, stable, static pages.
“We knew that simply redesigning the front end wouldn’t solve our underlying problems. The real challenge was our legacy codebase, complex processes and unstructured data. By moving to a model where Terminalfour acts as a data hub for course information, we’ve simplified integrations, strengthened governance, and given ourselves the flexibility to iterate rather than rebuild again in a few years when the underlying systems change. Bringing CourseFinder into our core technology stack has also allowed us to apply our in-house Terminalfour expertise to improve the entire process.
- James Leah, Web Development Manager, University of Huddersfield
This means there are fewer moving parts, simpler integrations, and clearer ownership of where data lives and who's responsible for it.
It's a genuinely different philosophy, and for institutions still building course finders as elaborate middleware applications bolted onto their CMS, it's an approach that can really help.
How they did it
Making this work at scale required some serious engineering.
Huddersfield built a course data pipeline using Azure Functions and a Claim Check architecture, a pattern designed for handling very large message payloads efficiently, where a reference to data is passed through a queue rather than the data itself.
The system ingests course updates from multiple upstream sources into Azure Blob Storage, then uses Azure Queue Storage to trigger automated processing workflows.
Data is mapped into payloads corresponding to different content types within Terminalfour; modules, course descriptions, entry requirements, career outcomes, and then it’s pushed through the API.
All 780 courses can now be populated within minutes, replacing what was previously a manual, error-prone process.
More than 11,000 course modules can be synchronised into Terminalfour in under half an hour.
Shared list items that appear across multiple courses are handled the same way, populated once and reused throughout.
And previously manual copy-and-paste processes between systems have largely been eliminated, significantly reducing the risk of transcription errors.
The goal was straightforward: eliminate manual data entry wherever possible.
Updates that previously required a staff member to copy information from one system into another now flow automatically.
Course removals are now automatically triggered from the Student Records system, eliminating the need to manually unpublish courses across multiple platforms.
When issues do arise, diagnostic data is now surfaced directly within Terminalfour fields, allowing developers to identify problems quickly without investigations across multiple systems and teams.
That's an efficiency gain and also a quality gain, because manual transcription is where errors creep in.
Structured data as a design principle
One of the most quietly significant aspects of the rebuild was tackling "legacy content architecture."
In the old CourseFinder, large fields full of unstructured text were common.
A single content area might contain everything from entry requirements to career prospects, formatted with markdown that complex scripts had to parse and transform before it could be displayed.
Adding a new design component, or changing how information was presented, meant untangling that content first…which is a project in itself.
But the rebuild took the opposite approach.
Those monolithic fields were broken into discrete, well-defined content types within Terminalfour: one element for entry requirements, another for career outcomes, another for module information, and so on.
The content is now structured at the point of ingestion, not transformed downstream.
This matters more than it might seem.
Structured content is portable content.
It can be reused across pages and channels without reformatting.
It can be validated automatically. It can be adapted to new designs without re-engineering integrations.
If you're building content infrastructure that needs to serve not just today's website but tomorrow's, whether that's a mobile app, a personalised portal, or something not yet invented, structured data is the foundation.
Marketing teams can now format course content directly within structured fields, with no need to understand Markdown or any other formatting syntax.
Eliminating duplication with smart reuse
Course content has a duplication problem by nature.
Modules can appear across multiple programmes, research groups can be referenced on dozens of course pages, and accreditation information can be repeated wherever it's relevant.
In the old model, this often meant maintaining parallel copies: content entered in multiple places, updated inconsistently, drifting apart over time.
Huddersfield addressed this by moving repeatable content into dedicated branches within Terminalfour and using navigation objects alongside programmable layouts to create dynamic feeds.
When a page is published, the layouts pull the correct information from a single managed source.
One update, consistent everywhere, without version drift and no duplication overhead.
“At the beginning of the project, we consulted with internal stakeholders who were responsible for building courses. The feedback was overwhelmingly negative - the build was inflexible, time-consuming, and unintuitive. Moving the build to Terminalfour has changed that. We're now using a fit-for-purpose system and have teams on the ground who can support colleagues to use Terminalfour.”
-Josie Ellis, Head of Marketing, University of Huddersfield
Governance built into the workflow
Here's something that tends to get overlooked in course finder redesigns: the content on these pages carries real compliance obligations.
In the UK, the Competition and Markets Authority (CMA) has clear requirements about the information institutions has to provide to prospective students, and how it needs to be accurate and complete at the point of decision.
Huddersfield wired CMA compliance directly into their workflow structure.
Different elements of course information (those with different ownership and approval responsibilities) follow distinct workflow paths through Terminalfour, ensuring they're reviewed by the right academic or professional services teams before publication.
They can audit approvals, ownership is transparent, and compliance is embedded in the day-to-day operations rather than a last-minute scramble before Clearing.
During the annual rollover, branches from previous years can now be updated and synchronised with external systems, automatically removing legacy courses and refreshing data without manual intervention.
For any institution navigating CMA requirements (and in the UK, that's everyone), this is an approach that’s really worth considering for your university or college.
Search that actually works for course discovery
Search is one of those features that looks simple but isn't (it’s a huge pain point for many universities and colleges).
For a course finder, a generic site search rarely works well: the ranking logic, filtering, and relevance tuning needed for course discovery is different from what works for finding a news article or a staff profile.
Huddersfield rebuilt their course search using Terminalfour's Advanced Search Module powered by SearchStax, configuring a dedicated course profile that's intentionally separate from the rest of the site search.
Ranking, filters, and relevance are tuned specifically for applicant behaviour.
And with detailed analytics now flowing from that search experience, the team can analyze how prospective students are actually looking for courses and refine it accordingly.
That last part, the feedback loop, is often what separates a course finder that serves users from one that merely exists.
What other higher ed institutions can take from this
The Huddersfield CourseFinder is a technology project, but the decisions behind it are strategic ones that any higher ed web or marketing team can learn from.
- Treat your DXP/CMS as infrastructure, not just a publishing tool.
If your DXP/CMS is only handling content that someone typed directly into it, you're using a fraction of what it can do. Treating it as a data hub, a structured, API-connected layer that aggregates from authoritative sources, fundamentally changes its value to the institution. - Fix data structure at the source.
Messy, unstructured content doesn't become manageable at the presentation layer, it tends to stay…messy. The rebuilds that really improve agility are the ones that fix the content model, not just the template. - Design for reuse from the start.
If the same information appears in more than one place on your site, you should be managing it in one place. Navigation objects, content inheritance, and programmable layouts exist precisely for this, but they require deliberate content modelling to work well. - Compliance is a design problem.
CMA obligations, accessibility requirements, accuracy standards for admissions information… these aren't things to retrofit onto a finished product; they need to be embedded in workflows and data structures from the beginning.
Huddersfield’s team describes this rebuild as the beginning rather than the end: there's plenty still to do, and the search analytics alone will likely surface a list of improvements to pursue over the coming months.
The difference now is that the foundation they’ve built can actually support that kind of iteration, something the previous system simply couldn’t accommodate.
Check out their CourseFinder.
For anyone working through a course finder rebuild of their own, or questioning whether their current architecture is holding them back, it's worth taking a look at what they've put together.