Lighthouse 13.5新增ARD审计：它还在找ai-catalog.json，规范已经改成ard.json

摘要：Lighthouse 13.5在9月18日发布，新增一项审计，检查网站的ARD目录文件是否符合规范。ARD全称Agentic Resource Discovery，是Google、微软和Hugging Face三位作者提出的草案，用来让AI代理通过搜索找到一个组织提供的MCP工具、A2A代理和技能。按13.5的源码，Lighthouse依次找robots.txt里的Agentmap行、页面里rel为ai-catalog的link标签、HTTP响应头里同名的Link，都没有就去请求/.well-known/ai-catalog.json。可8月26日的v0.91规范已经把标准路径改成/.well-known/ard.json，链接关系改成ard，旧名字只是可选兼容。只按新规范发布的网站，在Lighthouse里会显示为不适用。这项审计属于实验性的代理浏览类别，不打0到100的分，也和Google搜索排名无关。

Lighthouse里的“代理浏览”这个类别，今年5月加llms.txt审计时，站内讲过一次。这次它又多了一项，检查的东西更偏门：一份告诉AI代理“我这里有哪些工具可以调用”的目录文件。

Search Engine Journal的Matt G. Southern在9月21日的报道里翻了Lighthouse的源码，发现了一个有意思的错位。这篇以那篇报道为主体，对照发布说明、源码和规范原文，讲清楚这项审计查什么、怎么判分、那个错位会带来什么结果，以及普通网站要不要跟。

Lighthouse 13.5这次加了什么？

按GitHub上的13.5.0发布说明，这个版本发布于2026年9月18日，新增审计只有一项：ard-schema，用来检查代理资源发现的目录文件。同一版本里还有几条相关改动：

• 把llms.txt审计和新的ARD审计归到同一个分组下，分组名叫代理可发现性。
• 抓取模块新增了捕获响应头的能力，新审计读HTTP Link头要用到它。
• WebMCP相关的两项审计做了调整：所有表单都覆盖到时判为通过而不是不适用；注册的工具超过建议数量时给出警告。
• 持续集成里加了一个每周运行的检查，ARD项目上游的结构定义或一致性测试有变化时会提醒。

如果你的页面已经用WebMCP注册了工具，升级到这个版本后，注册数量超过建议上限时会看到新的警告；表单全部被工具覆盖的页面，结果会从不适用变成通过。发布说明没写建议上限是多少，以报告里的提示为准。

发布说明写明，预计这个版本随Chrome 156进入开发者工具，并在两周内上线PageSpeed Insights。

它在哪个类别里，怎么打分

这项审计属于Lighthouse实验性的代理浏览类别，和SEO类别是分开的。SEJ特别指出，发布说明里没有任何地方把它和Google搜索联系起来。

按Chrome的代理浏览评分说明，这个类别不像性能、SEO那样给0到100的加权总分。文档给的理由是，代理网络的标准还在形成，目前的重点是收集数据、给出可操作的信号，而不是排名。报告里显示的是通过了几项检查的比例，以及每项审计的通过或失败。

ARD是什么，和llms.txt、WebMCP有什么不同？

ARD是一份还在提议阶段的规范，规范页面列了三位作者：Google的Junjie Bu、微软的R.V. Guha、Hugging Face的Shaun Smith。SEJ在6月报道它发布时，它还是v0.9草案；当前版本是v0.91，日期8月26日。

它要解决的问题是：大模型越来越依赖外部能力，比如MCP工具、A2A代理、技能和其他可调用的服务，规范把这些统称为代理资源。AI怎么知道某个组织提供了哪些资源？ARD不走手机应用商店那种先装好再用的路子，它让代理通过搜索动态发现，注册中心维护一个共享、持续更新的索引，资源一发布就能被找到。

三种东西各管一段

简单记：llms.txt管“我这里有什么内容”，WebMCP管“到了我这里能做什么”，ARD管“去哪里能找到我提供的工具”。

一条ARD条目长什么样

规范里的示例是一个天气数据的MCP服务器，条目大致如下：

{
  "identifier": "urn:air:acme.com:server:weather",
  "displayName": "Weather Data Node",
  "type": "application/mcp-server-card+json",
  "url": "https://api.acme.com/mcp/weather.json",
  "capabilities": ["WeatherTool", "ForecastTool"],
  "description": "Enterprise weather MCP server for live telemetry.",
  "representativeQueries": [
    "what is the current wind speed in Chicago",
    "get the 5-day forecast for Seattle"
  ]
}

几个字段的规则，按规范整理：

