Website governance: page ownership, content standards, and review

Reference article · 6 min read

A public website is not a project that ends. It is a shared operating surface that staff across many departments change every week, often with no coordination beyond email. Governance is the set of written decisions that keeps the site coherent anyway: who owns each page, who may publish, what a page must meet before it goes live, and what happens to the pages nobody has touched in years.

Most agencies already have the pieces informally. A communications office watches the home page, someone in IT holds the administrator account, and each department has a person who knows how to post an agenda. Governance turns that arrangement into something written down and staffed, so the site survives turnover, reorganizations, and the departure of the one person who understood the menu structure.

Assign ownership at the section level

Ownership is clearer when it is attached to a section of the site rather than to individual pages, and to a position rather than a name.

• Owning department. Accountable for whether the content is accurate and current. Program staff, not the webmaster, decide what the fee schedule says.
• Named owner and backup, by job title. Record the position, then the person filling it. Titles outlast staff.
• Technical owner. IT owns the platform, templates, integrations, uptime, and the account lifecycle.
• Editorial owner. Communications owns navigation, page naming, the home page, and consistency of voice across departments.

Build a full inventory of URLs and map each one to an owner. Anything unmapped is an orphan; put those in a queue where a department either adopts the page or it is retired. The inventory is the backbone of everything else in this article.

Separate authoring from publishing

Most disputes about "who can change the website" dissolve once roles are explicit in the content management system.

• Author. Drafts and edits, cannot publish.
• Reviewer. Checks against the content standard and approves.
• Publisher. Pushes live. A small group, often one or two per department.
• Administrator. Configures the system. Fewer people than you expect.

Tie accounts to the agency identity system so access ends when employment does, and keep an audit log of who changed what and when. Web content can fall under public records retention obligations; requirements vary by state, so confirm with your records officer and counsel before you set any deletion practice.

Write the content standards down

A standard that lives in one editor's head is not a standard. Keep it to a page or two that an author can actually read.

• Plain language. Write for the task, not the org chart. Short sentences, active voice, second person, acronyms spelled out on first use, and a clear statement of what the reader should do next.
• Accessibility. Require headings in order, meaningful alt text, captions on video, sufficient contrast, keyboard operability, labeled form fields, and no information conveyed by color alone. A federal rule under Title II of the Americans with Disabilities Act establishes a technical standard for state and local government web content and mobile apps, with compliance timelines that differ by entity size. Confirm current obligations with your ADA coordinator and counsel rather than relying on secondhand summaries.
• Links. Descriptive link text that makes sense out of context. No bare URLs, no "click here." Check for broken and redirected links on a schedule.
• PDFs. The default is an HTML page. Reserve PDFs for documents that must be printed, signed, or filed as formal records. When a PDF is necessary, require real text rather than a scanned image, proper tagging, a document title, and a short HTML summary so the content is findable.
• Structure and metadata. Page title, short description, stable URL, and a redirect whenever a page moves.

Review on a schedule and retire what is stale

Every page gets a review interval when it is created. Seasonal content such as hours, fees, and program deadlines may need review several times a year. Ordinances and policies can go longer. News releases should age out of navigation automatically.

Give each page a review date and route the reminder to the owning position. At review, the owner picks one outcome: keep as is, update, merge into a stronger page, archive, or delete with a redirect. Record the decision and the date. A site that only grows becomes unusable; removal is part of the job, subject to your retention rules.

Intake for new sections and escalation when departments disagree

New content requests deserve a short intake form: requester, the audience, the task the reader is trying to complete, which existing pages this replaces, the owning position, the review interval, and a sunset date for anything campaign-related. Make the default answer "add to an existing section." New top-level navigation should be rare and decided deliberately.

Disagreements need a named path, not a standoff. The editorial owner decides first. Unresolved questions go to a small governance group with representatives from communications, IT, the ADA coordinator, records management, and legal, chaired by someone with authority to decide. Publish the decisions so they apply to everyone equally.

Metrics that justify the effort

Choose measures tied to whether residents complete tasks and whether the site is maintainable.

• Top internal searches that return nothing useful.
• Call and counter volume for topics that have a web page.
• Pages past their review date, orphaned pages, broken links, and untagged PDFs.
• Automated accessibility findings, paired with manual sampling, since scanners catch only part of the picture.
• Time from request to publish.
• Total page count over time. Trending down is often a success.

How to start, and what to require of the platform

1. Inventory every URL and assign an owning position.
2. Publish the one-page content standard.
3. Configure author, reviewer, and publisher roles in the system.
4. Run a retirement pass on the oldest content.
5. Set review dates on everything that remains.

When procuring or renewing a content management system, ask vendors to demonstrate role-based workflow and approvals, per-page review and expiration dates, and required fields such as alt text. Ask for an accessibility conformance report covering both the published output and the authoring interface, and ask for a live demonstration with a screen reader. Require bulk reporting on last-reviewed dates and redirects, full export of content and metadata in an open format at no additional charge, author training and documentation, and clear contract language on who remediates accessibility defects in templates versus in content.

HQT works with state and local agencies on web platforms, content operations, and accessibility practices.

Frequently asked questions