交付流程
让同一套标准，贯穿每个环节。
首页只是入口之一。服务页、文章或地区页面，都可能是访客第一次接触你的地方。每一个希望被搜索发现的公开页面，都需要明确的用途和同样的技术关注。
我们在模板里建立共用标准，再逐页检查内容与配置。共用模板提供基础，每一页仍然需要自己的判断。
从业务问题出发，形成页面规划，经过内容与设计、开发、发布检查和上线，再由复查结果推动下一次更新。
- 规划与设计
- 明确访客的问题，把页面接到相关信息，用清楚的标题组织已确认的内容，并安排有用的下一步。
- 开发与检查
- 交付可读取的 HTML，配置页面元信息和搜索控制，检查手机与键盘操作，并核验实际发布的结果。
- 持续维护
- 新增页面遵循相同标准。改动之后检查问题，结合能获得的搜索与使用证据，判断哪里需要关注。
每一个新增页面，都进入一套持续维护的系统。
内容更新
让每次更新，成为经过检查的发布。
静态交付仍然支持持续发布。确认后的编辑可以来自源码文件，或单独约定范围的无头 CMS 集成。公开网站交付生成后的结果。
更新经过构建和检查后再上线。构建失败时，应保留当前发布版本；恢复需要使用已知版本，并检查相关的外部服务。
确认后的源码或 CMS 编辑触发构建与预览；检查失败则返回修正，通过后发布；上线后的问题可以触发恢复已知版本。
- 编辑输入
- 客户提供或确认行业内容。约定包含 CMS 时，编辑者可通过界面持续更新，共用模板保持页面结构。
- 预览检查
- 检查内容、链接、元信息、适用 schema、手机布局和交互。网址变化需要同时核对跳转与 canonical。
- 恢复边界
- 回退网站版本，只恢复网站发布结果，不会撤销支付、CMS 编辑或其他外部服务操作。这些系统需要各自的恢复流程。
每次修改都经过检查，并有明确的恢复方式。
持续维护
把观察，变成有计划的改进。
维护覆盖页面可访问性、失效链接、过时信息、搜索访问，以及体验变化。工具与权限决定哪些情况能够直接观察。
我们区分需要修复的故障、新增功能和研究假设。改进遵循与原始交付相同的检查和发布流程。
检查与可获得的报告揭示问题；诊断产生范围明确的修复或提案；经过检查的发布和复核，把所得认识带到下一轮巡检。
- 发现与诊断
- 检查页面及相关服务，找出实际原因，记录需要改变什么。Search Console 和可获得的使用报告，可以为诊断提供依据。
- 做合适的改动
- 在约定照看范围内维护已有功能。较大的变化单独评估，确保负责人、成本和业务用途明确。
- 复核与学习
- 检查实际发布的页面与外部工作流。观察能获得的证据，判断改动效果，并保留有助于后续决策的认识。
持续维护，是检查、判断和复核不断进行的循环。
交接与成本
让下一位接手的人，也能看懂网站。
源码只是交接的一部分。有经验的开发者还需要构建与部署说明、内容模型、外部依赖，以及明确的账户与访问方案。
静态文件可以迁到合适的托管环境。迁移仍需检查域名、跳转、canonical、表单和外部服务。外部平台有自己的条款和迁移限制。
源码、构建说明、内容与资源、服务账户信息，以及网址规则，构成交接材料；接手者部署到合适环境后，检查公开页面与集成。
- 技术交接
- 提供源码、依赖和构建信息、部署说明、内容结构，以及运行网站需要的配置。
- 账户与依赖
- 明确域名、托管、CMS 和服务账户的归属，安排适当的访问交接。密钥不进入公开文档和源码资源包。
- 分别说明成本
- 域名续费、托管用量、外部服务和 SiteMonk 订阅，是不同的费用。静态交付可以减少运行时维护；实际费用取决于选定服务和用量。
可迁移，需要源码、运行资料，以及经过核验的交接。