• identifier必填，是全局唯一的发现标识，以urn:air开头，后面接发布者域名和资源名称，比如上面的urn:air:acme.com:server:weather，用域名锚定，防止别人冒名。
• type必填，用媒体类型标明资源是什么，比如MCP服务器卡片、A2A代理卡片、技能描述，也可以是嵌套的目录。
• url和data二选一，前者指向资源文档，后者直接内嵌，不能同时出现。
• representativeQueries建议提供2到5个，是用户可能提出的自然语言问题。规范说注册中心靠它建语义索引，没有它就搜不到，这也是ARD条目和普通目录条目的区别。
• trustManifest可选，用于身份绑定和合规证明。规范要求其中声明的身份必须和标识里的域名一致，一个自称属于google.com的条目，拿不出google.com签发的证明就会被验证型注册中心拒绝。

type字段能填什么

规范不规定每种代理资源内部的结构，只做一个“信封”，用type标明里面装的是什么，具体内容交给各自的协议去定义。type可以是任何合法的媒体类型，规范列出的常见类型如下：

规范也提醒，这些类型目前是社区事实标准，正式的媒体类型注册还在推进中。

注册中心怎么搜

ARD还定义了注册中心的搜索接口，要求必须提供标准的HTTP REST接口，任何HTTP客户端都能用。搜索走POST /search，探索走POST /explore，查询对象有三个成员：上下文、文本和过滤条件，搜索时文本必填。

规范里有一句话值得做SEO的人记住：搜索返回的相关度分数只反映语义相关性，不能被理解为信任、合规或安全方面的判断。排在前面只代表“更贴题”，不代表“更可信”，信任评估和排序是完全分开的。这和搜索引擎的逻辑很不一样。

v0.91还把条目重新表述为JSON-LD节点，可以通过上下文引入其他命名空间的词汇。规范强调这只是换了表述方式，含义没变，旧格式的清单照样能用。

Lighthouse到底怎么找你的目录文件？

这部分直接看13.5的源码最清楚。负责收集信息的模块会查四个地方：

• robots.txt里有没有以Agentmap开头的一行，有就取后面的地址。
• 页面DOM里有没有rel属性包含ai-catalog的link标签。
• 主文档的HTTP响应头里，有没有rel为ai-catalog的Link，这一项只在导航模式下检查。
• 以上都没有，就用/.well-known/ai-catalog.json。

前三项按这个优先顺序取第一个找到的地址，然后去请求它。

判分规则

负责打分的审计代码逻辑很短，整理成表：

结构校验部分，源码注释写明是把ARD官方一致性测试套件里的清单校验函数直接移植成了JavaScript。Lighthouse的判断标准，就是ARD项目自己的测试标准，那个每周运行的检查，用途就是在上游标准变化时及时跟进。

审计的标题也透露了信息：通过时显示“ai-catalog.json结构有效”，失败时显示“ai-catalog.json结构无效”。文件名直接写在了标题里。

规范已经改名，Lighthouse还没跟上会怎样？

SEJ发现的错位就在这里。

v0.91规范的发现机制一节写了四种方式：在/.well-known/ard.json放一份包含entries数组的清单；在robots.txt里加Agentmap指令；在页面head里放rel为ard的link标签；通过DNS服务绑定记录指向静态条目源或者动态搜索接口。

规范对使用方的要求是：解析一个域名的条目时，必须请求/.well-known/ard.json，必须识别rel为ard的链接。前一版本用的路径/.well-known/ai-catalog.json和链接关系ai-catalog，使用方可以额外查询，算是照顾旧发布者的礼节。

对发布方的建议是：把条目发布在/.well-known/ard.json，输出rel为ard的链接，不需要同时保留旧路径。规范还专门提醒，只放在旧路径上的资源可能找不到，因为查旧路径对使用方是可选的，旧路径的发布者应该迁移。

而Lighthouse 13.5查的，只有旧名字。SEJ说，截至9月21日，在13.5的源码和项目主分支里都没找到ard.json或ard链接关系的引用。规范里提到的页面内JSON-LD发现和DNS记录，13.5的代码也没有检查。

几种发布方式在13.5里的结果

第一行是最需要说清楚的情况。按新规范做得最标准的网站，在Lighthouse里得到的是“不适用”。SEJ的解读很准确：这只说明Lighthouse在它目前查的地方没找到目录，不说明网站缺少符合当前规范的清单。

如果你既想符合新规范，又想在Lighthouse里看到校验结果，robots.txt里的Agentmap指令是两边都认的写法，指向同一份清单即可。规范之外多放一份旧路径文件也行，但规范明说没必要，以后还多一份要同步维护的文件。

普通网站现在要不要做ARD？

大多数网站不用急。ARD描述的是“可调用的资源”，比如MCP服务器、A2A代理、技能包。一个内容站或者普通电商站，如果没有对外提供这类工具，就没有什么可以写进清单的。

可能需要它的是这几类：提供API或MCP服务器的SaaS产品，做开发者工具的公司，已经在做AI代理、希望被其他代理调用的团队。对它们来说，ARD是一个值得跟踪的方向，但规范还在提议阶段，三个月里已经从v0.9改到v0.91，连标准路径都换了。

