用 AI 审计 500 页网站：需要多少次聊天会话

按本文的模型测算，通过 AI 聊天审计一个 500 页的网站，完整做一遍大约需要 21 次会话，并占用您自己大约 15 小时。更大的代价在于，这 21 份结果合起来并不等于一次审计：每个会话开始时都没有其他会话看到的证据，它们在不同网页上检查不同的内容，用各自的措辞给出结论，因此既没有统一的方法可供合并，也没有方法能在下个月重复。AI 会话非常擅长解释和修复问题；当它们从一份完整的问题清单出发时，效果最好。

无论您用 ChatGPT、Claude 还是其他助手来审计网站，下面的算术都一样，因为它源于聊天会话本身的工作方式，而不是某一款产品。本系列的第一篇文章为什么单个 AI 会话无法审计整个网站讨论了单个会话能覆盖的范围，并按每个会话 25 页和 100 页两种容量估算了每个网站所需的会话数。本文则计算不断开启新会话时会发生什么：您要花的时间，以及会话之间的结果漂移。

500 页的网站位于前四分之一，但并不少见

在这个模型中，网站规模决定一切，所以先从真实的规模说起。2026 年 5 月至 10 月间，SEOReport 审计的外部网站中，有 29 个网站的 XML 站点地图至少列出了一个网址。这些站点地图列出的网址数中位数约为 90 个；四分之一的网站列出 20 个或更少，四分之一列出超过 440 个，规模最大的十分之一列出超过 3,000 个。

这些是提交给 SEOReport 审计的网站，并不是整个网络的随机样本。500 页的网站在其中刚好进入前四分之一，通常是有博客、服务或产品页面、可能还有几种语言版本的成熟企业网站。站点地图列出的是网站希望搜索引擎发现的网页；标签页、筛选页和归档页的网址可能不在其中，因此站点地图中的数量只是审计需要考虑的网页数下限。

模型：先算每次会话的网页数，再算每个网站的会话数

这是一个模型，不是实测。其中每个数字都来自 4 条明确的假设，您可以修改其中任何一条。

1. 每次会话 25 页。 这是本系列第一篇文章所用两种容量中较低的一种。认真审查一个网页，要读的远不止可见文字：状态码、响应头、head 标签、结构化数据，以及该网页与站点地图和其他网页的关系。2026 年 5 月至 10 月间，SEOReport 审计了 45 个外部网站，标记出的 506 个问题中有 94% 位于网页读者根本看不到的地方，中位数网站的问题分布在 5 个不同的证据位置。每个网页都要掌握这么多证据，同时还要认真作答，所以会话容量应取较低值而非较高值。简单的网页可以多放一些；结构繁重的模板则要少放一些。
2. 为全站文件额外安排 1 次会话。 包括 robots.txt、XML 站点地图，以及 HTTP 与 HTTPS 之间、带 www 与不带 www 的主机名之间的重定向。
3. 每次会话占用您 20 分钟。 大约 10 分钟用于重新说明方法并交代网页清单，10 分钟用于保存输出并合并到总清单中。
4. 每个网页占用您 1 分钟。 用于抓取或粘贴网页及其响应头，并确认会话确实读取了它。助手的抓取工具返回的往往是转换成文本、不带响应头的网页，所以才需要这一步；AI 智能体检查您的网页时看到了什么一文展示了其中的差别。

公式：会话数 = 网页数 ÷ 25，向上取整，再加 1。您花费的分钟数 = 20 × 会话数 + 网页数。

与会话数相比，所需小时数对“每次会话多少页”这一假设没那么敏感，因为处理每个网页所花的分钟数不会随着会话容量变大而减少。如果每次会话 10 页，500 页的网站需要 51 次会话、约 25 小时。如果每次会话 100 页（即第一篇文章中较宽松的容量），则需要 6 次会话，但仍然要花约 10 小时。

这些小时数还没有计入 3 件事：助手自身工作的时间、修复本身，以及为检查第一遍而做的第二遍审计。

为什么 21 次会话合起来不等于一次审计

