robots.txt分组不继承：157个站的实测

摘要：157份真实的robots.txt里，74个站为Google广告爬虫单开了一组，其中70个因此把通配组的规则整段漏掉，占94.6%，中位漏30条路径，最多的一个站漏了92条。更值得留意的是，这两段规则里绝大多数站主一个字都没写过——41.4% 的文件是建站平台生成的，而65个用同一套模板的站，竟然有64种不同的样子。

先说一件很多人没意识到的事：robots.txt这个文件里，规则不往下继承。

你在文件开头写了 User-agent: *，底下跟着四十条 Disallow，管住了购物车、结算页、账户中心、带筛选参数的集合页。写完你觉得这是全站的底线规则，谁来都得守。

然后你在文件下半部分补了一段，专门给某个AI爬虫开的，写着 User-agent: GPTBot，下面两三条 Disallow。你的本意是收紧——这个爬虫特别烦，得额外管管。

实际发生的事情正好相反。那一刻起，GPTBot就完全不受上面那四十条约束了。它只看自己那一组，通配组对它彻底失效。你写得越细，放开的越多。

这不是bug，是标准这么规定的。而标准写在一份你大概率没读过的文档里，你的robots.txt里没有任何一行字提醒你这件事正在发生。

近期OpenAI那边的说法把这个话题又推了一把。OpenAI表示robots.txt的规则可能不适用于它的取页机器人，理由是那次访问是真人在对话框里问出来的，不是爬虫自己在爬。同一份报告里，欧洲站点中约15% 被识别的AI取页请求，落在了站点明确标了禁止的地址上。

于是就有了这么个局面：一边是爬虫方说规则可能不适用，一边是站点自己写的规则根本没盖住想盖的对象。前者吵得很热闹，后者几乎没人查。

这次把211个海外品牌独立站的robots.txt全抓了一遍，能正常解析的157份，逐份按标准语义拆成分组，再逐个爬虫算它实际落在哪一组、和通配组差了多少条规则。下面全是这157份文件里数出来的。

你的robots.txt里，有多少行是你自己写的？

先从这个问题开始，因为它决定了后面所有讨论的性质。

插件后台那一堆开关同样默认帮你选好了，一个出海独立站的逐项取舍清单是照着过一遍的做法。

这个文件写废了的后果有多大，整站从搜索结果里消失的那类事故就是最直接的样本。

41.4% 的文件出自同一套模板

