直接答案
当你希望 agent 或 validator 在解析完整页面前，先发现 llms.txt、API catalog、service docs 这类机器资源时，再上 HTTP Link headers。实际最适合加的通常是首页、开发者 / 文档 hub 或 well-known 机器入口，而不是每一篇文章 URL。只有目录确实列出真实 API 时，才使用 /.well-known/api-catalog。
它适合做 discovery，不适合被当成 Google 排名技巧、HTML links / sitemap 替代品，或 crawler 权限控制。
大多数 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 搜索可见性评分卡 开始。
生产证据与已审计源码
在 2026 年 8 月 10 日，Fennec 生产首页返回的真实 header 是：
HTTP/2 200
content-type: text/html; charset=utf-8
link: </.well-known/api-catalog>; rel="api-catalog"; type="application/linkset+json",
</llms.txt>; rel="alternate"; type="text/plain"; title="FennecSEO llms.txt",
</llms-full.txt>; rel="service-doc"; type="text/plain"; title="FennecSEO full LLM-readable export",
</audit/agent-seo/>; rel="service-doc"; type="text/html"; title="Agent SEO audit"
中文首页当时也返回了本地化版本，指向 /zh/llms.txt、/zh/llms-full.txt 和 /zh/audit/agent-seo/。
相反，这篇文章自己的 URL 并没有返回 Link header。这不是缺陷，而是边界：discovery header 更应该放在入口页和机器端点，而不是默认铺到每篇 blog。
这份 8 月 10 日响应是历史生产证据，不是符合标准的范本。catalog 的 item 当时列的是 feed、sitemap 和 LLM-readable 文件，而不是 API；首页也在超出其窄语境的情况下使用了 alternate 与 service-doc。
2026 年 8 月 31 日完成的源码审计在未来发布前修正了这些边界：首页现在只声明 API catalog；catalog 只列出 Fennec 的 canonical、robots.txt 和 soft 404 三个持续维护的 POST endpoint；catalog 自己的响应也只回链自身。llms.txt 继续通过约定路径提供，不再被强行套上不准确的 relation。在获得发布授权之前，这仍是本地源码修正。
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 想理解网站时，通常会有几种选择：
- 抓首页。
- 解析 HTML。
- 跟随导航和内链。
- 抓 sitemap 和
robots.txt。 - 寻找
llms.txt、API docs 或 well-known files。 - 判断站点是否暴露真实能力。
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。它只是增加了一条结构化发现路径。
Link headers 不能控制什么
这里有三个经常被混淆的边界：
- Google 不要求 Link headers、llms.txt 或额外 AI 文件，页面才能出现在 Google 的 AI 搜索功能里。 Google 现在明确说，AI Overviews 和 AI Mode 仍然沿用普通 SEO 基础，没有额外技术门槛。
- Link headers 不能替代 crawler policy。 OpenAI 当前把 OAI-SearchBot 用于搜索展示，把 GPTBot 用于模型训练抓取，两者都应在
robots.txt里管理。 - Link headers 也不能保证用户触发代理会按自动爬虫逻辑工作。 OpenAI 单独说明了
ChatGPT-User，并指出这类用户触发访问里robots.txt规则未必同样适用。
所以，如果你真正要解决的是“能不能抓”“能不能用于训练”，先把 robots.txt 与访问策略写清楚；Link headers 负责的是在允许访问的前提下，让 agent 更快找到正确资源。
它在 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 或认证流程。
语义准确的实用 Headers
先确定 link context，再选择 relation。对于 API service landing page，service-desc 可以标识机器可读描述，service-doc 可以标识主要供人阅读的服务文档：
Link: </openapi.json>; rel="service-desc"; type="application/json",
</docs/api/>; rel="service-doc"; type="text/html"
如果某篇文章有内容等价的 Markdown representation，alternate 可以表示这篇文章的替代表示：
Link: </zh/blog/example.md>; rel="alternate"; type="text/markdown"
如果发布方确实有公开 API，再单独加入 catalog relation：
Link: </.well-known/api-catalog>; rel="api-catalog"; type="application/linkset+json"
目前没有专门对应 llms.txt 的注册 relation。只有当它确实是 response context 的替代表示时，才使用 alternate；只有当内容导出确实在描述真实 service 时，才使用 service-doc。与其强行套用不精确的 relation，不如保留 HTML link 与约定俗成的 /llms.txt 路径。
最重要的规则很简单：
只宣传你能长期维护准确的资源。
如果 llms.txt 过期，header 只会让 agent 更快找到过期信息；如果 API catalog 指向死掉的文档，discovery 就会变成噪音。
Fennec 的实现位于 public/_headers，Astro 会把它复制到构建输出。已审计源码只在 /、/zh/ 和 /.well-known/api-catalog 声明 api-catalog relation；文章模板不输出 discovery header。
应该用哪些 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://api.example.com/v1/audits",
"type": "application/json",
"title": "SEO Audit API"
}
]
},
{
"anchor": "https://api.example.com/v1/audits",
"service-doc": [
{
"href": "https://developer.example.com/audits/",
"type": "text/html",
"title": "SEO Audit API documentation"
}
]
}
]
}
如果服务器返回 application/octet-stream，有些 scanner 仍然能抓到，但信号会弱。RFC 9727 API catalog 更应该使用 application/linkset+json。
如何测试
先测试首页：
curl -I https://fennecseo.app/
curl -I https://fennecseo.app/zh/
重点检查：
- 是否存在
Linkheader - 每个引用 URL 是否返回
200 - Content-Type 是否和 header 匹配
- URL 是否为有效的 absolute 或 root-relative 地址
- 本地化资源是否使用正确语言路径
- 合适时，人类页面里也能找到这些资源
然后测试 API catalog：
curl -I https://fennecseo.app/.well-known/api-catalog
curl https://fennecseo.app/.well-known/api-catalog
Fennec 在 2026 年 8 月 10 日 的预期返回是：
HTTP/2 200
content-type: application/linkset+json; profile="https://www.rfc-editor.org/info/rfc9727"; charset=utf-8
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"
这能帮助你确认 response layer 的三件事：
- 站点正在声明 API catalog relation；
- 机器端点声明了
application/linkset+json和 RFC 9727 profile； - 这个机器端点自己也继续通过
Linkheaders 暴露相关资源。
但这不能证明 catalog body 合规。还要单独抓取并检查 JSON：RFC 9727 要求 item link 标识真实 API endpoint。8 月 10 日的 body 不符合这一要求；已审计源码已把这些 entries 换成 Fennec 持续维护的 canonical、robots.txt 和 soft 404 checker APIs。在源码发布并完成线上复核之前，应把生产环境视为尚未变化。
最后，再把 HTTP 结果和人类页面、agent-facing 工具页面对照。header 干净不等于资源就有价值，真正决定体验的是这些目标资源是否仍准确、可维护。
如果你还需要比较 crawler 和 agent 看到的页面内容，可以使用 Bot Simulator。
它如何支持 AI 搜索可见性
Link headers 不能让弱内容变成高质量来源。
它解决的是更窄的问题：机器发现。
当页面本身已经不错时，它才更有价值：
- 页面可抓取
- 内容具体且有帮助
- sitemap 干净
llms.txt有维护- 站点有真实工具、文档或机器可读资源
- 团队用 Search Console 和日志衡量结果
在 AI 搜索可见性评分卡 里，Link headers 属于 discovery layer。只有背后的资源有用，它才值得加分。
常见错误
避免这些问题：
- Link headers 指向不存在的文件
- 把同一组 headers 机械地放到所有文章 URL 上
- 没有 API 或机器可读资源，却宣传 API catalog
- 只改本地文件，忘了部署时生成的 headers
/.well-known/api-catalog返回错误 Content-Type- 中文页面仍然只指向英文资源
- 把 Link headers 当成 OAI-SearchBot 或 GPTBot 的权限控制替代品
- 把 Link headers 当成 HTML links、sitemap 或内容质量的替代品
- 为了提高 scanner score 添加所有新兴 agent protocol
好的 Agent SEO 往往是“朴素但可靠”的：信号清楚、资源准确、行为可测试。
用 Fennec 落地的下一步
快速检查可以这样做：
- 对首页执行
curl -I。 - 查看是否有 agent-useful
Linkrelations。 - 逐个抓取被引用的
llms.txt、API catalog 和 service docs。 - 用 Agent SEO Audit 验证。
- 用 Technical SEO 和 Bot Simulator 确认页面仍然可抓取且内容一致。
如果页面还没有 measurement baseline，先结合 AI 搜索可见性评分卡 再决定它是不是优先 AI search asset。
Sources
- IETF RFC 8288: Web Linking
- IETF RFC 8631: Link Relation Types for Web Services
- IETF RFC 9727: The api-catalog Link Relation Type
- IETF RFC 9264: Linkset media types
- Google Search Central: AI optimization guide
- Google Search Central: AI features and your website
- OpenAI: Crawlers and user agents
问答
Link headers 会提升 Google 排名吗？
不应该假设它有直接排名收益。Link headers 是机器和 agent 的发现信号，不是绕过正常 SEO 基础的捷径。
Agent SEO 里哪些 Link relation 值得关注？
只有目录里存在真实 API 时才使用 api-catalog。alternate 或 describedby 适合 alternate representation 与描述资源；service-doc 或 service-desc 适合真实服务文档与机器可读服务描述。
每个页面都要加很多 Link headers 吗？
不用。优先放在首页、重要 hub、API 文档，以及机器可读资源确实能帮助 agent 的页面。
Link headers 能控制 OpenAI 是否使用这个页面吗？
不能。Link headers 是发现提示，不是权限控制。自动抓取策略应通过 robots.txt 管理 OAI-SearchBot 与 GPTBot；OpenAI 另外把 ChatGPT-User 归类为用户触发代理。
如何测试 Link headers？
对 URL 执行 curl -I，检查 Link header，逐个抓取被引用资源，并确认状态码、Content-Type 和新鲜度。
