ExperienceKit: Why University Websites Break at Scale, and How to Fix It

This post is part of the ExperienceKit series. New to ExperienceKit? Start with the introduction, which the whole series builds on.

This article looks at the structural reasons university websites break at scale, and at the approach that fixes it: a governed component library, combined with AI page generation fast enough that nobody needs to route around it.

The scale problem is organizational before it is technical

A university is a federation rather than one organization with one website: faculties, departments, institutes, research centers, administrative units, student services, each with its own leadership, budget, priorities, and often its own opinions about the web. The website mirrors that federation.

Central web teams sit in the middle of an impossible equation. They are accountable for the whole estate: brand, accessibility compliance, quality, security. But they control almost none of the day-to-day publishing. Editing rights are spread across hundreds of people. A common pattern is a large decentralized editor pool where web publishing is a small slice of each person's actual job, done occasionally, learned once at onboarding, and rarely refreshed. Add academic-cycle turnover, with student workers and rotating administrative staff, and the central team is effectively running continuous onboarding for a workforce it does not manage.

Governance policies are written for exactly this situation. They also fail in exactly this situation, for a simple reason: policy scales linearly with enforcement effort, and enforcement effort is the one resource central teams do not have.

The four failure modes

The symptoms differ campus to campus, but they cluster into four patterns.

1. Departmental sprawl

Every department wants, and often legitimately needs, its own presence: program pages, event pages, research showcases, admissions funnels. When the central pipeline is slow, departments solve their own problem. Subsites multiply. Off-CMS microsites appear on page-builder platforms, invisible to central analytics, brand review, and accessibility monitoring. The estate's true size becomes unknowable; audits routinely surface sites the central team did not know existed, still bearing a logo two rebrands old.

2. Brand drift

Brand drift at a university comes from entropy more than rebellion. An editor cannot find the right component, so they approximate one with a rich-text field and inline styles. A department's student webmaster prefers a different button treatment. A faculty imports a template from somewhere. None of these people intend to weaken the brand. But a prospective student clicking from central admissions to a departmental page experiences the drift directly, as a small signal that the institution's left hand does not know its right. For an organization whose product is, in part, credibility, that signal is expensive.

3. Accessibility debt

This is the failure mode with legal weight. Universities are held to accessibility standards (WCAG conformance under regulations that vary by country but converge on the same requirement), and enforcement applies to the whole estate, including the pages nobody central ever reviewed. Under a page-by-page model, accessibility depends on the least-trained editor's most recent edit: heading levels chosen for looks, images without alt text, links reading "click here," color combinations that fail contrast. Auditing thousands of decentralized pages one at a time amounts to admitting that most pages will never be audited. The debt compounds silently until a complaint or a monitoring notice makes it urgent.

4. The slow-page spiral

The three problems above share a root cause: the official path is slow, so people leave it. A typical sequence, familiar enough to be a composite of nearly every campus, looks like this. The recruitment office needs a landing page for open day. The request enters the central queue behind a faculty migration and a security update. The estimate is four weeks; the event is in five. The page ships days before the event, the campaign window mostly gone. Next cycle, the office skips the ticket and buys a landing-page tool. The page goes live in a day: off brand, off domain, unaudited, and outside every system the university uses to measure and govern its web presence.

The spiral is self-reinforcing. Every shortcut increases sprawl; sprawl increases the central team's remediation load; remediation load makes the queue slower; the slower queue justifies the next shortcut.

Why more policy doesn't fix it

The instinctive response is stronger governance: tighter brand guidelines, mandatory training, editorial review boards, lock-downs. Universities have tried all of these, usually several times. The results are consistent (modest, temporary improvement, then regression) because each remedy asks hundreds of occasional editors to hold more rules in mind while doing a task that is peripheral to their job, and asks the central team to police compliance with capacity it does not have.

The lesson is that governance-by-vigilance is the wrong architecture, not that governance is hopeless. The versions of governance that work at university scale are the ones where the correct outcome is the only available outcome: where compliance is a property of the system, not of each editor's memory.

There is a useful analogy inside every university already: nobody polices whether departmental letterhead uses the right logo, because the letterhead is a template and the logo is simply on it. Web governance keeps failing because the web equivalent of the template (a system where the brand and accessibility decisions are physically embedded in the building blocks) has been missing. That is the gap a governed component library closes.

The fix: decide once at the component level, then remove the wait

The fix takes two moves, and they only work together.

Move one: a governed component library

Instead of governing pages, govern the parts pages are made of. A governed component library (in Drupal, a set of Single Directory Components) turns every institutional standard into a structural property:

