AI 网站审计：如何借助 AI 智能体审计网站，从证据到验证修复

1. 什么是 AI 网站审计

网站审计检查网站如何构建、交付和连接：是否受到保护，搜索引擎和 AI 系统能否读取，用户能否正常使用，速度如何，以及加载了哪些第三方服务。AI 网站审计在这项工作中加入了 AI 智能体。智能体启动检查、阅读结果、用通俗语言解释，与你一起决定先修什么，并为将要修复的人或编码智能体撰写变更请求。

有三种截然不同的做法，常被用同样的词来描述：

本文讨论第三种做法，因为 AI 在这里能真正节省时间，同时每项发现都有可核对的证据。检查保持可重复，智能体则增加判断、上下文，并负责与发布变更的人和工具交接。如果你还不熟悉 MCP，可以阅读 MCP 指南，其中用通俗的语言解释了主机、客户端、服务器和工具。

2. AI 智能体单独能做什么、不能做什么

语言模型非常擅长阅读、总结和写作，但它不是网络工具。除非应用为它提供相应的工具，否则它看不到浏览器或爬虫在可见页面之下所看到的内容。下表对比了单独工作的智能体（最多带一个网页浏览工具）与基于结构化检查工作的同一智能体。

带终端的编码智能体，例如 Claude Code、Codex 或 Cursor，也可以自己运行 curl、dig 或 openssl。这有助于确认某一项发现，但智能体是边做边选命令：覆盖范围取决于它想到检查什么，每次运行结果各异，而且没有任何机制把它的探测限制在你已验证的域名内。

中间一列的风险是有名字的。OWASP 的 LLM 应用风险清单把错误信息描述为看似可信的虚假或误导性输出，幻觉是主要原因之一，当人们不加核实就信任时，危害更大。在审计中，它表现为：对一个模型从未读取过记录的域名声称“DMARC 策略设置为 none”，或者指出服务器实际上已经发送的响应头缺失。

第二种风险来自页面本身。读取网站的智能体读取的是不受信任的文本，页面可能带有针对模型的指令，有时对人类访客不可见。OWASP 称之为间接提示注入。谨慎的审计配置会把页面内容当作要报告的数据，而不是指令，并让人批准智能体采取的任何操作。

智能体擅长的，是证据之外的一切：解释某项发现对这个具体网站意味着什么、归并相关发现、询问检查无从得知的背景（那个旧的预发布子域名还在用吗？），以及撰写足够精确、能让编码智能体照做的修复请求。这种分工正是优秀 AI 网站审计的核心。

3. 需要覆盖的六大领域及各自的检查清单

全面的网站审计要检查六个层面。每个层面回答不同的问题，产出不同类型的证据。网站审计指南沿着一条客户旅程走完这六个层面；下面是实用的检查清单。

安全

• HTTPS 和 TLS：受信任的证书链，未来几周内不会到期，使用 TLS 1.2 或 1.3，且 HTTP 会重定向到 HTTPS。
• 安全响应头：HTML 响应上应有 Strict-Transport-Security、Content-Security-Policy、X-Content-Type-Options、框架嵌入保护和 Referrer-Policy。
• CORS：携带私有数据的响应不应有 Access-Control-Allow-Origin: *，也不应出现反射来源并配合凭证的情况。
• DNS 与邮件 DNS：每个发送邮件的域名都有有效的 SPF 和 DMARC 记录，从不发送邮件的域名则使用严格的记录（v=spf1 -all、p=reject）。
• 暴露的文件和密钥：/.env、/.git/或旧备份等路径无法访问，前端 JavaScript 中没有 API 密钥。
• 子域名：没有指向已删除云资源、可能被他人认领的 DNS 记录（子域名接管）。
• 攻击面：只开放你有意开放的端口和 HTTP 方法，了解所有登录和管理页面，如果运行 WordPress，CMS 和插件要保持最新。
• 供应链：第三方脚本只从你选定的来源加载。

其中一些检查只读取公开信息。另一些，例如请求敏感路径或扫描端口，会发送需要所有者同意的请求，所以审计工具只应在你已验证所有权的目标上运行它们。网站安全审计指南介绍了应用层面：账户、权限和登录。

技术 SEO

