robots.txt说允许，GPTBot仍有10个站进不去

摘要：同一批211个独立站首页，这次换了7种身份各要一次，只看谁拿得到、谁拿不到。132个站愿意对普通浏览器给出真页面，在这132个上，Googlebot拿到97.7%，GPTBot拿到90.9%，而什么身份都不报的那一次只拿到48.5%。更意外的是反向：robots.txt里明确点过GPTBot名字的13个站，13个全都把页面交了出来；真正在送达环节挡住AI爬虫的，恰恰是那些robots.txt里一个字都没提过它的站。文章还记了一个55字节的402付费墙和一个字节数为0的418。

上一篇文章的结尾留了个尾巴。当时抓211个独立站首页，最后只剩132个能拿来做内容分析，剩下那79个要么连不上、要么撞上人机验证、要么直接被403挡回来。我说那79个的去向是另一篇文章的题目。

这就是那一篇。

那一篇把132份首页的可读字符逐个数了一遍，132个独立站首页有28个是空壳，算是这次实验的上半场。

先把两篇的关系交代一下，免得混。上一篇问的是：抓回来的字节里到底有没有字。这一篇问的是更前面的一个问题：字节到底有没有到你手里。前者是内容问题，后者是通路问题，而通路出事的时候，内容写得再好也没有任何意义。

这两个问题的先后顺序不能颠倒。先确认拿得到，再讨论拿到的东西够不够好。顺序反了，你会在一个根本没送出去的页面上花几周时间调标题、补描述、加结构化数据，然后困惑于为什么一点变化都没有。

先讲一件2026年8月中旬在圈子里传得挺广的事，原始报道是Search Engine Roundtable关于误配置内容分发网络重创SEO的那篇。有位技术顾问接手了一个客户，客户的自然流量在两周里几乎归零。所有人第一反应都是算法更新，因为曲线掉得又快又干净，长得就像被核心更新削了一刀。查完之后真相是这样的：客户的IT外包商在内容分发网络的后台点开了一个爬虫控制开关，一键屏蔽所有机器人。

同样的顺序问题在流量诊断里也成立，收录、排名、流量是三件事讲的就是别把三层混在一起查。

这类后台的选项密度确实高，独立站的缓存与回源率优化决策树能帮你分清哪些开关碰得、哪些碰不得。

这一下同时打穿了三条业务线。搜索引擎抓不到，页面陆续掉出索引；购物广告的商品列表全部消失；而广告账户那边毫无察觉，钱照扣，一天没落下。整整两周，客户的网站内容一个字都没改过。

我把这件事记下来，不是因为它离奇，而是因为它太不离奇了。这一类故障有一个共同的形状：东西明明还在，只是那一次请求没拿到。它和“东西根本不存在”是两种病，药方还互为毒药——上一篇讲的是前者，这一篇讲的是后者。

掉出去之后怎么捞回来，页面不被Google收录的急救手册按症状分诊列了完整流程。

更麻烦的是它的隐蔽性。缺失型故障你自己能查出来，抓一次页面剥掉标签数一数就完了。送达型不行，因为拦截发生在边缘，请求根本没到你的服务器。你的访问日志里干干净净，一条记录都没有，唯一记着这件事的是对方。

所以这篇文章不打算讲配置怎么点。配置面板一年改三次版，写下来第二个月就过期。它要解决的是更前面那个问题：一个页面拿不到，你怎么在十分钟之内判断它属于哪一种病。判据只有一条，后面会用211个站的实测数据把它撑起来——同一个地址，换一个身份再要一次，两次结果不一样，那就是送达型。

日志能回答什么、不能回答什么，AI爬虫到底有没有抓你的站那篇分得很细。

把这类判据成体系地排一遍，AI时代技术SEO的五个新层次是本站的审计总纲。

一次开关被点开，为什么你的后台什么都看不到？

先把这类事故的形状讲清楚，不然后面的数据你会不知道该往哪儿放。

三条业务线是被同一个动作打穿的

前面那个案例里最值得咂摸的细节，不是流量掉了多少，是三件事同时发生却互不通气。自然搜索的排名开始滑坡，购物广告的商品列表消失，付费广告继续正常投放并且正常扣费。

这三件事共用同一个前提：机器要能读到你的落地页。搜索引擎读不到就不给排名，购物平台读不到就下架商品，而广告投放系统的账单逻辑跟落地页能不能被读到没有强绑定，于是它就成了三条线里唯一没报警的那条。

商品列表这条线还有自己的资质门槛，跨境电商GTIN怎么申请讲的是它另一头的合规要求。

这就是送达型故障最恶心的地方。它不会给你一个统一的报警，它会给你三个互相矛盾的信号。一条线沉默，一条线报警，还有一条线在正常收钱。你坐在中间，很难第一时间想到这三件事其实是一件事。

另一位顾问在同一周晒出了另一个案例。一家在线市场类网站被爬虫压得服务器扛不住，团队只好在防火墙层加了一层机器人访问限制，纯粹是为了让站活着。结果曲线掉得跟被算法更新处理过一模一样。他的原话是：这看着像核心更新甚至像垃圾内容更新，但它不是。

多个信号打架的时候需要一条共同的时间轴，SEO变更日志的企业站治理给的就是这套记法。

被抓到扛不住是真实存在的，网站被恶意流量打崩时的识别与应急拦截讲的是另一头的压力。

为什么它长得像算法更新

两者的曲线确实很像，因为掉的都是“被收录页面能带来的流量”这一层。但形状上有几处能分开。

算法更新的下滑通常有结构：某一类页面掉得多，另一类掉得少，长尾和头部的比例会变，不同国家的市场往往不同步。防火墙误伤的下滑没有这种结构，它是整片的，所有类型的页面按同一个节奏往下走，因为拦的是请求，不看你是什么页面。

时间点也不一样。算法更新有一个业内共同的时间戳，你在几个行业媒体上都能查到同一天。配置误伤的时间戳只在你自己的变更记录里，而绝大多数团队根本没有变更记录这个东西。

还有一个更简单的分法：算法更新不会让你的购物广告商品列表消失。一旦出现“自然流量和商品列表同时消失，但广告费照常扣”这种组合，八成不是算法的事。

到底是谷歌动了还是你自己动了，排名突然抖一下的分层归因有一套现成判据。

抓取报告里那几类问题地址各占多少，Google抓取报告怎么读给了排查顺序。

日志里为什么找不到证据

很多人的第一反应是去翻服务器日志，看看搜索引擎爬虫是不是不来了。这个动作方向没错，但会得到一个误导性的结论。

拦截发生在边缘节点，也就是内容分发网络那一层。请求在那里就被判了，返回一个403或者一个人机验证页，然后结束。这一整趟往返，你的源站从头到尾都不知道发生过。所以你打开访问日志，看到的不是“爬虫来了被拒绝”，而是“爬虫没来”。

这两句话在日志里长得一模一样，含义差着十万八千里。前者是送达问题，后者是抓取需求问题，处置方式完全相反。分开它们的唯一办法，是去边缘那一层的日志里看，或者更直接——自己扮成那个身份去要一次。

边缘那一层能做的事比多数人以为的多，边缘SEO是什么讲了它的原理与落地形态。

日志里要看得出真实来源IP，得先把格式配对，访问日志怎么配才查得清问题有现成模板。

三条业务线，三套互不相通的告警

再往深一层看，这类事故之所以能拖两周，跟工具本身的设计也有关系。

搜索端的报告有延迟。抓取异常的数据从发生到出现在报表里，通常要隔一到三天，而且它默认按周汇总，一条曲线要跌得足够深才会引起注意。等你看见它，事情已经发生一阵子了。

购物端的反馈快一些，商品被拒会有邮件通知。但那封邮件的措辞通常是商品层面的，比如某个商品的落地页无法访问，看着像是单个商品的问题。收件人多半是运营，运营的第一反应是重新提交，而不是怀疑整个站的机器人策略。

这份报表的口径坑不少，GSC的数字为什么人人都读错逐项拆过一遍。

重新提交之后多久能回来，网站收录速度实操指南用三个平台的数据给了参考区间。

广告端根本不参与。投放系统关心的是出价、预算、素材和落地页能不能打开——注意，是能不能被真人打开。真人打得开，钱就照花。于是三条线里唯一实时的信号，恰好是唯一不报警的那一条。

这也解释了为什么这类故障的发现往往靠一个巧合：某个人手痒去查了一下收录，或者某个客户问了一句为什么搜不到你们了。它不是被监控发现的，是被人撞见的。

变更记录这件小事，值多少钱

开头案例里有一个容易被忽略的细节：动手的是客户的IT外包商，而发现问题的是SEO顾问。这两个角色之间通常没有共享的变更记录。

我见过太多这样的结构了。网站的域名解析在一个人手里，内容分发网络在另一个人手里，服务器在第三个人手里，而对流量负责的那个人，往往三个后台都没有账号。出了事，第一小时全花在找谁动过手上。

解法不复杂，就是一份共享的变更记录，谁在哪个后台改了什么，一行字。它的价值不在于防止犯错，而在于把排查时间从两周压缩到两小时。

把这些分散的动作收进定时任务，独立站服务器怎么用cron把运维自动化是最省心的做法。

做外贸独立站的团队还有一个额外的复杂度：链路上的角色更多。域名可能在境外注册商，加速可能用了境外的内容分发网络，源站可能在境内，中间还可能夹着一层做国内访问优化的节点。每多一层，就多一个能悄悄拦人的地方。

这条链路上最常见的意外，是那些为国内访问做的优化配置。有些高防和加速产品的默认规则对境外来源的请求更严，而搜索引擎爬虫的出口恰恰全在境外。你为了让国内用户打开得快一点，顺手把抓取你的那批机器归进了可疑名单。

判断方法还是那一条：换个身份要一次。如果境内出口的请求正常、境外出口的请求被挡，那问题就在这一层，跟你的内容毫无关系。

主机放境内还是境外本来就是取舍，外贸独立站用国内主机还是国外主机把备案、速度与合规摆在一起算过。

海外用户打不开的排障路径，从DNS、线路到CDN的网络层排障是同一套方法的另一面。

