Back to articles

AI SEO 审计：为什么一次会话无法覆盖整个网站

SEOReport Team·
ai-seo-auditseo-auditai-agentstechnical-seosite-audit

在一次聊天会话中进行的 AI SEO 审计，只能覆盖它实际读取的页面。本文从网站规模、页面之外的证据，以及只存在于页面之间的冲突三方面说明原因。

AI 助手很擅长审查单个页面：它读取提供给它的标题、各级标题和正文，并说明应当修改什么。但一次 AI 会话无法审计整个网站，原因有两个。第一，SEO 审计所需的大部分证据并不在助手读取的页面文本中，而是在响应头、robots.txt、XML sitemap、重定向以及页面之间的关系里。第二，网站规模一旦超过一定程度，其 URL 数量就会超出一次会话能够同时读取并相互比较的范围。第一个原因的影响更大，而且换用更大的模型并不能缩小它。

SEOReport 在 2026 年 5 月至 10 月间审计了 45 个外部网站，在标记出的 506 个问题中，有 94% 位于页面读者永远看不到的地方。本文依次说明覆盖率的算术、这些证据所在的位置，以及如何借助 AI 审计网站：在助手开始修复之前，先给它一份网站级诊断。本文是为什么 AI 抽查无法替代系统化的 SEO 审计一文的延伸，那篇文章比较了两种方法，本文则聚焦于数据。

一次聊天会话能接触到什么，网站审计又会记录什么

在聊天中进行的 AI 网站审计，通常从一个 URL 开始。助手的抓取工具请求该页面，把收到的内容交回来（通常已转换为可读文本），然后对话围绕这段文本展开推理。系统化审计则从更高一层，也就是整个网站开始。它会读取对整个主机生效的文件，记录所请求的每个 URL 的 HTTP 响应，比较原始 HTML 与渲染后的页面，然后再把页面彼此比较，并与 sitemap 对照。

flowchart TD A["您把一个 URL 粘贴到聊天中"] --> B["抓取工具请求该页面"] B --> C["返回页面，通常为纯文本"] C --> D["针对这一个页面的建议"] E["系统化审计从整个网站开始"] --> F["robots.txt 和 XML sitemap"] E --> G["状态码、响应头、重定向跳转"] E --> H["原始 HTML 与渲染后的页面"] E --> I["sitemap 和链接所指向的页面"] F --> J["页面之间相互比较"] G --> J H --> J I --> J J --> K["逐个 URL 给出附带证据的发现"]

单个 URL 的这条路径是有价值的工作。但它只是网站众多路径中的一条，而且每一步都可能丢失信息。转换为文本时，访客能读到的文字会保留下来，head 中的标签和响应头却可能被丢掉。而下一次会话开始时，并不包含本次会话读过的页面。

您要助手审计的网站有多大？

SEOReport 在 2026 年 5 月至 10 月间审计的 45 个外部网站中，有 15 个（33%）在 robots.txt 指定的地址或 /sitemap.xml 上都没有 XML sitemap。在 sitemap 至少列出一个 URL 的 29 个网站中，sitemap 所列 URL 数量的中位数约为 90 个；四分之一的网站列出 20 个或更少，四分之一列出超过 440 个，规模最大的十分之一列出超过 3,000 个。

XML sitemap 中列出的 URL 数量，29 个外部网站，2026 年 5 月至 10 月

这些网站是提交给 SEOReport 进行审计的网站，并非整个网络的随机样本，整体偏小。即便如此，差异依然很大：规模最大的十分之一网站列出的 URL 数量，是规模最小的四分之一网站的 150 多倍。那三分之一在预期地址上没有 sitemap 的网站同样值得注意。对它们来说，助手或爬虫在惯常的位置找不到页面清单，只能沿着链接逐个抓取来发现页面。

用 AI 完成整站 SEO 审计需要多少次会话？

下表是一个模型，而非实测。它用上文的 sitemap 规模，除以假设的单次会话能够完整读取并仍可并排比较的页面数。假设如下：

  • 一次会话会把每个 sitemap URL 完整读取一次，并保留下来，以便与其他页面比较。
  • 表中给出两种容量：每次会话 25 个页面和 100 个页面。两者都只是示意。实际容量取决于助手、它的抓取工具以及每个页面的体量，我们没有对此进行测量。
  • 只计算 sitemap 中的 URL。robots.txt、响应头、重定向跳转和渲染后的页面都会额外增加工作量，因此表中每个数字都是下限。
20 个 URL，四分之一分位点11
约 90 个 URL，中位数41
447 个 URL，四分之三分位点185
超过 3,000 个 URL，规模最大的前 10%120+30+