不适用不等于有问题

PageSpeed Insights更新后，很多人会在报告里第一次看到这项审计，显示为不适用。这是绝大多数网站的正常状态，不需要处理，也不会影响SEO得分，因为它根本不在SEO类别里。

SEJ还提醒了一句，5月Lighthouse加llms.txt审计时他就写过：Google搜索的指导意见和Lighthouse的代理检查，看的是不同的东西。Lighthouse报告里出现某项代理审计，不等于Google搜索会用它来排名。站内对llms.txt的实际作用也讨论过不少，比如llms.txt内容实测那篇。

想试的话，先做这几步

• 确认自己确实有可以被代理调用的资源，并且已经有对应的描述文档，比如MCP服务器卡片。
• 按v0.91规范写清单，每个条目带identifier、type和url，补上两到五个代表性问题。
• 发布到/.well-known/ard.json，页面head里加rel为ard的link标签。
• 如果想在Lighthouse里看到校验结果，在robots.txt加一行Agentmap指向同一份清单。
• Chrome 156的开发者工具或更新后的PageSpeed Insights里跑一次，看代理浏览类别下的结果。

落到文件上，大致是这三处：

# /.well-known/ard.json
{
  "entries": [
    {
      "identifier": "urn:air:example.com:server:catalog-search",
      "type": "application/mcp-server-card+json",
      "url": "https://example.com/mcp/catalog-search.json",
      "description": "Product catalog search MCP server.",
      "representativeQueries": [
        "find stainless steel water bottles under 20 dollars",
        "check stock for SKU 10045"
      ]
    }
  ]
}

# 页面 head
<link rel="ard" href="https://example.com/.well-known/ard.json">

# robots.txt 末尾
Agentmap: https://example.com/.well-known/ard.json

示例里的域名、标识和问题都是演示用的，换成自己的真实资源。

robots.txt是很多工具都会读的文件，改之前确认新加的行不影响现有规则。Agentmap不是robots协议里的标准指令，守规矩的爬虫会忽略它不认识的行，但最好还是放在文件末尾，别插进某个用户代理分组中间。robots.txt分组的规则，站内robots.txt分组不继承那篇有说明。

AI代理在网站上实际能做什么、做不了什么，站内AI代理只能猜着用你的站那篇有更贴近普通网站的检查。对多数网站来说，先把那些基础做好，比抢先写ARD清单更实在。

常见问题解答

ARD是什么？

Agentic Resource Discovery，代理资源发现，一份提议中的规范，让AI代理通过搜索找到一个组织提供的MCP工具、A2A代理、技能等可调用资源。作者来自Google、微软和Hugging Face。

Lighthouse 13.5什么时候能用？

发布说明写明，预计随Chrome 156进入开发者工具，并在发布后两周内上线PageSpeed Insights。13.5.0于2026年9月18日在GitHub发布。

ARD审计会影响Lighthouse的SEO分数吗？

不会。它属于实验性的代理浏览类别，和SEO类别分开，这个类别也不打0到100的分，只显示通过检查的比例。

Lighthouse在哪里找ARD目录文件？

按13.5源码，依次找robots.txt的Agentmap行、rel为ai-catalog的link标签、rel为ai-catalog的HTTP Link头，都没有就请求/.well-known/ai-catalog.json。

为什么按规范做了，Lighthouse却显示不适用？

v0.91规范的标准路径是/.well-known/ard.json，链接关系是ard，而Lighthouse 13.5只查旧的ai-catalog名字。只按新规范发布的网站会被判为不适用。

ai-catalog.json和ard.json有什么区别？

ai-catalog.json是ARD前一版本的路径，ard.json是v0.91的标准路径。规范要求使用方必须读ard.json，读旧路径是可选的，所以只放旧路径可能不被发现。

普通网站需要做ARD吗？

多数不需要。ARD描述的是MCP服务器、A2A代理这类可调用资源，没有对外提供这类工具的内容站和电商站，没有可写进清单的东西。

ARD和Google搜索排名有关系吗？

目前没有证据。Lighthouse的发布说明没有把这项审计和Google搜索联系起来，代理浏览类别和SEO类别也是分开的。

ARD条目里的representativeQueries有什么用？

它是用户可能提出的自然语言问题，规范建议2到5个，注册中心靠它建立语义索引。没有这个字段的条目搜不到，这是ARD条目和普通目录条目的区别。

能用DNS发布ARD吗？

规范支持通过DNS服务绑定记录指向静态条目源或动态搜索接口，示例如_entries._agents.example.com。Lighthouse 13.5不检查DNS方式。

审计结果是0.9分是什么意思？

按源码，清单能加载、结构校验没有错误但有低严重度的警告时给0.9分；有错误给0分；没有错误和警告给1分。

权威参考资料