• 可抓取性：robots.txt 没有屏蔽你希望被索引的页面或资源。
• 索引：重要页面上没有误加的 noindex，站点地图列出的是 canonical URL。
• 标题和 meta 描述：存在、唯一，并能描述页面。
• 标题层级：一个清晰的主标题和合乎逻辑的大纲。
• Canonical：每个页面指向其首选 URL，而不是重定向或错误页面。
• 结构化数据：与可见内容一致的有效 JSON-LD。
• 内部链接和重定向：重要页面可从导航或内容到达，没有多次重定向形成的链条。
• Search Console 数据：展示量高但点击率低的页面，以及你排名恰好略低于顶部结果的查询。这些往往是最快见效的改进。

这里有一个重要的局限。Google 在索引页面前会渲染 JavaScript，但其 JavaScript SEO 基础知识仍然建议使用服务器端渲染或预渲染，部分原因是有些机器人无法运行 JavaScript。读取静态 HTML 的审计看到的页面，就是这些机器人看到的样子；如果网站在浏览器中构建内容，请把审计结果与渲染后的页面对照。技术 SEO 审计指南对此有更深入的讲解。

AI 可见性就绪度

• AI 爬虫策略：每个 AI 爬虫的 robots.txt 规则符合你的决定，而不是没人选择过的插件默认值。一些服务商为其搜索和训练爬虫分别提供了文档化的标记；例如 Google 在其搜索爬虫之外介绍了 Google-Extended。
• llms.txt：可选。这是一份列出最有用页面的简短 Markdown 索引，主要适合文档密集的网站；llms.txt 指南说明了它能做什么、不能做什么。
• 实体清晰度：各处使用相同的企业名称、描述、地点和联系方式，并以 Organization 结构化数据作支撑。
• 可回答性：页面在靠前位置、以文本而非图片的形式，直接回答真实的客户问题。
• 提示词覆盖：列出买家会向助手提出的问题，并为每个问题指出你网站上回答它的页面。
• 来源信号：署名的作者或组织、日期和引用，使页面便于被引用和归属。

这些是对自有内容的就绪度检查，并不能说明任何助手目前是否引用了你；那需要另外记录问题和回答。Google 表示，其 AI 功能除了常规的搜索收录资格外没有额外要求，因此抓取权限和清晰的内容才是首要。AI 可见性审计指南介绍了如何构建问题集。

无障碍

• 文本替代：每张有信息的图片都有有意义的 alt 文本，装饰性图片使用空 alt。
• 表单：每个字段都有可被程序识别的标签，而不只是占位符文本。
• 结构：标题顺序正确，有 main 和 nav 等地标，并提供跳转链接。
• 名称：每个按钮和链接都有可访问名称，没有空链接。
• 语言：页面用 lang 属性声明语言。
• 人工检查：仅用键盘操作、可见的焦点、颜色对比度、缩放与重排，以及用屏幕阅读器走一遍。

W3C 明确指出，工具无法自动检查无障碍的所有方面，必须有人工判断。自动检查能发现缺失的标签，但标签是否合理只有人才能判断。无障碍审计指南介绍了对照 WCAG 2.2 的人工检查。

性能

• Core Web Vitals：在页面加载的第 75 百分位上，最大内容绘制（LCP）在 2.5 秒以内，下一次绘制的交互（INP）在 200 毫秒以内，累积布局偏移（CLS）不超过 0.1（web.dev）。
• 优先看真实用户数据：当页面或网站流量足够被收录时，Chrome UX Report 数据显示真实 Chrome 用户在过去 28 天内的体验；Lighthouse 实验室结果则帮助你找出原因。
• 移动端优先：测试重要页面的移动版本，例如首页、产品或服务页面，以及结账或联系表单。
• 常见原因：过大的首屏大图、阻塞渲染的脚本和字体、由未设置尺寸的图片或延迟出现的横幅造成的布局偏移，以及沉重的第三方标签。

PageSpeed Insights 文档指出，实验室数据与真实用户数据可能不同，实验室得分高并不意味着真实访客体验良好。网站性能审计指南介绍了如何把一项缓慢的指标与造成它的元素联系起来。

集成

• 清单：页面上的每个分析工具、标签管理器、广告像素、同意管理工具和站点验证标签，以及各自的负责人。
• 重复和遗留：同一个分析标签装了两份，或是去年已结束活动留下的像素。
• 同意：需要时设有同意管理工具，并且标签会等待用户同意。
• 个人数据：标签读取的数据层、URL 或页面标题中不含电子邮件地址、电话号码或姓名。例如 Google 分析帮助要求网站所有者不要在 URL、标题和事件中包含个人身份信息。

