Website Content Governance When a Hundred People Can Publish

A website with one editor has a content problem. A website with a hundred editors has a governance problem, and they are not solved the same way. Universities, counties, school districts and large nonprofits all end up in the second category, usually without deciding to — publishing rights accumulate, and eventually nobody can say who owns the tuition page or which of four office-hours listings is correct.

Redesigns do not fix this. A new design imposed on an ungoverned content estate looks better for about a year and then drifts back, because the forces that produced the mess are still operating. What follows is what actually holds.

The failure is structural, not personal

It is tempting to frame this as departments being careless. They are not. A departmental editor has another job, was given CMS access and twenty minutes of training, and is trying to publish something before a deadline. Every shortcut they take is rational given those constraints.

So the design question is not "how do we make people care about heading structure." It is "how do we make the correct thing the easiest thing." Governance that depends on everyone reading a style guide will fail. Governance built into the tools mostly will not.

Make the accessible option the default option

The highest-leverage move is a component system that does not permit the common failures. If editors assemble pages from components rather than a free-text editor, then headings come out in order, images demand alt text before saving, colour contrast is fixed by the component rather than chosen per page, and link text comes from a field rather than "click here."

This is the difference between a site that passes an audit at launch and one that still passes two years later. Our accessibility audits regularly find builds that were sound on day one and non-conformant since, entirely through content added by well-meaning editors with a rich-text box and no guardrails.

Name an owner for every page

Not a department — a person, recorded in the CMS, with a review date. Ownership by department means ownership by nobody, because the department does not read anything.

The review date is the important half. A page with an owner and a twelve-month review date generates a task; a page with an owner and no date generates nothing. Most organizations find that a third of their pages have no defensible owner at all, and that discovery is itself the beginning of the cleanup.

Separate the pages that must be right from the ones that merely exist

Not all content deserves the same governance. A tuition page, an eligibility rule, a set of office hours and an emergency notice carry real consequences if wrong. A department's news post from 2019 does not.

Identify the pages carrying facts people act on — usually a surprisingly short list — and govern those tightly: named owner, short review cycle, and ideally a single source referenced everywhere else rather than the fact being retyped on six pages. Let the long tail run on lighter rules. Trying to govern everything equally is how governance programmes collapse.

Give facts one source

The most common content failure in a large estate is duplication. Office hours appear on the department page, the contact page, the visit page and the homepage. Three of them are wrong within a year, and nobody knows which.

Structure the CMS so a fact is entered once and referenced everywhere it appears. This is a content-model decision made during the build, and it is very hard to retrofit — which is why it belongs in the specification. It also determines whether AI assistants quote you correctly, as covered in GEO for government websites.

Match permissions to competence, not seniority

Most large sites have one permission level: can edit. That means a new departmental assistant has the same power as the web team over templates and navigation.

A workable model has three tiers. Contributors draft within components and cannot alter structure. Publishers within a department can publish departmental content. A central team owns templates, navigation, shared components and anything carrying an accessibility guarantee. Add approval workflow only where the content justifies it — universal approval queues become rubber stamps within a month.

Train on tasks, and record it

Training that tours the CMS is forgotten immediately. Training that walks through the six things this person will actually do — publish a news item, add a document, update a staff profile, change hours, post a notice, add an image with alt text — survives.

Record it, and keep the recording with your handover documentation. In an organization with turnover, the recording is what onboards the next person, and it is the difference between governance that decays with staffing changes and governance that does not.

Plan for retirement, not just publication

Every large estate has thousands of pages nobody has read in years, and every one of them is a maintenance liability and a possible source of a wrong answer.

Build retirement into the cycle: pages with no owner and no traffic get flagged, reviewed and either re-owned, updated or removed with a redirect. Removal needs a destination — a 404 on a page someone linked to is a failure even if the content deserved to go. See our migration checklist on handling that properly.

What to specify in a build

If you are procuring a site for a many-publisher organization, put governance in the requirements: a component-based editing model with accessibility enforced in the components; a content model with single-source facts; three-tier permissions; per-page ownership and review dates; task-based training with recordings; and a documented retirement process.

Those requirements cost something, and they are the difference between a site that degrades and one that holds. We treat governance as part of the build rather than a document delivered afterwards on higher education and municipal projects.