AI 代理做 SEO 检查时，实际看到了您网页上的什么

当您让 AI 代理检查某个网页的 SEO 时，它通常是基于转换成文本的网页来工作的。各级标题和正文能到达它那里；HTTP 状态码、响应头、重定向跳转、head 标签和结构化数据通常到达不了。因此，代理能很好地审查您的文字，却无法确认决定搜索引擎是否将该网页编入索引的大部分因素。

不同助手的抓取工具各不相同，而且会随时间变化，所以真正有用的问题是：代理到底收到了什么。2026 年 10 月，我们用自己的一个网页回答了这个问题，把完整的 HTTP 交互记录与代理所依据的文本视图并排记录下来。本文如实报告我们运行了什么、每种视图包含什么，以及如何把代理缺失的证据交给它。

我们用两种方式抓取了自己的一个网页

我们选择了一篇已发布的文章，即我们的重定向链指南，并使用一个用户可能会粘贴到聊天中的较长地址来请求它：http://www.seoreport.dev/articles/redirect-chains-guide/。纯 HTTP、www 主机和末尾斜杠都是网站会进行规范化的变体，因此这个请求必然会发生重定向。

我们用 3 种方式读取了它：

1. 完整的 HTTP 交互：使用 curl，记录每一次跳转、最终的状态行、每一个响应头以及原始 HTML。
2. 对同一份 HTML 的纯文本提取：去掉脚本、样式和 <head>，保留可见文本。这正是许多抓取工具在助手读取网页之前所做的转换。
3. 某款 AI 编程助手内置的抓取工具：要求它逐项报告所收到内容中确实存在的东西，不做推断。

在本文关心的每一项上，视图 2 和 3 的结果都一致，因此下表将二者合并显示。唯一的区别是：抓取工具传递了网页的 title，而纯文本提取保留的是 H1，二者文字相同。

按大小计算，文本视图约为 10 KB，而 HTML 响应为 71 KB。被丢掉的大部分是脚本和样式代码，任何 SEO 审查都用不到。剩下的，恰恰是 SEO 审查本该读取的证据。

表格中有两个细节比数字更重要。第一，关于 canonical 标记的答案取决于我们的提问方式。当要求它把每个标记标为“存在或不存在”时，抓取工具对一个网页确实具有的 canonical 回答了“不存在”，之后才补充了一句关于 <head> 的说明。而当我们提供“无法判断”这一选项时，它选择了后者。一个收到第一种回答并据此行动的代理，会建议您添加一个早已存在的标记。第二，Article JSON-LD 和 article:modified_time 标记中都带有 2026 年 10 月 3 日的修改日期，而网页上可见的署名只显示了 2026 年 9 月 28 日的发布日期。搜索引擎能读取为“最后更新”的那个日期，只存在于代理从未收到的那部分网页中。

这个网页本身没有任何问题。两次重定向跳转远低于 Google 抓取文档所说其爬虫会跟随的 10 次上限，canonical 也指向网页自身。我们的结论是：无论有没有问题，代理都无从得知。

抓取工具只在网页出错时才报告状态码

我们又用一个在我们网站上并不存在的地址重复了测试。服务器返回了 404，抓取工具也如实说明：它报告了 "HTTP 404 Not Found"，并且没有返回任何网页文字。而在正常网页上，200 从未被提及。

这种模式（错误会显示出来，成功的响应则悄无声息）恰恰漏掉了最麻烦的那些情况，因为它们返回的都是 200：

• 看起来像“不存在”、却返回 200 的网页。 我们的 404 页面上写着 "Article Not Found. The article you are looking for does not exist."。如果服务器以 200 状态码发送同样的文字，文本视图将一模一样。只有状态行能告诉搜索引擎它究竟是哪一种；当 Google 检测到返回 200 的这种网页时，Search Console 会将其报告为“软 404”。
• 读起来毫无问题、却告诉搜索引擎不要编入索引的网页。 Google 的 robots meta 标记文档（2026 年 10 月核对）指出，任何可用于 robots meta 标记的规则，也都可以通过 X-Robots-Tag HTTP 响应头发送。以这种方式发送的 noindex 在文本中不会留下任何痕迹。如何查找并处理这类网页，请参阅Search Console 中的此网址带有“noindex”标记。
• 在响应头中声明 canonical 的网页。 Google 的文档说明，可以用带 rel="canonical" 的 Link 响应头代替 HTML 标记，这也适用于 PDF 等非 HTML 文件。文本视图看不到它。