如果连这个都推不动，还有一个更低成本的替代品：把关键配置定期导出成文本存一份。内容分发网络的规则、robots.txt、跳转规则，每周一次，存进版本库。下次出事的时候，跑一次比对就知道动了什么。

这也是我决定跑这次实验的原因。与其猜，不如把211个站排成一排，用7种不同的身份各要一次，看看谁拿得到、谁拿不到。

跳转规则这一层最容易失控，.htaccess的六层综合治理给了可版本化的写法。

同一个首页，7种身份各要一次会发生什么？

方法先交代清楚，因为这篇所有的百分比都挂在这一段上。

7种身份是怎么选的

样本沿用上一篇那211个国际化独立站的域名，覆盖服饰、家居、消费电子、美妆、户外几个大类，都是有独立品牌、面向多国市场的品牌自营站。用同一批样本的好处是，两篇文章的结论可以直接互相印证。

身份一共7种，除了用户代理串不同，其余请求参数完全一致：都跟随跳转，都开压缩，都不执行脚本，超时都是同一个数，并发窗口也是同一个。

这批站几乎都做了多语言，国际化SEO和hreflang怎么做是理解它们结构的前提。

需要说清楚一件事：我报的这些名字全部是自称。用户代理串本来就是一行可以任意填写的文本，这一点MDN关于User-Agent请求头的说明里写得很清楚。请求是从一台普通的云服务器发出去的，IP地址跟这些爬虫官方公布的网段没有任何关系。也就是说，这台机器唯一做的事情，就是在请求头里写下一行字。

这个设定不是偷懒，它恰恰是实验的一部分。真爬虫的身份是可以被反查的：拿到IP之后做一次反向域名解析，再把解析出来的域名正向解析回去，看两次能不能对上。这套流程各大搜索引擎都公开写过。所以这次实验里，一个站放不放我进去，直接反映了它到底是按名字判断，还是按行为判断。

基线不能拍脑袋定，得从数据里长出来

211个域名里，普通Chrome请求真正拿到一个像样页面的只有132个。剩下79个的构成是：32个直接给了人机验证页，18个连不上或者连接被重置，12个返回4xx，还有十几个返回了正文极短的空响应。

各家爬虫的串长什么样、怎么验，爬虫识别与UA分类指南列得很全。

验证页背后那套机器人管理逻辑，防火墙到底拦不拦得住AI爬虫拆过一遍。

所以后面所有比例都算在这132个上。这么定的理由是：只有当一个地址已经证明了它愿意对普通请求给出真页面，你才有资格说另一个身份被“挡住”了。否则你只是在统计一堆本来就打不开的站。

这一步看着琐碎，其实是这类审计最容易出事的地方。上一篇栽过一次跟头：把一批HTML里几乎没有可读文本的空壳页混进结构审计的样本，某个结论虚高了6.4倍，另一个虚高了11倍。判据一个字都没写错，错在样本边界。

7种身份的成绩单

数字在传播中走样是通病，10条最佳实践清单里8条数字对不上是另一个例子。

先看前五行。搜索引擎爬虫和AI爬虫之间确实有差距，但没有传言里那么夸张——最高97.7%，最低90.9%，中间隔着不到7个百分点，换算成绝对数是9个站。

然后看最后一行。什么身份都不报的那一次请求，通过率直接砍掉一半还多。在这批站上，沉默比自称是AI爬虫的代价大得多。

抓取量的对比更悬殊，AI爬虫抓取量已超Googlebot 3.6倍给了量级。

什么算“拿到了页面”

这个判据得说清楚，因为它决定了上面每一个数字。

一次请求要算成功，得同时满足四个条件：状态码在200到299之间，最终正文超过1500字节，不是人机验证页，连接没有失败。任意一条不满足，都记成没拿到。

1500字节这条线是有来历的。这批数据里，正常首页的字节数中位数在3万以上，而所有验证页和错误页都在3000以下，中间有一段非常干净的空档。把线画在这个空档里，两边都不会误判。

字节这条线两头都要看，46个电商站的页面体积实测量的是上限那一头。

识别验证页的办法是看正文特征：这类页面通常带一段固定的提示文案和一个挑战脚本，长度集中在2000到6000字节之间，标题字段往往是“请稍候”或者“正在验证”这一类。逐个人工核对过一批之后，我把特征固化成了几条字符串匹配。

这里有一类特别容易漏的情况：状态码200、正文只有几百字节的“薄响应”。全部211个域名里，普通Chrome拿到这种薄响应的有10个。它们不是拒绝，也不是验证，就是一个空壳——服务端返回了一个骨架，内容等着客户端去请求。

薄响应在监控里是最隐蔽的一种，因为它状态码正常、响应时间正常、甚至还有HTML结构。要发现它，只能加一条正文长度的检查。这也是上一篇文章的主题。

薄响应多半是渲染模式造成的，AI爬虫抓不到JS渲染的引用率实测做过对比。

可提取性有更系统的量法，语义化HTML到底影响AI抓取吗拿样本页跑过。

为什么只测7种，不测更多

能测的爬虫身份远不止7种，光是叫得出名字的AI相关抓取程序就有二三十个。选这7个是有取舍的。

桌面Chrome和空用户代理是两个必需的极端，一个代表“最受欢迎的身份”，一个代表“没有身份”。中间五个覆盖了三类利益关系：会还流量的搜索引擎、只取不还的训练抓取、以及介于两者之间的AI搜索抓取。

这些串在日志里长什么样，AI Agent抓取日志的8类UA实测做过完整账本。

再加身份的边际收益很低。同一家公司的多个抓取程序，在防护规则里通常被归进同一个分类，测三个和测一个的结果高度重合。而每多一个身份，就要多跑211次请求，对被测站是实实在在的负担。

时间窗也是个变量。全部1477次请求在同一个时间窗内跑完，避免出现“这个站是白天抓的、那个是深夜抓的”这种偏差。做送达型测试，时间必须被控制住，因为限流规则本身就是时间的函数。

这次实验的边界在哪里

把局限性摆在前面说，后面的数字才好用。这份数据有四个地方是不能超出去解读的。

时间维度还有另一层，304状态码能省抓取预算量的是同一批站的条件请求能力。

第一，只测了首页。首页往往是全站防护配置最松的一页，因为它承担品牌展示的职责，谁都不希望它出问题。商品页、搜索结果页、筛选页的待遇通常更严。所以这批通过率应该被理解成上限，不是平均值。

第二，只采了一次。送达型故障有很强的时间性，限流是按窗口算的，某个站在某一分钟拒绝你，下一分钟可能就放行。单次采样能看出结构性的差异，看不出偶发的抖动。

搜索结果页本身也有问题，40个电商站的站内搜索页实测发现查无结果和查得到长得一样。

响应时间和抓取预算是联动的，TTFB怎么优化才不白费把两头串在了一起。

第三，只有一个出口。所有请求从同一台机器发出，IP在中国。这个条件对做了地理分流的站影响很大，后面有一整节在讲它。换个出口重跑，部分结论会变。

第四，身份是自称的。这既是实验设计的一部分，也是一个边界——它测的是“按名字放行”这套逻辑，测不出那些真的做了验证的站会怎么对待真爬虫。不过从结果看，做验证的站少到可以忽略。

跨语言的实体对不上是另一类顽疾，国际化SEO最难的不是hreflang列了五大根因。

把这四条摆清楚之后，这份数据能支撑的结论其实只有一句话：在同一个时刻、同一个出口、只看首页的条件下，身份这一个变量能造成多大的差别。而答案是：能造成从48.5%到97.7%的差别。这已经足够说明问题了。

这个结果第一眼是反直觉的。按常理，你不说自己是谁，系统应该没有理由针对你。实际情况正好相反，而原因在下一节。

空用户代理的通过率只有一半，被挡的63次里有59次撞上验证页

这一节讲那个对照组，因为它是整份数据里信息密度最高的一行。

被挡的不是拒绝，是验证

空用户代理的63次失败里，59次拿到的是人机验证页，只有4次是干脆的403。这个比例几乎是压倒性的，说明拦它的不是一条黑名单规则，而是那套“我不认识你，先证明你是人”的默认逻辑。

验证页和拒绝页是两种东西。拒绝页的意思是“我知道你是谁，我不给”，验证页的意思是“我不知道你是谁，你先过一关”。前者针对身份，后者针对未知。

三层拦法各有代价，拦AI爬虫该不该给了robots、UA与WAF的选型框架。

而机器过不了那一关。它不执行脚本，不算工作量证明，不点复选框。所以对一个不执行脚本的请求方来说，验证页在效果上等价于永久拒绝，只是它长得更客气一点，还回一个看起来正常的HTTP状态。

这里有个细节值得记一笔：这59个验证页里，很多返回的状态码不是403而是200，正文两千来字节。如果你的监控只看状态码，它们会被记成“正常”。一个返回200的验证页，在你的可用性看板上是绿的，在爬虫眼里是一堵墙。

36个站的robots.txt字节数几乎一样

整理这批数据的时候，我顺手把每个站的robots.txt也抓了下来，本来只想统计规则。结果排序的时候看到一件怪事：132个站里有36个的robots.txt大小挤在3560到3720字节这个极窄的区间里。

状态码的语义值得复习，HTTP状态码怎么影响SEO把301、302、404和410的选择讲透了。

自己写这份文件时有虚拟与物理的优先级问题，robots.txt该怎么写才不冲突说明了顺序。

一百多个互不相干的品牌，文件大小差不到5%，这不可能是巧合。翻开内容一看，规则结构确实高度一致，屏蔽的都是购物车、结账、订单、后台那几类路径，只有域名和站点地图那几行不一样。这是同一个建站平台自动生成的模板。

真正有意思的是下一步：这36个站里，有34个的空用户代理请求撞上了人机验证页。比例是94.4%，远高于全样本的47.7%。

哪些页面类型值得屏蔽，电商robots.txt该屏蔽的7类页面给了清单。

同一批站的另一处平台默认值，53个支付页的CSP实测也是配了等于没配。

