Websites for every department, lab and event, under one university brand

A university does not have one website. It has a central site, then dozens or hundreds of department pages, research lab sites, conference and event sites, centres, and student organisation pages, many of them built by whoever had time that semester. This page is about running that long tail: who builds what, how the brand stays intact, what public institutions need to know about the ADA Title II web rule, and where a white-label site platform does and does not fit.

TL;DR

The four kinds of site a central web team never quite controls

Most universities already have a content management system for the main site, and it is usually run well. The problems sit at the edges, and each edge has its own shape.

Academic departments and schools

Departments want their own voice: programme pages, faculty profiles, seminar series, news. They usually have a part-time communications person, or an administrator who "does the website" alongside everything else. The risks are stale facts (last year's admissions deadline, a professor who left) and drift from the brand, because a department that finds the central system too slow starts a separate site.

Research labs and centres

A lab site belongs to a principal investigator and is usually maintained by a PhD student or postdoc. It lists people, publications, open positions and datasets. Labs are where you find the most sites nobody remembers: the student who built it graduated, the PI moved institutions, and the site still sits on a university subdomain with a 2019 "join us" page. A lab site needs a clear owner and a clear end: what happens when the PI leaves or the grant ends.

Conferences, events and campaigns

A conference site has a hard start and a hard end. It needs registration information, a programme, travel details, and then it needs to be archived (not deleted, because papers and recordings get cited). Events are the cleanest case for a short-lived site with an end date written down when it is created.

Student organisations

Clubs and societies change officers every year. Whatever the outgoing treasurer built, the incoming one usually cannot log in to. Student sites need the lightest editing tools, the strongest guard-rails, and a rule that access belongs to the role, not the person.

A structure that works

The pattern we recommend, whatever platform you use:

Site typeOwner of recordWho editsApproval before publishingPlanned end
Department or schoolHead of departmentDepartment communications or adminRecommended for new pagesNone; annual review
Research lab or centrePrincipal investigatorLab membersOptional; PI's choiceWhen the PI leaves or funding ends; content handed to the department
Conference or eventOrganising committee chairEvent teamYes, until the programme is finalArchive [30-90] days after the event
Student organisationStudent activities office (the role, not a student)Current officersYesRe-confirmed every academic year

Two rules do most of the work. First, every site has an owner of record who is staff, not a student or a contractor, even if students do all the editing. Second, every site in the register has either a review date or an end date. Our website governance policy template has the full wording for roles, review cycles and retiring sites, and it fits a faculty structure with almost no changes.

Accessibility: what public institutions need to know

Public colleges and universities are public entities under Title II of the Americans with Disabilities Act. In April 2024 the Department of Justice published a rule requiring the web content and mobile apps of state and local government entities to meet WCAG 2.1 Level AA. ADA.gov's guidance on the rule lists public universities and community colleges among the kinds of entity it covers.

In April 2026 the Department published an interim final rule that pushed the compliance dates back by a year. They are now:

Which date applies depends on the population of the state or local government your institution belongs to, or on whether it is a special district (some community college districts are). ADA.gov's guidance says parts of a government without their own population figure use the population of the larger government they belong to. The interim rule did not change the WCAG 2.1 AA standard. The Department said it may propose changes to the substance of the 2024 rule, and that otherwise it expects to apply the rule at the new dates. Confirm your own position with your general counsel and accessibility office.

Things in the rule that matter for the long tail of university sites:

For the practical side, use our website accessibility checklist and the WCAG guide. No platform makes a site compliant by itself: templates can be built to help, but the alt text, headings, link wording, captions and documents that editors add have to be checked too.

Where We.Inc fits, and where it does not

We.Inc is a white-label site platform: the university runs a brand account, and each department, lab, event or student organisation gets its own account and site under it. What that gives you today:

What it is not: it is not a replacement for a large enterprise CMS running the main university site with deep integration into your student information system, course catalogue or identity systems. The honest fit is the long tail around it. We do not publish accessibility conformance claims, security certifications, data-residency guarantees or uptime figures; if your procurement needs those answers, ask us directly and we will tell you what we can and cannot provide.

Questions to settle before a pilot

  1. Which unit owns the register of sites, and who can say no to a new one?
  2. Which domains will sites use (subdomains of the main domain, or departmental domains)?
  3. What happens to a lab site when its PI leaves?
  4. Who checks accessibility on new templates, and who checks content?
  5. Which sites need approval before publishing in the first term?

A sensible pilot is one academic department, two labs, one upcoming conference and two student organisations: five different owners, five different life cycles. Book a demo and bring that list.

Sources

Last checked 2026-10-25.

This section is general information, not legal advice.

Book a demo. Pricing is tailored to your volume and setup, and you get your exact price on the call. 0% transaction fee.

Frequently asked questions

Does the ADA Title II web rule apply to public universities?

Yes. Public colleges and universities are public entities under Title II, and ADA.gov lists them among the entities the 2024 web rule covers. The rule requires WCAG 2.1 Level AA. After the April 2026 interim final rule, compliance dates are April 26, 2027 for entities with a total population of 50,000 or more, and April 26, 2028 for smaller entities and special district governments.

Do old conference and lab sites have to meet WCAG 2.1 AA?

The rule has an exception for archived content that is kept only for reference, research or record-keeping, held in a clearly labelled archive area and not changed since it was archived. A site that is still being edited does not qualify. Confirm your own position with your general counsel.

Can each department have its own domain?

Yes. In We.Inc each site can use its own custom domain or a subdomain, and the central team decides per site whether that site may connect a domain.

Can the central web team approve pages before they go live?

Yes. Approval before publishing can be the default for every site and switched on or off per site. It is a single approval step by the brand owner.

Is We.Inc a replacement for our main university CMS?

Usually not. It fits the long tail of department, lab, event and student sites around the main site, not a main site with deep student-system integrations.

Keep reading

More in White Label

We.Inc is an AI-powered website builder you can resell under your own brand. Launch a branded client dashboard, bill on Stripe Connect, and deliver AI-generated websites in minutes. White-label pricing is tailored to your volume and setup: book a 30-minute demo for a quote.

Product

Who It's For

Features

Resources

Company

View Sitemap