最佳实践
十项规则、我们最常见的错误，以及适用于国际化、安全和 CI 的具体模式。
最近更新:
十条规则
- 精心筛选。 少量高信号页面胜过大量平庸页面。十 到三十个链接可以作为有用的起始经验值，但最终数量应由预期任务决定。
- 使用绝对 URL。 始终
https://yourdomain.com/...。相对 URL 在技术上允许使用，但不够稳妥。 - 按产品功能面分组。 诸如 产品, 定价, 开发者 体现用户（以及 LLM）的思考方式。除非博客/文档/指南分类与你的实际导航相对应，否则应避免使用这些分类。
- 保持摘要客观。 H1 后面的引用块应读起来像维基百科 的开头，而不是像着陆页首屏英雄文案。
- 每个条目只写一句话。 冒号后的说明用于消除歧义，而不是用于营销。
- 使用
Optional标签要节制使用。 它为新闻资料、品牌素材和归档提供了清晰的编辑入口，但 v2 并未赋予它特殊的机器语义。 - 同步你的稳定 URL。 如果其中的页面
llms.txt发生移动，请更新它或设置重定向。失效的 URL 会损害该文件的信誉。 - 发布
llms-full.txt，且仅用于明确的摄取需求。 汇总后的文档可以帮助已知使用方，但也会增加文件大小、时效性和安全方面的成本。 - 运行 验证器 在 CI 中运行。 破坏你的文件的内容迁移应当使构建失败。
- 为文件注明日期。 例如这样一条简短说明： “最后审查日期：2026-04-01” 放在正文中，对人类和爬虫都有帮助。
常见错误
- 没有 H1。 H1 是唯一必需的元素。没有它，文件就无效。
- 多个 H1。 使用 H2 作为章节标题。必须恰好只有一个 H1。
- 自定义 front matter。 YAML 和 JSON 标头位于已发布语法之外， 可能会让符合规范的解析器拒绝或误读该文件。
- 粘贴了 Markdown 表格或图片。 保持前言集中，并在 H2 区块内使用链接列表。额外结构会增加解析歧义，而且常常会重复已链接的页面。
- 包含需要身份验证才能访问的 URL。 如果某个页面需要登录，就不要列出它，LLM 会 碰壁。
- 过长的描述。 “世界上最先进的 AI 驱动平台 用于下一代协同转型” 对任何人都没有帮助。每条注释只保留到足以区分目标为止。
- 在不说明范围的情况下列出 500 个 URL。 重新检查任务，把真实内容边界 拆分为路径级文件，或为已知消费者提供一个单独的完整内容资源。
- 无意中阻止了该资源。 确保每个声明的根目录或路径级文件在你设定的抓取政策下都可访问。
多语言站点
该提案没有规定唯一的国际化架构。常见的设计选择有两种：
- 在根目录放置一个默认语言文件。 当列出的资源和目标使用方采用同一种语言时，这是最简单的方案。
- 按语言区域的变体。 提供
/llms.txt（默认）、/fr/llms.txt,/es/llms.txt。请从根文件正文或某个 可选 部分，或者用rel="describedby"在本地化页面上。
无论选择哪种模式，都不要在不同语言区域重复 URL 集合：每个变体都应指向每个页面的本地化版本。
安全与隐私
- 其中的所有内容
llms.txt是公开的。 把这个文件视为广播。 - 绝不要列出预发布或预览网址。 任何获取公开文件的客户端都可以 看到它们。
- 不要列出在查询字符串中包含机密的 URL。 这听起来很明显；我们见过 这种情况发生。
- 如果页面在身份验证后公开用户数据，就不应将其列在这里。
- 每次发布都审计该文件。 泄露草稿 URL 是最常见的安全 失误。
将该文件视为外部配置，不要假设智能体会服从它。在 Ahrefs 对 137,210
个域名的分析中，研究类别里数量最多的用户代理字符串是
prompt-injection-survey/1.0。该标签既不能证明发生了攻击，也不能证明其运营方是谁，但它有助于提醒你保持内容客观、审查变更，并约束任何使用该文件的智能体。
在 CI 中自动化
将 llms.txt 像对待任何其他产物一样：生成、验证，并以它作为发布门禁。
- 根据内容源（CMS、MDX 集合、数据库）生成它。
- 运行 验证器 在 CI 中运行；出现任何错误时让构建失败。
- 比较不同版本中的文件差异；若发生大量删除，提醒文档负责人。
-
部署后对生产 URL 进行冒烟测试：
curl -fsS https://yourdomain.com/llms.txt | head -1.