robots.txt 对 AI 爬虫的屏蔽效果：你可能误读了 RFC 9309

下面这条规则看起来像是阻止了 OpenAI 的爬虫：

User-agent: *
Disallow: /checkout/
Disallow: /customer/

User-agent: GPTBot
Crawl-delay: 10

但它什么都挡不住。GPTBot 读取自己所在的组，只找到一条 Crawl-delay 指令而没有 Disallow，于是会抓取所有内容——包括 /checkout/ 和 /customer/。

根据 RFC 9309，爬虫在匹配到特定 user-agent 组时，只使用该组的规则，不会继承 User-agent: * 的配置。在文件中为某个 bot 指定了名称，就会彻底关闭该 bot 的通配符规则。

所以，当你添加一个命名组想要更加谨慎时，实际上反而变得更不谨慎了。而且这种失败是隐形的——文件看起来好像说了点什么。

我在做别的事情时发现了这个，而别的事情正是这篇文章剩余部分的内容。

我花了几周时间，整理了每一个能帮助电商网站被 AI 系统发现、读取、信任或完成交易的项目——专门针对 Magento，因为那是我工作的平台。结果是一份包含 42 个项目的列表：awesome-magento-aeo，CC0 协议，如果有用的话尽管 fork。

有趣的不是这份列表本身，而是它的分布。

十一 个 llms.txt 的实现。这个文件格式是 2024 年才提出的，本质上就是站点根目录下一个 Markdown 文档。

三个关于爬虫策略的实现——正是上面 RFC 9309 陷阱所在的层面。

社区在最容易的层面建了十一个，在困难的层面各建了三个。

为什么十一不是表面看起来的笑话

我的第一反应是：重复劳动，大家都在做同一个周末项目。但这个看法是错的。

为一个真实商店生成 llms.txt 并不简单。你会遇到多店铺布局、需要解析而非直接倾倒标记的页面构建器内容、CMS 指令、客户组定价，以及大到足以让朴素生成方式内存耗尽的目录。

这十一个实现恰恰在那些维度上有所不同——基于游标的大目录分页、按店铺作用域的实体选择、加权排序、博客内容通过 IndexNow ping 填充文件。

从外部看它们一模一样，但在平台变难的地方完全分叉。这就是新生品类的样子：几个人解决同一个问题，但对哪些部分重要各执己见。

我写这篇文章时萎缩了的那个品类

2026 年 3 月，OpenAI 从聊天内即时结账退了一步。公开数据显示，上线六个月前宣传的"超过一百万"商家中，实际活跃的只有十几家到三十家左右。该模型转向了 ChatGPT 内的产品发现，购买最终在商家自己的网站完成。

Agentic Commerce Protocol 没有消失——它的角色从结账转向了信息流、促销和库存查询。OpenAI 的开发者文档仍然描述着面向批准合作伙伴的即时结账，所以细节仍有争议。但方向没有争议。

列表上五个代理结账项目中，没有一个发布过稳定的 1.0 版本。

如果你在规划一个冲刺来对接聊天内结账，信息流才是被曝光的现实路径。结账集成是协议正在前往的方向，而不是本季度的收入来源。

先衡量。Bing Webmaster Tools 在其 AI Performance 视图中报告引用次数和 grounding 查询——据我所知，这是唯一免费的第一方来源，能告诉你 AI 系统引用你页面的频率。Google Search Console 在 2026 年 6 月增加了生成式 AI 报告，但它显示的是展示量而非引用次数。

修复爬虫策略。写规则之前先读 RFC 9309，然后验证规则确实做了你想让它做的事。

先做结构化数据，再做 llms.txt，按这个顺序。Schema 暴露机器可读的价格、库存和标识符；llms.txt 引导系统找到重要的页面。

停在这里。这之后的一切都为时过早，而过早是一个成本，不是一枚徽章。

我维护着列表上 42 个条目中的 11 个。我自己的项目在各自章节中排在最后，而不是按字母顺序排列——否则它们几乎会出现在所有地方。我读的是文档和 README 而不是源代码，所以我没有独立审计过每一个实现，对于不确定的地方我标记的是 partial 而非 complete。

欢迎修正，不需要解释——尤其是关于我自己的修正。

完整的说明文，包含纳入标准和被我省略的部分，在我的网站上。