面向 AI Agents 的 Link Headers：为什么 HTTP Discovery 很重要

大多数 SEO 发现路径发生在 HTML 里：链接、canonical、hreflang、schema、导航和 sitemap。

AI agents 又增加了一个入口：HTTP response。

在 agent 解析完整 HTML 页面之前，它可以先读取响应头。一个有用的 Link header 可以指向 llms.txt、API catalog、service documentation 或 agent-facing audit page。

这就是为什么 Link headers 正在变成一个实际的 Agent SEO 话题。

它不是排名技巧，而是一层机器可读发现信号。

这篇是 Agent SEO audit cluster 里的 HTTP discovery spoke。如果你想先做衡量层，可以从 AI 搜索可见性评分卡 开始。

Link Header 是什么

HTTP Link header 让服务器可以描述当前 URL 与另一个资源之间的关系。

一个简单例子：

Link: </llms.txt>; rel="alternate"; type="text/plain"; title="FennecSEO llms.txt"

它的意思是：这个响应有一个相关的 alternate 资源，位于 /llms.txt，类型是 text/plain。

一个 header 里也可以包含多个 link：

Link: </.well-known/api-catalog>; rel="api-catalog"; type="application/linkset+json",
      </llms.txt>; rel="alternate"; type="text/plain",
      </audit/agent-seo/>; rel="service-doc"; type="text/html"

对普通浏览器用户来说，这可能不可见；但对 agent、crawler、validator 或 API client 来说，它是一个快速资源地图。

为什么 Agent 会关心它

一个 agent 想理解网站时，通常会有几种选择：

1. 抓首页。
2. 解析 HTML。
3. 跟随导航和内链。
4. 抓 sitemap 和 robots.txt。
5. 寻找 llms.txt、API docs 或 well-known files。
6. 判断站点是否暴露真实能力。

Link headers 可以缩短这条路径。

当站点有一些视觉导航里不明显的资源时，它尤其有用：

资源	Agent 为什么关心
llms.txt	给 AI readers 的精选站点摘要
llms-full.txt	更大的可读导出或内容地图
/.well-known/api-catalog	基于 RFC 9727 的 API discovery
产品或 API 文档	真实能力的 service documentation
Agent SEO audit page	人类可读的 agent 信号说明
RSS feed	新内容发现
Sitemap	canonical URL 发现

这不能替代 HTML links 或 XML sitemaps。它只是增加了一条结构化发现路径。

它在 Agent Readiness 里的位置

IsItAgentReady 这类 agent-readiness 工具会检查网站是否暴露了明显的发现信号。

早期层级通常比较熟悉：

• robots.txt
• XML sitemap
• Link headers
• llms.txt
• Content Signals
• Markdown content negotiation

后面的层级更偏产品能力：

• API catalog
• MCP Server Card
• Agent Skills index
• OAuth metadata
• A2A Agent Card
• WebMCP

对大多数内容站和 SaaS marketing site 来说，Link headers 是合理的下一步，因为它改动小、scanner 可见，而且不需要为了分数虚构不存在的 API 或认证流程。

一个实用 Header 组合

产品内容站可以先从首页 header 开始：

Link: </.well-known/api-catalog>; rel="api-catalog"; type="application/linkset+json",
      </llms.txt>; rel="alternate"; type="text/plain"; title="llms.txt",
      </llms-full.txt>; rel="service-doc"; type="text/plain"; title="Full LLM-readable export",
      </audit/agent-seo/>; rel="service-doc"; type="text/html"; title="Agent SEO audit"

中文首页则应使用已有的本地化机器资源：

Link: </.well-known/api-catalog>; rel="api-catalog"; type="application/linkset+json",
      </zh/llms.txt>; rel="alternate"; type="text/plain"; title="Chinese llms.txt",
      </zh/llms-full.txt>; rel="service-doc"; type="text/plain"; title="Chinese full export",
      </zh/audit/agent-seo/>; rel="service-doc"; type="text/html"; title="Agent SEO audit"

最重要的规则很简单：

只宣传你能长期维护准确的资源。

如果 llms.txt 过期，header 只会让 agent 更快找到过期信息；如果 API catalog 指向死掉的文档，discovery 就会变成噪音。

应该用哪些 Relation

relation 要和资源匹配。