证据在交互过程中，而不在网页上

文本视图丢掉的所有内容都属于同一类：服务器与爬虫之间交换、而阅读网页的访客永远看不到的证据。它们分布在 6 个地方。

状态码和重定向。 每一次跳转都是一个独立的响应，有自己的状态码。有些抓取工具会在发出请求前把 http:// 改写为 https://，因此从 HTTP 到 HTTPS 的那次重定向根本不会被请求。重定向与 URL 规范化指南说明了哪些跳转应当保留。

响应头。 X-Robots-Tag、Link、Cache-Control、Vary 以及各项安全响应头，都在 HTML 之前传输。它们都不是网页上的文字。

head 标签。 canonical、meta robots、hreflang、meta description 和 Open Graph 标记都位于 <head> 中，而文本转换会把它去掉。

结构化数据。 JSON-LD 位于 <script> 元素内。文本转换会去掉脚本，JSON-LD 也随之消失。结构化数据与社交元数据指南说明了它应当包含哪些内容。

原始 HTML 与渲染后的 HTML。 有些抓取工具会在转换网页前运行 JavaScript，有些则不会，而输出中很少说明是哪一种。一个内容只有在 JavaScript 运行后才出现的网页，在一个工具看来可能是完整的，在另一个工具看来却是空的。我们在AI 爬虫实际看到了什么一文中测量了这种差异出现的频率。

URL 之外的文件和网页。 robots.txt 是一个单独的文件，除非明确要求，否则代理永远不会去请求它。Google 的文档指出，当 robots.txt 屏蔽了某个网页时，Google 根本无法读取该网页上的 noindex，因此两者必须一起检查。sitemap、内部链接以及任何重复的 URL，则完全位于其他网页上。

sequenceDiagram
    participant U as 您
    participant A as AI 代理
    participant F as 抓取工具
    participant S as 您的网站
    U->>A: 检查这个网页的 SEO
    A->>F: 抓取该 URL
    F->>S: GET http://www.example.com/page/
    S-->>F: 301 和 Location 响应头
    F->>S: GET https://example.com/page/
    S-->>F: 301 和 Location 响应头
    F->>S: GET https://example.com/page
    S-->>F: 200、响应头、完整 HTML
    Note over F: 跳转、状态码、响应头、head 标签和 JSON-LD 均被丢弃
    F-->>A: 以 Markdown 格式返回可见文本
    A-->>U: 仅基于文本给出的建议

我们标记的大多数 SEO 问题都在网页文本之外

我们自己的审计数据显示，一次审查在多大程度上依赖于文本视图所丢掉的内容。SEOReport 在 2026 年 5 月至 10 月间审计了 45 个外部网站，在标记出的 506 个问题中，有 94% 位于网页读者永远看不到的地方：响应头、head 标签、结构化数据、XML sitemap、robots.txt、重定向，或网页之间的关系。

下图把这 506 个问题按“需要去哪个位置查看证据”逐一归类。

只有网页可见内容中的 5.9%，属于文本视图会保留的那类证据。按照代理需要收到什么才能看到它们来分，其余位置可归为 3 组。HTTP 状态码和响应头、head 标签以及结构化数据，合计占 506 个问题的 69%：这些证据就在网页自身的响应中，却被文本转换丢掉了。更好的文本提取无法把它找回来，直接读取响应本身才可以。XML sitemap、作为整体阅读的文章库、网页之间的关系以及 robots.txt，合计约占 20%：这些证据不包含在任何单个网页的响应中。剩下的 5.6% 需要对网页或其地址再看一次：把渲染后的网页与原始 HTML 对照、把智能手机端的响应与桌面端对照，或查看网页之前的重定向跳转。

同一样本也显示了对每个网站的影响：这 45 个网站中的每一个，都至少有一个已标记问题位于网页可见文本之外；其中 24 个网站（53%）的全部已标记问题都在可见文本之外。对这 24 个网站而言，仅限于可见文本的审查，手头将没有任何一项已标记问题的证据。

如何把代理缺失的证据交给它

代理能很好地基于它看得到的证据进行推理。解决办法就是把交互过程摆到它面前。