把这两件事合起来看，结论就出来了：这批站的声明层是平台给的，送达层也是平台给的，店主两边都没有动过手。他打开后台，看到一份写得挺规整的robots.txt，很容易以为那就是自己网站对机器的全部态度。其实那份文件只是平台的说明书，真正决定谁能进门的是另一套他没打开过的开关。

顺带一提，做完归一化去掉域名之后，这36份文件里只有2份是完全一致的。模板是同一个，但每个站都被注入了那么一点点属于自己的东西——就像同一款毛坯房，交房时每家的电表编号都不一样。

37个站还在配一个搜索引擎早就不读的指令

既然robots.txt都抓下来了，就顺手多量了几项。123份能正常解析的文件里，112份声明了至少一个站点地图，总共550行，平均每个站快5行。这个数字挺健康。

另一项就没那么健康了：37个站还在用Crawl-delay这条指令，占比30%。这条指令主流搜索引擎早就明确说过不支持，抓取节奏由它自己的算法决定。

站点地图写错的方式比想象中多，Sitemap到底怎么写才不出错收了2400个站踩过的坑。

两种robots指令的分工经常被搞反，robots.txt和meta robots什么时候用哪个讲了边界。

这37个站不是写错了语法，是在对着一个没人听的收音机认真调频。它不会造成伤害，但它是一个信号：这份文件多半是很多年前配好之后就再没人碰过。一个多年没人碰过的robots.txt，和一套去年才上线的机器人防护策略，凑在同一个域名上，两边说的话对不上是迟早的事。

文件大小的分布也很有意思。最小的一份只有39字节，第二小的62字节，最大的一份57578字节，中间差着1476倍。57578字节是个什么概念？它比这批站里三分之一的首页HTML还大。

一份39字节的robots.txt和一份57578字节的robots.txt

这两个极端值得各说几句，因为它们代表了两种完全不同的治理思路。

39字节那一份，内容只够写一行用户代理加一行允许。它传达的信息是：我们知道这个文件应该存在，所以放了一个，但我们没有任何要限制的东西。对一个内容不多、结构简单的品牌站来说，这个选择其实相当合理。

57578字节那一份是另一个极端。这么大的文件里塞的通常是成百上千条筛选参数的屏蔽规则，一条一条列出来。它反映的是一个站的URL空间已经膨胀到必须靠黑名单去管的地步。

这两种做法没有绝对的高下，但有一条经验是通用的：robots.txt的长度和站点的URL治理质量，往往成反比。规则越长，说明能被生成出来的无效地址越多。真正干净的架构不需要那么多条禁令。

筛选器地址爆炸有系统解法，电商筛选器URL不爆炸的方案是一套8步流程。

无效地址进了索引就是另一笔账，索引膨胀的诊断与处置给了决策矩阵。

还有一个观察角度是站点地图声明。112个站在robots.txt里声明了站点地图，总共550行，平均每站4.5行。声明多行的通常是做了分卷的大站，这是好习惯。而那11个一行都没声明的站，等于把发现新页面这件事完全交给了链接爬行。

平台默认值正在替大多数人做决定

把这一节的几个发现串起来，会得到一个比单条数据更重要的判断。

靠链接爬行就得看架构深浅，独立站网站架构怎么搭讲的正是抓取深度。

36个站用同一份模板生成robots.txt，其中34个的空用户代理请求被同一套逻辑拦下。这不是36个独立的决策，这是一个决策被复制了36次。

这件事本身不坏，平台默认值通常是行业里比较稳妥的选择，能挡掉大量低质量抓取。问题在于所有权的错觉：店主以为那是他的配置，其实那是平台的配置，而平台会改。

平台改默认值的时候，通常会发一封邮件或者写一篇更新日志，很少有人读。等到下一次分类逻辑调整，你的站的行为会跟着变，而你的文档里什么都没变。

所以对用建站平台的独立站来说，有一个动作特别值得做：把平台生成的robots.txt完整存一份到本地，注明日期。每季度取一次，做一遍比对。变了不一定是坏事，但不知道它变了，一定是坏事。

报一个名字就能进，129个站没有一个反查过我的IP？

现在回到那个最锋利的问题上。

托管平台悄悄改规则的事发生过，托管主机可能正悄悄拦AI爬虫是一个真实案例。

这台机器什么都没做，只是写了一行字

再强调一次实验的设定：发请求的是一台普通云服务器，IP在中国，跟任何一家搜索引擎或AI公司的官方网段都没有关系。它做的唯一一件事，是在请求头里写下Googlebot这个词。

结果是129个站把首页交了出来。

用代码识别蜘蛛有几种写法，5种PHP代码识别搜索引擎蜘蛛含反向验证的做法。

没有一个站对我做过反向解析验证。这件事在数据里是可以证明的：如果有站做了验证，我这个身份必然通不过，因为我的IP反查出来是一家云厂商，怎么都不会变成googlebot.com。而129这个数字，跟真Googlebot能拿到的上限已经贴得很近了。

反向解析验证这套流程一点都不神秘，各大搜索引擎的官方文档里都写着，很多服务器软件也内置了。它的原理是拿到访问者IP，先反查域名，再把域名正查回IP，两次对得上才认。整个过程一次请求，几毫秒。

没人做的原因也不神秘：默认配置里它是关的，打开它需要一点点运维知识和一点点性能预算，而不打开它在绝大多数日子里不会出任何问题。

反查验证在Nginx上怎么配，Nginx拦AI爬虫与限速怎么不误伤Googlebot有完整配置。

按名字放行，就等于把门锁交给了报名字的人

把这条结论和上一节的空用户代理放在一起，整套逻辑就完整了。

这些防护系统的判据是名字，不是行为。你说你是Googlebot，它就当你是Googlebot；你什么都不说，它就把你当可疑对象拦下来验证。于是在这套规则里，愿意报名字的都进去了，什么都不说的反而被挡在外面。

这个机制有一个直接的商业后果，值得每一个正在纠结“要不要拦AI爬虫”的站长想清楚：你在后台勾掉的那些复选框，只对那些老老实实报名字的爬虫有效。真想拿你数据又不在乎规矩的那一类，改一行用户代理串就绕过去了，成本是零。

换句话说，这类拦截的实际效果是筛掉守规矩的，留下不守规矩的。你想拦的没拦住，不想拦的拦了一堆。

想知道它们到底抓什么，AI爬虫到底抓你什么是从代码逆向出来的。

那三个连Googlebot都没进去的站

129之外还剩3个。Googlebot在这3个站上也没拿到页面，其中2个撞了验证页，1个连接直接失败。

撞验证页的那两个里有一个是运动品牌的主站。它的表现相当极端：普通Chrome拿到200，17万字节的完整首页；空用户代理也拿到200，同样17万字节；而Googlebot、Bingbot、GPTBot、ClaudeBot、PerplexityBot这五个身份，全部拿到366字节左右的403。

五个身份，五张几乎一样大的拒绝页，而那两个不报名字的请求畅通无阻。这个站的规则写得清清楚楚：只要你自称是爬虫，不管你是哪家的，一律不给。

17万字节还不算大，Googlebot抓取的2MB限制才是那条硬线。

另一个站更彻底。普通Chrome和空用户代理都能正常拿到3万多字节的页面，五个爬虫身份全部是连接失败，状态码0，一个字节都没有，连robots.txt都取不到。这不是拒绝，是根本不建立连接。

反向解析验证怎么开，为什么很少有人开

既然按名字放行有这么大的窟窿，那把验证打开不就完了？确实是这样，但阻力比想象中大。

这份文件取不到的后果很重，网站突然从谷歌消失多半是robots.txt写废了讲了机制。

技术上，这个功能在主流的Web服务器和防护产品里都有现成的开关。原理前面说过：拿到访问者IP，先做反向域名解析，再把解析出来的域名正向解析回IP，两次对得上才认这个身份。搜索引擎官方也公布了可供比对的IP段清单，直接按段匹配更快。

阻力主要有三个。第一是性能，反向解析要走DNS查询，虽然可以缓存，但在流量高峰期加一层外部依赖，运维不愿意。第二是维护，AI爬虫的官方IP段列表更新频繁，而且不是每一家都公布，公布了的格式也各不相同。

按IP段核验伪造爬虫的做法，后台日志里的爬虫伪造识别有5000个站的实战数据。

新出现的代理型爬虫怎么认，Google-Agent是什么单独讲过一个。

第三个阻力最实在：不打开它，99%的日子里什么都不会发生。伪装爬虫身份来抓数据的行为，对绝大多数独立站来说不构成可感知的成本，那就没人有动力去开这个开关。

我的建议是分层处理。对搜索引擎爬虫做严格验证，因为误伤代价太高，值得那点性能开销；对AI爬虫按名字放行或者拒绝就够了，反正真想绕的也绕得过去。把验证的力气花在你最不能失去的那个身份上。

按行为判断长什么样

名字之外还有另一条路，就是看行为。这条路更贵，但更结实。

行为特征包括请求节奏、路径分布、是否读取样式和脚本资源、是否遵守robots.txt里的禁令、有没有携带合理的接受头。真爬虫和伪装者在这些维度上的差别，比用户代理串那一行字大得多。

举个具体的：真正的搜索引擎爬虫会去读robots.txt，而且会在抓取之前读。一个从来不取robots.txt、上来就直奔商品列表的请求方，不管它自称是谁，都值得怀疑。

抓取和渲染分几步，搜索引擎抓取和渲染DOM分几步决定了哪些资源会被取。

再举一个：真爬虫的请求间隔通常是分散的，会跟着服务器响应时间自动调节；脚本化的抓取往往节奏固定得像节拍器。把访问日志按秒聚合画一条曲线，规律得过分的那一条，多半不是它自称的那个。

这些判断在中大型站上有成熟的产品可以买，小站自己做性价比不高。但知道这套逻辑存在是有用的，至少你在选防护产品的时候，可以问一句：你们是按名字判还是按行为判。

现成工具能省很多事，服务器日志分析工具教程讲了怎么读出预算浪费。

132个站里有77个至少挡了一个身份

把整张矩阵摊开数一遍，结果比单看某一行更有冲击力。