静态检查只能显示标记所声明的内容。标签是否真的等待同意，或点击之后触发了哪些事件，需要在打开开发者工具的浏览器会话中查看。网站集成审计指南演示了这一追踪过程。

4. 如何一步步用 AI 审计网站

Model Context Protocol（MCP）是 AI 应用调用其他服务工具的通用方式。接入审计服务后，聊天或编码工具中的智能体可以直接运行检查并处理结果。工作流共九步；前两步每个网站只需做一次，其余步骤在每次审计时重复。

1. 连接。在 AI 客户端中把审计服务添加为 MCP 连接，并通过浏览器登录。需要账户的远程 MCP 服务器通常使用 OAuth，如 MCP 授权规范所述，因此你在登录窗口中批准访问，无需把密码或 API 密钥粘贴到聊天中。Sitelemetry 在 ChatGPT、Claude、Claude Code、Codex 和 Cursor 中都以这种方式连接；MCP 连接指南列出了各客户端的步骤。
2. 设定范围和授权。确定哪些网站和页面在范围内，只审计你拥有或获得书面许可测试的网站。被动检查读取任何访客都能看到的内容；主动安全检查会发送探测请求，因此应在你验证了域名控制权之后再运行。用平实的话告诉智能体范围：只限生产环境、这三个 URL、不提交表单。
3. 运行审计。要求完整审计或某一个领域：“对 https://www.example.com 运行完整审计，并按严重程度列出发现。”较长的审计可能作为后台任务运行；让智能体等待结果，不要另起第二次扫描。
4. 阅读证据。每项发现都应附有严重程度、观察到的证据、影响和修复建议。对评为高危的发现，要求智能体引用证据，并用 curl -sI 或 dig 自己复现一两项。能复现的发现，才能放心修复。
5. 排序。先按严重程度排序，再按暴露程度（页面是否公开、是否涉及登录或支付），最后按工作量。把共用同一个修复的发现归为一组，例如在同一服务器配置中设置的几个响应头，并询问智能体哪些发现对这个网站重要，哪些在此处风险较小。
6. 向编码智能体交付可直接执行的修复提示词。把选定的发现整理成一份精确的变更请求，包含证据、约束、验收标准和复测步骤（示例见下）。交给在你代码仓库中工作的编码智能体；如果同一个客户端有仓库访问权限，也可以由它一并完成。
7. 通过正常流程上线。审阅 diff，在预发布环境测试，并像对待其他变更一样部署。审计不能取代代码审查，编码智能体在没有人批准的情况下也不应部署。
8. 复查以验证。部署后对同一目标运行同样的检查。只有新的结果不再显示该发现，它才算关闭，而不是智能体说它修改了某个文件就算。
9. 监控。设置审计定期重复，让插件更新、新标签或即将到期的证书在访客察觉之前就被发现。对大多数小型网站，每周一次即可；每天部署的网站适合每日运行。

MCP 规范建议设置人工介入，让人可以拒绝工具调用；OWASP 则把过度代理单独列为一项风险，即智能体拥有的功能、权限或自主性超出任务所需时，可能造成破坏性操作。实践中：让审计工具只负责读取，代码变更和部署则由人批准。

让编码智能体无需猜测即可执行的修复提示词大致如下（示意性示例）：

Fix: Strict-Transport-Security header missing
Target: https://www.example.com (all HTTPS responses)
Evidence: GET / over HTTPS returned 200 without a
Strict-Transport-Security header.
Constraints:
- Change only the header configuration of the web server or CDN.
- Use max-age=300 for now (first rollout stage); no preload.
- Do not change redirects, cookies or other headers.
Acceptance criteria:
- curl -sI https://www.example.com/ shows a
  Strict-Transport-Security header with max-age=300.
- The header is present on HTML, CSS and JavaScript responses.
Retest:
- Re-run the security audit for www.example.com and confirm
  the finding no longer appears.

每个部分各有作用。证据告诉编码智能体观察到了什么，免去重新发现问题。约束让变更保持小范围；从较短的 max-age 开始 HSTS 并分阶段提高，是 HSTS 指南所述的稳妥做法。验收标准是任何人都能运行的命令，复测步骤则用发现问题的同一检查来完成闭环。

5. 如何评估 AI 网站审计工具

