网站防火墙挡住的，往往正是你想放进来的 AI 爬虫

搜「网站防火墙」的人多半是想装一套或者调几条规则。这一章讲的是反过来的那件事：它正在把你想放进来的 AI 爬虫挡在门外，而在托管平台上，能挡它的那一层往往不是你能改的那一层。下面给出诊断顺序、四家平台各自让你动哪一层，以及两种改了等于没改的情况。

读这一章之前

动手改之前先要有一份「现在是什么样」的读数。还没按 UA 逐个测过的话先去测，那些状态码是下面每一个判断的输入；靠猜是哪一层出问题，一个下午就没了。怎么从响应头分辨是边缘在挡还是源站在挡，在 谁在挡 AI 爬虫 里讲过。

先定一个词，后面才立得住：AI 爬虫是替某个 AI 产品来取你页面的、有名字的自动客户端。哪些值得放行、哪些名字其实是控制令牌而不是爬虫，在 该放行哪些 AI 爬虫 里定。本章假设你已经想清楚要放谁进来，只回答怎么真的放进来。

自己浏览器打开是 200，什么都证明不了

爬虫拿到你的 HTML 之前，有三套系统先投票：你发布的 robots.txt、站前面那层边缘规则、以及源站本身。你的浏览器三关全过，因为它长得像浏览器、来自住宅网络地址。一个有名字的爬虫经常卡在第二关 —— 而第二关正是托管平台留给自己的那一层。

最常见的白干就是从这儿来的。有人改了 robots.txt，部署，用浏览器打开那个文件，看到新规则生效，于是认定站是开的。文件是请求。边缘规则才是决定，而没人动过它。

robots.txt 是请求，边缘规则才是决定。在托管平台上你很少能同时改到这两层。

网站防火墙挡人时，按这个顺序查

从外往里查。每一步都告诉你下一步还有没有必要，而且在第一处拒绝停下来，可以避免一次改三样东西。

1. 用一个有名字的爬虫 UA 请求首页，记下状态码和响应头。403 或者一个人机校验页是边缘的决定；200 才进入第二步。
2. 拉自己的 /robots.txt，读适用于那个名字的那一组。通配组下面一条 Disallow: /，对所有没有自己分组的爬虫都成立。
3. 在交付的 HTML 里找 meta name="robots" 里的 noindex，在响应头里找 X-Robots-Tag。这两样不阻止抓取，所以永远不会表现成一次失败的请求。
4. 三层都干净、爬虫还是拿不到有用的东西，那问题就不在有没有交付，而在页面里装了什么。

第一步和第三步抓的是两种毛病，很容易混。第一步答的是「我被交付了吗」，第三步答的是「我被允许拿去用吗」。一个页面可以过了一个、栽在另一个，而任何地方都不报错。

四家平台各自让你改哪一层

下面每一行都是那家平台真正让你动的那一层，取自它自己 2026-08-21 的官方文档。这些差别不是外观差别，它决定了一次修改到底能起什么作用。

Cloudflare 这一行是好情况：一个界面、一次一个爬虫，而且是全套餐可用，不是升级才给。站前面挂着 Cloudflare 的话，先去那儿看，再动仓库里的任何东西。

Vercel 这一行最容易被读反。它针对 AI 爬虫的那套托管规则集默认是关的，也就是说 Vercel 站上一次说不清来源的拦截，通常不是它干的。它另一套 bot protection 规则集同样默认关闭，而且开启后会「automatically excludes verified bots, such as Google's crawler, from evaluation」—— 同一个开关下，搜索爬虫和一个较新的 AI 爬虫可能得到完全相反的待遇。Vercel 还写明了一个叠加陷阱：「Bot Protection doesn't work when a reverse proxy (e.g. Cloudflare, Azure, or other CDNs) is placed in front of your Vercel deployment.」很多出海站正好是 Cloudflare 套在 Vercel 前面这种结构。

WordPress 是设置文案最误导人的一个。那个勾叫「不允许搜索引擎索引本站点」，而它自己的文档把边界写得很清楚：「Neither of these options blocks access to your site — it is up to search engines to honor your request.」5.3 版之后它靠写一个 meta 标签生效，不再改 robots.txt —— 只审文件的人会什么都查不出来。

Shopify 把文件交给你，但不建议你整个重写。它的文档推荐用 Liquid 对象而不是纯文本，因为默认规则「updated regularly to ensure that SEO best practices are always applied」。手写一份替换掉，等于把那天的默认值冻在原地。

有两家今天核不到，就不写

Webflow 的帮助中心 2026-08-21 对我们回 403，Netlify 那页回 404，两家都拿不到官方原文。我们不描述自己打不开的设置界面。你的站在这两家上，就按上面四步查出是哪一层在拒绝，再去看厂商当前那一层的文档。

这也是本章边界的一般形状：一章能告诉你看哪一层、以及在那一层改动能做到什么；今天那个开关在后台哪个菜单下，只有厂商当前文档说得准，而那个位置会变。

交付物：七行，一遍过

抄进自己的笔记，把右边一列填掉。十五分钟能跑完，而且换平台也不作废 —— 每一行写的是层，不是菜单路径。

每改一次，重跑第一行。整张表里只有它报的是爬虫真实经历到的东西，其余六行报的是你配置成了什么，这两件不是一回事。

有几行在你的平台上会填出「压根没有」。那是另一个问题，答案也不一样 —— 托管平台留给自己的那五层，以及每一层的替代做法，在 Shopify SEO 做不到的那几件事。

做错了会怎样

这里大部分白费的力气来自三种情况，而且没有一种会报错。

1. 边缘在拒绝，你却在改文件。症状是 robots.txt 完全正确，403 一动不动。部署完重跑第一行，状态码没变，就说明文件从来不是原因。
2. 放开了抓取，忘了摘掉 noindex。爬虫被交付了，页面却不能用，而每一条请求日志看上去都健康。只有第三步能抓到它。
3. 两家叠着，各自以为对方在管。Vercel 文档明写它的 bot protection 在反向代理后面不工作。谁在外层谁说了算，而那一层不一定是你配置过的那一层。

想知道某个爬虫此刻实际收到了什么、而不是你的设置写了什么，把它丢进 AI 爬虫可达性检查，再和上面那张表的第一行对一下。

常见问题

网站防火墙会把 AI 爬虫挡掉吗？

会，而且这是托管平台上最常见的那一层。判断办法是用指名 UA 请求一次：回 403 或者人机校验页，就是边缘在拒绝，跟你的 robots.txt 无关。

Cloudflare 默认屏蔽 AI 爬虫吗？

Cloudflare 文档写的是 AI Crawl Control 全套餐可用、自动生效，放行还是拦截按爬虫逐个设。你这个域名当前的默认动作是什么，只有那个后台里看得准。

改了 robots.txt 没反应，为什么？

因为 robots.txt 是一个请求，爬虫自愿遵守；对一个还没到你站上就被拒绝的请求，它一点作用都没有。状态码没变，说明拦截发生在文件之上。

noindex 会让爬虫抓不到页面吗？

不会。抓取成功，页面也拿到了，这条指令说的是别拿去用。所以一个站可以在日志里看着完全可达，同时在结果里一条都不出现。