132个证明了自己愿意给普通请求真页面的站里，7种身份全部拿到页面的只有55个。剩下77个站，至少有一个身份在门外。占比58.3%。

这77个的构成很不均衡。绝大多数只挡了空用户代理那一个身份，属于默认防护带来的副作用，站主大概率不知道。真正对多个爬虫身份区别对待的，是十几个。

同一批站的另一项体检，211个站有152个拿不出图标用的是同一个样本池。

把这77个按“挡了几个身份”分一下：挡1个的最多，挡2到3个的少数，挡5个以上的只有个位数——但这几个站恰好都是知名品牌，防护配置明显是专门做过的。

这个分布本身说明了一件事：大多数的拦截不是决策，是默认值。真正做过决策的站，你从矩阵上一眼就能认出来，因为它们的模式是干净的、有规律的，而不是零星地缺一格。

顺带纠正一个常见的误解。行业里聊起爬虫拦截，语气通常是“大家都在拦AI”。这批数据不支持这个说法。真正针对AI爬虫做过区别对待的站是个位数，绝大多数站的AI爬虫通过率跟搜索引擎爬虫只差几个百分点。拦AI这件事在讨论区里的热度，远高于它在配置文件里的热度。

把这类矩阵纳入固定动作，企业网站SEO审计框架给了完整检查表。

robots.txt写着允许，为什么GPTBot还是有10个站进不去？

这一节是全篇的骨架，讲的是同一个网站的两层配置怎么互相不认识。

声明层和送达层是两套独立的系统

先把概念摆清楚。robots.txt是声明层，它写的是“我希望你抓什么”，本质上是一份君子协定，靠对方自觉遵守。防火墙、机器人管理、边缘规则是送达层，它决定“你这次请求到底拿不拿得到字节”，是物理层面的强制。

协定这个词是有出处的，机器人排除协议一直到2022年才正式成为标准文档，也就是RFC 9309定义的机器人排除协议，在那之前它当了将近三十年的行业惯例。而送达层那些工具，大部分是最近五到八年才普及的。

误以为它有强制力就会写出错误规则，robots.txt能禁止UTM追踪参数吗是个典型误区。

抓取、索引、排名这条链的基本盘，搜索引擎到底怎么工作讲得最清楚。

两层的年龄差、归属团队差、更新节奏差，凑在一起就是本节数据的来源。

写规则的和配防护的，通常不是同一批人

这个组织问题比技术问题更难解，但它才是错配的真正源头。

robots.txt归谁管？多数公司里归做SEO的那个人或者那个外包团队，因为它是SEO工具箱里的东西。改它不需要权限，只要能改网站根目录的一个文本文件。

防护规则归谁管？归运维或者安全。他们的KPI是可用性和防攻击，不是收录量。在他们的世界里，多拦一个来源是安全的，少拦一个是有风险的。所以每一次拿不准的时候，默认动作都是往紧了配。

不同页面类型的规则要分开配，各类页面的meta robots和canonical配置按5类页面拆过。

跨部门讲清楚价值有方法，老板听不懂SEO错其实在我们给了一套讲法。

这两拨人开会的频率，通常是一年一次，还是在出事之后。他们之间也没有共享的语言：一个说的是抓取预算和收录率，另一个说的是每秒请求数和阻断率。

有一个成本很低的改善办法，是把“爬虫可达性”变成一个双方都认的指标。做法是把本文那个每天跑的脚本的输出，同时发给这两拨人。同一个数字，两个部门看，比开十次会管用。

抓取预算这个词要用对，Google抓取预算优化的12项实操说明了它的边界。

更进一步，可以在防护规则的变更流程里加一个必选项：任何涉及机器人分类的改动，上线前跑一次身份对照。这个动作三分钟，能挡掉本文开头那一整类事故。

两个方向的错配，各占一半

上线流程里还该加一道防护，Staging站被索引后的8步清除讲的是反方向的泄漏。

先看中间那一列。robots.txt明明写着允许，实际却没拿到页面，GPTBot有10个站，ClaudeBot有8个，Bingbot有4个，PerplexityBot有3个，连Googlebot都有1个。

这10个站的名单我逐个核过，涵盖家居、快时尚、手机配件、护肤、户外装备几个大类，没有明显的行业集中。它们的共同点只有一个：写规则的人和配防护的人不是同一批人。

再看最右边那一列，这个方向更值得玩味。robots.txt里明确写着禁止抓取根目录，服务器却照样把页面交了出来，Googlebot有15个站，ClaudeBot有14个，GPTBot和PerplexityBot各13个，Bingbot有12个。

同一批站的商家名称也体检过，112个独立站里17个在犯的双语重复是另一处细节。

这个方向严格来说不算故障，因为robots.txt本来就只约束自觉遵守它的一方，服务器没有义务照着它拦人。但它把那件事说透了：这两层根本不通气，谁也不知道谁写了什么。

为什么错配总是往一个方向偏

把两列放在一起看，能看出一个规律：越是新出现的爬虫身份，声明与送达不一致的概率越高。Googlebot只有1个站错配，GPTBot有10个，差了整整十倍。

站内搜索页该不该禁，站内搜索URL该Disallow吗对比了4种方案。

原因不难想。Googlebot出现了二十多年，几乎所有防护产品的默认白名单里都躺着它，误伤它的成本人尽皆知，出厂设置就已经替你避开了。GPTBot是2023年才出现的名字，它落在哪一档、被哪条规则匹配到，取决于每家产品各自的分类逻辑，而这套分类逻辑还在频繁调整。

这条规律有实用价值：做排查的时候，别从最老的那个身份查起，从最新的那个查起。老身份大概率被默认放行了，新身份才是错配的高发区。

这些产品各自的抓取策略并不相同，主流AI搜索工具实测对比做过10款横评。

那10个站分成三种形态

把robots.txt写允许却没送达的那批站逐个翻开，形态其实只有三种。

第一种是挑战型。服务端返回了人机验证页，状态码可能是403也可能是200。这类站的意思是“我不确定你是谁”，属于默认防护开得比较紧。这一类占了大头。

第二种是直拒型。干脆的403，正文很短，服务器字段指向某家边缘产品。这类是有人明确配过一条规则，只是配规则的人不知道robots.txt里写了允许。

第三种最容易被忽略：跳转丢失型。服务器返回301指向另一个地址，而那个地址对这个身份又是另一套待遇，跟着跳几次之后就断在半路。表面上没有任何拒绝动作，结果是一样的。

这三种的修法完全不同。挑战型要去调防护等级或者加白名单；直拒型要去找那条规则；跳转丢失型要去查跳转链本身。把它们混在一起当成同一个问题处理，是这类排查最常见的浪费。

跳转链本身也常出错，HTTPS 301跳转的双向实战有可直接抄的配置。

做一次两层对齐审计需要多久

这件事其实不难，难在没人把它当成一个固定动作。

做法是列一张两列的表。左边一列从robots.txt里抠出来：每个被点名的身份，允许还是禁止，禁止的是哪些路径。右边一列从实测里来：同一个身份实际拿到了什么。

然后只看不一致的行。左允许右没拿到，是误伤，优先级最高。左禁止右拿到了，是声明没有强制力，通常不用管，除非你本来指望它拦住什么。

一个中等规模的站，这张表连测带填半小时能做完。而它能回答一个几乎没人能立刻回答上来的问题：你的网站到底对哪些机器开着门。大多数团队对这个问题的答案，是基于三年前某一次配置的记忆。

有的爬虫根本不吃通配符，robots规则的星号对AdsBot无效就是一个例外。

保哥做技术审计的时候，这张表通常放在报告的第一页。原因很简单：它是整份报告里唯一一个客户看完会立刻打开后台去改的东西。

点名了GPTBot的那13个站，一个都没有真挡住它

接下来这组数据是这次实验最出乎我意料的一条，它把上一节的结论又推进了一层。

让报告推得动预算有套讲法，预算会上SEO总被砍怎么办用的是商业语言。

写过条款的，全部放行

123份能解析的robots.txt里，明确点过GPTBot名字的有13个站——不管是允许还是禁止，只要文件里出现过这个词就算。

这13个站里，GPTBot实际拿到页面的是13个。一个不落。

表态这件事有更可核查的写法，AI内容披露怎么写主张用不做什么的清单。

而剩下那110个从没提过GPTBot的站，GPTBot拿到页面的是99个，通过率90%。

三个AI爬虫身份，三条一模一样的结论：凡是在robots.txt里认真写过它的站，没有一个在送达层挡住它；真正挡住它的，全部来自那些robots.txt里一个字都没提过它的站。

这个反差说明了什么

第一层解释是最直白的：认真写过AI爬虫条款的团队，说明有人专门想过这件事。想过这件事的人，通常也会去检查防护规则有没有误伤，两层是同一批人配的，自然对得上。

第二层解释更有意思。没写过条款不代表没态度，恰恰相反，那110个站里挡住GPTBot的11个，多半是买了一套“一键拦AI爬虫”的服务，钱付了，开关开了，规则由服务商维护。他们的态度写在账单上，不写在robots.txt里。

这也就意味着，你去读一个站的robots.txt，读到的信息量比你以为的少得多。它只能告诉你这个站有没有人手写过规则，告诉不了你这个站到底放不放行。要知道后者，只有一个办法：真的去要一次。

凭感觉选策略容易翻车，GEO效果怎么验证建议给每条建议配一个对照组。

数据源打架时该信谁，收录数据到底信site命令还是GSC给了三源校准法。

顺手量到的AI爬虫条款分布

既然统计了，就把完整名单放出来。123个站的robots.txt里，各个AI相关爬虫被点名的次数是这样的：GPTBot 13次，PerplexityBot 12次，OAI-SearchBot 11次，ClaudeBot和ChatGPT-User各10次，Google-Extended 9次，Amazonbot 8次，CCBot 7次，anthropic-ai、Applebot-Extended、Bytespider各6次，Claude-Web和meta-externalagent各5次。

点名之后真写了禁止根目录的更少：Bytespider 3个站，CCBot和Amazonbot各2个，GPTBot、ClaudeBot、Google-Extended、Applebot-Extended、meta-externalagent各1个。

