Branditify for colleges, universities and higher-education institutions
The programme page is live. That is not the same as applications being open.
A prospective learner arrives understanding the institution and still not knowing which programme, at which campus, in which mode, for which intake — or whether they can apply today at all. The website usually answers the first question and guesses the last one. This is the brief that keeps the whole decision, and the application window that decides what the button is allowed to say.
Branditify builds the public website, the search architecture and the systems around the admissions journey. Programmes, eligibility, fees, accreditation, rankings and every admission decision stay with your institution.
Illustrative interface · sample data
What Branditify provides
Systems your institution operates, and services Branditify performs.
Two different things, shown as two different things. A system is something your admissions and marketing teams run every week once it is live. A service is work Branditify does to your institution’s brand, website and search presence. Each one names the higher-education job it is for.
Systems
The operating layer around the public journey.
An institution’s public website is one layer of four, and the other three begin at different moments — an enquiry, an enrolment, a course. The systems below are the ones that touch the journey this page is about; the internal academic layers are argued further down rather than sold here.
CRM
Every enquiry as a record with an owner: which programme it came from, which campus and mode and intake it asked about, where it originated, who in admissions holds it and what the next action is. Stages that are the institution’s real ones — enquiry, application started, application submitted, decision pending — rather than one "interested" flag on a spreadsheet.
What this Industry page adds to the Product is the higher-education behaviour: which six facts a public enquiry should already carry, why an application window is a separate fact from a published programme, and which state the system is never allowed to infer.
See the CRMBooking Platform
A campus visit or an open-day slot booked against dates the institution has actually opened, confirmed to both sides, and landed on the enquiry record with the programme and campus context attached. A booked visit is a visit — the interface never lets it read as a held seat or an application.
Dashboards
An institution usually cannot see which programmes and campuses its enquiries are actually coming from, because the answer is spread across a CMS, a CRM, an ad account and a spreadsheet. A dashboard over genuinely connected sources reports what those systems hold — and shows a gap as a gap rather than filling it in.
The two internal layers — an enrolled student’s academic record, and learning delivery — are separate systems that begin after this journey ends. Chapter eight sets out where each one starts, and why joining them matters more than merging them.
Services
The work that makes an institution findable and decidable.
Higher-education websites are usually large, old and governed by many departments at once, which is why the same three problems recur: pages that read as near-duplicates of each other, information nobody can find, and a brand that changed three redesigns ago in some places only. The before-and-after under each is the shift it makes.
Premium Websites
Programme pages that carry the fields a decision actually needs — level, campus, mode, intake, duration, eligibility as your institution publishes it, the application window from its source, one correct next action — inside an information architecture built on your real structure of campuses, schools and departments. Built to WCAG 2.1 AA as the standard for what we produce.
SEO / AEO
The institution entity, the schools and departments, every programme you genuinely run and the questions a prospective learner actually types — each with a page that can answer and be cited. The technical half matters more here than almost anywhere: canonical discipline across level and mode variants, crawlable content instead of PDFs, and one authority instead of scattered subdomains.
Content
What a programme actually covers, how the admissions process runs, what a campus is like, who teaches — written per programme rather than generated from a template with the name swapped. Faculty, research and campus content as your institution supplies it, in language a seventeen-year-old and their parent can both use.
Branding & Identity
An identity system that survives being used by every school, department, event and campus at once — with the components and rules that let a department publish something on-brand without asking anybody, which is the only version of governance that actually holds at this scale.
Performance Marketing
Programme-and-intake specific landing pages instead of one broad Apply Now, so the enquiry arrives carrying the programme, campus, mode and intake it came for — and reaches admissions with its source intact rather than as an anonymous name and number.
Custom Software
A scoped build for the parts no standard CMS fits: a programme catalogue that matches your real taxonomy, an application handoff into the system you already run, multi-campus content workflow, a document-request flow, or the join between systems that were never designed to speak. Scoped against a real difference, never sold as an upgrade.
Social media and ongoing maintenance are real parts of this work and are scoped with the build rather than carded here. What decides this project is whether a prospective learner can find the right programme and know what to do about it.
A programme page is not a decision
Three programmes, one paragraph, and nothing a learner can decide on.
This is the most common structural fault on higher-education websites, and it is not a design problem. The same description is reused across a whole catalogue with only the programme name changed — which leaves a prospective learner unable to choose between them, and leaves a search engine treating them as near-duplicates of one another.
This is not a forty-field prospectus table. Seven fields with a named source each is what turns a page into a decision — and the fields a particular institution publishes are its own choice, not ours.
How should university programme pages be structured?
One canonical page per programme, carrying the fields a decision needs and nothing generated from a template: the programme, its level and duration; every campus and study mode it runs in; the intake and the application window for that intake, read from the admissions source; what the curriculum actually covers, written for this programme; eligibility as the institution publishes it; the fee where one is published; and one correct next action. The failure mode to avoid is reusing one description across the catalogue with the name swapped — it leaves a learner unable to choose and leaves the pages competing with each other in search as near-duplicates.
Published ≠ open
The same programme, the same page, and two different buttons.
Nothing changes about the programme between these two states. The page is live in both. The only difference is what the admissions source says about the window for this intake — and that is the only thing that should decide what the page offers.
The honest action. A learner leaves knowing when to come back and how they will hear about it — which is worth more than a form that goes nowhere.
Now the action is the application, and it carries the programme, campus, mode and intake the learner already chose.
The same discipline applies to every date on the site: an open day, a document deadline, a counselling schedule. If nothing authoritative owns it, the page does not assert it.
Does a published programme page mean applications are open?
No. A programme page being live is a publishing fact — it says the institution offers the programme, and nothing about any date. Whether applications are open for a given intake belongs to the admissions office or the admissions system, and it changes on its own schedule. So the useful structure reads the window from that source and derives the action from it: information and register-interest while it is shut, the application itself once it opens. A page that shows Apply Now because the programme exists eventually collects applications into a process that is not running.
Enquiry ≠ application ≠ admission
Three states the institution owns, and a decision no website makes.
The admissions-software market sells one continuous funnel from first enquiry through to enrolment and academics. It reads well and it teaches institutions to treat an enquiry as an application and an application as an admission, which is how a dashboard ends up reporting intake numbers that were never real.
Enquiry received
Somebody asked about a programmeA named person in admissions owns it, with the programme, campus, mode and intake it arrived carrying.
Application submitted
The institution’s own application processA different act, in a different system, on the institution’s own form. An enquiry never becomes one by ageing.
Admission decided
Under review by the institutionNot a status the website computes, displays as likely, or moves along. It appears only when the institution says so.
No applicant score, no admission probability, no likelihood of acceptance. A percentage beside a real person’s name is a guess presented as a fact, and here it would be a guess about somebody’s education.
Does an enquiry or an application mean a student has been admitted?
No, and the three are separate on purpose. An enquiry means somebody asked, and it lives with a named owner in a CRM. An application is a different act in a different system, on the institution’s own form. An admission is a decision only the institution makes, and it is never computed, predicted or advanced by a website. Systems that collapse them — counting enquiries as applications, or showing an admission as likely — produce numbers admissions staff cannot act on, and in this category they also mislead a real person about their own education.
Website → admissions
Admissions should not have to ask what the website was already told.
Most institutional enquiries arrive as a name, a phone number and a programme guess. Everything the learner actually chose on the way there — the field, the level, the programme, the campus, the mode, the intake — is discarded at the form, and an admissions counsellor rebuilds it by asking. At institutional volume that is the single largest recoverable cost in the journey.
The public journey knows
Field, level, programme, campus, mode and intake — because the learner chose each one to get to this page.
The handoff carries
Those six facts, the page it came from, and the campaign where the platform genuinely reported one.
The record opens with
A programme interest, a source, an owner and a next action, instead of a blank note and a callback.
What genuinely transfers depends entirely on what the systems expose: an API, an authorised export, or nothing usable. That is established before anything is designed, and where a connection does not exist the journey is built to hand over cleanly rather than to pretend.
Can website enquiries and programme context carry into an admissions CRM?
Yes for everything the website itself holds — the field of interest, the level, the programme, the campus, the study mode, the intake and the page the enquiry came from all travel with it, because the learner chose them. Campaign and source depend on what the ad or referral platform actually passes through, and where that is missing the honest record is an empty field. What the handoff never does is invent an academic history or an intent score. The practical gain is that admissions opens a record already knowing what the learner wanted, instead of re-asking six questions the site had been told.
One statement, one owner
Every fact on an institution’s website belongs to somebody. Almost none of them belong to us.
Higher education is the category where an over-claim does the most damage, because the facts are external and checkable: a regulator grants recognition, a ranking body publishes a position, an audited report carries a placement figure. So each one is published as the owner’s fact, credited, or it is not published.
This is a positive contract rather than a disclaimer. An institution with real recognition, a real ranking and a real placement report gets a website that presents all three clearly and credits them properly — which is worth considerably more to a careful parent than a bolder claim nobody can trace.
How should accreditation, rankings and placement statistics be shown on a university website?
As somebody else’s facts, credited. Recognition and accreditation belong to the body that granted them, so they are shown as that body’s status with the institution’s evidence behind it. A ranking belongs to its publisher, so it carries the publisher, the year and the category — a bare "top ten" ages into a liability. A placement statistic belongs to the institution’s own published report and carries the period and scope it covers, as a past result rather than a forecast. Branditify builds the structure that displays and credits all of this; we do not grant, verify or interpret any of it, and nothing that no record can source — an admission or eligibility decision — is published at all.
Four systems, four starting points
The website, the CRM, the academic record and the learning system are not one product.
Each of these begins at a different moment and holds facts the others should read rather than duplicate. The market sells them merged; institutions that buy them merged end up with a weak public journey and a weak academic system at the same time.
Discovery, the institution’s story, programme information, search presence, decision support and the first action.
It does not hold a prospect relationship, an academic record or a course.
The prospective learner as a relationship: source, owner, follow-up, application progress where the admissions process reports it.
It is not the public site, and it is not where an admission is decided.
The enrolled student’s institutional and academic record — programme, semester, registration and the academic operations the institution runs.
It is not a marketing system, and nothing public reads from it.
Learning delivery for an authorised learner: content, modules, assessments where scoped, and progress.
It is not the institution’s public acquisition website, and an LMS login page is not a programme page.
The College Management Product owns layer three and has no route on this branch, so it is described rather than linked. That boundary is deliberate in both directions: this page is the public journey, and it stops where the academic record begins.
What is the difference between a university website, an admissions CRM, a College Management System and an LMS?
They start at four different moments. The website owns the public journey — discovery, programme information, search presence and the first action. A CRM owns the prospective learner as a relationship from the enquiry onward. A College Management System owns the enrolled student’s institutional and academic record: programme, semester, registration and academic operations. An LMS owns learning delivery after authorised access. Most institutions need several of them, joined rather than merged, so that each fact has exactly one home and every other system reads it instead of keeping a second copy that drifts.
The questions that decide the project
Answered directly, including the ones answered no.
Does every institution need custom software?
No, and most do not. A well-implemented CMS with a proper information architecture, an established admissions CRM and the systems you already run will serve a standard institutional journey better than a first custom build, and they arrive with integrations and support already solved. Custom becomes the right answer when the structure genuinely does not fit — an unusual programme taxonomy, multi-campus content workflow, a handoff between systems that will not speak — and not because custom sounds more serious.
Custom higher-ed website or a standard CMS?
A standard CMS, well configured, is the right answer more often than agencies admit — it gives departmental authors a governed way to publish and it is a known quantity for your IT team. What pushes a project towards custom is a programme catalogue that no CMS content model represents cleanly, multi-campus governance that templates cannot express, or an application handoff that has to be built rather than embedded. The honest sequence is architecture first, platform second.
Is accessibility part of the build?
Yes — we build to WCAG 2.1 AA as the standard for what we produce, because for a public institution it is a procurement requirement rather than a nice-to-have. What we will not claim is that a site is permanently conformant: your legacy PDFs, third-party embeds, video captions and future departmental edits all affect it, and keeping conformance is an ongoing institutional practice we can support but cannot promise on your behalf.
Can many campuses and departments work in one system?
Yes, and this is usually the real problem to solve. It needs a content model that matches your actual structure, permissions that let a department publish its own pages without being able to break anybody else’s, components that make on-brand the easy path, and a review step where one genuinely belongs. Governance that depends on everyone remembering a PDF guideline does not survive contact with forty departments.
Can the existing website and its content migrate?
Usually, with a survey first. Programme, department and faculty pages, media and metadata migrate reasonably well; what needs a decision rather than a script is the long tail of pages nobody has owned for years. Old URLs get a redirect plan where they carry genuine search equity — and only there, because a redirect map with thousands of guesses is its own problem. We would rather sample your real content and tell you what should not come across.
What decides the cost and the timeline?
The number of programmes, departments and campuses; how much content is being rewritten rather than moved; whether the application handoff and CRM integration are in scope; the accessibility baseline; the migration and redirect work; multi-campus governance; and reporting. We would rather scope those against your actual institution than quote a figure on a page that has not seen it.
Who owns the website, the systems and the enquiry data?
Your institution. Source code, hosting, data ownership, exports and handover are written into the project scope before work starts, and third-party tools sit under your own accounts wherever the platform allows it. Prospective-learner data is yours to export and take with you, and nothing is architected to make leaving us expensive.
Relevant work, described exactly
What Branditify has actually built.
Three delivered projects, each named with the industry its own published record carries and the scope that record lists. Matched on delivered scope — an identity system and a website with search architecture as one job, a catalogue turned into something navigable, and a service structure with the enquiry interface behind it.
The closest delivered analogue to an institutional rebuild: one engagement that produced the identity system, the premium website and the search architecture together, rather than a brand project followed by a site that ignores it. That combination is what an institution is usually buying.
Delivered scope: brand identity system, logo redesign, packaging-ready identity assets, retail-friendly brand assets, product communication style, premium website on a modern stack, SEO and AEO schema, content and media production, and analytics and tracking.
View the projectA large catalogue turned into something a visitor can actually move through — discovery and navigation structure across many items, on one UX system, performing on a phone. A programme catalogue is the same problem with different nouns.
Delivered scope: ecommerce website development, UX/UI design system, product discovery and navigation structure, mobile-optimised performance, analytics and tracking, and a post-launch growth retainer.
View the projectA set of offerings turned into pages a buyer can decide from, with the enquiry and booking interface direction that follows and the schema built in. The programme-page-and-enquiry half, delivered in full for a buyer who compares carefully.
Delivered scope: brand strategy and identity, responsive website development, UX/UI design system, service page structure, enquiry and booking interface direction, SEO and AEO schema, content and media production, mobile-optimised layouts, and analytics and tracking.
View the projectWritten for the same decisions
Useful reading while you are deciding.
Editorial, not client proof.
Questions an institution asks
Answered directly.
What should a college or university website include?
An information architecture built on your real structure — campuses, schools, departments, programmes — with one page per programme carrying the fields a decision needs, a page per campus, the admissions process explained rather than implied, faculty and research information as you publish it, and an accessible, crawlable version of everything currently trapped in PDFs. The test is whether a prospective learner and their parent could choose you from the site without phoning first.
Should every programme have its own page?
Every programme you genuinely run, yes — with content written for it. What should not exist is a page per combination of programme, level, mode, campus and city: those become near-duplicates that compete with each other in search and confuse a reader. One canonical page per programme, with its campuses and modes shown as properties of that programme, is both better for a learner and stronger in search.
How should application dates and deadlines be shown?
Read from whichever source actually owns them — the admissions office, an admissions system or a central calendar — and used to decide what the page offers. While a window is shut the page shows the information and a way to register interest; when the source says it is open, the action becomes the application. What a page should never do is infer a window from the fact that the programme page is live, or display a date nobody authoritative published.
Can a website decide whether somebody is eligible?
No, and it should not appear to. A programme page publishes the eligibility criteria as the institution wrote them, and a prospective learner reads them — that is normal and useful. Whether they actually qualify is an institutional assessment, and nothing we build tells a person they are eligible, ineligible, admitted or rejected. That also means no page offers what would amount to educational or legal advice about their situation.
How should rankings be displayed?
With the publisher, the year and the category, or not at all. A ranking is the ranking body’s fact, not the institution’s, and a bare claim like "among the top ten" detached from who said it and when reads as marketing and ages badly. If a current, published position exists, presenting it accurately is more persuasive than inflating it — and we do not create, interpret or upgrade one.
How should placement statistics be presented?
From your own published report, with the period and the scope it covers, as a past result. Presented that way a genuine figure is credible and useful. What must not happen on the way to the page is the conversion of a historical statistic into an implied outcome for the next cohort — no placement guarantee, no average package promised, no career outcome asserted.
Can Branditify verify our accreditation or improve our ranking?
No. Recognition, approval and accreditation are granted by the relevant bodies and evidenced by your institution; rankings are awarded by their publishers. Branditify builds the structure that presents them accurately and credits them correctly. Anything that would amount to verifying, interpreting or influencing that status sits entirely outside what a digital partner should be doing.
How can SEO help a college or university?
Mostly by fixing structural problems rather than by adding keywords. Large institutional sites typically suffer from near-duplicate programme pages, content locked inside PDFs, scattered subdomains splitting authority, and no canonical discipline across level and mode variants. Resolving those — with one authoritative page per real programme, department and campus, and the entity architecture that lets a search or answer engine describe you accurately — is where the durable gain is.
Can campus visits and open days be booked online?
Yes, against dates the institution has actually opened, confirmed to both sides, and landed on the enquiry record with the programme and campus context attached. The discipline that matters is what a booking does not mean: it is a visit, not a reserved place and not an application, and the interface should never blur the three.
Can old website content and URLs migrate?
Programme, department, faculty and media content migrates reasonably well. The work that needs judgement is the long tail — pages nobody has owned for years, and content that has quietly gone stale — because deciding what should not come across is more valuable than moving everything. Old URLs get a redirect plan where they carry real search equity, and only there.
Is a custom build better than a standard CMS for higher education?
Not automatically, and often not. A well-configured CMS with the right content model gives departmental authors a governed way to publish and is a known quantity for your IT team. Custom earns its place when your programme taxonomy does not fit any content model cleanly, when multi-campus governance cannot be expressed in templates, or when an application handoff has to be built rather than embedded. Architecture first, platform second.
Who owns the website, the systems and the data?
Your institution. Source code, hosting, data ownership, exports and handover are agreed in the project scope before work begins, and third-party tools stay under your own accounts wherever the platform allows it. Prospective-learner and enquiry data is yours to export at any point, and nothing is built in a way that makes leaving us expensive.
Start
Begin with one programme, and the page you already know is not deciding anything.
Tell us your structure — campuses, schools, programmes — what your current site says about one of them, and where an enquiry goes today. We will come back with the architecture, the programme journey and the handoff it needs, and with the parts you should keep rather than rebuild.
Branditify builds the public website, the search architecture and the systems around the admissions journey. Programmes, eligibility, fees, accreditation, rankings and every admission decision stay with your institution and its own process.