搜索最好的 AI 网站审计工具，会看到很长的榜单。合适的选择取决于你的网站，但区分一款有用的 AI 网站审计工具与“附带扫描器的聊天机器人”的问题，对每款产品都一样。

然后在依赖任何候选工具之前，先在自己的网站上测试：

• 运行两次，对同一页面且不做任何改动。发现和严重程度应当一致。
• 手动核对三项发现，安全、SEO 和无障碍各一项，使用 curl、dig 或页面源代码。
• 在预发布环境植入一个已知问题，例如没有 alt 文本的图片或重复的标题，看它是否被报告。
• 修复一项发现并复查。它应该消失，且无关的内容不应有变化。
• 阅读其局限说明。说明自己不检查什么的工具，比声称什么都检查的工具更值得信任。

第 8 节列出了 Sitelemetry 的覆盖范围、如何交接修复以及它的局限。

6. 常见陷阱及规避方法

这些陷阱背后的道理都一样。把智能体当作一位反应快、表达清晰、但没见过服务器的同事：给它证据，限制它的权限，并在线上站点上检查结果。

7. 实例：一家小型诊所的网站

一家牙科诊所在 www.example-clinic.com 运行一个带在线预约表单的 WordPress 网站。办公室经理把审计服务连接到她的 AI 助手，验证域名，并要求对首页和预约页面做完整审计。结果中包括（示意性数据，非真实）：

智能体解释了为什么前两项优先：备份会让任何猜到路径的人获取数据，而跟踪代码中的地址会被每个读取数据层的第三方标签收到。它还询问屏蔽 AI 爬虫是否出于有意。没有人做过这个决定，于是这成了所有者要做的决策，而不是一项修复。

对于备份，修复不是改代码：删除该文件，查找服务器上的其他副本，弄清是哪个进程生成了它。然后检查访问日志中是否有更早的下载，更换备份中包含的所有密码或密钥，如果患者数据可能已暴露，则按诊所的数据泄露流程处理。对于表单标签，智能体写了一份修复提示词，指明这五个字段及其所在的预约页面，约束是视觉设计保持不变，验收标准是屏幕阅读器会为每个字段朗读标签。开发者的编码智能体完成修改，开发者审阅并部署，复查显示该发现已消失。DMARC 记录交给管理 DNS 的人，按 DMARC 部署指南所述，从 p=none 并带报告开始。每一项都以同样的方式收尾：修改、部署，再用发现问题的同一审计复查一遍。

8. 用 Sitelemetry 运行这一工作流

Sitelemetry 是围绕本文工作流构建的 AI 网站审计工具：

• 六大领域。安全方面，Enterprise 套餐最多包含 27 个模块：DNS、SPF 和 DMARC、TLS、HTTPS 状况、安全响应头、CORS、暴露的文件、API 和密钥暴露、子域名接管、供应链、认证面、开放端口、HTTP 方法、WordPress 等。技术 SEO，包括 Google Search Console 的点击、点击率、排名位置和快速改进项。AI 可见性就绪度、无障碍、通过 PageSpeed Insights、Lighthouse 和 CrUX 真实用户数据进行的性能检查，以及集成。
• 证据与修复。每项发现都带有严重程度、证据、影响和修复建议，每次审计还可以生成一份可直接交给智能体执行的修复提示词，包含约束、验收标准和复测步骤。
• 在你的 AI 工具中使用。它通过 MCP 和 OAuth 登录，在 ChatGPT、Claude、Claude Code、Codex 和 Cursor 中工作；MCP 连接指南介绍了如何连接。OAuth 登录意味着你在浏览器窗口中批准访问，无需把密码或 API 密钥粘贴到聊天中。
• 验证与监控。修复后复查，在线上站点上确认。根据套餐不同，监控按每周、每天或每小时运行。报告可导出为 JSON 或 PDF，Enterprise 套餐支持白标报告。
• 套餐。Starter $49/月，Professional $149/月，Enterprise $249/月；价格页面列出了各套餐的内容。

它的局限正是本文要求你去寻找的那些。托管审计只观察目标而不改动，主动安全检查只在已验证的目标上运行。SEO、AI 可见性、无障碍和集成检查读取静态 HTML，不执行 JavaScript。AI 可见性检查的是内容就绪度，不会去查询 AI 助手。无障碍检查是静态的，以 WCAG 2.2 为导向，不是完整的人工评估，安全审计也不是渗透测试。对于静态分析看不到的部分，请保留第 3 节中的人工检查。