最让人抓狂的一种情况是：你打开自己网站的 robots.txt，白纸黑字写着 Allow: /，
每个 AI 爬虫都单独放行了一遍，可 ChatGPT 依然说"我没找到你的网站"，Perplexity 从来不引用你。
这时候问题通常不在那份文件上。
| 层 | 谁在管 | 你能不能直接看见 |
|---|---|---|
| 1. robots.txt | 你自己写的规则 | 能，直接打开就能看 |
| 2. CDN / WAF | Cloudflare 的机器人管理、AI Crawl Control、Bot Fight Mode | 不能直接看见，要去后台查 |
| 3. 源站 | 服务器防火墙、速率限制、插件 | 要看日志 |
绝大多数在线的"AI 爬虫检测工具"——包括我们自己那个免费工具——默认只检查第 1 层： 抓你的 robots.txt，解析规则，告诉你哪些爬虫被允许。它们不会（也无法）知道第 2 层发生了什么， 因为第 2 层的拦截发生在请求到达你的服务器之前。
所以会出现这种很讽刺的结果：工具说"全部放行"，真实爬虫却连门都摸不到。
Cloudflare 在 2025 年推出 AI Crawl Control，其中一个开关就是"屏蔽 AI 爬虫和抓取器"。 据 Cloudflare 当时的说法，新加入的域名会默认开启这个功能。
开启后，Cloudflare 会直接拒绝已知的 AI 爬虫请求——不管你的 robots.txt 写了什么。 你的文件还在，看起来也没变，但爬虫拿到的是 403 或者一个挑战页。
去哪里看：Cloudflare Dashboard → 选择你的域 → 左侧 Bots（机器人） / 机器人管理 → 找 AI Crawl Control。开关状态以你实际看到的为准，不同账号、不同时期默认值可能不同。
这个功能的做法不是拦截请求，而是直接改写你的 robots.txt： Cloudflare 在你返回的文件里注入一段托管规则，常见表现是文件里多出一块类似这样的内容：
# BEGIN Cloudflare Managed content User-agent: GPTBot Disallow: / ... # END Cloudflare Managed content
于是出现了一个特别坑人的现象：你源站上的 robots.txt 文件是放行 AI 的， 但访客（和爬虫）实际拿到的那份是封禁的。你用 FTP 打开源文件自查，永远查不出问题。
怎么确认：不要看本地文件，直接看线上返回的真实内容——在浏览器打开
https://你的域名/robots.txt，搜一下有没有 Cloudflare Managed 字样。
这两个是通用的机器人防护，本来用来挡垃圾流量和撞库，但它们判断"是不是机器人"的方式比较粗—— 会下发 JavaScript 挑战、托管挑战，或者直接返回 403。
AI 爬虫一般不执行 JS，遇到挑战页就直接放弃。结果就是你没主动屏蔽任何 AI 爬虫，但它们全都被当成坏机器人赶走了。
如果你的站开了 Bot Fight Mode，同时又希望被 AI 检索到，这两件事是冲突的，需要二选一或加白名单规则。
浏览器打开 https://你的域名/robots.txt，搜索 Cloudflare。
有托管块就说明第 ② 处生效了。
robots.txt 说允许，不代表真的允许。用命令行假装成 GPTBot 去请求一次：
curl -A "GPTBot" -I https://你的域名/
看返回的状态码：200 = 进来了；403 / 503 = 被 CDN 挡了；
返回一大段 HTML（挑战页）也是被挡。
没有命令行也没关系——用 Aivisnap 免费检测， 它除了读 robots.txt，还会用 6 个真实爬虫的 UA 各请求一次，专门用来抓这种"文件说可以、实际不让进"的情况。
Dashboard → Bots / 机器人管理，把 AI Crawl Control、Bot Fight Mode 的状态都过一遍。 只看默认视图容易漏，有些开关藏在二级页面里。
curl 一次确认文件恢复原样。robots.txt 是自愿协议。它只约束愿意遵守的爬虫。反过来，不守规矩的抓取器根本不看这个文件—— 想挡住它们得靠 WAF，不是靠 robots.txt。这也是为什么"我明明写了 Allow 却没被抓"和 "我明明写了 Disallow 却还是被抓"都可能同时成立。
允许 ≠ 一定被抓。放行只是给了许可，Google 和 OpenAI 会不会来、多久来一次， 取决于它们自己的调度。新站等几周是常事。别因为改完一天没动静就改回去。