两组数字放一起，画面就清楚了：132个中大型独立站里，真正在robots.txt里明确禁止某个AI爬虫的，一只手数得过来。行业里关于“要不要拦AI”的讨论声量很大，但落到文件里的动作非常少。大多数站的做法是既不表态也不设防，把这件事整个交给平台默认值。

被点名最多的和被禁止最多的不是同一批

把点名次数和禁止次数放在一起排，会看到一个错位。

点名次数最高的是GPTBot，13次，但真写了禁止根目录的只有1个站。禁止次数最高的是Bytespider，6个站点名、3个站禁止，禁止率50%。CCBot和Amazonbot的禁止率也都在四分之一以上。

这个错位说的是两种不同的心态。写GPTBot的人多数在做一件“表明我知道这件事”的动作，具体规则往往是允许或者只禁几个目录。而写Bytespider的人通常是被抓怕了，那是一条带着情绪的规则。

顺便说一句，名单本身也在快速变化。这123份文件里出现的AI相关爬虫名字有二十来个，其中有几个是2024年之后才出现的，还有几个已经改过名。一份三年没更新的robots.txt，上面的AI爬虫名单大概率有一半已经失效。

国内那几家的抓取和带量情况，AI流量来源漏掉九成按日志逐条拆过。

按UA拦截的老代码尤其容易过期，WordPress拦截恶意User-Agent记了一次死亡迁移。

一份能拿去对照的身份清单

为了让上面那些数字能直接用，把这批文件里出现频率最高的几个身份整理成表。每一行的最后一列是最要紧的：拦掉它，你会失去什么。

这张表里最容易配错的是第三行和第六行。ChatGPT-User不是训练抓取，它是用户在对话里问到某个地址时才去取一次的实时请求，把它归进“拦AI训练”这一档，效果是用户当场问起你的品牌，对方拿不到你的页面。

Google-Extended则相反，它只控制生成式用途，不影响搜索收录，是唯一一个可以放心用来表达“不想被拿去训练”的开关。很多想拦AI又怕影响收录的站，其实要的就是这一个，却去动了别的。

实时取页决定了当场能不能被引用，2万条数据揭秘AI引用机制总结了5条规律。

官方对这类做法的态度也变过，Google官方指南叫停的5个动作值得对照着看。

做配置之前把这张表过一遍，能避开大半的误伤。名单会变，但分类逻辑不太会变——分清“训练用”、“检索用”、“用户实时取页”这三类，比记住二十个名字有用得多。

那个空用户代理进得去、AI爬虫进不去的站

数据里有一个站的组合特别值得单拎出来，因为它把本节的结论翻过来演示了一遍。

按引擎分别优化更有效，四大AI搜索引擎的GEO策略做了分引擎拆解。

这是个北欧家居品牌。普通Chrome拿到200，Googlebot拿到200，Bingbot拿到200，空用户代理也拿到200，四个身份拿到的字节数几乎一模一样，都是6040上下。

而GPTBot、ClaudeBot、PerplexityBot三个身份，全部拿到403，正文2097字节的人机验证页。

同一批数据里品牌词那条线更隐蔽，AI引用拆品牌词和非品牌词画在一句你看不到的话上。

这个站的规则设计得非常清楚：搜索引擎放行，未知来源放行，AI抓取拦截。在它这儿，报出AI爬虫的名字比什么都不报还要吃亏。

这个案例的价值在于它证明了名字判断的双向性。上一节说沉默会被当成可疑，这个站说沉默反而安全，两者并不矛盾——因为规则是每个站自己写的，而这批站的规则彼此之间毫无共识。

没有共识这件事本身就是结论。你没法从“行业惯例”推出任何一个具体站点的行为，只能一个一个去测。在机器人这件事上，不存在一套大家都在用的规矩，只存在一百多套各不相同的默认值。

那64个连空用户代理都放行的站

反方向也值得看一眼。132个站里有64个把页面给了什么都不报的那次请求，占48.5%。

这64个站的共同特征是防护层比较薄。要么是自建服务器没上第三方防护，要么是上了但只开了基础的攻击防御，没开机器人管理。它们不是特意对匿名请求友好，是压根没配这一层。

这个状态好不好，得看你怎么权衡。好处是任何读取方都能拿到内容，包括那些还没被主流防护产品收录进分类表的新爬虫——这两年新出现的AI抓取程序，多数属于这一类。坏处是低质量抓取和数据采集也一样畅通。

服务器这一层影响SEO的地方不止一处，服务器配置对SEO的20项影响列了完整清单。

我的看法是，对绝大多数独立站来说，这个状态比默认全拦要好。被多抓几次的成本是可计算的带宽，被少收录一次的成本是看不见的流量。两边都不确定的时候，选那个错了还能补救的。

换个角度说，如果你是那个做AI抓取的一方，最理性的策略就是不报名字。这大概是整个机器人协定体系里最尴尬的一处：老实交代身份的一方，承担了全部的不确定性。

抓取本身是有成本的，碳中和SEO运营把爬虫经济学算进了同一套规范。

402这个1997年就写好、二十多年没人用的状态码，怎么突然出现了？

这一节讲一个单独的站，因为它一个站就讲完了整件事的未来形态。

55个字节的付费墙

这个站是做手机配件的国际品牌。7种身份的结果分成三档，干净得像是有人特意设计过：

那55个字节是一段JSON，内容类型是application/json，正文是一句话：请联系站点所有者以获取访问权限。响应头里的服务器字段是那家内容分发网络的名字。

402这个状态码的正式含义是“需要付款”。它1997年就被写进HTTP规范，在现行的RFC 9110的HTTP语义定义里也仍然在册，之后二十多年一直挂着“保留待将来使用”的牌子，是整个状态码表里最著名的那个空位。MDN关于402状态码的条目至今还写着它是实验性的、尚未有标准用法。现在这个空位被填上了。

响应头这一层能表达的东西很多，HTTP响应头的X-Robots与Vary机制逐个讲过。

三档待遇背后是一套定价逻辑

把这三档摆开看，它不是防护，是分级供货。

浏览器免费拿，因为浏览器背后是可能下单的人。搜索引擎免费拿，因为搜索引擎会把流量还回来。而训练型AI爬虫既不下单也不还流量，于是它拿到一张账单。

这个逻辑一旦成立，接下来的事情就顺理成章了。同一家内容分发网络在2026年8月宣布，要给AI代理配上可以按访问付费的钱包；同一批新闻里还有一条更要紧的：从2026年9月15日起，新注册域名的默认设置会变成——被归类为训练型或代理型的爬虫，在展示广告的页面上一律屏蔽；而那些“既做搜索又做训练”的混合型爬虫，在所有拦AI训练的配置下都会被屏蔽。

流量还回来这件事本身在变，流量下降不等于SEO失败给了8个维度的解释。

同一家还在推另一种交付方式，给AI交付内容的HTTP内容协商实操讲了怎么配。

混合型这三个字是关键。Googlebot就在这一档里。

这条变更公布之后，社区里已经有人报告，把AI训练设成屏蔽之后，Googlebot和Bingbot取站点地图开始收到403，把开关关掉就恢复，完整经过见Search Engine Journal关于AI爬虫屏蔽波及Googlebot的报告。到底是配置误操作还是分类逻辑提前生效，官方还在核实。但对独立站站长来说，结论是一样的：那个看起来只关乎AI的开关，另一头连着你的自然流量。

你现在就该做的一件小事

不用等到9月。打开你的防护后台，把爬虫分类那一页翻出来，逐条确认三件事：搜索类是不是允许，训练类你选的是什么，混合类被归到了哪一边。

另一家搜索引擎值得单独维护，Bing SEO怎么做讲了它被低估的地方。

后台之外源站这一层也要看，Nginx全页缓存怎么配影响的是同一条链路。

如果你的后台里根本没有“混合类”这个概念，那更要留意，说明你用的版本还没更新到这一套分类，等它更新的那天，你的选择会被自动映射到新分类里去，映射规则不一定合你的意。

按访问付费一旦普及，独立站有三条路

这件事对独立站的影响还没显现，但方向已经能看出来了。往前推演，大致有三条路。

第一条是收费。你把内容当成资产，给AI抓取标个价。这条路只对内容本身有稀缺性的站成立——独家评测、原创数据、专业教程这一类。绝大多数电商站的商品页不具备这个条件，因为同样的商品信息在十几个渠道都有。

第二条是全放。你判断被AI引用带来的曝光价值高于内容被使用的损失，于是彻底开放，甚至主动优化机器可读性。做品牌认知、做长尾获客的站多数会走这条。

这类内容的索引控制有讲究，帮助中心和知识库SEO怎么做讲了工程化做法。

可见性怎么系统地做，AI搜索可见性的5维度策略给了实战路径。

第三条是分层。核心内容收费或者屏蔽，导购型、目录型的内容全放。这条路技术上最麻烦，但商业上最讲得通。

选哪条不是这篇文章能替你决定的，但有一个前提是共通的：你得先知道现在的状态是什么。这批132个站里，绝大多数处在“既没选也不知道自己在哪一档”的位置上，而默认值正在替他们做选择。

混合型分类为什么是个陷阱

再回到那条9月生效的分类规则上，因为它设计得确实别扭。

问题的根源是同一个爬虫在做两件事。搜索引擎抓你的页面，一部分用于建索引给你导流量，一部分用于训练它的生成式产品。这两件事共用一个用户代理串，站长没有办法只同意前者不同意后者。

于是分类系统只能造一个“混合型”的桶把它装进去，然后规定：只要你选了拦AI训练，混合型就一起拦。逻辑上自洽，后果上很吓人——你以为你在拒绝被训练，实际效果是拒绝被收录。

另一处说不清的争议，结构化数据对AI搜索到底有没有用做了官方说法加实测。

这个设计把一个本该由内容方和平台方去谈的问题，转嫁成了站长的一个二选一。站长手里那个开关，只有全开和全关两档，中间那些他真正想要的选项并不存在。

短期内能做的只有一件事：确认你现在选的是哪一档，以及默认值变更之后你会被映射到哪一档。这两个问题的答案不在文档里，在你自己的后台里。