所花的时间看得见，也可以做预算。结果漂移更难察觉，而正是它让合并后的结果不可靠。

每个会话开始时都不知道其他会话的发现。 第 14 次会话不知道第 3 次会话已经在博客模板上发现了同样缺失的 canonical 标签。它会把这个问题当作新问题再报告一次，或者把一个影响 180 个网页的模板问题当成单个网页的备注。项目文件和记忆功能可以把早先的笔记带到后面的会话，这有帮助，但笔记只是结论，并不能让第 14 次会话采用第 3 次会话的判断标准。

每个会话自己决定检查什么。 当被要求审查一批网页时，助手会自行选择在每个网页上检查哪些信号。一个会话读取了结构化数据；另一个会话因为网页看起来没问题就跳过了。到最后，您知道哪些网页被打开过，却不知道哪些检查在哪个网页上执行过。

每个会话用不同的措辞给出结论。 “缺少 canonical”“没有 rel=canonical 链接”和“canonical 标签缺失”是同一个问题的 3 种写法。严重程度也会漂移：同一个问题在一个会话里是“严重”，在下一个会话里却是“轻微”。决定优先级的那个数字，即有多少网页存在同一问题，只有在您手动统一每一行措辞之后才能得出。

网页之间的问题会落在会话之间的缝隙里。 在 2026 年 5 月至 10 月间 SEOReport 审计的同一批 45 个外部网站中，有 32 个（71%）至少存在一个在任何单个网址上都看不出来的问题：只有把站点地图与其列出的网页对比、把网页彼此对比，或把整个文章库作为一个整体来读时，问题才会显现。把网站拆成每批 25 页，恰恰拆散了这些对比。分别在第 4 次和第 19 次会话中审查的两篇近似重复的文章永远不会碰面，这正是导致重复网页（用户未选定规范网页）的那些重复网页能在逐页审查中漏网的原因之一。

下个月无法重复。 同一个问题问两次，回答的措辞可能不同，偶尔连判断也不同。如果您在 12 月再做一遍这 21 次会话，发现的问题变少了，您无法判断是网站改善了，还是会话改变了看法。没有固定的方法，就没有可供比较的基准。

flowchart TD
    subgraph many["多次聊天会话"]
        A["选出下一批 25 个网页"] --> B["新会话：再说明一遍方法"]
        B --> C["会话自选检查项，并用自己的措辞作答"]
        C --> D["把它的发现复制到您的笔记中"]
        D --> E{"还有剩余网页吗？"}
        E -->|是| A
        E -->|否| F["手动合并 21 组笔记"]
        F --> G["没有可供下个月重复的记录"]
    end
    subgraph one["一次审计，再针对每个问题使用 AI"]
        H["一次审计：每次运行方法相同"] --> I["附带证据的问题清单"]
        I --> J["每个问题一次 AI 会话"]
        J --> K["之后再审计，方法相同"]
        K -->|"问题仍未解决"| J
    end

一次审计改变了什么，又没有改变什么

审计同样会抽样。SEOReport 的完整诊断会检查首页、站点地图中列出的网页，以及内部链接指向的网页。它并不会读取每一个网页；凡是基于抽样得出的问题，都会注明检查了多少个网页，因此每项结果的范围都有据可查。

它改变的是方法。每次诊断都以同样的方式运行同一套既定检查，并为每项检查记录证据，因此同一网站的两份报告可以逐项对比。那些在聊天会话之间被遗漏的对比，会在一次运行中完成：与所列网页相矛盾的站点地图条目、指向缺失网页的内部链接、近似重复的文章、相互矛盾的文章日期，以及没有任何链接指向的网页。输出是一份清单：附带证据和受影响网址的问题、按优先级排序且附有验证步骤的修复计划，以及 PDF、Markdown 和 JSON 格式的导出文件。带评分的 SEO 报告包含哪些内容详细介绍了这一结构。

