先说个真实感受最近我翻自己站点的访问日志发现除了真人访客后台里越来越频繁地出现 GPTBot、ClaudeBot、PerplexityBot 这些名字。它们像一群沉默的读者不点击、不评论、不留痕却正在影响越来越多人的浏览方式。Cloudflare 的工程师显然也注意到了这个现象他们在自家网络上分析了大约 20 万个域名的访问行为给这些域名的“Agent 可读性”打了个分平均分只有 48 分连及格线都没到。这意味着什么意味着你的网站正在被第二类用户疯狂“阅读”但绝大多数站点根本读不明白。我在之前的项目里踩过不少坑今天把整个问题掰开揉碎聊清楚包括 Cloudflare 这次扫描到底在说什么、为什么评分这么低、以及作为一个网站管理者你该怎么把分数拉上去。1. Cloudflare 这次扫描到底在说什么1.1 数据从哪来20 万个域名不是“抽查”出来的先说清楚一个经常被误解的点Cloudflare 不是闲着没事派爬虫去全网扫描了 20 万个网站而是因为它本身就是全球体量极大的 CDN 和反向代理服务商大量网站的流量都要经过它的边缘节点。也就是说Cloudflare 手里握着的是一个巨大的、真实的 HTTP 流量观察窗口。他们从这个窗口里抽取了约 20 万个域名的流量样本重点统计的是这些网站在过去一段时间里有没有被 AI 代理访问过、被哪些 AI 代理访问、代理拿到 HTML 之后能不能顺利提取出正文内容、robots.txt 有没有明确放行或拒绝、页面是不是重度依赖 JavaScript 渲染。这些维度综合起来构成了一个“Agent 友好度”或者说“Agent 可读性”的评分体系。这个 20 万的样本量其实很能说明问题它覆盖了大量中小站点不是只挑头部大站看。头部大站有专门的团队维护体验可中小站点才是整个互联网的基本盘。基本盘平均分 48 分才真正反映了整个 Web 生态对 AI 时代的准备程度。1.2 48分是怎么算出来的可读性评分的核心维度我看了 Cloudflare 公布的研究思路结合我自己做站点维护的经验这个评分大概绕不开下面几个维度访问权限robots.txt 和元数据标签是否允许 AI 代理抓取。很多站点要么没有 robots.txt要么把所有爬虫一刀切全部 DisallowAI 代理自然进不来。内容可达性正文是不是直接出现在初始 HTML 里。纯前端单页应用SPA的网站在这个默认上会吃大亏因为 AI 爬虫执行的 JS 有限拿到的 HTML 可能只是一个空壳。语义清晰度页面里有没有规范的标题层级、文章结构、结构化数据。如果整个页面是满屏混乱的 div 嵌套代理很难判断哪里是正文、哪里是导航、哪里是广告。干扰程度有没有弹窗、验证码、Cookie 同意框、登录墙。这些对人类是烦对 AI 代理直接就是不可逾越的障碍。这几个维度里任何一个做得差都会直接拉低总分。48 分作为一个平均分说明绝大多数网站至少在中了“内容可达性”和“干扰程度”这两刀。2. 为什么绝大多数网站对 Agent 不友好2.1 罪魁祸首JavaScript 渲染与 SPA 化过去十年开发生态有个大趋势前后端分离、前端工程化、单页应用。React、Vue 这些框架极大地提升了交互体验但也带来一个副作用——很多网站把内容完全交给了 JavaScript 动态渲染。你打开页面时浏览器会老老实实执行几 MB 的 JavaScript然后把内容画出来。可 AI 代理不是浏览器它们更像一个“轻量级访客”虽然现代爬虫也会尝试执行部分 JavaScript但复杂度一上来就力不从心了尤其是那些依赖异步接口、路由懒加载、动态切页的站点。我用一个很直白的类比如果网站是一本书传统服务端渲染相当于直接把印刷好的书页递到你手里而客户端渲染等于递给你一堆白纸和一台打印机并告诉你“你想看的内容需要先运行这个驱动程序才能打出来”。人类访客有浏览器这个万能打印机AI 代理没有或者说不愿意花这个成本。所以如果你做的是重交互 SPA又指望 AI 代理能读出你的内容基本是痴心妄想。这可以说是 48 分低分的最大贡献者。2.2 我自己踩过的 robots.txt 的坑robots.txt 是第二个大坑。很多站长对它的理解停留在“用来禁止搜索引擎收录”的层面却忽略了这文件是 AI 代理涌入后真正的前线。我刚部署个人博客那会儿robots.txt 长这样User-agent: * Disallow: /当时我的想法很简单我还没准备好被索引先不让任何爬虫进来。结果就是几周后我检查 Cloudflare 的访问日志发现所有 AI 代理全被挡在门外GPTBot、ClaudeBot、PerplexityBot 一个都没进来过。问题是它们不会因为被挡就放弃而是会尝试别的路径、反复重试白白消耗我服务器的请求配额我还什么都得不到。后来我把规则改成了只允许必要的 AI 代理访问公开路径禁止抓取后台和管理接口。改完的第二天日志里就开始出现正常的 AI 抓取记录状态码从 403 变成了 200那一刻我才真正理解robots.txt 不是一堵墙而是一扇门关键在于你开门的方向对不对。2.3 登录墙、验证码与 Cookie 弹窗三大“杀手”就算你放行了 AI 代理站点本身也可能存在阻碍。登录墙是最无奈的。我遇到过不少内容站文章标题和摘要都能看到点进去却让你登录。真人访客烦一下可能就注册了可 AI 代理绝对不会为了看一篇正文去走注册流程。它的行为逻辑是读不到就算了去别家找。如果你的核心内容全锁在登录墙后面你等于亲手把第二类用户推给了竞品。验证码也一样。AI 代理遇到 CAPTCHA 基本就是死路没有视觉推理能力去点“我不是机器人”。Cloudflare 自己的 5 秒盾Bot Fight Mode尤其要注意它拦截的不只是恶意 Bot也会误伤正规 AI 爬虫。我在第 4 节会细说怎么放行白名单。Cookie 弹窗可能很多人没想到。真人访客会下意识点“同意”AI 代理可不会。那些全屏遮罩式、强制选择偏好的 Cookie 弹窗在 AI 眼里就是一道不可逾越的墙。更关键的是很多弹窗的遮罩层会覆盖正文区域即便代理能加载 HTML文本提取的时候也会被弹窗文案污染。3. 把网站在 Agent 眼里变得可读实操拆解3.1 第一步先给 AI 爬虫“开门”robots 配置举例我建议你先把 robots.txt 里那些一刀切的禁止规则拆开对主流 AI 代理单独放行。下面是我现在用的配置你可以直接参考# 放行主流 AI 代理 User-agent: GPTBot Allow: / User-agent: ClaudeBot Allow: / User-agent: Claude-Web Allow: / User-agent: PerplexityBot Allow: / User-agent: Google-Extended Allow: / User-agent: Applebot-Extended Allow: / # 其他爬虫保持默认 User-agent: * Allow: / Disallow: /admin Disallow: /wp-admin Disallow: /api/private需要注意两点。第一放行范围要想清楚如果你不想让 AI 代理把你的内容拿去无限训练可以在根目录加一句X-Robots-Tag: noai, noimageai的 HTTP 响应头或者针对指定路径加 meta 标签。这是语义化表达“允许读取但别拿来训练”的常见做法。第二路径排除很重要后台、管理后台、私人接口不要放出来否则 AI 代理会像搜索引擎一样去收录你不想公开的东西。我放行之后做过一次测试用一个模拟 AI 代理 UA 的脚本去抓自己的文章页状态码从 403 变成 200内容完整返回。这才是第一步后面还有更关键的改造。3.2 第二步内容载体改造SSR/静态化/语义化如果你用的是 WordPress、Ghost、Hexo 这类传统内容系统恭喜你它们默认就是服务端渲染正文在 HTML 里层层可见。真正的硬骨头是 SPA。我有两个方案摆在台面上方案 A轻量静态化。如果你做的是内容站最省心的做法是退回静态生成路线。博客、文档、新闻类站点完全可以预渲染成静态 HTML部署到对象存储或 Cloudflare Pages 上。这样每个文章页都是一份完整的 HTMLAI 代理抓一次就能拿到全部正文。方案 B为 AI 代理做预渲染。如果你实在离不开 SPA可以在收到 AI 代理 UA 的请求时用无头浏览器预先渲染页面再返回静态 HTML。实现方式可以是自建一个预渲染服务也可以借助 Prerender 之类的中间件。你不用给所有页面都做只要覆盖正文页即可因为 AI 代理关心的也就这些页面。内容载体优化后还要做结构语义化。这是很多人忽略的细节——一个“干净”的 HTML 对 AI 代理来说意义重大。我建议至少做到每个页面只有一个h1标题包含实际主题。正文段落使用article包裹导航使用nav底部信息放到footer。Exception 加廖结构化数据例如文章页加上 JSON-LD 的 Article 标记。下面是一个常见示例{ context: https://schema.org, type: Article, headline: 你的网站有第二类用户, author: { type: Person, name: 你的名字 }, datePublished: 2025-01-01, mainEntityOfPage: { type: WebPage, id: https://example.com/article } }结构化数据相当于给 AI 一张“内容地图”它不用猜直接就能定位标题、作者、发布时间和正文区域。实测下来加了 JSON-LD 之后AI 代理抓取的质量确实有可感知的提升。3.3 第三步用 Cloudflare 管理 Agent 流量与放行规则如果你用了 Cloudflare这里的操作空间很大。首先在Security → Bots里打开异常检测看 Bots Analytics 有没有把 GptBot 这类正规 AI 代理标成“疑似恶意”。我踩过的坑就是开着 Bot Fight Mode 的网站在默认配置下会把几乎所有爬虫都拦下来不管是好的还是坏的。你需要去WAF → Custom Rules里加一条放行规则匹配 UA 为GPTBot、ClaudeBot、PerplexityBot等官方 UA 的请求动作设为“Skip”或者“Allow”。另外Cloudflare 控制台里有针对 AI 爬虫的分析分类你可以直接看到一定周期内 AI 代理的访问量、命中哪些页面、返回什么状态码。我个人的习惯是每周看一眼这个报表关注两个值AI 代理访问占比和抓取失败率。访问占比说明你的内容在 AI 分发渠道里有多受关注失败率则直接反映你的 Agent 可读性改造成果。我还强烈建议开启托管质询Managed Challenge它能自动识别真人浏览器、可信爬虫和恶意 Bot而不是一刀切。真人访客不会感知到太多障碍正规 AI 代理也能通过恶意垃圾流量会被挡在外面。3.4 进阶主动提供 Feed 或 API做到前面几步你的站点在 AI 眼里基本已经“读得懂”了。如果还想更主动一点我建议做两件事。一是保证 RSS/Atom Feed 可用。这真的是最古老也最好用的 Agent 友好接口。AI 代理抓取 Feed 比抓取整个页面更容易拿到最新内容列表和时间戳很多 Agent 框架在选数据源时也会默认偏好 Feed。我在自己的站点上保留了完整的 RSS 输出实测很多 AI 工具会优先从 Feed 里取最新文章而不是逐页爬取。二是针对高频内容做一个轻量 API。比如你的站点有一个“今日推荐”“产品更新”之类的模块与其让 AI 代理去猜页面结构不如直接提供一个 JSON 接口返回干净的结构化数据。这不只是对 Agent 友好对你自己做数据分发也是收益。需要注意的是API 要加一个简单的鉴权参数避免被垃圾流量刷烂。如果你对 Agent 开发有接触你会明白不管用 LangChain 还是其他 agent 框架与编排方案Agent 的核心能力边界往往取决于“数据源能不能被稳定读取”。你主动提供 Feed 和 API就等于给 Agent 铺了一条高速公路省去它爬取解析的弯路被引用的概率自然更大。4. 监控与排查Agent 来了你看得见吗4.1 怎么从日志里认出 AI 爬虫改造完之后你要能持续观察效果。最直接的方式是查服务端日志。以 Nginx 为例grep -iE gptbot|claudebot|perplexitybot|anthropic-ai|google-extended|applebot-extended access.log | tail -100这条命令能让你看到哪些 AI 代理来过、访问了哪些路径、返回什么状态码。如果你把 access log 接入了监控系统可以按 UA 维度聚合统计每周 AI 代理访问量变化趋势。如果你用的是 Cloudflare Tunnel 或者直接接入了 Cloudflare CDN我建议从 Cloudflare 侧看日志。因为我遇到过一种情况本地 Nginx 日志里完全没有 AI 爬虫记录但 Cloudflare 侧显示 AI 代理天天在抓。后来一查是 Cloudflare 的 Bot 拦截层把请求挡掉了流量根本没到源站。这种场景下光看服务器日志会误判成“没有 AI 来”实际上不是不来是走了就被拒了。顺便说一句我自己排查过的一次 Cloudflare Tunnel 相关问题时发现Tunnel 本身不干扰 AI 爬虫的访问决策AI 代理照样会请求通过 Tunnel 暴露的站点。所以判断 Agent 可读性时别以为是链路问题大概率是内容层或规则层的问题。4.2 常见问题速查表403、5秒盾、缓存、带宽我是一个表格党整理了一张高频问题的速查表基本覆盖了我在改造项目里遇到的所有坑现象可能原因解决方向AI 代理返回 403/406Cloudflare Bot Fight Mode 或服务器 UA 过滤误伤在 WAF 白名单放行官方 AI UA返回 5 秒盾质询页托管质询对 AI 代理不友好确认代理是否使用官方 IP/UA必要时创建 Skip 规则页面 200 但内容为空SPA 渲染正文由 JS 动态生成做服务端渲染或预渲染改造状态码 200 但内容乱码/含大量弹窗文案Cookie 弹窗、浮层遮罩污染正文提取对 AI UA 隐藏弹窗脚本总抓取量巨大带宽飙升放行规则太宽AI 代理高频重试加请求频率限制、控制 Allow 路径范围回应内容与实际页面不一致CDN 缓存过期策略不当调整缓存 TTL关键内容标记 no-store这里我想特别强调“状态码 200 但内容为空”这个情况它比 403 更隐蔽。我遇到过不止一次页面看起来正常、HTTP 状态码也是 200可 AI 代理拿到的 HTML 里正文部分是空 div。这种问题不到 AI 侧根本发现不了普通真人用户永远不会报错因为浏览器渲染之后一切正常。这类问题几乎只可能在服务端渲染和客户端渲染之间出现。改造的时候最好用 curl 模拟 AI 代理 UA 抓一次页面看看返回的 HTML 里有没有实际文案。我推荐在改造前后各抓一次对比能明显看出差异。4.3 安全收尾放行 Agent 不等于裸奔最后特别提醒一点放行 AI 代理不等于把站点完全裸奔交出去。我见过不少人改完 robots.txt 后就把所有规则全开放结果不只是正规 AI 代理进来了连伪装成 GPTBot 的垃圾爬虫也混了进来。有恶意爬虫会伪造 UA把自己伪装成知名 AI 代理然后高频抓取你的内容去洗稿或做其它用处。应对方式很简单别只看 UA要同时校验 IP 来源。OpenAI、Anthropic、Perplexity 这些公司都公开了自己的爬虫 IP 段你可以在 Cloudflare WAF 规则里加上 IP 段验证只对“官方 UA 官方 IP 段”的请求放行。再提醒一个合规层面的细节放行 Agent 前你最好在网站底部或隐私政策里写明“本站内容可被 AI 代理按 robots 许可访问”。这不是法律建议但在当前环境下明确标注访问边界能避免后续内容被滥用时的扯皮麻烦。我在一次项目里就遇到过明文规则写好了、但忘了同步给 Cloudflare 的 WAF 规则结果 AI 代理在 Cloudflare 层被拦、但服务器层又放行两边配置不一致排查花了整整一个下午。现在我把所有规则集中管理服务器层只负责拒绝敏感路径Agent 访问策略统一放在 Cloudflare 层逻辑清晰多了。5. Agent 可读性背后的更深一层你的内容正在被“代读”5.1 第二类用户如何改变流量结构这可能是整篇文章里我最想强调的部分。Agent 可读性不只是技术指标它是流量结构变化的信号。过去网站流量的典型路径是用户打开浏览器 → 输入域名 → 访问网站。现在越来越多的用户走的是用户在 AI 对话框里提问 → AI 代理去检索你的网站 → 总结后把答案给用户。在这个链路里用户全程没有直接访问你的域名但他确实使用了你的内容。这就是“第二类用户”的核心定义通过 AI Agent 间接消费你网站内容的用户。如果你不对这些 Agent 友好你的内容就不会被 AI 引用你在这个新分发渠道里就等于不存在。而这次 Cloudflare 扫描 20 万个域名得出平均 48 分本质上就是在告诉你目前绝大多数网站正在这个新渠道里静默消失。我还想点破一点Agent 可读性和搜索引擎优化SEO的逻辑一脉相承但要求更苛刻。搜索引擎有自己的成熟爬虫能处理复杂 JS还会为页面建立索引。AI 代理执行的 JavaScript 能力参差不齐对内容纯净度的要求更高。所以以往那种“内容埋在弹窗后面、靠 SEO 插件堆关键词”的玩法在 Agent 面前完全不灵。5.2 从 48 分到 80 分我做了什么最后分享一个具体案例。我有一个旧项目就是用 React 写的前端文章内容全部由接口异步加载robots.txt 当时也写得非常粗糙。我扫了一眼后台AI 代理的访问几乎是零。按照提交的流程改造了一遍第一步规范化 robots.txt放行主流 AI 代理排除后台和管理页面。第二步给文章页加了服务端预渲染让 AI 代理拿到完整 HTML。第三步加 JSON-LD 结构化数据明确标识标题、作者、发布时间。第四步在 Cloudflare WAF 里放行官方 AI 代理的 UA 和 IP 段同时关掉对它们不友好的 Bot Fight Mode。五步关闭对 AI 代理展示 Cookie 弹窗通过一个简单的 UA 判断让正式 AI 代理直接看到干净正文。整个改造大概花了一个周末。改完之后的第二周我打开 Cloudflare 的分析报表看 AI 代理访问量从原来的一周几十次涨到了一天几百次抓取失败率从 60% 降到了 10% 以内。如果你按类似路径去改造自己的站点从 48 分这个平均线冲到 80 分是完全可行的。这个分数变化背后是 AI 代理能有效读到你的内容了意味着你的网站真正接入了 AI 分发的新网络。我自己现在对站点所有改版的一个默认标准就是上线前必须用模拟 AI 代理抓一次正文能不能干净取出过不了这一关就不算完成。这个习惯帮我避掉了不少事后返工。