在拥有 sitemap 的 29 个网站中，约有一半在宽松假设下可以把整个 sitemap 放进一次会话。这正是基于聊天的审查最站得住脚的情形。超过中位数之后，所需会话数会随网站规模增长，而这些会话加起来也并不等于一次审计。

除非助手具备记忆功能，或者您把笔记粘贴到下一次会话中，否则每次新会话开始时，都不包含上一次会话读过的页面。笔记携带的是结论。而后续的比较需要证据本身：第 12 页上确切的规范网址，第 340 页那次重定向背后的状态码。此外，如果会话每次都自行选择做法，不同批次检查的内容就可能不同，因此第 7 批和第 8 批并不是用同一种方式测量的。

大部分 SEO 证据并不在您粘贴的页面上

会话数量还是较小的问题。下图取 SEOReport 在 2026 年 5 月至 10 月间审计的 45 个外部网站中标记出的 506 个问题，按照查看其证据时需要去看的位置进行归类。其中 94% 位于页面读者永远看不到的地方：响应头、head 标签、结构化数据、XML sitemap、robots.txt、重定向，或页面之间的关系。

506 个已标记问题的证据所在位置，45 个外部网站，2026 年 5 月至 10 月

在同样这 45 个网站中（2026 年 5 月至 10 月），每个网站都至少有一个已标记问题位于页面可见文本之外，其中 24 个网站（53%）的全部已标记问题都在可见文本之外。中位数网站的已标记问题分布在 5 个不同的证据位置，四分之一的网站分布在 6 个或更多位置。即使完全不计安全响应头，其余已标记问题中仍有 91% 位于页面可见文本之外。

每个位置都需要各自的查看方式：

  • HTTP 响应。 Google 关于阻止编入索引的文档（2026 年 10 月核对）指出，noindex 可以通过 X-Robots-Tag 响应头发送；其关于指定规范网址的文档指出，rel="canonical" 可以通过 HTTP Link 响应头发送。这两者都不会出现在页面文本中。
  • robots.txt。 Google 的 robots.txt 文档（2026 年 10 月核对）指出，该文件必须位于顶级目录，且其规则只适用于提供该文件的主机、协议和端口。www.example.com 和 shop.example.com 各自遵循自己的文件，我们的 robots.txt 与抓取权限指南对此有详细说明。
  • 原始 HTML 与渲染后的页面。 Google 的 JavaScript SEO 文档（2026 年 10 月核对）指出：Google 使用渲染后的 HTML 为页面编入索引；canonical 最好放在 HTML 中，JavaScript 不应将其改为其他 URL；Google 遇到 noindex 时可能会跳过渲染。SEOReport 在 2026 年 5 月至 10 月间对 34 个外部网站比较了服务器返回的原始 HTML 与渲染后的页面，其中 7 个（21%）在搜索引擎最先读取的内容上依赖 JavaScript：标题、meta description、canonical 或 H1 要在 JavaScript 运行后才出现，或者原始 HTML 中几乎不包含页面文字。读取转换后文本的助手只会看到这两个版本中的一个，而对话中很少说明是哪一个。

有些问题只存在于页面之间

在同样这 45 个外部网站中（2026 年 5 月至 10 月），有 32 个（71%）至少存在一个无法在任何单个 URL 上看到的问题：只有把 sitemap 与其列出的页面相比较、把页面彼此比较，或把文章库作为整体阅读时，这类问题才会显现。若不计文章库，这一数字为 45 个中的 28 个（62%）。

下面以一个示例网站说明这类证据的形态：

text
# https://www.example.com/robots.txt
User-agent: *
Disallow: /checkout/


# https://www.example.com/sitemap.xml lists
https://www.example.com/checkout/
https://www.example.com/old-services/      (answers 301)


# https://www.example.com/en/services/ declares
hreflang="es" -> https://www.example.com/es/servicios/


# https://www.example.com/es/servicios/ declares
no hreflang link back to /en/services/

每个文件单独看都没有问题。只有把它们放在一起读时，问题才会出现：

  • sitemap 与页面相互矛盾。 Google 的 sitemap 文档（2026 年 10 月核对）指出，sitemap 并不能保证其中的 URL 会被抓取和编入索引；其规范网址文档则把列入 sitemap 视为一个较弱的规范化信号。列出会重定向、被屏蔽或带有 noindex 的 URL，就是在发送相互矛盾的信号。SEOReport 在 2026 年 5 月至 10 月间抓取了 29 个外部网站的 sitemap 页面，其中 8 个（28%）至少有一个 sitemap URL 会重定向、带有 noindex 标记，或被 robots.txt 屏蔽。
  • robots.txt 掩盖了 noindex。 Google 的文档指出，被 robots.txt 屏蔽的爬虫永远看不到页面上的 noindex；如果有其他页面链接到该 URL，它仍可能被编入索引。要发现这一点，需要把 robots.txt 和页面放在一起看，我们的可索引性冲突分析对此做了详细梳理。
  • hreflang 缺少回链。 Google 关于本地化版本的指南（2026 年 10 月核对）写道："如果两个网页没有相互指向对方，这些标记将被忽略。"要确认这一点需要同时查看两个页面，hreflang 实施指南对此有演示。
  • canonical 指向有问题的目标。 如果 canonical 指向的页面会重定向或带有 noindex，只有同时抓取该目标页面才能发现。