两层都得写才生效的例子还有一个，一键退订必须写两层少一层就被限流。

顺便说一句，从技术上说，402现在的用法比它原本的设想更实在。原本的设想是给网页做小额支付，从来没落地过；现在它变成了机器之间的收费闸口，居然跑通了。一个状态码等了二十九年，等来的客户不是人，是机器。

被挡回来的那几百个字节，能告诉你什么？

拒绝页本身是有信息量的，而且信息量远比大多数人以为的大。这一节讲怎么读它。

先看服务器字段和状态码的组合

把132个站上所有“没拿到页面”的响应汇总，按服务器和状态码分组之后，分布是这样的：

自定义错误页配不好会变成软404，自定义错误页怎么配才不踩坑讲了状态码的坑。

第一行就占了六成。这说明一件很实际的事：你排查送达问题的时候，大概率只需要打开一个后台。

另外有一条负面结论也值得记：这批被挡的响应里，那个专门用来标记“本次拦截由谁做出”的响应头，一个都没出现。这个头是有标准的，但默认不开。所以别指望响应头会自己承认是它拦的，你得靠状态码、服务器字段和正文长度这三样去推。

正文长度是个被低估的线索

拒绝页的字节数比你想的更能说明问题。这批数据里有几个非常清晰的簇。

默认不开的响应头不止这一个，浏览器HTTP缓存头怎么配是另一处容易漏的地方。

第一个簇是356到372字节，一共出现了几十次，横跨十几个互不相干的品牌——运动鞋、快时尚、百货、奢侈品、小家电都有，服务器字段全是同一家内容分发网络。十几个毫不相干的大牌，用的是同一张370字节的拒绝页。它们甚至不知道自己撞了衫。

第二个簇更整齐：某个快时尚集团旗下六个品牌，六个独立域名，拒绝页字节数在357到366之间，服务器字段被隐藏了。同一套基础设施，六张同款的门。

同一家边缘产品的行为值得摸清，CDN对SEO到底有什么影响拆了6层缓存与边缘路由。

第三个簇是极短的那些。有两个站的403正文只有25字节，还有两个站只有17字节。17个字节是什么概念？一条短信的十分之一。它们连“你被拒绝了”这句话都懒得写完整。

正文长度之所以有用，是因为它能帮你判断这道墙是谁砌的。几百字节的标准页，多半是内容分发网络的默认拒绝模板；十几二十个字节的，通常是有人手写了一条规则并且随手返回了一个字符串；几千字节还带脚本的，那基本就是人机验证页。

六个品牌，六个域名，同一张门

第二个簇值得再拆一下，因为它演示了一件很多人没意识到的事。

批量查异常地址有成套方法，网站死链怎么批量查出来从检测到提交一条龙。

那六个品牌分属同一个快时尚集团，各自有独立的域名、独立的站点、独立的运营团队，在消费者眼里是六个不同的牌子。而在这次实验里，它们对爬虫身份的响应是同一套：同样的403，同样隐藏了服务器字段，正文字节数在357到366之间。

这意味着六个品牌共用同一套基础设施和同一份防护策略。改一次，六个站一起变。对做竞品分析的人来说这是个好消息——测一个就等于测了六个；对这个集团自己来说，这是一处单点风险。

一个大站还是多个小站，出海该建一个大站还是多个品牌小站算的正是这笔账。

同样的模式在另一家的十几个大牌身上也成立，只不过它们不属于同一个集团，而是买了同一家内容分发网络的服务，用了同一份默认拒绝模板。运动鞋、快时尚、百货、奢侈品、小家电，五个八竿子打不着的行业，被同一张370字节的纸挡住。

从审计的角度，这个现象有一条很实用的推论：当你发现某个站的拒绝页字节数落在几个常见值附近，基本可以判定它用的是默认模板，也就意味着这条规则大概率没有人专门配过。没有人专门配过的规则，通常也是最容易改回去的。

反过来，如果拒绝页是定制的、带品牌标识的、甚至写了联系方式，那说明有人认真对待过这件事。这时候你要做的不是去改配置，是去找那个人聊。

那几个特别的响应

有一个站对ClaudeBot返回了418。

418这个状态码的正式定义来自1998年愚人节的一份玩笑规范，含义是“我是一个茶壶”，用来表示这台设备拒绝冲泡咖啡因为它是茶壶。它从来不是正经的HTTP状态码，但主流软件栈里一直留着它，很多防护系统拿它当“我就是不想理你”的委婉表达。

这个响应的正文字节数是0，服务器字段是空的。一个茶壶，什么都没说。这大概是整份数据里最有幽默感的一次拒绝。

拦截也可以在更前面一层做，Linux服务器的防火墙端口规则怎么配讲了端口层的做法。

还有4个站的情况完全不同：它们对7种身份一视同仁，全部返回429，也就是请求过多。其中3个站的429响应带着3万3千多字节的HTML正文，服务器字段是同一家前端托管平台。

这4个站不在132的基线里，因为连普通Chrome都没拿到页面。它们不是在挡爬虫，它们是在挡所有人。如果你只测了爬虫身份没测浏览器身份，很容易把这种情况误读成“我被针对了”。

负载高到要限流的时候，服务器突然变慢负载飙高怎么排查是上游的功课。

429这个状态码的含义是请求过多，正确的用法是配一个说明什么时候可以重试的响应头。这4个站里没有一个配了。对爬虫来说，这意味着它只能靠自己猜下次什么时候再来，而多数爬虫的策略是保守——猜错了就少来，少来就意味着你的新页面被发现得更慢。

更值得注意的是那三个带着3万多字节HTML正文的429。一个状态码说“你请求太多了”，同时又给了你一整页内容，这在协议层面是矛盾的。检查工具会按状态码判失败，浏览器会按内容正常渲染，两边看到的是两个世界。这种自相矛盾的响应，是监控系统误报的重要来源。

限流是按什么算的

既然说到429，顺手把限流的机制讲清楚，因为它是送达型故障里最容易被误解的一种。

限流通常按三个维度中的一个或几个算：来源IP、身份标识、或者两者的组合。按IP算的话，同一个数据中心出来的所有请求会共用配额——这就是为什么你从云服务器测的结果，可能比真实用户的体验差。

时间窗也有讲究。有的按固定窗口算，每分钟清零；有的按滑动窗口算，看过去六十秒。前者在窗口边界会出现两倍的突发容量，后者更平滑。这个差别决定了你的监测脚本会不会周期性地误报。

同源请求还有别的副作用，给内链加UTM参数为什么伤SEO讲了分析与抓取的取舍。

还有一层是并发限制，跟总量无关，只看同一时刻有几个连接。一个每秒只发一次请求但从不关闭连接的脚本，照样可能触发它。做监测的时候记得让每次请求独立完成，别复用长连接。

还有一个站更离奇：7种身份全部返回404，正文10个字节，服务器字段是某家对象存储服务。一个知名户外品牌的主域名首页，对所有人都是404。这多半是域名解析或者跳转规则出了问题，而它显然已经这样有一阵子了。

监测跑起来之后日志会涨，服务器日志怎么管才不爆盘有现成的轮转方案。

怎么让脚本自动认出拒绝页

如果要把这套检查做成每天跑的自动化，识别拒绝页这一步必须机器化。人工看一眼当然准，但没人愿意每天看。

可以用的信号有四个，按可靠性排序。

最可靠的是正文长度加状态码的组合。正常首页几万字节，拒绝页几百字节，验证页两千到六千字节，中间的空档非常宽。定一条阈值几乎不会误判，前提是你先测过自己站的正常值。

第二可靠的是关键字符串。在你的正常首页里挑一段一定会出现、又不会出现在任何错误页上的文字，比如某个固定的导航项或者版权行。检查这段字符串在不在，比检查状态码结实得多。

第三是内容类型。前面那个402返回的是application/json，而正常首页一定是text/html。类型不对，直接判失败。

第四是服务器字段的变化。正常情况下你的站每次返回的服务器字段应该是稳定的，一旦某次变成了另一个名字，说明这次响应不是你的源站给的。这一条特别适合发现“被中间层接管了”的情况。

把四个信号组合起来，一个几十行的脚本就能跑。误报率主要来自站点自己发版本，所以报警最好带上一句“和昨天比变了什么”，而不是只说“失败了”。

字节数相同不代表内容相同

还有一个反过来的陷阱，是我在整理这批数据时才意识到的。

那几个Akamai集群的拒绝页，字节数在356到372之间浮动，差几个字节。刚开始我以为是不同的模板，核对之后发现是同一张页面——差的那几个字节是页面里嵌的请求标识符，每次都不一样。

反过来也成立。那三个返回429的前端托管站，七次响应的字节数分别是33790、33801、33799、33795、33793、33793、33791，全都在33790附近抖动，看着像七个不同的页面，其实是同一个模板加上时间戳。

所以做长期监控的时候，不要把字节数当成内容指纹，它每次都会抖。要比对内容，得先把动态部分剥掉再做散列，或者干脆只比关键字符串在不在。这个坑我见过不止一个团队踩，表现是监控天天报警，报到最后没人看了。

同一个域名，为什么给浏览器和爬虫送去了不同的国家？

这一节要讲一个我原本没打算测、但数据自己跳出来的维度。

身份不是唯一的变量，来源地也是

先坦白一个实验条件：这批请求是从一台位于中国的服务器发出去的。这个条件我原本当成噪音，后来发现它是信息。

那个运动品牌的例子最典型。普通Chrome请求最终落在中国站，服务器字段是一个国产的网关软件，17万字节；而五个爬虫身份落在国际站的403上。同一个域名，两条完全不同的路。

中国这一侧的搜索生态是另一套，中国搜索流量不是百度的天下拆了5个战场。

咖啡机品牌那个更直白：Chrome和空用户代理都被送到了它的中国站，五个爬虫身份连接都建立不起来。手机配件品牌也是，Chrome和PerplexityBot拿到的是中国站的175233字节，Googlebot拿到的是国际站的173747字节。快时尚品牌那个则是Chrome和Googlebot进了中国站，其余五个身份被301跳到国际域名之后就停在那儿了。

