Large websites rarely break because of one bad decision. They drift. A department publishes a campaign page nobody else knows about. A price changes in one language but not the others. A Friday plugin update stops the enquiry form, and nobody knows who approved it. Soon the site has hundreds of pages, dozens of logins and no answer to a simple question: who decides? Website governance answers it once, not in every meeting.
This guide is for in-house teams running a site with many pages, editors, departments or languages, and most of it needs only a spreadsheet and a few short documents.
What website governance covers
Website governance is the set of agreed rules for who owns each part of a website, who can change it, how changes are approved and released, and how standards are kept over time. Once several teams publish, it has to be written down and, wherever possible, built into the CMS. It comes down to six things, covered in order below: ownership, access, workflow, page structure, languages and change control.
It sits between two neighbouring jobs: maintenance keeps the software healthy, as in our website maintenance checklist, and a design system keeps every page looking and sounding like you. Governance decides who does what, so both actually happen.
Signs the site has outgrown informal rules
Two or more ticks usually means it’s time to write the rules down.
Decide who owns what
Every other rule depends on ownership: an approval workflow is useless if nobody knows who approves.
Three levels of ownership
- The site owner is accountable for the whole website: priorities, standards, the main navigation and the final say when departments disagree. Usually the head of digital or marketing.
- Section owners are accountable for the accuracy of their content: HR for careers, legal for policies, each product team for its pages. They need no web skills, just to know when their content is wrong.
- The platform owner is accountable for the technology: hosting, the CMS, plugins, integrations, security and backups. It might be your IT team, your developer or a care-plan provider, but it must be named.
An example to adapt:
| Area | Owner | Approves changes | Review |
|---|---|---|---|
| Homepage and navigation | Site owner | Site owner | Quarterly |
| Product and service pages | Product marketing | Web editor | Every six months |
| Careers | HR | HR lead | When roles open or close |
| Templates, plugins, integrations | Platform owner | Site and platform owners | Every release |
Turn your content inventory into an ownership register
Export every URL from your XML sitemap or a crawl tool into a spreadsheet, with columns for owner, last reviewed, next review and status (keep, update, merge or remove). This register is the backbone of managing a large website, showing pages without an owner, overdue reviews and duplicates at a glance.
Check it yourself. Pick ten pages at random. If you can’t name the owner of each within a minute, ownership exists only on paper.
Two rules stop it decaying: a leaver’s pages pass to a named successor, not “the team”, and a page nobody will own is merged, archived or removed, with a redirect if it ever earned traffic or links.
CMS user roles and permissions
Our guide to WordPress best practices covers the standard roles. On a large site, the harder question is giving many people exactly the access their job needs.
Map job functions to roles, not people
Define roles once, by job, then assign people to them. A typical WordPress mapping:
| Job function | Typical role |
|---|---|
| Site owner | Editor, plus a separate administrator account for settings |
| Web editors | Editor: review, publish and fix content anywhere |
| Department contributors | A custom role limited to their own content |
| Translators | A role limited to their language, where the multilingual set-up allows it |
| External developers | Administrator on staging; time-limited access on live |
Where standard WordPress roles run out
In a default WordPress install, Authors and Contributors can work with posts but not pages. Editing pages needs at least the Editor role, and an Editor can edit every page on the site, including the homepage and other departments’ content.
Three common ways to close the gap:
- Give departmental content its own content type. A custom post type for jobs, products or locations can carry its own permissions, so an HR role manages job listings and nothing else.
- Use a role management plugin to create custom roles with exactly the capabilities each group needs, and document each one.
- Route through review. Give contributors a role that can edit but not publish, so a few web editors approve every change.
Start with the simplest option: every custom role must be maintained, tested after updates and explained to new staff.
Access hygiene at scale. Make removing website access part of the HR leaver process, give every supplier account an end date, and make sure your organisation, not a supplier, holds the top administrator, hosting, domain and analytics accounts.
A content approval workflow people will follow
A common governance failure isn’t too little approval. It’s too much. When correcting a phone number takes a week, people route around the process, straight to the developer or to a new microsite. A heavy workflow creates the sprawl it was meant to prevent.
Match the approval to the risk
| Change | Example | Route |
|---|---|---|
| Minor correction | A typo, a swapped photo | Section owner or web editor publishes |
| New or rewritten content | A new page in an existing template | Contributor drafts; web editor publishes |
| High-stakes content | Prices, legal or regulated claims | Web editor plus specialist; scheduled release |
| Structural change | Templates, plugins, URLs, integrations | Change control, through staging |
Name a deputy for every approver, and agree an emergency route for corrections that can’t wait.
What WordPress gives you out of the box
Core WordPress has a light workflow. Anyone who can edit but not publish a piece of content can submit it for review, setting its status to Pending Review; editors filter by that status, then publish or schedule. Revisions can be compared and restored. Core sends no alert when something is waiting, so agree when editors check the Pending list. For many organisations, that plus clear written rules is enough.
Editorial workflow plugins add multi-step approval and reviewer notifications; check any candidate is maintained and compatible with your page builder and multilingual set-up. Either way, keep review and approval in the CMS or on staging, not in email, so “who approved this?” still has an answer months later.
Templates and components: control the structure, free the content
The strongest governance is built into the CMS, not written in a policy. When editors assemble pages from approved templates and fill in fields rather than styling by hand, most standards enforce themselves.
- Keep a template catalogue: every page type, its purpose and its required fields.
- Lock the layout, open the content. Editors change words, images and links; spacing, fonts and colours come from the system.
- Add governance fields. “Page owner” and “review by” fields on every template put the ownership register inside the CMS.
- Create a route for new components. New layouts are requested, built once and added to the catalogue, not improvised as one-off pages.
- Give campaign pages an end date, and decide at creation who removes or redirects them.
Multilingual website management
Every language multiplies the problem: versions drift apart quietly until a customer quotes the wrong price back to you. Launch decisions are covered in how to plan a multilingual website. Once the site is live, these rules keep it consistent:
- Name a source language where changes start, unless a page is deliberately local.
- Give each language a named owner, ideally a native speaker who approves its changes.
- Store shared facts once. Prices, phone numbers and specifications belong in global settings or shared fields, not retyped per language.
- Agree what must stay in sync, and how quickly:
| Content | Must match the source? | When |
|---|---|---|
| Prices, specifications, legal text | Yes, exactly | In the same release |
| Contact details and opening hours | Yes | The same day |
| Service and product descriptions | Same meaning; wording can adapt | Next scheduled release |
| News and articles | Optional per language | Language owner decides |
Removing or renaming a page in one language also affects search, because each language version’s hreflang tags point to the others. Our multilingual SEO guide explains how those tags work and what to check after changes.
Change control: staging, releases and release notes
Content flows down, code flows up
On WordPress, content, settings and page-builder templates share one database, so copying a staging site over the live one can wipe out every edit made since the copy was taken. The safe pattern:
- Content is edited on the live site, through the approval workflow.
- Code, plugins, templates and settings change on staging first and are tested against a recent copy of live content. Code is then deployed; template and setting changes are repeated on live or moved with an export tool, never by overwriting the live database.
Custom code belongs in version control, so every change is recorded and reversible. The website development guide shows how this fits into a proper build.
Release on a rhythm, with a note every time
A fixed release window, such as one day a fortnight, is easier to plan around than ad hoc changes. Avoid releasing before weekends, holidays or big campaigns; true emergencies, such as an urgent security fix, skip the window and are documented afterwards. Each release gets a short note:
- What changed, in plain language, and why
- Who requested and approved it
- What was tested, including forms and tracking in every language
- How to roll back, and where the pre-release backup is
Share it with section owners, who often spot problems first.
One site, a multisite network or separate sites?
WordPress multisite runs a network of sites from one installation: shared code, themes and plugins, separate content per site, and a Super Admin who controls the network.
| At a glance | One site | Multisite network | Separate sites |
|---|---|---|---|
| Updates | Once | Once, affecting every site | Each site separately |
| Permissions | Site-wide; finer control needs custom work | Per site; only the Super Admin installs plugins and themes | Fully separate |
| Main risk | Permission sprawl | One faulty update can affect every site | Duplicated effort and drift |
Choose one site when audience and brand are shared, however many departments contribute. That is most organisations.
Choose a WordPress multisite network for many sites with the same structure, such as brands or regions in a group, where a central team owns the platform and local teams own their content. Check early that your essential plugins support multisite; moving a site out of the network later takes real work.
Choose separate sites when audiences, systems or risks differ, or when a business unit might one day be sold. Our guide to choosing a CMS helps if they may not all belong on one platform.
The governance documents worth writing down
Keep each short, store them where editors work, and give each an owner:
- Ownership register: pages, owners and review dates.
- Roles and access policy: roles, who approves accounts, how leavers are removed.
- Publishing rules: approval bands, deputies and the emergency route.
- Template catalogue: page types and how to request a new one.
- Translation rules: language owners and what stays in sync.
- Release process: the release window, note template and rollback.
Review them yearly. A rule the CMS doesn’t enforce and nobody checks is only a suggestion.
What to do next
Start small. This week, review who has access and remove anyone who shouldn’t have it. This month, build the ownership register and write one page of publishing rules. Then put staging and release notes in place for everything that isn’t content.
Many in-house teams would rather hand over the platform side. Our website care plans cover core, theme and plugin updates, regular backups, and security and uptime monitoring, so your editors can focus on content. If the structure itself is the problem, with years of one-off pages and no templates, a website redesign is the moment to build governance in. Not sure which applies? Talk to us about what your site needs.