它也改变了 AI 要做的工作量。2026 年 8 月 23 日至 10 月 4 日间，SEOReport 审计了 249 个外部网站，报告标记出的不同问题（未通过或警告项）中位数为 14 个，四分之一的网站有 17 个或更多。一个问题可能影响很多网页，但它仍然是一项界定清楚的任务。一份附带证据、约 14 项任务的工作清单，与 21 次漫无边际的探索性会话，是完全不同的两件事。

审计不会替代判断，也不会替您写出修复方案。这正是 AI 会话的用武之地，也是较早一篇关于 AI 抽查的文章从另一个角度提出的观点。

如何在大型网站上用好 AI 会话

交给会话的是问题，而不是整个网站。 每次会话都从一个问题、它的证据和受影响的网址开始。智能体也可以通过 REST API 或 MCP 服务器自行创建报告并读取每一项问题，详见我们的 AI 智能体页面，这样它的工作就从诊断结果起步，而不是重新摸索整个网站。

每次会话只安排一项修复。 任务范围窄，会话就能专注于一个原因，答案也便于审查。下面这种形式的提示词效果很好：

Finding: XML sitemap lists URLs that redirect.
Evidence: https://www.example.com/old-pricing -> 301 -> https://www.example.com/pricing
          https://www.example.com/team -> 301 -> https://www.example.com/about
Platform: [your CMS, sitemap generator and hosting]
Task: Explain the most likely reason the sitemap still lists these URLs on this
platform, and give the smallest change that makes it list only final URLs.
Address this finding only.

如果必须用聊天来发现问题，请先把方法写下来。 在每次会话开始时粘贴同一份检查清单，为每次会话分配固定的网页清单，并要求统一的输出格式：一张包含网址、检查项、观察值和结论的表格。这样合并就成了机械操作。这能减少措辞和覆盖范围上的漂移，但无法找回那些只在网页之间才显现的问题。

用之后的审计和 Google 来验证。 对于 Search Console 报告的任何问题，先修复所有受影响的网址，然后对其中一个网址使用网址检查中的“测试实际网址”，确认 Google 能够抓取修改后的网页。实际测试不会检查重复网页或规范网页的判定，因此对这类问题，它只能确认可访问性。接着在该问题上点击“验证修正情况”。Google 的“网页索引编制”报告文档（2026 年 10 月核对）说明，验证通常最多需要大约 2 周，某些情况下会长得多。之后的报告，或通过 API 进行的每周监控（见持续 SEO 监控），可以告诉您在发现该问题的同一方法下，它是否已经消除。

对小型网站来说情况要温和得多：按照模型，一个 20 页的网站只需 2 次会话、约 1 小时，而只涉及单个网页的问题根本不需要审计。成本随网站规模增长，可重复方法的价值也随之增长。

常见问题

具备网页浏览功能的助手能独立审计整个网站吗？

浏览功能省去了粘贴，所以模型中每个网页 1 分钟的时间会缩短。但助手仍然一次只打开一个网页，自行选择打开哪些网页，而且拿到的往往是转换后的网页文本，而不是带响应头的完整响应。不同助手的工具行为各不相同，而且没有哪一种能提供一套下个月还能以同样方式运行的固定方法。

更大的上下文窗口能解决问题吗？

它能提高每次会话的网页数，从而减少会话次数。按照模型，即使每次会话 100 页，一个 500 页的网站仍需 6 次会话、约 10 小时，因为处理每个网页所需的时间不变。而且它丝毫不影响各次运行之间的结果漂移。

每次会话 25 页这个数字现实吗？

这是一个假设，针对的是既读取文字、也读取响应头、head 标签和结构化数据的会话。您可以按自己网页的情况修改它，并套用公式：会话数 = 网页数 ÷ 每次会话的网页数，向上取整，再加 1。关于结果漂移的结论并不依赖于这个数字。

我应该把聊天记录保留下来作为审计记录吗？

可以把它们当作工作笔记保留。聊天记录记载的是会话得出的结论，通常不包含它当时看到的原始证据，例如那一刻的状态码和响应头的值。一份为每个问题都保存证据的记录，才能让人日后核查结论，并与下一次审计进行对比。