Relation	适合用途
api-catalog	指向基于 RFC 9727 的 Linkset API catalog
alternate	指向 alternate representation，例如 llms.txt 或 Markdown
describedby	指向描述当前页面或站点的资源
service-doc	指向某个 service 或 capability 的文档
service-desc	指向 OpenAPI 这类机器可读 service description

不要把一个 relation 用在所有资源上。relation 越精确，agent 和 validator 越容易理解网站。

API Catalog 示例

如果你暴露 API catalog，它应该是真实 JSON，并且 Content-Type 要正确。

示例：

{
  "linkset": [
    {
      "anchor": "https://example.com/.well-known/api-catalog",
      "item": [
        {
          "href": "https://example.com/llms.txt",
          "type": "text/plain",
          "title": "LLM-readable site summary"
        }
      ],
      "service-doc": [
        {
          "href": "https://example.com/audit/agent-seo/",
          "type": "text/html",
          "title": "Agent SEO audit"
        }
      ]
    }
  ]
}

如果服务器返回 application/octet-stream，有些 scanner 仍然能抓到，但信号会弱。RFC 9727 API catalog 更应该使用 application/linkset+json。

如何测试

先测试首页：

curl -I https://example.com/

重点检查：

• 是否存在 Link header
• 每个引用 URL 是否返回 200
• Content-Type 是否和 header 匹配
• URL 是否为有效的 absolute 或 root-relative 地址
• 本地化资源是否使用正确语言路径
• 合适时，人类页面里也能找到这些资源

然后测试 API catalog：

curl -I https://example.com/.well-known/api-catalog
curl https://example.com/.well-known/api-catalog

最后，用 agent-readiness checker 扫描，并和手工结果对照。

如果你还需要比较 crawler 和 agent 看到的页面内容，可以使用 Bot Simulator。

它如何支持 AI 搜索可见性

Link headers 不能让弱内容变成高质量来源。

它解决的是更窄的问题：机器发现。

当页面本身已经不错时，它才更有价值：

• 页面可抓取
• 内容具体且有帮助
• sitemap 干净
• llms.txt 有维护
• 站点有真实工具、文档或机器可读资源
• 团队用 Search Console 和日志衡量结果

在 AI 搜索可见性评分卡 里，Link headers 属于 discovery layer。只有背后的资源有用，它才值得加分。

常见错误

避免这些问题：

• Link headers 指向不存在的文件
• 没有 API 或机器可读资源，却宣传 API catalog
• 只改本地文件，忘了部署时生成的 headers
• /.well-known/api-catalog 返回错误 Content-Type
• 中文页面仍然只指向英文资源
• 把 Link headers 当成 HTML links、sitemap 或内容质量的替代品
• 为了提高 scanner score 添加所有新兴 agent protocol

好的 Agent SEO 往往是“朴素但可靠”的：信号清楚、资源准确、行为可测试。

用 Fennec 落地的下一步

快速检查可以这样做：

1. 对首页执行 curl -I。
2. 查看是否有 agent-useful Link relations。
3. 逐个抓取被引用的 llms.txt、API catalog 和 service docs。
4. 用 Agent SEO Audit 验证。
5. 用 Technical SEO 和 Bot Simulator 确认页面仍然可抓取且内容一致。

如果页面还没有 measurement baseline，先结合 AI 搜索可见性评分卡 再决定它是不是优先 AI search asset。

Sources

• IETF RFC 8288: Web Linking
• IETF RFC 9727: The api-catalog Link Relation Type
• IsItAgentReady: Link Headers implementation guide
• Cloudflare: Introducing the Agent Readiness score
• Google Search Central: AI optimization guide

问答

Link headers 会提升 Google 排名吗？

不应该假设它有直接排名收益。Link headers 是机器和 agent 的发现信号，不是绕过正常 SEO 基础的捷径。

Agent SEO 里哪些 Link relation 值得关注？

优先看 api-catalog、alternate、describedby、service-doc，以及指向真实机器可读资源的 well-known 文件。

每个页面都要加很多 Link headers 吗？

不用。优先放在首页、重要 hub、API 文档，以及机器可读资源确实能帮助 agent 的页面。

如何测试 Link headers？

对 URL 执行 curl -I，检查 Link header，逐个抓取被引用资源，并确认状态码、Content-Type 和新鲜度。