Step 1: Audit Your Content
The first step is reducing the amount of content you have to govern.
A content audit is a systematic review of everything on your site: what exists, what’s performing, and what should be archived or removed. The less content you have, the less complicated every subsequent governance question becomes.
Specifically, look for:
- Duplicate pages — the same information living in multiple departments
- Orphaned content — outdated pages with no clear owner
- Internal-facing content — material written for staff that’s been sitting in public navigation for years
- Accessibility violations — issues that could put you at risk under the April 2026 ADA compliance guidelines
Don’t skip this step. Organizations that try to build governance on top of a bloated content library make everything harder than it needs to be.
Step 2: Define Who Creates, Reviews, and Publishes
This is where governance gets political, but it’s worth being honest about that upfront.
The core tension we see most often: leadership wants tighter control over what gets published, but doesn’t have the bandwidth to manage everything centrally. Departments need to contribute. The challenge is doing that without losing cohesion.
A layered model tends to work best:
- A small core team — holds ultimate responsibility for the website
- Subject matter experts — contribute content within their department
- Communications or marketing — serves as the quality check, so content stays consistent, on brand, and approved
A common mistake is giving too many people editor permissions without centralized oversight. But it’s equally common for someone in leadership to decide they need something on the homepage and just fire it off. We’ve seen both.
A well-designed governance system works in both directions. When documentation exists, it’s easier for the person managing the site to point to a policy rather than try to win an argument based on opinion. Governance gives the web team ammunition just as much as it gives editors guardrails.
Step 3: Build Workflows and Use Your CMS to Enforce Them
Defining roles is only useful if there’s a process behind them. And the best place to enforce that process is your CMS.
A content workflow should include clear states and handoffs:
- Editors create drafts
- A new draft triggers a notification to a reviewer
- The reviewer approves, requests changes, or schedules publication
- All parties can see the status of everything in the queue.
But the workflow is only as good as the clarity behind it. Editors need to understand not just how to use the tools, but how they’re supposed to use them — which areas are designated for which content types, the expected tone, and when something is a news item versus general copy.
Any review process also needs to account for capacity. You can build all the permissions and approval systems you want, but if no one actually has time to review content, it’s only going to slow things down. Before finalizing a workflow, confirm that the people responsible for approvals can fulfill that role consistently.
Archiving belongs inside the workflow too. A plan for when content gets published, what its lifespan is, and when it comes down should be part of the process from the start — not something you deal with later.
A platform like Drupal, which powers many government and higher ed websites, can enforce a lot of this automatically. Role-based permissions control who can create drafts, who can publish, and who can modify certain sections. Required fields can mandate alt text, meta descriptions, and expiration dates before content goes live. Scheduled archiving can flag or remove content that's past its expiration date, rather than leaving that to human memory.
These technical restrictions serve a political purpose too. It’s easier to explain “the system won’t let you do that” than to win a subjective argument about whether something belongs on the homepage.
This matters especially in higher ed and government, where content is too often published from the editor’s departmental perspective rather than the end user’s. Building constraints into the CMS is one of the most effective ways to shift that thinking, because it doesn’t rely on editors making the right call every time.
Step 4: Train Your Team So Standards Actually Stick
Training is often the piece that gets shortchanged — treated as a one-time event at launch rather than an ongoing investment.
Start with a focused workshop for a core group of editors, ideally fewer than twenty. Cover the tools and the standards: not just what the editing interface can do, but how they’re expected to use it. Make training materials available inside the CMS so editors have a reference point long after the workshop ends.
For larger organizations, a train-the-trainer model works well. Train a core group, and have them train others. This distributes governance knowledge across departments rather than concentrating it in one team.
The factor that determines whether any of this sticks is leadership buy-in and dedicated ownership.
There needs to be a core team responsible for the website, and that job needs to be a genuine, protected part of their role — not something squeezed in on top of everything else. Staff turnover and inadequate time allocation are the most common reasons governance breaks down after launch.