157份文件里，65份带着同一组特征：禁 /cart、禁 /checkout、禁 /orders，专门给 adsbot-google 开一组，禁掉一堆 /collections/*sort_by* 和 /collections/*%2B* 这样的排序与筛选参数组合。凡是做过独立站的人一眼就认出来，这是Shopify自动生成的默认robots.txt。

同一个平台还有别的东西是它替你生成的，一百二十八种结构化数据类型怎么选是另一处要接管的默认。

模板禁的那几类页面是否合理，电商该屏蔽哪七类页面里有逐类的判断依据。

65份，占41.4%。也就是说，这批站里每五个就有两个，robots.txt是开店时系统给的，不是人写的。

再往里看一层：这65个站里，只有16个（24.6%）在模板之外加过自己的 User-agent 分组。剩下49个站，文件从头到尾都是平台的默认内容，站主对里面每一条规则的知情程度，可能仅限于知道有这么个文件。

这本身不算错。默认模板写得其实不差，禁的都是该禁的：结算流程、账户页、会产生无穷组合的筛选URL。真正的问题在下一层。

平台默认为什么普遍质量不低

顺便说说为什么这类默认模板往往写得比自己写的还好，这不是恭维平台，是有机制原因的。

平台替你处理的还有图片这一摊，从命名到压缩的完整清单能看出默认做到了哪一步。

跨平台的共性坑不止这一处，建站第一年最容易失分的十二项配置是同一批经验的汇总。

一份平台默认模板服务的是几十上百万个店铺，它踩过的坑是所有店铺踩过的坑的并集。某个筛选参数导致索引爆炸，会有客服工单；某个接口路径被大量抓取拖垮服务，会有监控告警。这些反馈汇总到一处，最后变成模板里新增的一行。

而一个单独的站，它的robots.txt通常来自建站那天，之后除非出事，不会再动。默认值背后是海量样本的经验，你的自定义值背后是一个人某一天的判断。

这不是说不该自定义，而是说自定义之前要清楚自己在换掉什么。这也是后面会讲到的一个判断：接管默认值意味着接管它的维护责任，而这份责任原本是免费的。

同一套模板，65个站有64种样子

把每个Shopify站通配组里的 Disallow 路径集合排序后取指纹，65个站得到了64个不同的指纹。换句话说，几乎没有任何两份是完全一样的。

版本不一致最怕赶上迁移，迁移不掉流量的六维度路线图把要核对的东西列全了。

版本漂移要靠记录才看得见，把变更做成日志的十三类信号讲的就是这套办法。

条数分布更直观：40条的有37个站，44条的5个，45条的4个，47条的2个，还有单独出现的3条、4条、7条、12条、33条、34条、35条、36条、38条、43条、48条、54条、56条、75条。中位数40，最小3，最大75。

同一个平台生成的默认文件，规则数能从3条跨到75条，跨度25倍。原因有两类：一类是店铺开得早，模板还是老版本，后来平台加的新规则没有回填；另一类是站主动过手，加了或删了几行，于是从模板的某个版本上分叉出去了。

这两类叠在一起的后果是：你没法靠“我用的是平台默认”来推断自己文件里有什么。邻居家的默认和你家的默认不是同一份东西。

那些只有3条规则的店铺，缺了什么

最短的那份只有3条 Disallow。对照40条的主流版本，它缺的是后来平台陆续加进去的那一批：/cdn/wpm/*.js（网页像素监测脚本目录，54个站禁了）、/recommendations/products（推荐位接口，52个站禁了）、/*?*oseid=*（订单来源追踪参数，59个站禁了）、/apple-app-site-association、/.well-known/shopify/monorail。

平台自己加的追踪参数也会带来一堆地址，srsltid参数的四种处置方案是配套的处理。

筛选参数为什么必须堵，导航筛选URL不爆炸的系统方案把成因拆得比较细。

这些路径的共同点是会产生大量近似重复的地址，或者是纯接口不该被当页面收录。平台后来把它们加进模板，是踩过坑之后的补丁。而老店铺的文件没跟着变，那些补丁对它不存在。

这里就出现了本文要反复用到的那个判断：“我什么都没改”不等于“什么都没发生”。模板在变，你的文件停在了签收那一天的版本。

非Shopify的那92个站，情况反而更散

剩下92个站里，能识别出平台指纹的很少：WordPress特征2个、Magento 3个、BigCommerce 1个，其余大多是自研或者定制程度很高的站。这些文件的长度分布拉得极开，最大的一份13712字节、432行，通配组里265条 Disallow。

另一套电商系统的变体地址也会失控，变体的Schema、canonical与URL三层治理是那边的解法。

换成另一套系统同样有默认值问题，虚拟与物理robots.txt的优先级是那边最常踩的一个。

规则条数中位数是82条，最长的一份有368条规则、110个分组。到这个体量，文件已经不是一个人能通读的东西了，它更像是几年里不同人各加几行留下的地层。

我在做站点体检时习惯先看这个文件的行数。超过150行基本可以断定没人完整读过它。这不是苛责谁，一个没有测试、没有报错、改错了也不会有任何反馈的配置文件，本来就不具备被认真维护的条件。

规模最大的那几份长什么样

把体量拉到极限看一眼。样本里最长的一份13712字节、432行，通配组里265条 Disallow；规则总条数最多的一份有368条；分组数最多的一份切了110个 User-agent 分组。

没人读的配置背后通常是没人负责，团队怎么搭才出活说的是这件事的组织根因。

老站的配置层层叠加最后没人读得懂，资深团队的技术SEO为什么会失灵说的是同一类结构性问题。

110个分组意味着什么？意味着这个站对110类访问者分别定义了策略，而按前面说的分组不继承规则，这110组里每一组都必须独立完整，任何一组缺了什么，对应的爬虫就获得了额外的权限。110组同时保持完整，靠人工是做不到的。

这类文件通常出现在有历史的大品牌站上，多个团队、多次改版、多个地区站合并，每一轮都往里加了几段。它们不是被设计出来的，是被沉积出来的。

做体检时遇到这种文件，更实际的做法不是逐条改，而是先把它按分组导出成表格，让人第一次看清楚里面到底有几套策略。看清楚之后八成会发现，其中一大半分组的规则内容其实完全一样，可以合并成一组多写几行 User-agent 就完事——文件能从四百行缩到八十行，而行为一个字都没变。

为什么给一个爬虫单开一组，等于放开它？

这一节讲机制。机制不复杂，但它反直觉的程度足以让绝大多数人第一次听说时不相信。

要理解这条规则先得知道爬虫在整条链路的哪一环，抓取、索引、排名三步是怎么走的讲得最基础。

规范里的原话是：只选一组，不合并

爬虫排除协议在2022年被写成了正式的互联网标准。RFC 9309这份标准文档里对分组匹配的描述很直接：爬虫要在文件里找出所有 User-agent 值能匹配自己的分组，选出匹配得最具体的那一个，然后只执行那一组里的规则。

规则和理解之间隔着好几层，从关键词匹配走到意图理解的演变是另一条线的背景。

站内搜索该不该禁是个典型的分组决策题，四种处理方案的对比可以顺着这条规则重新读一遍。

关键词是“只”。不是把匹配到的几组合并，不是先执行通配组再叠加专属组，是二选一。User-agent: * 那一组只在没有任何专属组匹配上的时候才轮到它。

再说得糙一点：通配组不是全局配置，它是兜底分支。谁被点了名，谁就从兜底里出列了。

怎么判断哪一组更具体

匹配规则是前缀匹配，比较的是长度。文件里写 User-agent: Google，来的是Googlebot，能匹配上；同时文件里还有 User-agent: Googlebot-Image，那么Googlebot-Image这个爬虫会选后者，因为它匹配上的那个串更长、更具体。

前缀匹配这种规则对命名很敏感，slug命名的七维设计与上线后铁律是同一层的讲究。

服务端识别爬虫用的也是同一套名字，五种识别搜索引擎蜘蛛的写法里能看到这些令牌长什么样。

这条规则带来两个实际后果。第一，Googlebot 和 Googlebot-Image 分属两组时，你以为写给Googlebot的规则对图片爬虫是无效的。第二，也是更常被忽略的：你只要在文件任何位置写下某个爬虫的名字，无论那一组内容多简单，都已经把它从通配组里摘出去了。

顺带说一句大小写。协议里 User-agent 的值是不区分大小写的，写 GPTBot 还是 gptbot 效果一样。但指令名和路径值不一样，路径是区分大小写的，/Admin 和 /admin 是两回事。这一点在做过URL大小写规范化的站上偶尔会咬人。

一个可以自己核对的实例

拿allbirds.com这份文件说。它的通配组里有40条 Disallow，从 /a/downloads/-/* 一路禁到 /recommendations/products。

集合页这一类地址还要处理分页，分页的索引判断与canonical设置是紧接着的一步。

同一个平台上的集合页还有别的默认行为，集合页没有产品时该怎么处理是另一个例子。

文件下半部分有这么一段：

User-agent: adsbot-google
Disallow: /checkouts/
Disallow: /checkout
Disallow: /carts
Disallow: /orders
Disallow: /11044168/checkouts
Disallow: /11044168/orders

6条。而通配组是40条。差出来的33条路径——集合页排序参数、博客的加号编码组合、主题预览参数、政策页、站内搜索、像素监测脚本目录——对Google广告爬虫全部是开放的。

这两段都不是allbirds写的，是Shopify生成的。模板同时提供了严格的通配组和宽松的专属组，而把两者的关系讲清楚的那句话，不在文件里。

这算漏洞吗

严格讲不算，标准就是这么设计的，而且设计得有道理：分组不继承，意味着你可以给某个爬虫写一套完全独立的策略，不用担心被上面的规则牵制。灵活性是有代价的，代价是你必须自己保证专属组的完整性。

不是所有问题都能靠技术项解决，流量暴跌的七大元凶里有更靠前的那些原因。

把这类问题排进修复队列要看影响面，三类站点的高回报修复顺序给了一个可用的排序法。

问题出在心智模型上。大多数人对配置文件的默认想象是层叠的：全局设一套，局部覆盖几条，没覆盖的沿用全局。CSS是这样，nginx配置是这样，环境变量也是这样。robots.txt偏偏不是。

所以我更愿意把它叫做缺省分支被误读，而不是漏洞。你没有做出的那个决定——“专属组里要不要重复通配组的内容”——系统已经替你回答了，答案是不重复。

如果连兜底分支都没有呢

顺着这个逻辑往下推一步：既然通配组是兜底，那不写通配组会怎样？

不设约束的另一面是不做适配，三类站点的移动端改造对比是另一处容易被跳过的基本功。

不设约束的后果最后体现在总量上，三类站点的聚合自然流量实测是从结果反推的角度。

没有兜底意味着抓取量完全不受约束，抓取预算优化的十二项实操是收拾这种局面的第一步。

答案是所有没被点名的爬虫完全不受任何限制。157个站里出现了1个这样的站，yeti.com。它认认真真给9个AI爬虫各写了规则，唯独没有 User-agent: * 这一组。

于是它的实际策略是：这9个被点名的按各自的规则来，其余所有爬虫——包括Googlebot、bingbot、各种SEO工具爬虫、以及所有它没想到的新爬虫——全站畅通无阻。

这个案例的价值在于它把整个逻辑推到了尽头：点名一个爬虫是把它从兜底里摘出来，而不写兜底，等于所有人都在兜底外面。两件事是同一条规则的两面。

要说明的是，yeti.com这么写未必是失误，也可能是有意为之——它想管的就是那9个，其余的本来就不打算管。判断一个配置是不是问题，得看意图；但至少要先知道它实际在做什么。

74个站里70个漏了口子，到底漏了什么？

把机制说完，来看这157份文件里它实际造成了多大面积的影响。

抓来的东西不对路会带来别的麻烦，信息词流量过大的六大危害是另一种结构失衡。

口子开着最先长出来的就是垃圾页，索引膨胀的诊断与处置矩阵给了处理顺序。

数字先摆出来

为 adsbot-google 单开分组的站有74个。其中通配组规则条数多于专属组、也就是存在实际泄漏的，有70个，占94.6%。

地址层级本身就影响可达面，目录层级对SEO的六招优化可以一起看。

这些数字要和后台报告对上才有用，五类问题URL的占比与排查顺序是配套的读法。

泄漏路径数的中位数是30条，最少3条，最多92条，70个站合计2140条。

74个站里有70个中招，这个比例高得不像是各自独立犯错的结果。它更像是同一个模板被复制了74份的结果，事实也确实如此。

漏掉的都是哪几类路径

把70个站漏掉的路径汇总起来数频次，排在最前面的是这几类。

标签组合页是最典型的重复源，标签页怎么处理才不稀释权重是配套的做法。

这些路径的形态和站点结构直接相关，一万个站的扁平URL实测结论给了结构层面的判断。

筛选页要不要写禁止其实有判别法，三类筛选URL的分流处理策略比一刀切靠谱。

这份清单读下来会发现，被漏掉的恰恰是最该禁的那一类：参数组合型URL。一个集合页配三个筛选维度，能展开出成百上千个内容高度重叠的地址。通配组里那一长串 %2B、%2b、+ 的重复写法，就是为了把编码变体也堵上。

结果这些精心写的规则，对74个站里的广告爬虫全部不生效。

为什么在广告场景下这件事更要紧

有人会说，AdsBot又不影响自然搜索排名，漏就漏了。这个判断只对了一半。

商品曝光那条链路上还有别的判定，六万商家实测的产品组排序给了参照。

落地页被抓成什么样会进到排序里，购物广告排序的六大因素里有这条链路的说明。

AdsBot系列爬虫的职责是抓落地页做广告质量评估。它抓到的是哪个版本的页面，会进到质量得分的计算里。如果它抓的是一个带了七八个筛选参数、内容稀薄、加载又慢的组合页，那么这个页面在广告系统眼里的表现，就不是你投放时指定的那个干净落地页的表现。

更麻烦的是量。参数组合是乘法关系，一个站放开筛选参数之后可访问地址数量可能翻两三个数量级。这些请求全部落在你的服务器上，而且因为是长尾组合，几乎必然全部穿透缓存直接打到源站。

保哥去年帮一个做户外装备的独立站查过一次源站负载异常。那个站的日常自然流量不高，但源站CPU常年在高位，缓存命中率只有六成出头。翻了三天日志，最后定位到大量带排序参数的集合页请求，来源是几个不同的官方爬虫。根因就是专属分组把通配组的参数规则漏掉了。把那几组补齐之后，缓存命中率回到九成以上，源站负载掉了一半。

Googlebot那边的情况

顺手也算了搜索爬虫。为 Googlebot 单开分组的站有22个，其中15个存在泄漏，合计377条路径。Googlebot-Image 被点名23次、17次泄漏，Googlebot-News 22次点名、15次泄漏，bingbot 10次点名、7次泄漏。

被抓到的重复地址还得靠规范标记收拢，八种跨页场景与冲突诊断是紧接着的一步。

被抓到之后走哪条分支，八种未编入索引状态的决策路径讲得很细。

同一个爬虫身上还有别的硬限制，抓取正文只读前两兆那条同样很少有人测过。

泄漏最多的是purple.com，87条；awaytravel.com 47条；functionofbeauty.com 44条；eufy.com 43条；brooklynbedding.com 40条。

这里的性质比广告爬虫更直接：这些路径本来是不想让搜索引擎收录的，现在收录通道对最主要的那个搜索引擎敞开着。索引膨胀、抓取预算被参数页吃掉、正经页面更新发现变慢，是这条链路上最常见的三个后果。

参数组合的量到底有多大

说“会产生大量地址”太抽象，算一次就具体了。

交叉分类会把组合数再放大一轮，交叉分类的五种优化方法是控制它的办法。

地址结构本身决定了组合空间有多大，扁平与层级两种结构的取舍可以一起考虑。

参数白名单是控制组合爆炸的正规做法，分层导航的URL重写与白名单治理给了完整配置。

取一个典型的服装类目页，筛选维度有尺码、颜色、价格区间、品类标签四个，各自可选值假设是8、12、5、20。如果这些筛选是通过URL参数实现的，且允许多选与任意组合，理论上可达的地址数是这四个维度可选子集的乘积。就算保守地只算单选情况，8×12×5×20就已经是9600个地址。

再乘上排序维度。sort_by 常见有6到8个取值，乘完接近7万。而这些地址背后是同一批商品，内容重叠度极高。

这就是为什么那一长串禁止规则要把 +、%2B、%2b 三种编码形式分别写一遍——只堵一种，另外两种照样能进。写规则的人考虑得很周到，而这份周到在专属分组那里被整段跳过了。

抓取预算是怎么被吃掉的

抓取预算这个概念常被讲得很玄，其实机制很朴素：搜索引擎对每个站有一个大致的抓取速率上限，它由服务器响应能力和站点重要性共同决定，短期内是个相对固定的量。

资源被占的另一头是存储，增量备份与快照怎么做才不成灾是同一类账。

预算被占的直接后果是新内容发现变慢，内容新鲜度的五条实战法则是另一头的应对。

预算被谁吃掉只有日志能回答，五千个站的爬虫伪造与抓取预算实测是这套分析的样板。

爬虫每花一次请求去抓一个参数组合页，就少一次请求去抓你真正在乎的页面。当参数页的可达数量是正经页面的几十倍时，爬虫的大部分预算会花在自动生成的垃圾上，而新上架的商品要等好几天才被发现。

诊断这件事最直接的证据在日志里：按URL是否带参数分两组，统计各自的抓取请求占比。健康的站这个比例应该很低。保哥见过最夸张的一次是带参数请求占到七成以上，站主完全不知道，因为在搜索平台后台的报告里，这些地址混在总数里看不出来。

为什么这个问题在报表里看不见

这一点值得单独讲，因为它解释了为什么94.6% 这个比例能长期存在而无人察觉。

看不见的东西有时能用正则挖出来，用正则从后台挖AI搜索提问是个可复用的技巧。

报表读错比没有报表更危险，核心指标解析的四个常见错误是同一类提醒。

后台报告本身也有它看不见的部分，三大数据黑洞与补全工程讲的是怎么绕过去。

搜索平台的抓取统计报告是按状态码、按文件类型、按响应用途分类的，没有一个维度是“这次抓取用的是哪一组robots.txt规则”。爬虫自己知道它命中的是哪一组，但这个信息不会出现在任何面向站长的界面里。

覆盖率报告那边同样看不出来。参数组合页被抓了、被判为重复内容、然后不建索引，最终在报告里体现为“已抓取但未编入索引”这一类——而这个类别下本来就堆着各种各样的地址，多几千个不显眼。

广告后台就更看不见了。它关心的是落地页体验评分，不会告诉你评分是基于哪个版本的页面算出来的。

所以这件事的发现路径只有两条：一条是自己读文件做减法，一条是自己读日志做分组统计。两条都得主动去做，没有任何系统会推给你。这也正是缺省分支这类问题的共同特征——它不产生错误，只产生偏差，而偏差没有告警。

认真管AI爬虫的那26个站，谁做对了？

前面讲的都是平台默认造成的。接下来这一节看的是站主主动动手的部分，因为它更能说明问题——同样是认真在管，做法差异带来的结果能差出几百倍。

这类活得有人长期负责，GEO布局的四层落地框架与监测体系给了组织形态。

这批爬虫的抓取量早就不是零头了，AI爬虫抓取量已经超过传统搜索爬虫数倍是量级上的参照。

26个站，3317条泄漏

157个站里，在robots.txt中主动点名过至少一个AI爬虫的，有26个，占16.6%。这26个站加起来的泄漏路径数是3317条。

被抓和被引用不是一回事，引用与排名脱钩之后的实战思路讲的是后半段。

想被这批爬虫好好读到，突破候选池的五步技术优化是正面做法。

要把这些爬虫在日志里分开数，八类UA的识别与流量归因方法是可以直接照抄的。

但这3317条的分布极不均匀。

注意最后四行。framebridge.com点名了20个AI爬虫，泄漏0条；swarovski.com点名9个，泄漏0；yeti.com点名9个，0；quince.com点名6个，0。

而awaytravel.com点名15个，泄漏705条。两边做的是同一件事，投入的力气也差不多，结果一个滴水不漏，一个把整份规则全放开了。

差别就在那一段的写法

awaytravel.com那一段长这样：

写法细节决定爬虫能拿到什么，四种渲染模式下AI能读到多少是渲染层的同类问题。

新出现的智能体爬虫该怎么归类，Google-Agent的识别与应对是最近一个具体的例子。

User-agent: GPTBot
User-agent: OAI-SearchBot
User-agent: OpenAI-Operator
User-agent: ChatGPT
User-agent: Claude-Web
User-agent: ClaudeBot
User-agent: PerplexityBot
User-agent: Google-Extended
User-agent: Storebot-Google
User-agent: Applebot
Allow: /
Disallow: /admin/
Disallow: /private/
Disallow: /checkout/
Disallow: /account/

十个爬虫共用一组，组里先写 Allow: /，再写4条 Disallow。而这个站的通配组有47条。

意图很清楚：站主想说“这些AI爬虫可以来，但别碰后台和结算”。语义上没毛病，问题是它把通配组里另外43条规则一起免掉了——集合页参数、博客标签组合、追踪参数、主题预览，全部对这十个爬虫开放。而且开头那句 Allow: / 还额外做了一次强调。

framebridge.com那一段的写法完全不同：22个 User-agent 行连着排下来，然后把通配组的全部 Disallow 原样抄了一遍，一条不少。所以它的泄漏是0。

就这么一个差别。抄一遍，还是只写增量。

Allow: / 这一行的实际作用

顺便把 Allow: / 说清楚，因为它出现得很频繁，而作用常被高估。

另一个常被写了图安心的标记，规范网址的九大决策与完整设置里有正确用法。

另一个常被误用的写法是拿它去禁追踪参数，robots.txt能不能禁UTM参数给了正确做法。

在robots.txt的语义里，没有被任何 Disallow 覆盖的路径，缺省就是允许。所以在一个只有 Disallow 的组里加一句 Allow: /，实际效果等于没加。它唯一有意义的场合是配合更长的 Disallow 做例外，比如禁掉 /private/ 但放开 /private/public-report/——这时候匹配按最长路径优先，Allow 才真正起作用。

把 Allow: / 写在专属组开头，最大的副作用是心理上的：它让人觉得这一组已经表达了完整策略，从而更不会去想“通配组那些规则是不是也得抄过来”。一句技术上无效的话，掩护了一个技术上很严重的遗漏。

被点名最多的爬虫是哪几个

按点名站数排：GPTBot 14个站、PerplexityBot 14个、OAI-SearchBot 13个、ChatGPT-User 12个、ClaudeBot 12个、Google-Extended 10个、CCBot 9个、Applebot-Extended 9个、Amazonbot 8个、anthropic-ai 7个、Bytespider 7个、Perplexity-User 7个。

这几家的抓取行为差别不小，四大AI搜索引擎的分引擎策略可以按名字对照着看。

名单写得再全也不如去日志里看谁真的来了，AI爬虫到底有没有抓你的站是一步步挖的过程。

被真正全站禁掉（专属组里写了 Disallow: /）的次数很少：Bytespider 4次、CCBot 3次、Amazonbot 2次，其余大多是0或1次。

这个分布本身有意思。大家点名AI爬虫，主流做法不是封杀，而是想做精细化管理——允许一部分、限制一部分。而精细化管理恰恰是最容易触发分组不继承这个坑的做法。真要全封反而不会出事，因为 Disallow: / 一条就覆盖了所有情况。

SEO工具爬虫那一栏

顺带看一眼这批站怎么对待第三方SEO工具的爬虫。MJ12bot 被点名34次、其中9次全禁；AhrefsBot 32次点名、4次全禁；BLEXBot 5次点名、4次全禁；SemrushBot 3次点名、2次全禁。

反代那一层可以做更细的分流，upstream与sub_filter的全场景配置是可落地的写法。

真要拦这类爬虫得在服务端做，按User-Agent拦截的三层防护写法比写在文本文件里管用。

点名多、全禁少，说明大部分站对这类爬虫是限速而不是拒绝——而限速用的正是下一节要讲的那条指令。

两种缺省叠在一起的时候

把这26个主动管AI爬虫的站和前面的平台模板数据交叉一下，会看到一个特别的组合。

换一套架构之后基建得自己重搭，sitemap与重定向这套东西谁来负责是同一个归属问题。

两层来源不同的配置打架是常态，插件与主题各出一套canonical该怎么归一是同一类问题。

26个站里有10个同时是Shopify模板站。这意味着它们的文件里存在两层来源不同的内容：通配组和广告爬虫组来自平台，AI爬虫组来自自己。而这两层是分别演化的——平台会更新前者，站主偶尔动后者，两边谁都不知道对方改了什么。

后果是通配组和AI组之间的差距会随时间自己扩大。平台往通配组加了三条新规则，AI组不会跟着加，泄漏数就从40涨到43。你什么都没做，问题自己长大了。

泄漏最严重的几个站正好都在这个组合里：awaytravel、flyingtiger、brooklynbedding、stanley1913、jackery、bollandbranch，全是Shopify站加自定义AI组。而泄漏为零的那几个里，framebridge也是Shopify站——区别只在于它把通配组整份抄了过去，抄的那一刻两层内容对齐了。

当然抄一次不等于永久对齐，平台下次更新通配组时它同样会开始漂移。所以这件事的正确形态不是“改一次改对”，而是“建立一个会定期重新对齐的机制”。

写给不存在的爬虫的那些规则

还有一类问题，比漏规则更让人无奈：规则写对了，但写给了一个不存在的对象。

平台砍掉一个特性之后旧配置就成了摆设，FAQ富结果被砍之后该怎么办是同一种清理。

该退休的东西留着不会报错但会误导，九个该淘汰的SEO指标是另一份清理清单。

清点了一遍样本里的无效爬虫名，结果是这样：Claude-Web 出现在7个站里，这是Anthropic早期用过、后来已经弃用的名字；anthropic-ai 也是7个站，属于早年社区流传的非官方写法，从来不是官方公布的产品令牌；ia_archiver 3个站，那是互联网档案馆很多年前的爬虫；Slurp 2个站，Yahoo的搜索早已改由Bing提供。

最集中的一份出现在awaytravel.com。它那一组里写了 OpenAI-Operator、ChatGPT、DeepSeek、DeepSeek Assistant、R1、Grok 这几个值，没有一个是官方公布的爬虫令牌。

这些行不会报错，不会有任何提示，它们只是安静地不匹配任何东西。而写下它们的人多半觉得自己已经把这一批新出现的助手都管住了。

名字写长写短都会出事

还有一个更细的坑值得单独说。匹配是前缀匹配，所以名字的长短直接影响命中范围。

类型名写错同样静默失效，十三种结构化数据类型的生成能避开手写的笔误。

字段名写错同样不会报错，两个内链结构化数据字段的正确用法是可以拿来对照的例子。

精确到字符的写法在别处也一样重要，slug的九个影响抓取与排名的细节是同一种较真。

写 User-agent: ChatGPT，按前缀匹配，ChatGPT-User 这个真实爬虫是能被它匹配上的——只要文件里没有更长更具体的组。这种时候写短反而误打误撞管住了。

但如果文件里同时还有一组写着 User-agent: ChatGPT-User，那么真实爬虫会选后者，前面那组白写。同一份文件里长短两个名字并存时，短的那个只对“没有更具体分组的那些”生效。

反过来写长了更常见也更危险：写 User-agent: Googlebot/2.1，加了版本号，就再也匹配不上了，因为真实的产品令牌是 Googlebot，前缀匹配比的是文件里的值是不是爬虫名的开头，而不是反过来。

判断方法只有一个：去对方的官方文档里抄那个产品令牌，一个字都不要改。凭印象写、凭直觉补版本号、凭习惯加连字符，都是在生成不会匹配任何东西的行。

写了也不会生效的那几行

缺省分支这件事还有一个变体：你写了一条规则，对方压根不认这个字段。执行结果和你没写完全一样，但你以为自己写了。

要知道页面上到底有什么得扒一遍，一次扒清五种格式的字段缺漏是审查的做法。

服务器这一层有一堆同样容易写了不生效的设置，二十项服务器配置清单可以对照排查。

Crawl-delay：47个站写了，Google全部忽略

157份文件里，有47份（29.9%）用了 Crawl-delay。取值分布是：10出现82次、1出现33次、5出现6次、0.5出现4次、0出现2次、0.2和30各1次。

真被爬崩了要先定位瓶颈，负载飙高时的CPU、内存与磁盘排查比限速更实际。

抓取速率要去后台调，后台过滤器的五步用法是同一处界面里的另一组开关。

这个指令不在RFC 9309里，Google明确说过不支持它，Googlebot读到这一行会直接跳过。Bing和Yandex认，但认的方式和数值含义各家不同——各家搜索引擎对非标准指令的支持差异有一份逐项对照，写规则之前值得先看一眼自己要管的那家在不在列。

取值10出现82次这件事本身也值得说一句。10秒一个请求，一天最多8640次抓取。对一个几万个URL的电商站来说，这个速率意味着全站抓一遍要好几天。如果这条真的生效了，写它的人多半会后悔。它没生效，反而救了一批站。

还有两个已经作废的指令

robots.txt里写 Noindex 的站有2个。这个用法在2019年被Google正式停止支持，之前它是个非官方但确实有效的技巧。现在写它，等于什么都没写——页面照样会被收录，因为爬虫连页面都能抓，只是不会因为这行字而不建索引。

被高估的做法之外也有被低估的，九个被低估的技巧是另一头的清单。

既然这里的noindex早就失效，页面加了noindex之后多久才消失说的是真正有效的那条路径。

Host 指令有10个站在用。这是Yandex早年用来声明主镜像域名的字段，Yandex自己也已经不再推荐，改用常规的301和canonical。其他搜索引擎从来没支持过。

另外有10个站存在同一个 User-agent 值在多个分组里重复出现的情况。标准对这种写法的处理是把它们视作同一组来合并，但不同爬虫的实现细节未必一致，属于应该避免的写法。

无效指令比错误指令更麻烦

这一点想展开说说。写错一条 Disallow 路径，后果通常会以某种方式暴露出来——该禁的没禁住，你在覆盖率报告里看到了不该出现的地址；或者不该禁的禁了，页面从索引里掉出去，流量下滑，你会去查。错误是有反馈的。

有没有效最终要拿收录速度验证，三个平台三百站的收录实测是这类验证的做法。

有反馈的问题反而好处理，三个平台的告警分级与诊断闭环讲的就是怎么把反馈用起来。

无效指令不一样。它安安静静地待在文件里，占着一行，给人一种“这件事我已经处理过了”的确定感。你不会再去想抓取频率的问题，因为你觉得写了 Crawl-delay 就管住了。等到真出问题的那天，你排查的方向会绕开这一行，因为它在你的记忆里是已完成状态。

所以做robots.txt体检时，第一步永远不是看规则对不对，而是把所有目标爬虫不支持的字段先挑出来删掉。删掉不改变任何实际行为，但它把文件里的虚假确定感清掉了，剩下的每一行才值得逐条推敲。

还有一个反向的例子：站点地图那一行

不是所有非标准写法都是无效的。Sitemap 这一行同样不属于分组指令，它是文件级的声明，主流搜索引擎都认。157个站里有145个写了，覆盖率92.4%。

主动推送和被动等抓是两条路，API、JS与Sitemap三种推送方式各有适用场景。

这一行指向的文件本身也很容易写错，两千四百个站踩过的sitemap坑都收在一处。

这个对比挺有意思：Sitemap 是社区先用起来、各家陆续跟进支持、最后进了标准；Crawl-delay 是社区先用起来、部分厂商支持、最大的那家始终不认、最后没进标准。写文件的人从表面上看不出区别，两者的行式一模一样，都是一个冒号加一个值。

能不能生效，取决于对面认不认，而不是取决于你写得多正式。这句话在本文后面还会再用一次。

Allow用了1874次，其中有多少是必要的

顺着这个话题把 Allow 的实际用量数一下。157个站里有91个用了 Allow，占58%，条数中位是13条，最多的一个站写了115条，全样本合计1874条。

写得多不如写得对，面包屑的四种类型与结构化数据实操是个正面例子。

写了一个属性未必等于产生了效果，nofollow到底还传不传权重是另一个被高估的标记。

这个量级说明 Allow 已经是主流写法，不再是补丁。但要它真正起作用有个前提：必须存在一条更短的 Disallow 把它要放行的范围覆盖住。匹配时按路径长度取最长的那一条，长的赢。禁 /private/ 同时放行 /private/report/，后者更长，所以报告目录能被抓——这才是它设计出来要解决的问题。

反过来，在一个只有 Disallow 的组里写一句 Allow: /，没有任何一条 Disallow 会因此失效，因为 / 是最短的路径，永远输。这一行的全部作用就是让人看着安心。

151行站点地图是怎么长出来的

再看一个量的问题。Sitemap 行有64个站写了不止一条，最多的delonghi.com写了151行，其次stokke.com 78行、hoka.com 65行、assos.com 29行。

多站点多语言还要考虑推送队列，实时推送与异步队列怎么搭是配套的工程。

站点地图拆分本身有更清爽的做法，索引文件分页与动态优先级是一套可落地的结构。

多写几条是合理的，大站按语言、按内容类型拆索引很常见。但到一百多条这个量级，多半不是设计出来的，是每上线一个新语言站点就往文件末尾追加一行，追加了几年。

这件事本身危害不大——爬虫会挨个去读。真正的信号在于它暴露了这份文件的维护方式：只有人往里加，没有人往外删。一个只增不减的配置文件，最后一定会变成没人敢动的样子，而它上面的每一行规则都还在生效。

282个爬虫名里的地层

把157份文件里出现过的所有 User-agent 值汇总去重，得到282个不同的值。按出现站数排，前面是意料之中的：* 出现在166处，adsbot-google 74个站，MJ12bot 34个，AhrefsBot 32个。

旧公式为什么会失效，从关键词转向主题权威的变化是同一种代际更替。

陈年配置和陈年链接是一回事，死链批量检测、分类到提交是清理的常规流程。

配置只增不减的毛病要靠流程治，把SEO配置纳入持续集成的做法是治本的那一档。

往下翻就有意思了：Nutch 29个站、HTTrack 8个、WebCopier 8个、Teleport 与 TeleportPro 各7个、WebZIP 7个、SiteSnagger 6个、WebStripper 6个、Microsoft.URL.Control 6个、UbiCrawler 5个。

这些名字属于一个特定年代。它们是二十年前的整站下载工具和实验性爬虫，绝大多数早已停止开发。29个站至今还在防备一个2000年代的开源爬虫，而它们中的大多数是最近几年才开的店。

原因不难猜：这些规则来自某个流传很广的robots.txt模板，被一代代复制下来。没有人删，因为删掉需要判断，而留着不需要。这就是配置文件的地层——每一层都是某个时刻某个人的合理决定，叠在一起就成了没人读得懂的东西。

robots.txt本身拿不到的时候，爬虫按什么办？

前面讨论的都是文件存在且能读的情况。但在这次抓取里，211个域名有54个根本没能拿到一份可解析的文件，占四分之一。这些站走的是另一个缺省分支，而这个分支的行为更少人知道。

这个地址在多域名下也得都能取到，多域名跳主域的完整配置要一起检查。

不同状态码触发的处理完全不同，301、302、404与410各自的含义是这一节的前置知识。

21个站返回403，效果是全部放开

状态码分布是这样的：正常返回200的168个，返回403的有21个，返回404的4个，429的3个，400的1个，301之后没跟到目标的1个，完全连不上的13个。

防爆破规则同样容易误伤正常访问，密钥认证与fail2ban的尺度把握是可参照的例子。

防护规则收得太紧会误伤，从识别到应急拦截的处理顺序里有把握尺度的办法。

边缘那一层怎么判定请求，六层缓存与边缘路由的实战配置能解释403是怎么来的。

先说403这一组，它是非200里最大的一群。403属于4xx，而按主流搜索引擎的处理规则，4xx一律等同于“这个站没有robots.txt”，也就是全站允许抓取。

这里的落差很大。返回403的站，通常是因为边缘防护把请求当成了可疑流量——这次抓取用的是普通浏览器UA，从一个数据中心地址发出，被拦下来完全正常。但站主如果以为“连文件都拿不到，爬虫更进不来”，那就理解反了：拿不到规则文件不等于拿不到页面，前者的缺省是放行，不是拒绝。

更值得警惕的是不一致。防护规则对不同来源的判定不同，很可能出现官方爬虫能正常读到文件、而一部分请求读不到的情况。同一个站在不同爬虫眼里适用着不同的规则，而你从任何一个后台都看不到这件事。

4xx与5xx的缺省正好相反

这是一组必须记住的对照。

跳转链路上的状态码同样要写对，双向跳转的完整配置是最容易出环的一处。

这两类错误在后台报告里的处理也不一样，404修复与软404排查是配套的操作。

4xx放开、5xx关闭，这两个方向相反的缺省背后是同一套逻辑：4xx是“确定没有这个东西”，那就按没有规则处理；5xx是“暂时问不到”，那就先别动，等问得到再说。

这套逻辑对爬虫是合理的，对站长却埋着一颗雷。如果你的站在发布期间短暂返回了5xx，robots.txt也跟着5xx，那段时间抓取会整体收缩。Google的处理是连续较长时间拿不到才会退回按404处理，也就是说这个收缩状态可能持续好几天，而你在任何监控里都不会看到告警——服务恢复了，抓取量却没立刻回来。

9个站给出的是一张网页

还有一类更隐蔽：状态码是200，内容却是HTML。这次遇到9个，包括arcteryx.com、notino.com、temu.com、zalando.com、segway.com等。

单页应用的兜底路由是常见成因，九个维度的架构选型对比能看出各方案的代价。

返回什么和渲染出什么是两件事，抓取和渲染分几步走能解释这种错位。

状态码和内容对不上就是软404，错误页配置怎么写才不踩坑讲的正是这种错位。

成因通常是路由配置里没有为这个路径准备处理，请求落到了单页应用的兜底路由上，返回了首页或者一个错误提示页。从状态码上看一切正常，监控也不会报警。

爬虫拿到这份内容之后会尝试按行解析，每一行都不是合法指令，最终得到一份空规则集。结果和404一样是全部允许，但它比404更难发现——404至少会出现在覆盖率报告里，一个返回200的错误内容不会出现在任何报表里。

检查方法只需要一条命令：请求这个地址，看响应头里的 Content-Type 是不是 text/plain，看正文第一行是不是以 User-agent 或者 # 开头。两分钟的事，但很少有人把它写进上线检查项。

还有5个站的文件小到不像有内容

顺带记一笔文件体积。157份里有5份小于100字节：kotn.com只有39字节、liu-jo.com 66字节、shopify.com 62字节、barkbox.com 81字节、hay.dk 94字节。

交付内容少不等于没做事，四板块汇报模板能把工作讲清楚。

交付物有没有达标要事先定义清楚，达标定义与验收条款怎么写是把这件事写进合同的做法。

这个体积通常只够写一个通配组加一两行内容，或者干脆就是一句 User-agent: * 加一句空的 Disallow:。空的 Disallow: 是标准里明确定义的写法，意思是显式声明不禁止任何东西，和不写这一行的效果相同，但它表达了一个明确的意图。

另外顺手数了两个格式细节：0份文件带字节序标记，这点比预期好——带标记会导致第一行被解析器吃掉；36份用的是Windows换行符，这个不影响解析，标准要求实现同时接受两种换行。

这份数据本身的口径限制

把话说完整：上面这些状态码不能直接当成“这些站对搜索引擎也是这个状态”。

不同地区看到的搜索世界不一样，全球搜索引擎格局与多平台策略是这种差异的背景。

口径不同结论就不同，网域资源与网址前缀资源的六场景选型是同一种口径陷阱。

同一个地址在不同地方拿到的结果不一样，从DNS、线路到CDN的网络层排障能把这种差异定位清楚。

这次抓取是从一台位于中国境内的服务器发出的，用的是普通桌面浏览器UA，请求频率是四个并发。这三个条件里，前两个都会显著影响边缘防护的判定。同一个地址，Googlebot去请求大概率能拿到200，这次抓取拿到403，两件事完全可以同时为真。

13个完全连不上的域名里，有一部分是网络可达性问题，不是站点问题。这一类没有归入任何结论。

所以状态码这一节的正确读法是：它证明的不是“这21个站配错了”，而是“同一个地址会因为来源不同而给出不同的规则文件”。后者才是真正值得警惕的现象——如果规则文件本身就因人而异，那么“我的robots.txt写了什么”这个问题就没有唯一答案。

而前面那157份可解析文件的分析不受这个限制影响，因为那些结论全部来自文件内容本身的结构，与抓取来源无关。

OpenAI说这条规则可能不适用于它，那还要不要写？

回到开头提到的那条消息。这一节讲的是当缺省分支的解释权在对方手里时，你还剩下什么。

被看见和被引用是两件事，从被看见到被AI推荐的三层框架把这条链路拆开了。

用户触发的抓取算不算爬虫

OpenAI的爬虫文档里对 ChatGPT-User 的定位是：用户在对话里提出问题时，它去取那个页面。文档同时表示，因为这类动作由用户发起，robots.txt的规则可能不适用。Perplexity对 Perplexity-User 的说法大体相同。Anthropic的立场不一样，它声明自己的三个爬虫都遵守这个文件。

这类访问在分析工具里怎么落账，过滤器加渠道分组的补法是能立刻用的。

用户触发意味着流量来自具体的提问，AI可见度监测的四大误区讲的是怎么把这类访问量起来。

这个分歧的实质是对“爬虫”这个词的定义。传统爬虫是自己排队、自己决定抓什么，站点没法逐次同意，所以需要一份预先声明的规则。而用户在对话框里贴一个网址让助手去读，行为形态更接近浏览器代访问——你不会指望robots.txt管住Chrome。

论证本身站得住。麻烦在于：如今主流助手取页都是这个形态，这个例外覆盖的范围正在从边角变成主流。一条规则如果它的例外大过本体，那它就不再是规则了。

第三方统计给出的数字

TollBit那份关于机器人行为的半年度报告里给了几个可以对照的数：在被观察的欧洲站点里，约15% 被识别出的AI取页请求，落在了站点标记为禁止的地址上。ChatGPT-User、Bytespider、YouBot 三个爬虫各自在“明确列出过它们”的欧洲站点中，有接近一半的站点上出现了这种情况。

指标怎么定决定了结论长什么样，三层可见性指标的拆解是一套可用的定义。

第三方数据要挑着信，二十款监测工具的深度评测与选型是判断口径的参照。

禁止率这边的数字则是另一个方向的对照：欧洲只有9% 的站禁 Claude-User，北美是26%；Perplexity-User 欧洲13%、北美26%。绝大多数较新的取页型爬虫在欧洲的禁止率是个位数。

把这两组数放一起：写规则的人不多，写了之后被绕过的比例不低。而在这份157个站的样本里，主动点名任何一个AI爬虫的只有26个（16.6%），和上面那个个位数到二十几个百分点的区间是能对上的。

封掉取页机器人，换掉的是什么

这里有一个容易走错的岔路。有人为了拦住AI流量，把和OpenAI相关的爬虫名一次性全写进禁止清单。

自然流量结构正在重排，流量下滑背景下的生存指南是做取舍时的大盘参照。

封与不封背后是同一笔账，三千条数据揭开的引用认知差能帮着算这笔账。

问题在于这些名字的职责不同。按OpenAI自己的文档，决定一个站点会不会出现在ChatGPT的搜索结果里，负责的是 OAI-SearchBot，不是 ChatGPT-User。把两个一起禁掉的站，交出去的是被推荐的机会，留下来的是一个对方说可能不适用的抓取控制。

而且这笔交易的两头不对称：被推荐这件事是确定会失去的，因为搜索型爬虫大概率会遵守；抓取控制这件事是不确定会得到的，因为取页型爬虫那边有例外说法。确定的损失换不确定的收益，这个方向基本不用算就知道不划算。

另有数据显示对话式检索的索引里并不是只有大站，中小站点同样有可观的出现比例。对一个刚起步的独立站来说，这条渠道的价值恰恰在早期最大。

那还写不写

写。但要清楚这份文件的性质变了。

声明之外还得让别处也提到你，共识层六信号的九十天实战是另一条路径。

声明类的东西到底有没有用，结构化数据对AI搜索的官方说法与实测是同一种验证方式。

小站在这条渠道上的机会窗口更明显，中小网站不被剃光的九种打法讲的是怎么抓住它。

它现在更像是一份公开的意向声明，而不是一道闸门。声明的价值在于：遵守它的一方会照做（这仍然是大多数），不遵守的一方在被追究时没法说不知道，而你自己在做后续判断时有一份可引用的基线。

真正的闸门要放在别处。要拦，就在能拦住的那一层拦；要看，就看真实到达了什么，而不是看你要求了什么。服务器日志和CDN记录里躺着的是前者，robots.txt里写着的是后者，两者从来不是一回事。

声明和执行分家之后，文件的用法要变

如果接受了“这是一份声明而不是闸门”的定位，用法上有几处要跟着调整。

真正的执行要落到权限上，五种环境禁掉目录执行权限的写法是同一种思路。

执行放到边缘层是现在的主流做法，在CDN边缘改SEO的原理与落地形态给了几种实现。

第一，规则要写得能被外人读懂。既然它的作用是对外表态，那就该像一份公开条款那样写：分组清晰、注释说明为什么禁、必要时留一个联系方式。而不是像现在这样，四百行没有一句注释。

第二，别把敏感路径写进去。这是个老问题但一直有人踩：Disallow: /admin-secret-panel/ 这样的行等于把后台地址公开广播了一遍。这份文件谁都能读，把不想让人知道的地址写进禁止清单，是在做反向索引。

第三，规则和执行手段要配对。想拦训练型爬虫，声明写在robots.txt，执行放在边缘层；想控抓取频率，声明可以写，执行得去搜索平台后台调设置；想让页面不被收录，那根本不该用这个文件，该用 noindex。每写一条禁止，问一句“不遵守的话我怎么知道、我能做什么”，答不上来的那些，就当成纯声明看待。

第四，定期核对被点名的爬虫是不是还存在。前面数过，7个站在给一个已经弃用的名字写规则。这类清理没有收益，但能让文件保持在可读状态，而可读是后面所有工作的前提。

通配组之外，还有谁在替你做决定？

robots.txt不是唯一一个有缺省分支的地方。把视野拉开一点，同一条抓取链路上至少还有三层，每一层都有它自己的缺省。

多层叠加之后归因会变难，流量下降怎么跟老板交代是八个维度的拆法。

现在的技术审查得多看几层，从AI爬虫到无障碍的五个新层面是重新划分之后的清单。

边缘层的默认拦截

今年这条链路上最大的变量在CDN。Cloudflare已宣布，从9月15日起，新加入的域名将采用一套新的默认设置：被归类为训练用途或代理用途的爬虫，在带广告的页面上默认被拦；搜索用途的爬虫仍然放行。同时，被判定为兼具搜索与训练双重用途的爬虫，会被所有“拦截AI训练”类的配置一起拦掉，包括那个旧的一键选项。

拦不拦爬虫也是一笔资源账，页面碳足迹与爬虫抓取的同一套规范换了个角度算。

边缘层还能主动给爬虫换一种交付格式，用内容协商给智能体发Markdown是另一个方向的用法。

Googlebot正好落在双重用途这一类里。已经有站长报告说打开AI训练拦截之后搜索爬虫抓站点地图开始返回403，关掉就恢复。Google那边的人在讨论串里请对方私信详查，这件事本身还没有定论。

类似的误伤不止这一例。边缘防护配置一旦设错对自然搜索表现的伤害有多直接，是过去一年反复出现的话题——它们的共同点都是规则本身没写错，只是作用范围比设置的人以为的更大。

但不管那个具体案例是配置失误还是产品行为，有一点是确定的：一个你从来没打开过的开关，会在某个日期自动进入新状态，而通知你的方式是一篇博客。官方说明里也写了，9月15日之前所有客户都可以选择不采用新默认——这句话的另一面是，不主动选择就等于采用。

三层规则的优先级

把这几层排一下，从外到内是这样。

非网页资源只能靠响应头管，自托管视频的收录与富媒体机制是个具体场景。

这几层的字段各管什么，X-Robots、缓存与Vary的分工有一份逐项说明。

这张表里藏着一个经典矛盾：用robots.txt禁掉一个地址，爬虫就读不到那个页面里的 noindex。结果是这个地址反而可能以无摘要的形式留在索引里。想让一个页面彻底不进索引，正确做法是允许抓取、然后用 noindex，而不是在robots.txt里堵死。

这个坑之所以经典，是因为两个动作的直觉方向一致（都是“不要这个页面”），实际语义却互相抵消。

响应头那一层为什么更可靠

表里那个 X-Robots-Tag 响应头值得多说两句，它是这几层里最被低估的一个。

响应这一层还能顺手做压缩，免插件压缩与压缩算法叠加是同一处的改动。

两个标记同时用会不会打架，noindex和canonical的九种场景判断把边界划清楚了。

它和页面里的 meta robots 语义完全一样，可写的值也一样，区别只在于它写在HTTP响应头里而不是HTML里。这个区别带来两个优势。

一是它能作用于非HTML资源。PDF、图片、纯文本导出文件里没法插 meta 标签，只能靠响应头。很多站的一大堆内部文档PDF被收录进索引，就是因为除了robots.txt之外没有别的手段可用，而robots.txt又恰恰是那个会让 noindex 读不到的手段。

二是它可以在服务器或边缘层按规则批量下发，不需要改模板、不需要重新构建。对一个有上万个动态生成地址的站来说，这是唯一现实的做法。

缺省当然还是“不写就是可索引”。但这一层的好处在于，它的缺省和你的部署流程离得很近——服务器配置是有版本管理、有评审、有回滚的，而robots.txt通常躺在某个后台文本框里，谁都能改，改了没有记录。

爬虫的来源地址也不是你以为的那样

再补一个最近的例子。Google在文档里说明其爬虫的出口位置并不总是在美国，也可能来自其他地区，具体取决于调度。这意味着基于地理位置做的边缘拦截规则，可能在你不知道的时候误伤官方爬虫。

靠表面信号推断内部机制常常会错，从法庭文件里看到的真实排序逻辑是个很好的提醒。

验证爬虫身份的正确方式一直是反向DNS查询加正向确认，或者对照官方公布的地址段，而不是靠UA字符串或者来源国家。UA是可以随便写的，地理位置是会变的，只有反查是能站住的。

日志里该看哪几个字段

既然结论是“看真实到达了什么”，那就把日志分析要看的东西列清楚，免得这句话停留在口号上。

日志文件本身的权限也得配对，目录权限与Web服务器的最佳组合是前置条件。

日志要留得住才谈得上分析，日志轮转与检索不爆盘的配置是前置工作。

最少需要五个字段：请求时间、请求地址（含查询参数，不要在日志里把参数截掉）、UA字符串、来源地址、响应状态码。有CDN的话还要加一个缓存命中标记，它能区分请求是打到边缘还是穿透到了源站。

拿到这五个字段之后，按下面几个维度分组统计，问题基本就浮出来了。

这几个统计做一次要不了半天，而它给出的是这条链路上唯一的事实。robots.txt里写的是意图，搜索平台报告里写的是结果，只有日志里写的是过程——而绝大多数抓取问题的根因都藏在过程里。

单开一组时的正确写法

讲完机制和数据，这一节给可以直接照抄的做法。

这类改动通常要拉上后端一起做，工程侧七个动作点的分工能减少来回。

三种写法的对照

同一个需求有几种实现时先比可维护性，三种面包屑方案加结构化数据是同样的比法。

同一件事有几种方案时先看效果差异，分页SEO的五种方案对比是同样的比法。

整份复制的缺点是文件会变长，而且通配组以后每加一条规则，所有专属组都得同步加。这个维护成本是真实的，也正是大多数站没这么做的原因。

但换个角度看，这个成本恰恰是你应该感受到的信号：每多点名一个爬虫，维护面就多一份。感受不到成本的时候，人会倾向于把爬虫名越写越多。

五步自查

第一步，把文件里所有 User-agent 行列出来，数一数总共有几组。只有一组的站可以直接跳到第五步，本文讲的坑与你无关。

自查清单越具体越容易执行，十八个无障碍改动带来的自然流量变化是一份可照抄的表。

自查完得排个先后，五百个站实测排出来的优先级是可以直接套的顺序。

第二步，把通配组的 Disallow 条数记下来，再把每个专属组的条数记下来，做个减法。任何一个专属组的条数明显少于通配组，就是候选问题点。

第三步，对候选问题点逐条比对，看通配组里有而专属组里没有的路径都是什么。如果里面出现了参数组合类、站内搜索类、后台类的路径，那就是真问题，不是有意的差异化。

第四步，用搜索平台提供的robots.txt测试工具，拿一个具体的问题地址加上具体的爬虫名去测。工具会告诉你实际命中的是哪一组、哪一行。这一步很重要，因为它是这套配置里唯一一处能拿到直接反馈的地方。

第五步，看那些不会生效的行：Crawl-delay、Noindex、Host，以及针对早已不存在的爬虫写的分组。删掉它们。

改动之前该测什么

这五步里第四步的测试最容易被跳过，因为它需要挑具体的地址和具体的爬虫名，比通读文件麻烦。但跳过它，前三步的判断就全靠推理。

改完要验的不止一处，FAQ结构化数据改成能被引用的形态也需要同一套验证。

配置类的东西都该先验后发，一个尾逗号让整页结构化数据失效是不验就发的代价。

测试要挑的地址有三类。第一类是你明确不想被抓的，比如一个带三个筛选参数的集合页地址；第二类是你明确希望被抓的，比如一个新上架商品的详情页；第三类是处在边界上的，比如某个 Allow 规则想放行的那个子目录。

爬虫名要挑的也有三类：通配组代表（随便填一个没被点名的名字）、你点名过的每一个、以及最主要的那个搜索爬虫。把地址和爬虫名做笛卡尔积，逐个测一遍，工具会直接告诉你命中的是哪一行。

这个矩阵通常不大，三个地址乘五个爬虫名是十五次，十分钟能测完。而它给出的是这份配置里唯一的直接反馈——其余所有环节，包括修改保存成功这件事本身，都不构成任何验证。

测完记得把结果存一份，写清楚测的是哪个版本的文件。下次改动之后重跑同一套，两次结果对比就是回归测试。一份配置文件一旦有了回归测试，它的性质就从“碰运气”变成了“可维护”。

如果文件是平台生成的怎么办

Shopify这类平台允许通过主题模板文件覆盖默认的robots.txt。改之前有两件事要想清楚。

接管平台生成的地址结构要一起处理跳转，标签地址优化与301实战是配套动作。

接管平台默认和换主题是同一类风险，改版不掉流量的完整防护清单列了要接住的那些东西。

一是覆盖之后，平台后续对默认模板的更新就不会自动进到你的文件里了。前面数过，默认模板一直在加新规则，那些规则是踩坑之后的补丁。接管默认值的代价，是从此以后所有更新都得自己跟。

二是覆盖的粒度。多数情况下你需要的只是追加几行，而不是重写全文。能用追加的方式实现就不要整份替换，这样平台更新还能进来一部分。

如果实在拿不准，一个折中做法是：先不动文件，把当前版本存一份带日期的快照，每季度重新抓一次做差分。知道它变了，比控制它怎么变更重要，也便宜得多。

把一份写错的文件改对，具体长什么样

拿前面那个泄漏705条的例子走一遍，因为它的错法非常典型。原来的写法是十个爬虫共用一组，组里一句 Allow: / 加四条禁止，而通配组有47条。

把规则做成可维护的分层，六层重写与缓存的综合治理是服务器侧的同一思路。

改法有三个层次，按投入从小到大排。

最省事的一档：把这一整组删掉。删掉之后这十个爬虫回到通配组，自动适用那47条规则，而原本那四条禁止（后台、私有目录、结算、账户）本来就在通配组里覆盖着。也就是说，删掉这一组，实际策略反而变成了站主原本想要的那个样子。这一档适用于绝大多数情况。

中间一档：如果确实需要对这批爬虫多禁一个目录，那就把通配组47条原样复制进来，再追加那一条，同时删掉开头那句 Allow: /。文件会变长四十多行，但语义准确。

最讲究的一档：把通配组和专属组都放进构建流程，用模板生成robots.txt，通配组的规则作为一个片段被各个分组引用。这样以后往通配组加规则时，所有分组自动同步。做到这一步，分组不继承这个坑就被工程手段永久绕开了。

顺带把无效的爬虫名一并清掉：那五个不存在的令牌删了不影响任何行为，但能让下一个人少看五行噪音。

怎么在变更发生时知道

最后说监测，这是本文里唯一一件必须做成自动化的事。

监测要闭环才有用，四步闭环与A/B测试方法是可以套过来的框架。

定时抓取加差分靠计划任务就能跑，用cron把独立站运维自动化给了脚本骨架。

做法很简单，一条定时任务：每天抓一次自己站的robots.txt，存下来，和上一份做差分，有变化就发通知。顺便记录状态码和 Content-Type，两者任何一个不对也发通知。

能抓到的东西比想象中多：平台悄悄更新了默认模板、同事在后台改了一行没说、某次发布把路由配置搞坏导致这个地址返回了首页、边缘防护规则更新之后这个地址开始返回403。这四类事情共同的特点是不会触发任何现有告警，因为站点本身完全正常。

再进一步，可以把同样的做法套到别的缺省上：定期抓自己首页的响应头存下来做差分，定期导出广告账户的关键设置做差分。凡是定义权不在你手里、又不会主动通知你的东西，快照加差分几乎是唯一的办法。

什么时候该单开组，什么时候压根不该开？

这一节是判断题，不是操作题。

什么该做什么不该做要落到人头上，三类分工与团队配比的决策是配套的组织答案。

三种该开的情况

第一种，你确实要对某个爬虫做完全不同的策略，比如允许搜索型爬虫抓全站、只对训练型爬虫封掉正文目录。这种差异化用别的手段实现不了，必须分组。

差异化对待的前提是各平台确实不同，四大模型的差异化布局给了具体差异。

区分对待不同爬虫的前提是知道它们各干什么，可见性的五个维度拆解可以拿来对照。

第二种，某个爬虫的抓取行为明显异常，你需要给它单独限速，而它所属的搜索引擎恰好支持 Crawl-delay。注意这个前提，Google不在此列。

第三种，你要彻底封杀某个爬虫。这种情况下专属组里只写 Disallow: /，不存在漏掉的可能，是最安全的一种分组。

更多时候不该开

如果你对某个爬虫的要求和对所有爬虫的要求是一样的，就不要给它单开组。把它留在通配组里，规则自动适用，一行都不用维护。

力气该花在更有回报的地方，低竞争词的九大挖掘策略是回报更高的那一档。

技术项做满分也不一定有用，问题多半出在意图没对齐说的是同一种用力过猛。

这话听起来是废话，实际执行时却经常反过来。人在面对一个新出现的爬虫时，本能反应是“我得专门处理一下它”，于是加一个分组，写两条规则，心里踏实了。而这个动作真实的效果，是把它从原本管得好好的通配组里放了出来。

保哥的经验是，在这种场景下先问一句：我对它的要求，和对通配组里其他爬虫的要求，具体哪一条不同？答得上来就开组，并且把通配组整份抄过去再加那一条；答不上来，就别动文件。

为什么“多写一点更安全”在这里不成立

这条直觉在大多数配置场景里是对的。防火墙规则多写一条更严，权限清单多写一条更紧，日志级别调高一档信息更全。写得多等于管得严，是个很稳的经验。

安全加固那边确实是写得越多越紧，版本隐藏、目录权限与访问控制正好是反例。

robots.txt把这条经验反过来了。在这里，多写一个 User-agent 分组，管辖范围是变小的，因为那个爬虫被从原本严格的兜底规则里放了出来。写得越细，管得越松。

之所以会这样，是因为这份文件的组织方式不是“规则列表”而是“对象分派”。它先按对象切分，再在每个对象名下写规则，对象之间彼此独立。而防火墙那类配置是先有一条条规则、再按顺序匹配，两种结构对“新增一条”的语义完全不同。

识别这类结构有个简单办法：看新增的那一行是加在规则序列里，还是加出了一个新的作用域。加在序列里，多写更严；加出新作用域，多写更松。前者像往清单里添一项，后者像开一个新分店，分店不自动继承总店的规矩。

一个可以拿来自问的清单

把上面的判断压缩成四问，做robots.txt变更前过一遍：

不同阶段该问的问题不一样，大促与日常的八维度差异是分场景的清单。

上线前的检查项越具体越好用，开发期十大优化要点清单是同一种写法。

这次改动是不是新增一个 User-agent 分组？如果是，通配组的规则我抄过去了吗？

我打算写的这个字段，我要管的那个爬虫认不认？有没有官方文档写着它支持？

这个地址我是想让它不被抓，还是想让它不被收录？如果是后者，我用的是robots.txt还是 noindex？

这份文件除了我还有谁能改？平台会不会自己动它？我上次看它是什么时候？

这套判断能不能用到robots.txt以外的地方？

能，而且这才是本文真正想留下的东西。robots.txt只是一个特别干净的样本。

把一类判断推广开来要有指标支撑，从指标体系到异常诊断是搭这套支撑的办法。

缺省分支这件事的一般形态

把这一整篇抽象一下，结构是这样：你没有做的那个决定，也已经有了一个答案。系统不会因为你没表态就停在原地等你，它会走缺省分支。而缺省分支的定义权，不在你这边。

不声明就由对方替你选，规范网址的九大决策逻辑是最典型的另一个例子。

robots.txt里，那个没被做的决定是“专属组要不要重复通配组的内容”，缺省答案是“不重复”，定义权在协议标准手上。你查得到这条规定，规范文档是公开的，但你的文件里没有任何东西提醒你它正在生效。

这是缺省分支最温和的一种形态——成文、公开、可查，只是不会主动找上你。应对办法也最简单：把缺省显式写出来。哪怕写出来的值和缺省完全一样，它也从此进入了代码评审、进入了版本历史、进入了下一个人接手时会读到的范围。

同一个结构在别处的样子

找几个身边的例子对照一下就清楚了。

归因窗口这类默认值影响很大，服务器端跟踪还原完整链路的八步是把它拿回来的做法。

分析工具那边的默认分组同样没人改，默认渠道组到底怎么归类值得先弄明白。

页面上不写 meta robots，缺省是可索引可跟随；不写 canonical，缺省是搜索引擎自己选一个；不写 Cache-Control，缺省是各级缓存按启发式规则自己猜一个有效期；广告系列不设否定关键词，缺省是系统按它认为相关的范围去匹配；分析工具不配转化窗口，缺省是平台给的那个默认天数。

这几件事的共同点是：它们全都不会报错。没有任何一个环节会告诉你“这里你没配置”。系统运行得好好的，只是运行在别人写的那个值上。

把缺省显式化的三条实操

第一条，配置文件里把关键缺省值写出来，加一行注释说明这是缺省值、来自哪份文档。多写一行的成本，换的是下一个人不用去查规范。

分类页的标题描述不写就由系统拼，自定义TDK的现代化方案是显式化的样板。

把每类页面的取值明确写死是个好习惯，五类页面的差异化配置是一份现成的表。

第二条，做变更评审时，把“这次没改的部分是什么状态”当成一个正式的检查项。评审天然只关注diff，而缺省分支恰恰不在diff里。

第三条，对那些定义权在第三方手里的缺省，建立定期快照。前面说的每季度抓一次robots.txt做差分就是这个思路，它便宜、可自动化，而且是你唯一能拿到变更信号的方式。

这三条里最容易被跳过的是第二条，最有效的也是第二条。

缺省的三种可见度，处理方式完全不同

把缺省按“你能不能查到、能不能测到、能不能改”分成三档，应对的力气该往哪儿花就清楚了。

能查、能测、能改，三件事要分开看，后台数字为什么人人都读错讲的是第二档的难处。

这三档的顺序不能颠倒。第一档花的是查文档的时间，第二档花的是搭测试的时间，第三档花的是持续监测的时间，成本一档比一档高。而大多数人的实际做法是跳过前两档直接抱怨第三档，这就把最便宜的收益放掉了。

本文整篇讲的都是第一档。robots.txt分组不继承这件事，标准文档里白纸黑字写着，任何人花十分钟都能读完，可它造成的实际影响是74个站里70个漏了几十条规则。不是难，是没人告诉你这里有个决定需要你做。

做决定和不做决定，成本是不对称的

最后留一句可以带走的判断。

不做决定的账最后总要还，老内容流量悄悄下滑的识别与分级是另一笔慢慢累积的账。

做一个决定，成本是一次性的：查文档、写下来、评审通过。不做决定，成本是持续的，而且要等到某个不确定的时刻才一次性结算——可能是索引膨胀被发现的那天，可能是源站扛不住的那天，也可能是平台默认变更生效的那天。

更麻烦的是，不做决定这件事在账面上是零成本的。它不占工时，不进排期，不出现在任何一份报告里。所以在资源紧张的时候，被砍掉的永远是“把缺省显式写出来”这类工作，因为它看起来什么都没改变。

确实什么都没改变。它改变的是下一次有人来看这份配置时，能不能看懂它到底在做什么。这个价值在你还在这个岗位上的时候看不出来，等到接手的人换了一轮才显现——而那时候没人会把这笔账算回到当初那个决定上。

常见问题解答

robots.txt里的分组真的完全不继承吗？

是的。爬虫排除协议的标准文档里写得很明确：爬虫在文件中找出所有能匹配自己的分组，选出匹配得最具体的那一个，然后只执行那一组的规则。User-agent: * 那一组只在没有任何专属组匹配的时候才生效，它是兜底分支，不是全局配置。所以一旦你在文件任何位置写下某个爬虫的名字，无论那一组内容多简单，它都已经脱离通配组了。

怎么快速判断自己的站有没有中这个坑？

数两个数就行。第一个数是通配组里 Disallow 的条数，第二个数是每个专属组里 Disallow 的条数。只要有任何一个专属组明显少于通配组，就把两边的路径列出来做差集，看漏掉的那些是不是参数组合页、站内搜索、后台入口这类。是的话就是真问题。在这份157个站的样本里，用这个方法查出来的中招比例是：给广告爬虫单开组的74个站里，70个存在泄漏。

我用的是建站平台的默认robots.txt，需要管吗？

需要看一眼，多数情况下不需要改。这批样本里41.4% 的文件出自同一套平台模板，模板本身写得不差。但要注意两件事：一是模板会随平台更新而变化，65个用同一套模板的站里出现了64种不同的规则集合，说明不同时期开的店拿到的是不同版本；二是模板里那个给广告爬虫开的分组，天然就比通配组宽松几十条。知道这两件事，比急着动手改文件更有价值。

Crawl-delay到底还能不能用？

看你要管谁。Google明确不支持，Googlebot读到会直接跳过；Bing和Yandex认，但各家对数值的解释不完全一样。样本里有29.9% 的站写了这一行，最常见的取值是10。如果你的目标是压Googlebot的抓取频率，这行字没有任何作用，应该去搜索平台后台调抓取速率设置，或者用服务器端返回503配合Retry-After做临时降速。

想让一个页面不出现在搜索结果里，该用robots.txt还是noindex？

用 noindex，并且必须允许抓取。这两个手段的关系是互斥的：在robots.txt里禁掉一个地址，爬虫就读不到那个页面里的 noindex 标记，结果这个地址反而可能以无摘要的形式留在索引里。正确顺序是先放开抓取，让爬虫读到 noindex，等它从索引里消失之后，如果确实想省抓取预算，再考虑要不要在robots.txt里加禁止。

为什么封掉ChatGPT相关爬虫要慎重？

因为这些名字的职责不同。按OpenAI自己的文档，决定站点会不会出现在ChatGPT搜索结果里的是搜索型爬虫，而不是那个用户触发的取页爬虫；同时对方表示，取页那个可能不适用robots.txt规则。两个一起封的结果是，被推荐的机会大概率真的失去了，而抓取控制那一半对方说可能不适用。确定的损失换不确定的收益，方向上就不划算。

robots.txt返回403会怎么样？

会被当成这个站没有robots.txt，也就是全部允许抓取。这次抓的211个域名里有21个返回403，是非200里最大的一群，成因基本都是边缘防护把请求判成了可疑流量。要注意的是4xx和5xx的缺省方向相反：4xx是“确定没有这个文件”，按全允许处理；429和5xx是“暂时问不到”，短期内会被当成全站禁止抓取。所以发布期间如果站点短暂返回5xx，抓取量可能好几天缓不过来，而这段时间任何监控都不会报警。

文件返回200但内容是HTML，算不算问题？

算，而且比404更难发现。这次样本里有9个站是这种情况，大多是路由没为这个路径准备处理，请求落到了单页应用的兜底路由上。爬虫会尝试逐行解析，每行都不是合法指令，最后得到一份空规则集，效果等同于全部允许。检查只需要看两样：响应头里的 Content-Type 是不是 text/plain，正文第一行是不是以 User-agent 或 # 开头。建议把这两条写进上线检查项。

怎么知道爬虫实际到达了什么，而不是我要求了什么？

看服务器访问日志或者CDN的请求记录，按UA和来源地址段分组统计。robots.txt记录的是你的要求，日志记录的是实际发生的事，两者对不上的部分才是需要处理的。验证爬虫身份要用反向DNS查询加正向确认，或者对照官方公布的地址段——UA字符串可以随便写，来源国家也会变，这两个都不能当依据。

权威参考资料