• Brand is decided once. The hero, cards, CTAs, and typography are designed, approved, and built centrally. Editors compose pages from them; they no longer make (or botch) visual decisions, because the components carry the decisions.
• Accessibility is decided once. Each component ships with correct semantics, contrast, focus behavior, and keyboard support, reviewed at build time. Every page assembled from the library inherits that review. The audit burden collapses from thousands of pages to dozens of components.
• Change becomes possible. A rebrand or an accessibility fix is a component update that propagates estate-wide, not a multi-year crawl through departmental pages.

This is what BrandKit is: the governed component library at the heart of ExperienceKit, a set of Single Directory Components built on your brand and delivered as part of the solution. We design, build, and maintain the components, so the institutional standards live in the parts every page is made of, not in a policy nobody has time to enforce.

Governed component libraries are established practice in higher ed, and teams that have worked with one know both its value and its Achilles' heel: it governs only the pages people build with it, which is why move one fails without move two.

Move two: make the fast path the governed path

People bypassed the official path because it was slow, not because it was governed. So the fix must attack the speed, and this is where AI page generation changes the equation.

With CampaignKit, the AI half of ExperienceKit, the recruitment office writes the brief it would have put in the ticket, as a plain-language prompt, and it generates the landing page in minutes, assembled entirely from the BrandKit components built on the university's brand. The page appears in Drupal as a draft, goes through normal editorial review, and publishes on the university's domain, in its analytics, under its accessibility umbrella.

The critical property is that the AI builds only from the approved components, so a generated page is on brand and accessible from the start. That makes the newly fast path also the fully governed path. The spiral runs backwards: the official route is now the quickest way to get a page, so shadow tools lose their reason to exist, sprawl stops feeding itself, and the central team's remediation load starts shrinking instead of growing.

What it looks like in practice

An open day page. Recruitment writes the prompt:

"Landing page for the April 18 open day: hero, intro on what visitors can expect, highlight cards for tours, faculty talks and student life, registration CTA, FAQ."

A draft is ready the same morning. The review is about the message, not the build. Nobody has to check whether the layout holds together or the brand is right, because the components already guarantee that. The reviewer just reads it like a draft: is the tone right, are the dates correct, does it say what we mean? The page is live weeks before the event instead of days.

A new degree program. The department drafts the prompt themselves; the generated page uses the same components as every other program page, so it is consistent with central admissions by design. The central team's involvement drops to editorial review: minutes, not a build slot in a queue.

Peak admissions season. The weeks when universities need landing pages fastest are exactly when queues are longest. Pages that must go live in hours can, and nobody has to trade away brand or accessibility to get them.

The accessibility review, next year. The estate's newest pages, historically its riskiest, are now its most reliable, because every one of them inherits component-level accessibility. The audit conversation shifts from triage to steady remediation of the legacy tail.

Getting started without a big-bang project

None of this requires rebuilding the university website. A practical sequence:

Start from the components you have, or the ones hiding in your theme. Universities with an established component library can move straight to the generation layer. Those without one usually discover they are closer than they think: the recurring sections across campaign and program pages (hero, intro, card grid, CTA, FAQ) are a small set, and building them as a governed component library, built on your brand, is a scoped project measured in weeks, not a replatform. Landing pages need surprisingly few components to cover most briefs.

Pilot with one high-volume, high-urgency page type. Campaign and event landing pages are the natural first case: they are requested constantly, needed urgently, and structurally similar. Run the first cycle with the central team reviewing everything the AI generates, partly for quality assurance and mostly because seeing the drafts calibrates everyone's trust faster than any policy discussion.

Bring the governance stakeholders in early, with the right message for each. The brand team hears "every generated page uses the approved components, so pages stay on brand." The accessibility officer hears "accessibility is decided once at the component level and inherited by every generated page." IT hears "everything lives in our Drupal, our domain, our analytics; it is native SDC in our own codebase, so there is no lock-in, and it removes shadow tools rather than adding one." These are the people who have vetoed web tools before; this time the architecture is on their side.

Measure the two numbers that define the problem. Time from request to live page, and the share of new pages built inside the governed system. Both move quickly, and both are numbers a provost or a communications VP understands without translation. They are also the numbers that turn a pilot into a program: when the open-day page took a morning instead of a month and stayed fully on brand, the case makes itself.

See it with your own components

The argument above is best evaluated the same way your editors will evaluate the tool: watch a real brief become a real page. ExperienceKit generates production-ready Drupal landing pages from a prompt, built entirely from a governed component library we deliver, built on your brand, and a demo with one of your actual campaign briefs takes half an hour.

Book a demo, or ask for the governance whitepaper and we'll send you a copy to share with your web governance group.