A complete website governance policy you can copy: who owns each page, who approves what, how often content is reviewed, how new sites get created and how old content is retired.
A website governance policy answers four questions before they turn into arguments: who is allowed to publish, who has to say yes first, how often every page gets looked at again, and what happens to content nobody owns any more. Below is a complete policy you can copy into your own document and adapt. Words in [square brackets] are the parts you fill in. After the policy there are notes on how to roll it out, and the mistakes that make policies like this fail.
It is written for organisations where more than a handful of people touch the website: a city with departments, a university with faculties and labs, a franchise network, an association with chapters, or a company with several brands. If one person runs the whole site, you need maybe a third of it: keep the content standards, the review cycle and the retirement rules.
Version [1.0] · Approved by [name, title] on [date] · Next policy review: [date, 12 months later]
This policy sets out who is responsible for [Organisation name]'s websites, how content is created, approved, reviewed and removed, and how decisions are made when people disagree. Its aim is a website that is accurate, consistent with our brand, usable by everyone including people with disabilities, and no larger than it needs to be.
This policy covers every website, subdomain, microsite and landing page that carries the [Organisation name] name or logo, including sites built or hosted by outside vendors. It covers text, images, video, documents (PDF, Word, spreadsheets), forms and embedded third-party tools. Social media accounts are covered by [name of social media policy], not this one.
The current list of sites in scope is kept in the site register (section 6). A site that is not in the register is not approved.
Every role below must have a named person and a named backup. Names are kept in the site register, not in this policy, so the policy does not go out of date when people move.
| Action | Content editor | Site owner | Web manager |
|---|---|---|---|
| Edit an existing page | Yes, then approval | Yes | Yes |
| Add a new page to an existing site | Yes, then approval | Yes | Yes |
| Publish without a second person | No | [Yes / only for urgent notices] | Yes |
| Create a new site or subdomain | No | Request only | After group approval |
| Change templates, logo, colours, fonts | No | No | After group approval |
| Add or remove an editor | No | Request | Yes |
| Add a third-party embed, form or tracking script | No | Request | With technical lead sign-off |
| Unpublish a page or site | Own pages only | Own site | Any (section 9) |
All new and changed content is checked by someone other than its author before it goes live, except for the urgent notices in 5.3. The approver confirms:
5.1 Turnaround. Approvers respond within [2 working days]. If an approver does not respond, the content editor may escalate to the web manager.
5.2 Legal and regulated content. Content about [fees, admissions, eligibility, employment, health and safety, elections, procurement] also needs sign-off from [legal / compliance / the responsible office] before publishing.
5.3 Urgent notices. Closures, emergencies and safety notices may be published immediately by [the site owner or web manager]. They are reviewed by an approver within [1 working day] and removed or updated within [24 hours] of the situation ending.
A new site, subdomain or microsite is created only when a section of an existing site cannot do the job. A request to the web governance group must state: the audience, what they need to do on the site that they cannot do now, the named site owner and editors, how long the site is expected to live, and who will retire it. Event or campaign sites must state an end date.
The web manager keeps a site register with, for every site: web address, purpose, site owner and backup, editors, approver, date launched, last full review, planned end date (if any), and the vendor or platform it runs on.
| Content type | Reviewed at least |
|---|---|
| Home pages, contact details, opening hours, fees and deadlines | [Every 3 months] and whenever they change |
| Service, programme and product pages | [Every 6 months] |
| Policies, About pages, staff and team listings | [Every 12 months] |
| News and event pages | Not reviewed; retired under section 8 |
Each quarter the web manager sends every site owner a list of their pages that are past their review date. A page still overdue [60 days] after that notice is unpublished under section 9. Each year the site owner confirms in writing that their site is still needed, and the register is updated.
The web manager may unpublish any page, without waiting for the site owner, if it: contains wrong information that could harm someone or create liability; breaks brand standards in a way the site owner has not fixed within [10 working days] of being told; is past its review date as set out in section 7; or contains a security problem. The site owner is told the same day and the page is restored once fixed. Disputes go to the web governance group, then to the executive sponsor.
Accounts are personal; shared logins are not allowed. Editors are added only at the site owner's request and removed within [5 working days] of leaving the role. The web manager reviews the full list of accounts every [6 months] with each site owner. Vendors get accounts only for the length of their contract.
Our target is [WCAG 2.1 Level AA / WCAG 2.2 Level AA]. Templates are tested by the web manager before release. Editors are responsible for the content they add (section 5). We publish an accessibility statement with a way to report a barrier, and reports are answered within [5 working days].
Any new website platform or vendor must be approved by the technical lead and the web governance group. Contracts must allow us to export our content, our code where we paid for it, and our data in usable formats at any time and at the end of the contract.
This policy is reviewed every 12 months by the web governance group and re-approved by the executive sponsor. Questions go to [web manager email].
A governance policy takes something away from people who used to publish whatever they liked, so the rollout matters as much as the wording.
You can run this policy on any platform, but some of it is much easier if the software does the enforcing. Check whether yours can: give each editor access to only their own sites; hold a page for approval before it goes live; lock the logo, colours and templates so only the central team can change them; show a list of every site with its owner; record who changed what; and export everything if you leave. If you are choosing a platform, our website vendor exit plan lists the contract terms to ask for.
We.Inc's white-label platform runs many sites under one brand account. Owners and admins manage the account, each site sits in its own client account with the features you allow it, publishing can be set to wait for the owner's approval (as a default for every site or per site), and the account keeps an audit log of organisation actions. Approval is a single step, not a multi-stage workflow, so if your policy needs two layers of sign-off you would handle the second outside the tool. If you want to see how a policy like this maps onto the platform, book a demo and bring your draft. See the white-label platform overview for the rest.
This template is general guidance, not legal advice. Check records retention, accessibility and procurement requirements that apply to your organisation with the people responsible for them.
A written set of rules for who owns each part of a website, who may publish, who must approve content before it goes live, how often pages are reviewed, and how content and whole sites are retired. It usually names roles such as an executive sponsor, a web manager, site owners, editors and approvers.
A common pattern is every 3 months for contact details, fees and deadlines, every 6 months for service and programme pages, and every 12 months for policies and About pages. News and events are not reviewed; they are archived or removed on a schedule instead.
The head of the unit the content describes: the department, school, location or chapter. They can delegate the writing to editors but stay accountable for accuracy. The central web team owns the platform, templates and brand standards, not the facts on each page.
Most organisations require a second person to check new and changed pages, with an exception for urgent notices such as closures, which are published immediately and checked afterwards.
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.