网站在所有者看来正常加载，搜索爬虫却可能看到空白页面，键盘用户可能无法提交表单，证书也可能临近过期。这些故障属于不同系统，一个分数无法解释全部问题。
先提出明确的问题：目标客户能否找到页面、理解产品，并安全完成重要任务？完整审计为其中一部分提供证据，但仍需要人结合业务背景判断，并测试完整用户旅程。
此审计的范围
可以测量什么
- 可用安全模块、有边界的SEO与AI内容样本、公开集成信号、静态无障碍检查，以及选定设备下的性能测量。
- 各引擎返回的发现和成功检查，以及相应证据、目标和测量范围。
不能证明什么
- 自动结果不是穷尽式渗透测试、完整无障碍评估，也不保证搜索可见性。
- 执行器结束后仍可能存在部分或不可用测量，应将覆盖范围与完成状态分开查看。
可用审计、安全模块和爬取额度取决于关联套餐及剩余用量。请查看当前价格页面；受保护目标的测试还需要适当授权。
1. 先确定问题，再选择扫描
定义重要页面和用户路径。订阅业务可以先选产品介绍、价格、注册和支持页面；商店可能更关注分类、商品、购物车和结账。记录准确主机名、环境和设备。
确认目标所有者及获准执行的测试。公开观察与主动安全测试可能产生不同影响。OWASP Web安全测试指南提供更全面的安全测试框架，自动审计只覆盖其中一部分。登录后的业务流程和破坏性测试场景应放在单独受控的评估中。
2. 理解六个审计领域
| 领域 | 有用的问题 | 重要边界 |
|---|---|---|
| 安全 | 哪些暴露设置或服务需要调查？ | 选择的模块和授权决定覆盖。 |
| SEO | 爬虫能否发现并理解样本内容？ | 有限HTML爬取不能证明已被索引。 |
| AI可见性 | 内容是否清楚、可访问且可追溯来源？ | 就绪度不是实际AI引用测量。 |
| 集成 | 出现了哪些公开集成信号？ | 脚本存在不能证明事件已送达。 |
| 无障碍 | 哪些静态标记障碍可以检测？ | 仍需键盘和辅助技术测试。 |
| 性能 | 什么拖慢加载或交互？ | 实验室与现场数据回答不同问题。 |
应结合阅读各领域。第三方组件可能同时影响性能、无障碍和数据收集。修复共同原因，而不是创建三个彼此无关的工单。
3. 根据证据和影响排序
以下是情境化的处理示例，不承诺某个扫描器一定分配相同严重级别。分配负责人前，记录受影响页面、观察值、预期行为和复现方式。
| 观察示例 | 情境中的优先级 | 应索取的证据 |
|---|---|---|
| 公开页面泄露真实秘密信息 | 若可用则为严重，应立即控制 | 脱敏位置、暴露范围、凭据负责人 |
| 商业页面意外设置noindex | 获客方面高优先级 | 响应元数据与预期索引策略 |
| 必填字段缺少可用标签 | 阻断主要任务时为高 | 标记与手动交互测试 |
| 未使用的社交预览元数据 | 低或信息级 | 相关分享平台及当前预览 |
严重程度本身不等于业务优先级。每笔结账都遇到的小问题，可能比未使用测试路由上看似严重的提示更值得先处理。
4. 将发现变成可执行修复
- 复现：按照报告中的设备或爬虫假设，检查准确URL和响应。
- 定位来源：区分应用标记、托管、CDN规则和第三方行为。
- 做最小而一致的修正：修改负责的模板或策略，让同类页面一起改善。
- 定义验收：写明能够证明解决的可观察条件。
- 明确责任：注明负责人、影响页面和发布时间窗口。
假设价格页面为空白，“改善SEO”不是可执行工单；“在保护私有API路由的同时，让渲染器取得公开套餐内容，并确认套餐表出现”才可测试。Google JavaScript指南解释了初始响应与渲染内容为何可能不同。
5. 先复测修复，再测试用户旅程
在可比较条件下重复原检查，把新证据与旧结果并列保存。不要拿桌面主页与移动结账比较，然后称之为回归。如果依赖服务失败，应先重试缺失测量，再评价网站。
- 确认报告URL已满足验收条件。
- 检查另一张共享该模板的页面。
- 用键盘及窄屏完成主要操作。
- 检查错误、输入验证提示和加载状态。
- 记录剩余人工审核与有意排除的范围。
无障碍方面，W3C初步检查是实用的手动起点。自动结果干净并不能替代这项工作。
6. 避免令人安心却误导的结论
complete: true表示流程结束，不表示所有可能条件都已测量或通过。请阅读覆盖、不可用提供商、跳过模块及样本URL。“不适用”不等于“通过”，无法访问的页面也不能提供配置良好的证据。
不要只优化综合分数。删掉有用功能可能提高性能分数，却损害产品。类似地，增加结构化数据不保证排名，AI就绪度也不展示助手引用频率。把分数作为分流辅助，并保留支持变更的具体观察。
7. 建立可重复的审核节奏
重大版本前为重要模板保存基线。托管、同意管理、导航、认证或模板发生变化后，重复相关审计及受影响旅程。使用可比较目标与设置，结果才真正说明变更的影响。
团队交接应包含四项：确认的缺陷、验证过的修复、不可用测量和人工后续工作。除技术指标外，也跟踪客户能否成功完成操作。Web Vitals指南有助于区分用户体验指标与一般质量分数。
先从一个业务关键公开页面开始。查看范围，修复证据充分且影响最大的一个问题，然后重跑该检查。通过助手使用时可查看Sitelemetry MCP设置指南，并在价格页面比较当前审计额度。
常见问题
完整审计会检查所有页面吗？
不会。爬取上限、可访问内容、所选模块、授权及提供商可用性决定实际范围。请阅读结果中的样本URL和覆盖情况。
总分很高能证明网站安全吗？
不能。分数只是已产生测量的检查摘要，无法排除未测试漏洞、损坏的登录后旅程或需要人工发现的无障碍问题。
所有信息级发现都应该修复吗？
不一定。先确认该观察是否真是网站缺陷。记录可以接受的行为，避免同一提示反复分散对重要工作的注意。
来源与延伸阅读
- OWASP：Web安全测试指南owasp.org
- Google：JavaScript SEO基础developers.google.com
- W3C：无障碍初步检查www.w3.org
- web.dev：Web Vitalsweb.dev
由 Sitelemetry 团队根据产品审计范围和链接的一手资料编写。除明确标注的实际观察案例外，示例均用于说明。