这四个站说的是同一件事：决定你拿到什么的不只是“你是谁”，还有“你从哪儿来”。

这件事对做多市场的独立站意味着什么

如果你的站做了地理分流，那么你在自己办公室里打开页面看到的东西，和搜索引擎在它的数据中心里看到的东西，可能根本不是同一个页面。

这不是什么新鲜风险，但它在送达型故障里会变成一个特别讨厌的干扰项：你从北京测一次没问题，同事从法兰克福测一次也没问题，而爬虫从它自己的出口测一次拿到403。三个人拿着三个不同的结果吵架，谁都没说谎。

所以排查这类问题，测试请求的出口位置必须被当成一个变量记下来。一份不写明“从哪里发的”的送达测试报告，价值大概等于一份不写单位的体检报告。

字节数差两倍以上的那四个站

还有一类更隐蔽的差别：页面给了，但给的不是同一份。

把Chrome和Googlebot拿到的字节数逐个对比，差异超过两倍的有4个站。一个户外配件品牌给爬虫的字节是给浏览器的2.13倍，一个北欧家具品牌只给了0.17倍，一个运动鞋品牌给了0.38倍，还有一个生活杂货品牌给了1.74倍。

字节数不等于内容量，多出来的可能只是没被压缩的模板，少掉的可能只是延迟加载的组件。但2.13倍和0.17倍这种量级，基本可以断定服务端确实按身份走了不同的分支。

给爬虫和给浏览器的差别还有更细一层，Googlebot为什么不读preload讲的就是这类差异。

给爬虫的比给浏览器的多，通常是好意——把客户端才会渲染的内容提前吐出来了。给爬虫的少一大半，那就要查一查少掉的是什么。0.17倍的意思是，爬虫看到的那一版页面，六分之五的内容不在。

地理分流和多语言声明是两件事

这里要澄清一个经常被混为一谈的问题。

地理分流发生在服务端，它根据你的IP决定把你送到哪个版本，动作是跳转或者直接改变响应内容。多语言声明发生在页面里，它告诉搜索引擎“这个页面还有这些语言版本”，动作是提供信息，不改变任何人拿到什么。

前者是强制的，后者是建议的。一个把用户强行跳走的站，就算多语言声明写得再完整，搜索引擎也可能只收录到它被跳到的那一版。

这些声明的实际待遇比预期低，hreflang写的语言版本只被当成规范页的别名是上个月的实测。

这批数据里能看到这个后果。四个做了地理分流的站，爬虫身份拿到的最终地址和浏览器身份完全不同，有两个甚至落在了不同的顶级域名上。对搜索引擎来说，它抓到的就是它被送到的那一个，其余版本能不能被发现，取决于别的路径。

比较稳的做法是：不强制跳转，给出一个明显的地区切换入口，让访问者自己选，同时把各语言版本的关系声明完整。这话说起来容易，跟增长团队的KPI经常打架，但从收录的角度它确实是最干净的方案。

怎么测多个出口

如果你的站做了地理分流，那单点测试是不够的，得从多个出口各测一次。

首屏那块地怎么安排，首页首屏从导航到分类区怎么设计有一份取舍清单。

成本最低的办法是用几家不同区域的云服务器，各开一台最小规格的机器，跑同一个脚本。三个区域基本够用：你的主要市场、你的第二市场、以及搜索引擎数据中心比较集中的那个区域。

更省事的办法是用现成的多地拨测服务，很多监控产品自带这个功能，配置一下就能从十几个城市同时发请求。缺点是这类服务通常不让你自定义用户代理串，做不了本文这种身份对照。

多台机器跑起来之后备份也得跟上，服务器怎么用rsync做增量备份讲了异地恢复。

还有一个几乎零成本的土办法：找几个在不同国家的同行或者客户，请他们打开页面截个图。不够严谨，但发现“某个国家看到的是完全不同的页面”这种问题，它足够了。

怎么在十分钟内判断故障属于哪一种？

数据讲完了，这一节讲怎么用。

三种病的判据表

一个检查没通过，可能是三件完全不同的事：东西根本不存在、东西存在但对方没拿到、对方拿到了但不采信。这三种的处置方式互为毒药，用错了不只是无效，是把事情弄得更糟。

判据这件事在选题上也成立，一个词值不值得单开一页用87个站的站点地图先替你答了一半。

这张表可以贴在工位上。同一句“没通过”，在这三格里分别意味着：你还没做、你做了但它没到、它到了但不算数。

送达型的两个特有属性

送达型故障有两个属性是另外两种没有的，理解它们能省掉大量无用功。

第一个是开关性。它几乎没有中间态，要么全通要么全断，不存在“部分页面受影响”这种渐变。所以如果你看到的是某一类页面掉、另一类不掉，那大概率不是送达问题，别往这个方向查。

开关型与滞后型的差别在实验里也有，A/B测试赢了上线却掉了问题出在那26天。

第二个是恢复的不对称。把开关关掉，拦截立刻消失，但流量不会立刻回来。索引要重新建立，商品要重新审核通过，抓取频率要重新爬回原来的水平。开头那个案例里，配置改回来之后，客户的流量是“只是刚开始恢复”。

这个不对称有一个很实际的推论：送达型故障的成本跟它持续的时间不是线性关系。断三天和断两周，恢复周期差的远不止四倍。所以这类问题的排查优先级应该高于它表面上的严重程度。

恢复要等多久，分四段看

把恢复这件事拆开，能看到四段各自独立的时钟，它们不同步。

第一段是拦截解除，这一段是即时的。开关一关，下一次请求就能过。这也是唯一你能控制节奏的一段。

第二段是重新抓取。搜索引擎不会因为你修好了就立刻回来，它按自己的调度表走，而且刚经历过一批失败的地址，重试频率通常会被下调。这一段从几天到几周不等，站的权重越高越快。

第三段是重新索引。抓到不等于立刻回到索引里，还要过一遍质量评估。掉出去的页面重新进来，往往比第一次进来更慢。

第四段是排名恢复。这一段最不可控，因为在你缺席的这段时间里，你原来的位置已经被别人占了，而占位的一方现在有了新的数据支撑。你不是回到原来的位置，你是重新去争一次。

那几种状态各自意味着什么，Google索引覆盖的8种状态给了算法决策路径。

回来之后进哪一层索引也不一定，Google分层索引揭秘讲了三层的差别。

购物类的商品列表是另一条时钟，通常比自然搜索快，因为它有明确的重新审核机制，但也要按批处理。开头那个案例里，配置改回来之后一段时间，客户的状态是“只是刚开始恢复”——注意这个措辞，那已经是修好之后的事了。

把四段加起来，一次两周的送达故障，完全恢复往往要一到两个月。这就是为什么这类问题值得用一个每天跑一分钟的脚本去防。

十分钟的分诊流程

真到了现场，按这个顺序走：

第一步，用普通浏览器的身份从外网要一次首页，确认站本身是活的。这一步排除掉“其实所有人都进不来”那4个站的情况。

第二步，换成搜索引擎爬虫的身份要同一个地址，比较状态码和字节数。两次结果不同，送达型基本坐实。

第三步，再换两三个AI爬虫身份各要一次。如果只有新身份被挡，去查防护产品的分类规则；如果连搜索引擎身份都被挡，立刻处理，这是在烧钱。

第四步，看拒绝响应的服务器字段和正文长度，定位是哪一层拦的。

第五步，才轮到去读robots.txt。注意顺序：robots.txt是最后一步不是第一步，因为它只能告诉你意图，告诉不了你事实。这一节的数据已经证明了，这两件事经常对不上。

三种病会同时出现

判据表是为了讲清楚才分成三格的，真实现场经常是混着的，而且顺序有讲究。

典型的混合形态是这样：一个页面既是空壳（缺失型），又对某些身份拿不到（送达型）。这时候先修哪个？先修送达。因为送达没解决，你补的内容对方一个字也读不到，改了等于没改。

另一种混合是送达型加采信型：页面能拿到了，但搜索引擎选了另一个地址当规范版本。这时候先解决送达，再等它重新评估，因为采信的前提是它得先拿到你的新版本。

三种病连在一起，其实是一条有先后的链：东西得先存在，然后得送到，最后才谈采信。修的顺序必须跟这条链一致，跳着修就是白干。

反过来，诊断的顺序可以倒着来，因为最容易验证的是最后一环——去看看对方到底采信了什么，通常一个后台工具就能看到。发现它采信的不是你想要的，再往前推是送到了没有，最后才问东西在不在。

误判的代价不一样

三种病判错的代价并不对称，这个不对称决定了你该往哪边偏。

把送达型误判成缺失型，代价是你花几周重写内容，问题一点没解决，而且这几周里损失一直在累积。这是最贵的一种误判。

把缺失型误判成送达型，代价小得多：你去查了一圈防护配置，发现没问题，然后回头查内容。浪费半天，但不会往错误方向投入大量资源。

把采信型误判成缺失型，代价是最典型的那个错误动作——加大声明力度。同一件事再声明一遍、写得更绝对，而对方不采信的原因是存在竞争性证据。这种情况下加强声明不但无效，有时候还会因为新增了一处不一致而让情况更糟。

所以经验法则是：拿不准的时候先按送达型查，因为它最便宜、最快、而且误判它的代价最高。十分钟能排除掉的事，没有理由放到最后。

三句话，把三种病问出来

如果只想记一件事，就记这三句问句，它们能覆盖绝大多数现场。

第一句：这个信息，除了眼睛之外还有谁能读到？问出来的是缺失型。答案如果是“打开页面就看得见啊”，那你已经答错了——看得见靠的是浏览器执行了脚本，而对方没有那双眼睛。

第二句：换一个身份再要一次，结果一样吗？问出来的是送达型。这句话的好处是它可以立刻被执行，不需要讨论，两分钟就有答案。

第三句：这个结论是我声明的，还是对方算出来的？问出来的是采信型。凡是对方算出来的东西，你只能提供证据去影响它，不能直接指定它。措辞里带着“已选定”“已检测到”这类词的字段，多半都属于这一类。