如果您的代理可以使用 shell，请让它运行下面这些命令，并在得出任何结论之前先把原始输出展示给您。如果不能，就由您自己运行，再把输出粘贴到聊天中。

# 1. Every hop, every status, the headers that matter (GET, following redirects)
curl -sL -D - -o /dev/null http://www.example.com/page/ \
  | grep -iE '^(HTTP/|location|x-robots-tag|link|content-type|cache-control|vary)'

# 2. Canonical, hreflang and meta robots tags from the raw HTML
curl -s https://example.com/page \
  | grep -oiE '<link[^>]*rel="(canonical|alternate)"[^>]*>|<meta[^>]*name="robots"[^>]*>'

# 3. How many JSON-LD blocks the raw HTML contains
curl -s https://example.com/page | grep -o 'application/ld+json' | wc -l

# 4. The crawl rules that apply to the page
curl -s https://example.com/robots.txt

三个习惯能让答案更可靠：

• 使用 GET，而不是 HEAD。 有些服务器对这两种请求的响应不同。我们的就是如此：测试中的第一次跳转，对 GET 请求返回 301，对 HEAD 请求返回 308。
• 先问它收到了什么，再问哪里有问题。 “列出您能看到的状态码、响应头和 head 标签”这样的提问，能把隐藏的缺口变成看得见的缺口，并让您知道哪些“不存在”的回答其实意味着“从未收到”。
• 问清楚 HTML 是否经过渲染。 如果代理的工具运行了 JavaScript，它看到的内容可能与服务器发送的不同。请将其与命令 2 得到的原始 HTML 进行比较，具体方法见 JavaScript 渲染指南。

对单个网页的完整检查，仍然只覆盖一个网页

有了完整的交互记录，代理就能正确地审查单个网页。但响应中无法包含网站的其余部分：您的 sitemap 是否列出了该网页、其他网页是否链接到它、是否有另一个 URL 与它重复、robots.txt 是否屏蔽了您的 sitemap 所宣告的网页。在上面的样本中，大约每五个已标记问题中就有一个，位于任何单个网页的响应都无法显示的地方。要覆盖这些问题，就需要在许多网页、许多会话中，用每次都保持一致的方法重复这项工作，这正是为什么一次 AI 会话无法审计整个网站一文讨论的主题。

完整的 SEOReport 诊断能在一份报告中完成其中大部分网站级工作。它会请求您的 sitemap 中列出的网页，跟踪您提交的地址经过的每一次重定向跳转，读取您的 robots.txt，并比较首页的原始 HTML 与渲染后的网页。每项发现都附带证据（状态码、响应头的值、受影响的 URL），每项基于网页抽样得出的发现都会说明检查了多少个网页。代理可以通过 MCP 服务器和 REST API 创建并读取这份报告，从而从网站的证据出发，而不是从文本出发。

常见问题

ChatGPT 能检查我网站的 SEO 吗？

它能审查到达它那里的任何内容：各级标题、正文，以及工具传递过来的 title。它是否还能看到状态码、响应头、head 标签或结构化数据，取决于它当时使用的抓取工具，而这一点因工具而异，也很少说明。请先让它列出收到了什么，或者把上述命令的输出粘贴给它。

AI SEO 检查工具和 SEO 审计是一回事吗？

AI SEO 检查工具通常只根据其抓取工具返回的内容审查单个网页。审计则会读取 HTTP 交互、robots.txt、sitemap 以及网页之间的关系，并为每项发现记录证据，使结果可以被核实和复现。两者回答的是不同的问题：前者审查网页的文字，后者确认网站实际向爬虫提供了什么。

为什么我的代理说我的网页没有 canonical 标记，而实际上是有的？

canonical 标记位于 <head> 中，而文本转换会把它去掉。在我们的测试中，抓取工具对一个确实存在的 canonical 回答了“不存在”。在根据这类建议采取行动之前，请用上面的命令 2，或在浏览器中查看网页源代码进行确认。

我的代理所用的抓取工具是否运行 JavaScript，这重要吗？

如果您的内容或标记依赖 JavaScript，就很重要。会渲染网页的工具，可能报告出原始 HTML 中没有的 title 或 H1；不渲染网页的工具，则可能把一个在浏览器中完整显示的网页报告为几乎空白。比较原始 HTML 与渲染后的网页，就能确定搜索引擎和其他爬虫最先收到的是哪一个版本。