我把网站彻底改造成「AI 代理可读」，这是真实数据。
过去几个月，我把 built2winweb.com 改造成了一个独立开发者所能做到的、最适合 AI 代理读取的网站：MCP 服务器、A2A agent card、NLWeb 的 /ask 端点、ACP、UCP、agents.txt、llms.txt、RSL 授权、每个页面的 Markdown 内容协商，以及接入 CDN 的 IndexNow。然后我坐下来认真做了测量。这是诚实的版本——包括没起作用的部分、两个和我对着干的 Cloudflare 默认设置，以及那个比所有协议管道加起来都重要的数字。
关键数据
- 209,600 — 推送到 IndexNow 的 URL
- 1,319 — Bing 实际收录的页面
- 28,685 — 站点地图中的 URL
- 16 — 外链域名——真正的天花板
我到底做了什么
完整清单记录在 agent-ready 页面，简要来说：/mcp 上的 MCP 服务器提供七个工具、SEP-2127 server card、带 AP2 商户扩展的 A2A agent card、ACP 描述符、UCP 商务档案、按路径划分的代理权限、在站内运行 BM25 并返回 Schema.org 类型化结果的 /ask 端点、llms.txt 与 llms-full.txt、AGENTS.md、Markdown 站点地图，以及从 robots.txt 引用的 RSL 1.0 授权，明确允许搜索收录、RAG 与模型训练。
以上全部在线、公开、无需 API 密钥。没有用任何框架——就是共享主机上手写的 PHP。想看的话，直接调用即可。
结果如何：数据
在这里，诚实比案例研究更有用。大约三个月内：
- 向 IndexNow 提交 209,600 个 URL
- Bing 收录 1,319 个页面
- 站点地图中有 28,685 个 URL
- Bing 搜索中 111 次展示、0 次点击
- 16 个外链域名
Seznam 从另一个角度讲述了同样的故事：发现 3,390 个 URL，抓取库中保留 86 个，收录 19 个。这是它所发现内容的 0.6%。
也就是说：我向搜索引擎通报自己的页面大约七遍，而全站约 4.5% 被收录。通报从来就不是瓶颈。
Cloudflare Crawler Hints 每 18 小时推送 4,900 个 URL
这一点，如果不打开 Bing Webmaster Tools 我根本发现不了。那 209,600 次 IndexNow 提交，全部来自我开启后就忘记的 Cloudflare Crawler Hints。在一个 28,685 URL 的网站上，它每 18 小时推送 4,900 个 URL——其中包括我特意标记为 noindex 的页面，以及至少一个返回 404 的 .well-known 验证文件。
Bing 注意到了。我后台的首条建议写着：「避免使用 IndexNow 批量模式，以防服务器负载过高和收录延迟。」我居然靠着一个忘记关掉的开关，把一个有用的协议变成了自找的麻烦。IndexNow 是为发生变化的内容准备的。反复把整站砸过去，正是让密钥被降权的做法。
我的 CDN 在和我自己的 robots.txt 唱反调
第二个意外更糟，因为它直接对抗我想达成的目标。我的 robots.txt 用了大约 200 行明确欢迎 AI 爬虫——GPTBot、ClaudeBot、PerplexityBot、CCBot 等等——并写明 Content-Signal: search=yes, ai-input=yes, ai-train=yes。
而在这一切之上，Cloudflare 注入了一段说法完全相反的托管内容：
# BEGIN Cloudflare Managed content
User-agent: ClaudeBot
Disallow: /
User-agent: GPTBot
Disallow: /
User-agent: CCBot
Disallow: /
User-agent: Google-Extended
Disallow: /
# END Cloudflare Managed Content它还声明了 ai-train=no，而我的写的是 yes。按照 RFC 9309，重复的 user-agent 分组会被合并，平局时 Allow: / 胜出，所以守规矩的爬虫大概仍在抓取——但我等于在依赖一条平局规则，去抵消一条我从未写过的指令。请检查实际输出的 robots.txt，而不是你磁盘上的源文件。你的 CDN 可能正在改写它。
「被发现」和「被引用」是两个问题
这是我不想要、但数据坚持的结论。我实现的所有协议解决的都是发现：帮助机器找到并解析已存在的内容。没有一个解决权威性：给别人一个引用你的理由。
只有 16 个外链域名时，Bing 选择不收录我网站的大部分内容，再多的通知也改变不了这个决定。Bing 在第二条建议里直说了：「你的网站缺少来自高质量域名的入站链接。」两个搜索引擎、零抓取错误、零违规，却几乎没有收录。这不是技术故障，而是对内容是否值得存储的判断。
如果你把这项工作当成 SEO 手段，别做。它不是。
藏在这一切下面的 bug
审计过程中，我发现了比任何协议细节都更尴尬、也更要命的问题：我有十三个文章 URL 显示的是错误的文章。
我的重写规则把若干 slug 指向了位置型锚点——blog-card-1、blog-card-3——它们指的是博客首页上的「位置」，而不是具体文章。当首页重新排序后，slug 就悄悄和内容脱钩了。一个讲「如何从 Shopify 迁移」的 URL，实际显示的是关于关键 CSS 的文章。其中一个还在我的站点地图里。
凡是用描述性命名的锚点，全部仍然正确，一个都没有漂移。教训乏味却通用：按事物本身命名，而不是按它所在的位置命名。而一个充满「标题货不对板」页面的索引，非常好地解释了 0% 的点击率。
我建议你怎么做
如果你想让网站对代理可读，真正重要的顺序是：
- 先修好坏掉的东西。我发现了错配的路由、2,020 个因城市 slug 中的撇号造成的陈旧 404，以及一条让页面白底白字的 CSS 规则。这些比任何缺失的清单文件代价都大。
- 发布
llms.txt和一个/ask式端点。成本低、真有用，能让助手拿到带引用的答案而不是靠猜。 - 检查你的 CDN 以你的名义做了什么。我最大的两个问题都是我从未选择过的默认设置。
- 然后去赢得链接。这是最慢的一步，也是决定其他一切的一步。
那么，值得吗？
值得——但不是出于我最初的理由。它买来的是精确度，不是流量。当有人问助手「定制网站多少钱」时，它现在可以取到一个带引用的类型化答案，而不是转述营销文案。我的源站不生成任何内容，所以关于我价格的信息不会被幻觉编造。这本身就有价值，也是对「人们接下来如何找到东西」的一个合理押注。
但它不是捷径。没有任何清单文件能替代「值得被引用」这件事。我宁愿把这话说清楚，也不想卖给你那个曲线一路上扬的版本。
如果你想要这样构建的网站
我用 PHP 手写每一个网站——不用 WordPress、不用页面构建器、没有月费——上面那套代理接口也是同一类工作。如果你想要一个人和机器都能读懂的高速网站，免费获取报价，告诉我你的需求。
相关阅读
常见问题
加了 MCP、A2A 和 llms.txt，排名提升了吗？
没有。三个月里，网站从少量收录变成 28,685 个 URL 中收录 1,319 个，Bing 上 111 次展示、0 次点击。这些协议解决的是「被发现」——帮助机器找到并解析内容。它们不创造权威性，而权威性才决定搜索引擎愿不愿意收录你。
Cloudflare Crawler Hints 是什么，该关掉吗？
它会代你把变更的 URL 自动提交给 IndexNow。在我的站点上它提交了 209,600 个 URL，约每 18 小时 4,900 个，其中包含 noindex 页面和一个 404。Bing 将其标记为过量。如果你的网站较大或由模板生成，先看看它实际在提交什么，再决定是否继续开启。
为什么我的 CDN 会修改 robots.txt？
Cloudflare 可能注入一段禁止 AI 爬虫的托管内容，并且它出现在你自己的规则之上。我的那段封锁了 GPTBot、ClaudeBot、CCBot 和 Google-Extended，而我的文件明确欢迎它们；它还声明 ai-train=no，与我的 ai-train=yes 相反。请始终读取线上 URL 实际输出的文件，而不是磁盘上的源文件。
IndexNow 值得配置吗？
值得，用于真正变更的内容——只需一个密钥文件加一次 POST 请求，Bing、Yandex、Naver 和 Seznam 都会消费它，Google 不会。只是别把没有变化的整站批量重新提交；正是这种行为会让密钥被降权。
小网站应该先做什么？
先修好坏掉的东西，发布 llms.txt 和一个能回答问题的端点，检查 CDN 的默认行为，然后把剩下的精力全部用来赢得链接。技术工作是一个周末的事，链接是几年的事。