三句话按顺序问，能在十分钟内把方向定下来。方向定错了，后面做多少都是负数。这也是这一系列文章想说的全部意思：先分清是哪种病，再谈治法。

顺序还有一层用处，是它能帮你判断该找谁。缺失型的活儿落在前端和内容那一侧，送达型的活儿落在运维和安全那一侧，采信型的活儿多半落在信息架构和数据一致性那一侧。问错了人，得到的答案通常是一句真诚的“我这边看着没问题”，而这句话在三种病里都成立。

所以真到了要拉群的时候，先把这三句问句发进去，让每一方各自回答与自己相关的那一句。比起描述现象，让各方去验证一条明确的判据，能省掉大半的扯皮。

这套自查怎么跑才不会误伤自己？

最后讲操作层面的注意事项，都是踩过的。

别用真爬虫的身份去压别人的站

先说边界。这套方法用在自己的站上没有任何问题，那是必要的运维检查。用在别人的站上要克制：单个地址取一次，间隔拉开，不要并发压。

这次实验对每个域名只发7次请求，全程跑完，没有对任何一个站造成可感知的负载。做竞品调研和做压力测试之间只隔着一个频率参数，别越过去。

三个容易读错的信号

第一个，200不等于拿到了页面。前面那59个验证页里有相当一部分返回的是200。判断标准要加一条正文长度，或者干脆检查正文里有没有你期待的关键字符串。

第二个，403不等于robots.txt写了禁止。这两件事在不同的层，403是送达层的动作，robots.txt是声明层的文字。看到403就去改robots.txt，是本文开头说的那种“药方互为毒药”的典型。

第三个，连接失败不等于站挂了。有8次响应是连接层就被丢弃的，状态码是0。这种情况下站本身活得好好的，只是那个身份的握手被拒了。

把这件事变成例行检查

送达型故障的最佳防御不是配置得多完美，而是缩短发现它需要的时间。开头那个案例损失了两周，而这个检查跑一次不到一分钟。

做法很简单：写一个每天定时跑的小脚本，用三到四个身份各请求一次首页和一个商品页，把状态码和正文长度记下来，任意一项跟昨天不一样就发个通知。不需要复杂的监控系统，一个定时任务加一个通知接口就够了。

保哥给客户做技术审计的时候，这一项现在是固定动作，成本极低但抓到过好几次问题。有一次是客户换了套防护方案，服务商的默认模板把两个AI爬虫身份归进了黑名单，客户完全不知情，是脚本第二天早上报出来的。

这个脚本大概长什么样

说得再具体一点，免得看完还是不知道从哪儿下手。

需要的东西只有三样：一个能发HTTP请求的命令行工具、一个能定时执行的任务、一个能把消息推到你手机上的接口。三样在任何一台Linux服务器上都是现成的。

循环的结构是两层：外层遍历你要监测的地址，一般是首页、一个分类页、一个商品页，三个足够；内层遍历身份，桌面浏览器、搜索引擎爬虫、一个AI爬虫，三个也够。九次请求，跑完不到一分钟。

每次请求记四个值：状态码、正文字节数、最终地址、服务器字段。存成一个纯文本文件，一行一条，带上时间戳。

比对逻辑就是拿今天的文件和昨天的比，任意一个值变了就推送一条消息，消息里带上变化前后。不要设复杂的阈值，任何变化都值得看一眼，因为这些值在正常情况下本来就不该变。

唯一需要注意的是别把自己的监测请求发成攻击。间隔至少几秒，串行跑，别并发。你监测的是自己的站，但如果同一个脚本被复制去测别人的站，这条纪律就重要了。

哪些地址值得放进监测清单

三个地址不是随便挑的，选错了监测等于没做。

首页必选，它是防护配置最松的一页。首页出问题，说明配置改得很激进，性质严重。但反过来不成立——首页正常不代表别的页面正常，这也是为什么不能只测首页。

第二个选一个分类页或者列表页。这类页面通常带参数，而很多防护规则是按参数特征触发的。它是最容易被误伤的一类，因为筛选参数长得很像自动化抓取的痕迹。

移动版和桌面版还可能不是同一页，移动优先索引的渲染机制讲了掉量自救。

筛选页要不要禁有判别法，电商筛选URL要不要写Disallow给了三类分法。

第三个选一个商品详情页，而且要选那种深层路径的。它代表你真正想被收录的那一层，也是抓取链路最长的一层。

还有两个可选项。一个是站点地图文件本身，前面提到的社区报告里，最先出问题的就是它——爬虫取站点地图收到403，而首页是好的。另一个是robots.txt，它被拦住的话性质更严重，因为爬虫会因此暂停整站抓取。

加上这两个，一共五个地址，三个身份，十五次请求。跑完两分钟，覆盖了这类故障90%以上的表现形态。这可能是整个技术SEO工具箱里投入产出比最高的一个动作。

指令生效的时滞也要算进去，已收录页面加noindex后多久消失做了6个场景的实测。

交付给客户的时候怎么写

最后说一句写报告的事，因为这类发现很容易被写成一堆没人看的技术细节。

有效的写法是三行。第一行写事实：某某身份在某某地址上拿到的是什么，附上状态码和字节数。第二行写后果：这个身份拿不到页面，会导致什么业务后果，尽量换算成能被理解的东西。第三行写动作：具体到哪个后台的哪一页，改什么。

不要在报告里解释协议原理。决策者需要的是“这个开关关着，你的商品列表就没了”，不是机器人排除协议的历史沿革。原理放附录，或者放到这样一篇文章里。

给数字配上口径说明同样重要，一条五年趋势线上有三处口径变更是个反面教材。

交付物写成规范才不返工，内容简报怎么写才能让稿子一次到位是同一个思路。

最后留一个数字当结尾。这次实验里，129个站把首页交给了一台只是在请求头里写了个名字的普通服务器。它们既没有查这个名字的真伪，也没有看这次请求的行为。门锁装得很认真，钥匙是喊出来的。

常见问题解答

robots.txt写了Allow，为什么爬虫还是抓不到页面？

因为这是两层不同的东西。robots.txt是声明层，写的是你希望对方抓什么，靠对方自觉遵守；防火墙、机器人管理、边缘规则是送达层，决定这次请求到底能不能拿到字节。本文实测的132个站里，robots.txt写着允许但GPTBot实际拿不到页面的有10个站，ClaudeBot有8个，连Googlebot都有1个。排查顺序应该是先测实际送达，最后才读robots.txt。

怎么快速判断流量下滑是算法更新还是爬虫被拦？

看三个特征。算法更新的下滑通常有结构，某类页面掉得多、某类掉得少，不同市场不同步；爬虫被拦是整片下滑，所有页面按同一节奏走。算法更新有全行业共同的时间戳，配置误伤只在你自己的变更记录里。最有辨识度的一条是：如果自然流量和购物广告的商品列表同时消失，而付费广告照常扣费，那基本可以排除算法更新。

为什么空用户代理的请求反而更容易被挡？

因为这类防护是按名字放行的，不是按行为。你自称是某个已知爬虫，规则里能匹配到对应的条目就放行；什么都不报的请求匹配不到任何已知条目，直接落进“未知来源先验证”的默认分支。实测数据里，空用户代理的通过率只有48.5%，被挡的63次里有59次是撞上人机验证页，而不是干脆的拒绝。

我的服务器日志里查不到爬虫被拒绝的记录，是日志坏了吗？

不是。拦截发生在边缘节点，请求在那里就被判了并返回响应，整趟往返你的源站从头到尾不知情。所以源站日志里看到的不是“爬虫来了被拒绝”，而是“爬虫没来”。这两句话在日志里长得一样，含义完全不同。要看到真相，得去边缘那一层的日志，或者自己扮成那个身份去要一次。

2026年9月15日那次默认设置变更，我需要做什么？

那次变更的要点是：新注册域名的默认设置里，被归类为训练型或代理型的爬虫在展示广告的页面上会被屏蔽，而“既做搜索又做训练”的混合型爬虫在所有拦AI训练的配置下都会被屏蔽。Googlebot属于混合型。所以要做的事只有一件：现在就去防护后台把爬虫分类那一页翻出来，逐条确认搜索类、训练类、混合类各自被归到了哪一边，别等默认值自动映射。

拦AI爬虫到底有没有用？

对守规矩的那一批有用，对不守规矩的那一批没用。本文的实验已经证明了这一点：一台普通云服务器只在请求头里写了一行字，129个站就把首页交了出来，没有一个站做过反向解析验证。真想拿数据又不在乎规矩的，改一个用户代理串就绕过去了，成本是零。所以这类拦截的实际效果，是筛掉了愿意报名字的那一批，留下了不报名字的那一批。

只测首页够不够，为什么还要测站点地图？

不够。首页通常是全站防护配置最松的一页，因为它承担品牌展示职责，谁都不希望它出问题；而分类页带参数、商品页路径深，被误伤的概率都更高。站点地图和robots.txt这两个文件尤其要测：社区里那份关于AI爬虫屏蔽波及搜索引擎的报告，最先出问题的就是站点地图取不到，而首页一直是好的。robots.txt被拦的性质更严重，爬虫会因此暂停整站抓取。建议的监测清单是首页、一个分类页、一个深层商品页、站点地图、robots.txt，共五个地址。

为什么修好之后流量没有立刻回来？

因为恢复分四段，只有第一段是即时的。拦截解除是开关一关就生效；重新抓取要等搜索引擎自己的调度，而且刚经历过一批失败请求之后重试频率通常会被下调；重新索引还要再过一遍质量评估；排名恢复最不可控，因为你缺席的那段时间里位置已经被别人占了，你不是回到原位，是重新去争一次。一次持续两周的送达故障，完全恢复往往要一到两个月。这个不对称正是这类问题排查优先级要高于其表面严重程度的原因。

做这种多身份检测，会不会对被测网站造成压力？

用在自己的站上完全没问题，属于必要的运维检查。用在别人的站上要克制：单个地址取一次，间隔拉开，不做并发压测。本次实验对每个域名总共只发了7次请求，全程没有对任何站造成可感知的负载。做竞品调研和做压力测试之间只隔着一个频率参数。

权威参考资料