网站治理是团队决定谁可以提出、批准、实施和验证网站变更的一套运营规则。它还规定内容何时复审、合并或退役，以及出现异常时谁负责回滚和沟通。
网站治理要点
- 设置一名最终负责的网站负责人，并建立跨职能运营组。
- 按风险对变更分类，再决定审核、权限和验证深度。
- 组织责任与 CMS 权限分开设计，遵循最小必要访问。
- 发布完成必须以公开页面证据为准，不以后台“已发布”为准。
- 每项内容都应有负责人、复审日期和保留、更新、合并或退役决定。
网站治理必须回答什么
- 谁拥有网站目标、页面归属和信息架构的最终决定权？
- 谁能提交、编辑、审核、发布和回滚？
- 哪些变化需要法律、安全、品牌、无障碍或 SEO 审核？
- 团队如何证明线上结果与批准内容一致？
- 旧内容何时更新、合并、重定向或删除？
一个负责人，加一个跨职能运营组
| 角色 | 主要责任 | 不应单独决定 |
|---|---|---|
| 网站负责人 | 目标、优先级、例外与最终问责 | 超出专业范围的法律或安全结论 |
| 内容/SEO | 意图、证据、元数据、内链和生命周期 | 生产权限与基础设施变更 |
| 设计/开发 | 组件、性能、可用性和实施 | 未经批准改变页面承诺 |
| 业务/运营 | 线索定义、路由、数据与反馈 | 把未验证活动当成业务结果 |
GOV.UK 服务团队角色说明展示了多学科协作思路；具体角色应按组织规模和风险调整。
按风险选择变更流程
| 变更级别 | 例子 | 最低控制 |
|---|---|---|
| 低风险 | 错字、已验证链接、普通说明 | 同伴复核与公开检查 |
| 标准 | 正文、图片、布局、内链 | 内容审核、预览、回归 QA |
| 受保护 | 价格、承诺、客户、法律、隐私 | 指定负责人批准与证据留档 |
| 紧急 | 安全、故障、严重错误 | 缩小范围、快速回滚、事后复盘 |
组织责任与 CMS 权限分开
负责人不一定需要管理员权限，管理员也不应自动拥有业务批准权。WordPress 的角色与权限文档可作为技术权限设计参考；真实治理仍需独立的审批和审计记录。
用公开结果作为发布闸门
- 状态码、title、description、canonical、robots 和 H1 正确。
- 图片、Schema、导航、内链、表单和语言切换符合批准结果。
- 桌面与真实移动宽度无溢出、遮挡或关键交互故障。
- 缓存已刷新，站点地图与最终 URL 一致。
- 负责人、验证时间、证据和回滚点已记录。
管理内容生命周期
每页记录目的、受众、规范意图、负责人、事实来源、上次复审和下次决定。可选状态包括：保持、更新、合并、重定向、归档或删除。Digital.gov 的内容生命周期说明提供了公共部门参考。
常见问题
小团队也需要网站治理吗？
需要，但可以很轻量。一页登记表、明确负责人、风险分级和发布检查通常比复杂委员会更有用。
治理会不会拖慢发布？
设计得当的分级流程会让低风险工作更快，同时把审查集中在真正影响法律、品牌、商业承诺和用户的变更上。
下一步：先建立一页式治理登记表，列出变更类别、负责人、所需证据和发布验收。