只要一次聊天会话恰好同时掌握了两半证据，它就能发现其中任何一个问题。但在多次会话中，这两半证据很容易落在不同的对话里，结果哪一次对话都看不到问题。

如何核实 AI 网站审计实际覆盖了什么

在根据助手的审计结果采取行动之前，请让它提供四样东西：它抓取过的 URL 列表、它读取的 robots.txt 规则行、您首页的状态码和响应头，以及它是否比较过原始 HTML 与渲染后的页面。如果它拿不出来，就应视为这次审计没有覆盖这些内容。然后把它的 URL 列表与您的 sitemap 对照。

这些证据您也可以用三条命令自行收集：

bash
curl -s https://www.example.com/robots.txt
curl -s -D - -o /dev/null https://www.example.com/ | grep -iE '^(HTTP/|location|x-robots-tag|link)'
curl -s https://www.example.com/sitemap.xml | grep -o '<loc>' | wc -l

第二条命令会发出一个普通的 GET 请求，并只打印响应头。如果您的 robots.txt 指定的 sitemap 地址不是 /sitemap.xml，请改用该地址。如果 sitemap 是索引文件，最后得到的数字是子 sitemap 的数量，而不是页面数量。还要确认助手确实拿到了您的页面。在 2026 年 5 月至 10 月间提交给 SEOReport 的 377 个外部网站中，至少有 51 个（13.5%）不允许自动爬虫评估其首页，至少有 34 个（9%）返回了人机验证或 CAPTCHA。助手的抓取工具同样是自动客户端；如果它遇到的是验证页面，它审查的就是那个验证页面。我们关于屏蔽爬虫的机器人防护的文章专门讨论了这种情况。

先给助手一份网站级审计，再让它修复

在诊断之后的工作上，助手表现很出色：解释一项发现、编写模板改动、起草重定向映射表、改写标题。一次会话所缺少的，是一份网站级、可重复的输入。完整的 SEOReport 诊断正好提供这一点。它会读取 robots.txt 和 sitemap，检查您的首页，以及从 sitemap 所列页面和内部链接所指页面中抽取的样本，记录所请求的每个页面的 HTTP 状态码，并比较首页的原始 HTML 与渲染后的页面。它会报告只存在于页面之间的发现，例如与所列页面相矛盾的 sitemap 条目、指向不存在页面的内部链接，以及内容近似重复的文章。每项发现都附带证据并列出受影响的 URL，每项基于抽样的发现都会说明检查了多少个页面。每次诊断都以同样的方式运行同一套既定检查，因此同一网站的两份报告可以逐项比较。

代理（agent）可以通过 MCP 服务器和 REST API 创建报告、轮询进度并读取每一项发现。这样，它的会话就能从诊断结果出发，把容量用在修复上，一次处理一项发现。代理页面介绍了这种配置方式。

常见问题

ChatGPT 能做 SEO 审计吗？

任何能力足够的助手都能审查提供给它或它能抓取到的页面，并清楚地解释问题。但整站 SEO 审计还需要 robots.txt、sitemap、响应头、原始和渲染后的 HTML，以及跨页面的比较。请把聊天中的审计看作对它所读页面的审查，并要求它提供这份页面清单。

更大的 AI 模型能弥补这一差距吗？

更大的容量会提高上述模型中每次会话可处理的页面数。但它不会把证据搬进页面文本：响应头、robots.txt 和跨页面冲突仍然需要有意识地抓取和比较。固定的方法与容量同样重要，因为正是它让两次运行的结果保持一致。

对于小型网站，一次 AI 会话够用吗？

对于只有 20 个左右 URL 的网站，一次会话可以读完所有页面。但它仍然需要拿到 robots.txt、sitemap、响应头和原始 HTML，所以请明确要求提供这些内容。规模只是问题中较容易的那一半。

我应该把整个 sitemap 粘贴到聊天中吗？

粘贴 sitemap 只能给会话一份 URL 列表，并不能给它页面本身、页面的响应头或状态码。助手仍然需要逐个请求这些 URL，于是又回到了上文的会话数量算术。

获取您网站的完整诊断

一份有据可依的报告和优先级行动计划，采用每月积分的订阅方案。

观看影片查看定价