llms.txt 与 robots.txt：给 AI 开门的两把钥匙

robots.txt 放在域名根目录，用 User-agent 指定规则作用的机器人，用 Allow 与 Disallow 指定路径是否允许抓取。它是一份约定，不是访问控制：遵守它的爬虫会照做，不遵守的照样能取，因此不能用它保护隐私内容。

规则按最具体的匹配优先，而不是简单的「后面的覆盖前面的」。同一路径同时出现 Allow 与 Disallow 时，路径更长的规则生效；长度相同时 Allow 通常优先。各平台实现细节可能存在差异，写规则时不要依赖这些边界情况。

第一种是测试环境的配置被带到生产：Disallow 写成整站禁止，上线后没人复查。第二种是内容管理系统的「阻止搜索引擎」开关遗留，页面带着 noindex 却仍在对外投放。第三种是产品页的 canonical 指回了首页。

前两种会让页面彻底消失，第三种会发出矛盾的规范化信号。canonical 是建议而非强制命令，但指向别处等于告诉系统「这一页不是主版本」，长期下来容易让独立页面失去独立地位，连带影响它在检索中的表现。

sitemap 是一份 URL 清单，帮助发现地址，并可通过 lastmod 提示更新时间。它不规定抓取时间，也不保证收录。只有内容真的改了才更新 lastmod，否则这份提示会逐渐失去参考价值，甚至让系统不再信任这个字段。

IndexNow 一类的主动提交同理：接口返回成功只说明提交被收到。把「提交成功、已抓取、已索引、被引用」记成四个字段，比一天提交几十次有用得多，也更容易向别人解释当前到底卡在哪一步。

llms.txt 是一个社区提案：在站点根目录放一份 Markdown 文件，用简短的标题和链接说明站点结构与重要页面，方便语言模型快速了解内容。它由个人与社区推动，不是 W3C 或任何标准组织的规范，也没有统一的强制格式。

Google 的生成式搜索官方指南明确表示不使用 llms.txt，其他平台也没有把它列为收录条件。因此它值得做，但定位是给愿意读的抓取方一份导读，不能替代抓取与索引的基本功。把它当成收录开关，是这类讨论里最常见的误解。

先保证能抓、能索引，再谈导读文件。顺序反了，做出来的东西可能根本没人读，还会让人误以为配置已经完成，从而跳过真正必要的检查。这两件事的工作量差别很大，先做便宜且确定有效的那一件，通常更划算。

配置完成后留一份快照：robots.txt 原文、sitemap 地址、几处关键页面的响应头。下次出现「AI 说不知道我们」时，从这份快照开始比对，比凭记忆重查要快得多。快照不需要复杂工具，一个按日期命名的文件夹加上原始文件就够了。