Website Content Governance: Who Owns, Approves and Publishes?
Website content governance defines who checks the facts, who approves changes and who can publish them.
Start with a process your team can follow. A small organisation may assign several responsibilities to one person; a larger one may need separate content owners and publishers.
Name the owner of each content type
Separate factual responsibility from editing access. A service lead may approve eligibility details while communications writes and publishes the page.
For each important content type, record:
- The person responsible for accuracy.
- The editor who prepares changes.
- The person authorised to publish.
- A backup for absences.
Give shared information one owner and, where possible, one source in the CMS. Office details and opening hours are easier to maintain when they do not need separate updates on several pages.
Agree which changes need approval
Use a short table to make the decisions clear. Adapt this example to your team:
| Change | Approval route |
|---|---|
| Typo or broken link | Authorised editor checks and publishes |
| Service eligibility or availability | Service owner approves; editor publishes |
| New service page or campaign | Content owner and communications review |
| New component or global navigation change | Design or development review plus owner approval |
| Urgent factual correction | Named person approves the correction and records it |
Identify any specialist reviewers. Give urgent changes a clear route so an incorrect page does not remain live while everyone waits for a routine meeting.
Match CMS permissions to the work
List the actions each role needs: drafting, editing, uploading, publishing, changing navigation and managing users.
Try those tasks with the actual account. Editors should be able to perform routine work without borrowing an administrator's login.
WordPress documents roles and capabilities; Statamic documents users and permissions. Ask the developer which parts of your approval process need additional configuration.
Keep the editing screens manageable
Use fields for information the site needs to organise or reuse. A resource might have a title, summary, topic, owner, document and review date.
Provide approved layouts for common pages. Make it clear when a requested change needs a new component or developer input.
Our WorkUP Queensland project used styled WordPress blocks and patterns, supported by CMS training and a recorded walkthrough.
Track the version being approved
Use clear statuses such as draft, ready for review, approved and published.
Keep approval against the version reviewed. If the wording changes substantially afterwards, send it back to the relevant owner.
Choose one place to record the decision, whether that is the CMS or a task system. The publisher should be able to find the approved wording without reconciling several email threads.
Check everywhere shared content appears
On this website, a blog's related-service cards use selected Statamic entries. Their titles and links come from those service records. Renaming one service can therefore change several articles without anyone editing the articles themselves.
Include those dependencies in approval:
| Change | Review beyond the editing screen |
|---|---|
| Service title or URL | Cards, navigation and links using that record |
| Shared notice or contact detail | Every template that displays it |
| Download replacement | Pages linking to it and people using the old file URL |
For WordPress sites, synced patterns are another example: editing the shared pattern updates its uses. Agree who can make that wider change.
Show editors how to recover mistakes
During handover, practise previewing a change and restoring a previous version. Include a shared content item or document if staff edit those regularly.
Check what the site's revision system covers. Statamic revisions, for example, require Pro and must be enabled for the relevant collections.
Document who handles problems that require a backup restore or developer help.
Review content when circumstances change
Set review dates for material that needs periodic checking. Also trigger a review when a service changes, a staff member leaves or a document is replaced.
Record publication, modification and review separately. On this site, articles retain their publication date and use a separate last-updated value. Checking an unchanged page can go in an internal review record without making the article look newly written.
Give “retired” a specific meaning. Historical information may need to remain with a clear notice and a link to current guidance; replaced content may need removal and a relevant redirect. GOV.UK distinguishes withdrawal from unpublishing. Removing a menu link alone leaves the page reachable through old links and search.
Use the governance worksheet with one section first. After a few updates, adjust the steps that cause confusion before extending the process.
Our website development service includes planning editing tools and permissions around the team using them.