打开 PageSpeed Insights 或 Chrome 开发者工具，这几天你会看到一个新增的检查分组：Agent 可发现性。它问的不是标题写得好不好，而是更直接的一件事——你有没有「能被 AI 直接调用的东西」，以及这些能力有没有一份机器读得懂的清单。

加的不是排名检查，是能力清单检查

这来自 9 月 18 日发布的 Lighthouse 13.5：新版加了一项 ard-schema 审计，并把原本的 llms.txt 审计归进这一组。官方说它会在两周内进入 Chrome 156 的 DevTools 和 PageSpeed Insights，算下来就是这几天。

先讲最容易误读的地方：发布说明没把它和 Google 搜索、AI 概览挂钩。它在实验性的 Agentic Browsing 分组里，和 SEO 分开，不给 0 到 100 分，只给通过比例。别当成排名因素。

ARD 是什么：给能调用的东西做一份目录

这项审计检查的是 ARD（智能体资源发现）目录。它解决的问题很具体：AI 得判断「谁会做这件事」，但现在的做法是把工具描述全塞进上下文比一遍，多到几百上千个就走不通了。

ARD 的思路是把「找能力」从模型里挪出来：你在自己的域名上放一份目录，写清提供哪些可调用资源（MCP 工具、智能体、Skill、普通接口都算），注册中心抓下来建索引，Agent 按任务意图检索；找到地址后，调用还是走原来的接口。类比：传统搜索帮人找到网页，ARD 帮 Agent 找到能力。

检查的位置和规范的位置，对不上

Lighthouse 找目录的顺序是：robots.txt 里的 Agentmap 指令、页面里 rel 为 ai-catalog 的 link 标签、响应头同名链接，都没有就兜底试 /.well-known/ai-catalog.json。

而 ARD 规范 0.91 版（8 月 26 日）已把标准位置改成 /.well-known/ard.json，并提示旧路径的目录「可能找不到」。所以只按新规范做的站，在这一版里会被判成 Not Applicable——不是你做错了，是工具还在看旧位置。过渡期做法很朴素：两个路径都放一份，robots.txt 加 Agentmap。要分清两种结果：Not Applicable 是没找到可调用资源，对内容站是中性的；真正的失败是目录不符合规范，或指针指向的目录加载不出来。这两种才要修。

同一组里的 llms.txt 审计是另一堂课。它从 13.3 就在，坑很典型：文件是 .txt、也按纯文本返回，但 Lighthouse 用 markdown 解析，纯文本链接一律不算链接；改成方括号加圆括号的写法，审计就从「不符合建议」翻成通过。但它测的是能不能被解析，不是有没有人在读——Google 搜索侧公开说过它不影响能否出现在 AI 结果里，规范也把用途收窄到了文档和接口参考。

落到这周，只有三个动作

  • 先盘资源，再谈发布。 没有能被调用的东西，这一行永远显示 Not Applicable，什么都不用做。
  • 有接口的两边都放。 规范位置发一份，兼容路径留一份，robots.txt 加 Agentmap，一份真源头两个入口。
  • 进技术巡检，别进 SEO 报表。 归属写「Agent 就绪度」，只看两条：目录能否加载、是否合规。分数不必追。

这一行检查透露的信号更重要：AI 侧的可见性，正在从「内容能不能被引用」往「能力能不能被找到和调用」延伸。现在想清楚这件事的公司，等审计铺进所有人的报告时不会慌。