1. 确定结果与边界
在打开审计工具之前，先命名一个负责人并写下目标。说明受众、旅程、页面或路由、时间窗口以及该工作应支持的决策。一个有用的目标描述一个任务，例如完成移动端从产品到购物车的流程，而不是模糊地希望让站点“更快”。
列出不可谈判的要点：可用的购买或咨询流程、账户访问、同意行为、无障碍、搜索抓取能力以及已批准的内容。若表单失败、内容对搜索隐藏或键盘使用变得更困难，合成分数的提升并不算成功。
用一句话写出起始页面、用户操作和成功的结束状态。
选择一个必须不变坏的结果，例如成功提交或没有新增可及性阻断项。
2. 捕获可比基线
在更改代码、内容、配置或标签之前，保存 URL 列表、日期、测试条件、发布版本、报告或跟踪以及手动任务结果。web.dev 建议在更改前记录站点状态并测试多种页面类型；对于单页应用，应包含路由、组件和流程，而不仅仅是首次加载。
使用不止一种视角。Lighthouse 提供自动化的性能、可及性、SEO 等审计。用已清除存储或干净配置文件测试首次加载，然后完成目标任务。在有足够真实用户数据时，对重要页面组和设备类别进行比较。Core Web Vitals 是现场（field）度量：LCP 涵盖加载、INP 涉及交互性、CLS 关注视觉稳定性。
现场数据反映真实访问；实验室测试使问题更容易重现。能用时两者兼用。
模拟加载无法测量 INP，因为没有真实用户输入；实验室的 Total Blocking Time 只是一个代理指标。
3. 对旅程端到端进行审计
按旅程与机制对发现项分组。审查页面资源与第三方的请求大小、时序与依赖关系。检查移动视口、键盘路径、可见焦点、标签、错误、标题层次、链接目的、缩放，以及当图片、脚本或依赖同意的服务变慢或不可用时会发生什么。
将自动化可及性输出视为分诊。W3C 表示，没有单一工具可以确定站点是否符合无障碍标准；需要有经验的人工评估。对于搜索，确保重要的渲染资源对爬虫和用户都保持可用。若变更影响它们，需包含重定向、规范（canonical）、内部链接、robots 指令、站点地图和结构化数据。
列出任务依赖的标签管理、分析、聊天、支付、字体、CDN、API 和同意工具。
对于支付、认证、用户数据、头部或安全控制，需取得合格的安全与支付评审。
4. 构建已排序的待办项清单
为每项写一个简短的假设：在此页面或流程中修改此机制，因为证据表明它造成了该问题；衡量预期结果并保护已命名的护栏。保持观察与诊断的区分。保存的跟踪(trace)可以显示一张大图延迟了内容，但补救措施仍需要设计与内容评审。
按影响（Impact）、置信度（Confidence）、工作量（Effort）与风险（Risk）对项目排序。影响对应受影响的优先旅程。置信度反映实验室、现场与人工证据是否一致。工作量包括协调，不仅是代码。风险包括依赖、安全、发布复杂性与可逆性。关键功能或安全暴露可以超过该模型并需要专家分诊。
保留负责人、证据链接、假设、页面、衡量办法、护栏、依赖、发布方式和回滚触发器。
除非出于安全需要，否则不要把无关的重构捆绑进一个可测量的变更中。
5. 安全发布并保留回退路径
在部署前记录变更内容、审批人、发布时间窗口、验证负责人、成功条件、回滚触发器与恢复方法。尽可能在具有代表性的非生产环境中测试，包括内容、权限、集成、重定向、同意选项和常见失败路径。生产环境仍可能因数据、缓存、配置与第三方而不同。
在平台支持时使用小规模推送、特性开关、版本化资源或可逆的配置。比较结果前确认缓存与 CDN 行为。OWASP 将配置与部署管理视作安全测试领域；头部、权限、文件暴露以及域或云设置不应作为随意的优化改动。
定义可观测的触发条件，例如结账失败、导航断裂、意外客户端错误或可及性回归。
回滚计划能减少恢复时间但不能消除所有风险；在依赖它之前务必测试恢复流程。
6. 验证、决策并重复
发布后，重复基线功能检查与可比的实验室测试。重新检查相关设备、浏览器、状态与集成。做到可比比较：URL、缓存状态、设备类别、可行的区域与测量窗口。确认护栏以及目标指标。
留出时间让证据充分积累。Google 指出，搜索变更可能需要数小时到数月才会显现，并建议等待数周以评估其是否有帮助。真实用户性能数据是汇总性证据，而非即时的发布结论。记录保留、修改、调查或回滚的决定；随后在模板、平台、标签、内容或依赖项发生实质性变更后重新建立基线。
预期的旅程结果改善且约定的护栏保持完好。
当现场或任务证据与实验室结果冲突，或关键护栏回退时应采取行动。