别照抄爬虫黑名单：266个令牌只23.3%真来过

摘要：157份robots.txt点名过的爬虫令牌去重281个，266个可核对。拿一台真实站点59天、248万行日志做交集，只有62个（23.3%）真来敲过门。命中率还随名单变长而下降：只点1到2个的站有85.5%是活的，点超过30个的6个站掉到26.0%。最长那份点了109个名字，只有2个来过，里面挡着二十多年前的邮件采集器和Windows 95上的IE。

robots.txt里最容易膨胀的不是规则，是名字。

规则写多写少，多数人心里有数；可名字这东西，加一个的成本几乎是零。看到一篇文章说某个爬虫很耗流量，加一行；同行的文件里有个陌生名字，抄过来；安全建议里列了一串坏机器人，整段贴上。每次加的时候都觉得多挡一个总没坏处。

这次想量的就是这件事：那些被点名的对象，到底还在不在。方法很直接——把157个海外品牌独立站的robots.txt里所有User-agent值收集起来，再拿一台真实运行的站点两个月的访问日志去对，看有多少名字在现实里出现过。

你在robots.txt里点的那些名字，有多少真的会来？

先看名单本身的规模，这个数字比预想的大。

要先能认清对面是谁，120种爬虫UA的分类与真假验证是这件事的基本功。

这个文件整体怎么运作值得先过一遍，写废了会让整站从搜索结果里消失是它最极端的一面。

157份文件，281个不同的爬虫名字

去掉通配的星号之后，这批文件里出现过的User-agent值去重有281个。合计被点名1024次，也就是说平均每个名字只被4个站提到过。

名字收集完总要决定怎么对待，robots、UA识别、WAF三层的选型框架给了取舍依据。

把这些名字按类型拆开看，8类UA的22周访问账本提供了一份可对照的样本。

分布极度不均：其中186个（66%）只出现在1个站上。这个比例本身就说明了名单的来路——如果这些名字来自某种共识，应该有很多站重复；只出现一次意味着它们来自各自不同的源头，各抄各的。

每站点名2个是中位数，最多的点了109个

按站看，每份文件点名的中位数是2个。这个数字很健康，说明多数站主是有针对性地在管特定爬虫。

这类零散积累的问题集中在几个固定位置，电商站十二类高频坑的诊断修复可以照单排查。

名单变长的外因很清楚，AI爬虫抓取量已经超过Googlebot好几倍让所有人都想管一管。

但分布的尾巴拖得很长：

最长的一份点了109个名字，第二长的42个。这两份文件后面会单独拆，因为它们的成色完全不同。

那186个只出现一次的名字，来路可以归类

只被一个站点名的186个名字，摊开看能分成四堆，每堆的来路都很清楚。

当年那批采集器盯的就是邮箱，临时邮箱的八款实测对比是需求换了形态之后的产物。

判断一个名字活没活，从日志一步步挖真相是唯一靠得住的路子。

按标识串拦请求这条路自己也有坑，老代码里那个已被移除的函数就是典型。

第一堆是桌面工具和开源库，占了最大一块。HTTrack、WebCopier、SiteSnagger、Offline Explorer、WebStripper、Teleport、Nutch、libwww、larbin这些，都是安装在个人电脑上或者由开发者自己跑的东西。

第二堆是二十年前的邮件采集器，名字往往带着当年那股江湖气：EmailSiphon、EmailWolf、CherryPicker、ExtractorPro、Mata Hari。

第三堆是各种小语种或区域性的搜索抓取，比如已经停运的欧洲引擎、早期的国内引擎子服务。

第四堆最少但最值得说：把公司名或产品名当成了爬虫令牌。样本里有一个站一次写了五个这样的名字，包括某家AI公司的产品名、某个模型的代号。这些名字从来没有作为抓取标识出现过——写的人是照着新闻报道里的公司名写的，而不是照着对方公开的技术文档写的。

名字进来的三种场合

反过来想，什么时候人会去加一个名字？基本就三种场合，而每一种都会带来不同质量的名字。

凭印象做判断的代价不小，排名搬不动的五个隐性原因多半也出在这上面。

报警之后的处理顺序也有讲究，三平台后台告警怎么分级诊断可以直接照做。

每次加名字都该留痕，把变更做成日志的十三类信号能让来路不再无从追查。

第一种是服务器报警之后。这时候人手里有日志、有具体的标识串，加进去的名字质量最高，因为它是亲眼见过的。

第二种是读到一篇文章之后。文章说某类爬虫在大量抓取内容，附一份清单。这时候加进去的是别人的观察，质量取决于文章的时效。

第三种是合规或者管理层要求之后。要求通常是模糊的——把AI爬虫管一下、把恶意爬虫挡住。执行的人为了显示做过，会倾向于把能找到的清单都加上，名单在这一步膨胀得最快。

三种场合里只有第一种带来的名字是活的。后面那张命中率的表，本质上量的就是三种来源的混合比例。

一个名字从有用到没用，中间发生了什么

把一个名字的生命周期摊开看，就明白为什么它一定会烂在文件里。

服务停掉不会有人通知你，某个缓存服务退役之后还能怎么查快照就是这么一回事。

同样的老化问题在内容侧更常见，上千篇旧内容的留改并删转怎么定是一套可复用的判据。

这种没人报错的欠账攒起来很可观，技术债怎么排查和分批还给了一套顺序。

第一阶段，这个抓取程序确实在活动，某个站主在日志里看见了它，写进文件，规则生效。这一步是健康的。

第二阶段，这条经验被写成文章或者清单，传播出去。从这一刻起，抄它的人手里没有那份日志，他只知道这个名字应该管一下。名字开始脱离证据。

第三阶段，那家公司改了名字、换了标识、或者干脆关掉这个服务。这件事发生在别人的公司里，不会产生任何通知——没有邮件、没有告警、没有任何一个系统会告诉你这个名字失效了。

第四阶段，也就是现在：文件里那一行完好无损，语法正确，规则齐全，看上去和旁边那些有效的行一模一样。它已经死了，但没有任何迹象。

四个阶段里，只有第一阶段和第三阶段是真实事件，中间那次传播和最后那次失效之间可能隔着好几年。这就是本文那些名字能活二十年的完整机制——它不是谁疏忽了，是这条链上压根没有反向的信息通道。

名单会长，是因为它没有过期机制

为什么会长成这样？因为名单只有加入的通道，没有退出的通道。

没被验证过的东西都不能算数，备份了不等于安全，恢复演练才是底气是同一个道理。

这类失分往往在第一年就埋下了，建站第一年最容易失分的十二项配置是同一批经验的汇总。

一个爬虫停止运营、改了名字、或者被公司关掉，不会有人通知你从robots.txt里删掉它。这条信息在你的系统里根本没有入口——它发生在别人的公司里。于是名字进来之后就永远留着，跟着文件一起穿过每一次改版。

这跟字段失效是同一类问题的两个方向：字段那边是指令的收件人公开宣布退出了，名字这边是收件人本身没了。后者更难发现，因为robots.txt里的字段总共只有九种，名字却有几百个。

拿59天的日志当尺子，它量得准吗？

要判断一个名字还在不在，只有一种硬证据：看它有没有发过请求。这就需要一份日志。

数据入门阶段最该建立的就是口径意识，三类工具与排名追踪的习惯可以先看这份。

更大规模的同类观察是，5000个站样本里的爬虫伪造与抓取预算实测。

日志能读出的东西不止爬虫身份，怎么从日志里读懂抓取与预算浪费有一步步的示例。

样本：248万行，38161个不同的User-Agent

用的是一台真实运行的中文SEO站点的访问日志，时间范围2026年6月19日到8月17日，59天，2479791行请求。

日志攒多了会有信噪比问题，慢查询日志攒了783MB而真正超时的只有32条是同一类现象。

日志要能查才有用，把日志收成结构化可检索的形式是前置工程。

把每行的User-Agent字段抽出来去重，得到38161个不同的串。其中含有bot、spider、crawl这类自称标识的有479个，它们贡献了636750次请求，占总量的25.7%。也就是说四分之一的流量来自自报身份的程序。

38161个标识串是怎么分布的

把这38161个标识按类型归一遍，能看清这份日志的构成，也顺带说明了爬虫在总流量里的真实位置。

设备维度的差异也很大，移动端与PC端排名差异的六个因素有对应的诊断办法。

标识串的构成本身有规律，模拟爬虫身份测站的具体做法里有可直接用的串。

这张表有两处值得注意。

一是标识串数量和请求数量完全不成比例：浏览器有33447种标识串，因为每个版本号、每个操作系统组合都算一种；爬虫只有401种，却撑起了近四分之一的请求。所以从标识串数量看，爬虫是极少数；从请求量看，它是很大一块。

二是那4232个无法归类的标识串只贡献了2.2%的请求，大多是各种畸形串、空串、或者只有一个单词的东西。这一堆里藏着一部分伪造流量，后面会碰到。

日志格式不一样怎么办，CDN后面的标识准不准

做这件事之前有两个实操问题得先解决，否则拿到的数据是错的。

前面挂了边缘节点会改变很多判断，六层缓存与边缘路由的实际影响值得一并了解。

格式和真实来源地址都要先配对，访问日志怎么配才查得清问题把这两件事讲全了。

第一个是日志格式。默认格式里User-Agent通常是最后一个引号包起来的字段，但如果有人改过格式、加过自定义字段，位置就变了。稳妥的做法是先看一行完整日志，数清楚是第几个引号对，再决定取哪个字段。用固定列号去取，改过格式的日志会取到别的东西。

第二个是站点前面有没有CDN或者反向代理。有的话，日志里的来源地址可能全是代理的地址，标识串一般不受影响但也要抽查几行确认。判断爬虫真伪要用真实来源地址，所以得先确认服务器有没有把代理传过来的那个真实地址记进日志。这一步不确认，后面所有关于来源的判断都不成立。

本文的数据在这两点上都核过：标识串取的是最后一个引号对，来源地址是直连地址。

这把尺子的三条边界

这份日志能证明什么、不能证明什么，必须先划清楚，否则后面的比例会被误读。

样本边界会直接影响结论，AI响应模式怎么分析也强调了取样这一步。

任何数据源都该先校准，第三方数据准不准的六步校准法能挡掉大部分噪声。

第一，它是一个站的日志，不是全网样本。某个爬虫没来过这个站，不等于它已经死了——它可能只抓电商站，可能只抓英文站，可能只抓有广告投放的站。所以下面所有没来过的结论，严格表述是这个爬虫在这类站上不活跃。

第二，59天是一个有限窗口。抓取周期长的爬虫可能刚好错过。不过对判断退役与否够用：一个还在运营的搜索或AI爬虫，两个月一次都不来的概率不高。

第三，User-Agent可以伪造。日志里出现某个名字，不代表真是它——这一点在后面会变成本文最有意思的一节。

为什么不用现成的爬虫数据库

有人会问：网上有专门维护爬虫标识的数据库和服务，为什么要自己翻日志。

外部数据源都有盲区，六个工具盲区里的捡漏方法是同一种思路。

外部数据源各有各的边界，五大类工具各自能回答什么可以拿来配自己的组合。

那些数据库解决的是另一个问题——它们告诉你某个标识串属于谁、是什么类型。这个信息很有用，本文查那62个令牌各自是干什么的时候也用到了同类资料。

但它们回答不了本文的核心问题：这个爬虫来过我的站吗。这个问题的答案只存在于你自己的日志里，任何外部数据源都没有。第三方数据库还有个天然的滞后——它收录一个新标识需要有人先发现并提交，而你的日志在对方第一次来的那一秒就已经记下了。

所以两者是配合关系而不是替代关系：日志告诉你有谁来了，数据库帮你查清来的是谁。顺序不能反——先有日志清单，再去查身份，而不是先拿一份数据库清单往文件里抄。

尺子先失效了一次：子串匹配和产品令牌匹配不是一回事

第一遍对交集的时候，出了个非常离谱的结果：有个令牌命中了225万次请求，几乎等于全站流量。

匹配规则本身也常被误解，通配符判定会和标准打架的那几种情况值得对照看。

量错口径这件事非常常见，量出74%的页面有差异，补上对照组后只剩2.2%是同一类返工。

原因是匹配方式错了。第一版用的是子串包含——只要User-Agent里出现这个令牌的字面就算命中。而其中一个站把整串浏览器标识写成了User-agent值，形如Mozilla/5.0开头的那种。子串一匹配，全站所有浏览器请求都算它来过了。

robots.txt的匹配规则完全不是这样。标准里写明，爬虫拿自己的产品令牌去和User-agent值比对，爬虫排除协议的正式标准里写明，产品令牌是那种简短的标识，不含版本号也不含括号里的描述。所以整串浏览器标识作为User-agent值，永远匹配不到任何爬虫。

修正之后的口径是这样：剔掉9个整串标识型的令牌，剔掉6个长度不足4个字符、没法可靠判定的短令牌（像doc、rma、008这类），剩下266个参与判定；匹配时要求令牌以独立形态出现，后面必须跟斜杠、空格、分号、右括号或者到串尾。这样baidu就不会误命中Baiduspider，chatgpt也不会把ChatGPT-User的请求重复计一遍。

两个口径的差距不小：宽松匹配得出73个来过，严格匹配是62个，虚高了17.7%。这已经是这个项目里第五次栽在尺子上，模式每次都一样——量之前先确认自己量的到底是什么。

266个令牌对上62个，这个交集为什么这么小？

结果摊开：266个被点名的令牌里，59天内真的发过请求的有62个，占23.3%；204个（76.7%）一次都没出现。

想知道它们来了都抓什么，把爬虫的真实抓取偏好逆出来比看文档更实在。

来过的那62个是什么样的

先看头部。请求量最大的几个是Meta的网页索引器、Googlebot、bingbot、AhrefsBot、ClaudeBot、SemrushBot、Amazonbot，全是当下正常运营的主流爬虫。

这些抓取器的产出去了哪里，引用与排名脱钩之后的判断值得对照看。

新出现的抓取器要及时补进名单，这一类智能体爬虫怎么识别和应对是最近才有的功课。

这张表最后两行很刺眼，后面有一整节专门讲它们。

62个令牌按用途分成五类

把来过的62个按它们干什么归一下，比按请求量排序更有用——因为待遇应该按用途给。

放开检索之后还要够得上门槛，权威信号怎么强化给了实测区间。

同一家的抓取器规矩也不一样，有一整类抓取器压根不看robots.txt这次改名把它推到台前。

训练和检索必须分开看，内容进模型的四条路说明了为什么一刀切不管用。

这个分类有个直接用处：同一家公司的不同令牌往往属于不同类。比如检索用的和训练用的是两个名字，而且用户触发的取页机器人可能不受robots.txt约束，两者可以给完全不同的待遇——允许它来抓取用于实时回答，同时拒绝它拿去训练。分不清这一层，就只能一刀切。

请求量高度集中，前十个占了近九成

还有个数字对做决策很有帮助：这62个令牌的请求量分布极不平均。

头部与长尾的分布规律到处都是，十种挖词渠道与意图分类也是同一种结构。

把精力放在头部对象上更划算，抓取预算优化的十二项实操也是同一个排序思路。

请求量最大的5个合计38.9万次，占这62个令牌总请求量的73.9%；前10个合计46.1万次，占87.7%。剩下52个加起来不到13%，其中有十几个在两个月里只来了几十次甚至几次。

这意味着名单里真正值得逐个琢磨待遇的对象，大概就十来个。其余的写不写、怎么写，对实际抓取量几乎没有影响。这跟前面那条命中率曲线是一对：名单不但不该长，长了也没用——多出来的部分对应的都是极小的流量。

Meta那个爬虫排第一，本身是个信号

请求量榜首是Meta的网页索引器，17.7万次，比Googlebot还多五成。可它只被2个站点名——157份文件里，绝大多数人的名单上没有它。

社交侧的抓取跟着分发走，六个平台的标签用法能看出流量来自哪里。

社交平台的抓取影响的是另一条链路，社群信号到底算不算排名因素有八个平台的拆解。

这说明名单和现实的脱节是双向的：既有名单上写着却不来的，也有天天来却没人写的。后者数量还不小，后面单独有一节。

来过一次算不算来过？这个阈值要说清

前面所有比例都用了同一个判据：59天里至少一次请求就算来过。这个门槛很低，得说明为什么这么定。

判据定义决定结论，从指标体系到异常诊断的完整做法可以拿来搭自己的口径。

因为本文要回答的是存在性问题，不是活跃度问题。一个爬虫哪怕只来过一次，也证明它还在运行、还在抓这类站，规则写给它是有意义的。反过来两个月一次都没来的，才有理由怀疑它已经不在了。

不过这个低门槛会带来一个副作用：62个来过的令牌里，有十几个只来了几十次甚至十几次。它们算活着，但对你的抓取量几乎没有影响。如果换成活跃度判据——比如要求月均请求超过一百次——这个数字会从62掉到二十出头。

两个口径服务两个不同的问题：判断该不该删名字用存在性，判断该不该花时间琢磨待遇用活跃度。混用会得出奇怪的结论，比如把一个还活着但很少来的爬虫删掉，然后某天它加大抓取时你的规则里没有它。

没来的那204个，大致分三堆

把没来过的令牌归一下类，来路相当清楚。

老工具的时代留下不少加固习惯，权限分离与应急响应的完整做法至今还适用。

真要动手拦要防误伤，拦AI爬虫与限速怎么不把Googlebot一起拦掉有具体写法。

第一堆是桌面离线下载工具和开源抓取库：HTTrack、Teleport、WebZIP、WebCopier、SiteSnagger、Offline Explorer、Nutch、libwww、larbin。这类东西的特点是它跑在某个人的电脑上，不是一家公司的服务。157份文件里有36个站（22.9%）点名过至少一个这类工具，Nutch被29个站点名，是其中最多的。

第二堆是已经退役、改名或者不再负责那件事的爬虫，18个站（11.5%）中招。

第三堆是从来没作为抓取标识存在过的名字——某家公司的产品名被当成了爬虫令牌。这类在样本里集中出现在1个站上，一次写了五个。

名单越长，里面来过的比例是不是越低？

把每个站的名单长度和它的命中率放在一起看，出现了一条相当整齐的曲线。

同一个指标各家算法不同这件事到处都有，关键词难度为什么各家工具差那么大是最典型的一例。

从85.5%一路掉到26.0%

越堆越多会稀释效果，模板和广告稀释主体内容的七个陷阱有对应量法。

越堆越多这个模式在索引侧也有，大量没用的页面怎么诊断和处置有一张决策矩阵。

单调下降，没有例外。只点一两个名字的站，命中率85.5%；点了三十个以上的，命中率26.0%，差3.3倍。

为什么会这样：加名字的动机决定了名字的质量

这条曲线的解释藏在动机里。

动机会被流程放大，四类流程漏洞怎么修讲的正是这个层面。

照抄清单在工具选型里同样常见，用第一性原理做工具选型比跟着别人的清单走稳。

只点一两个名字的人，通常是遇到了具体问题：某个爬虫抓得太凶把服务器压住了，或者不想让某家AI公司拿走内容。他有明确的对象，这个对象是他亲眼在日志或者监控里见过的，所以名字是活的。

点三十个名字的人，动机不一样。他多半是在做一件事情——把这类风险一次性处理干净。而要做到一次性，只能靠找一份现成的清单。清单是别人整理的，整理的时间不确定，有效性无从核对。

所以这条曲线严格说不是长度导致命中率低，而是长名单几乎必然来自照抄，而抄来的名单没人负责保鲜。长度只是这个动作留下的痕迹。

自己名单的命中率，怎么算出来

这个指标可以自己算，成本很低，而且算完就知道该不该动手。

批量核对时别手写语句，安全地批量改一批字段的做法能省掉不少风险。

算命中率的前提是日志留得够久，日志怎么管才不爆盘又查得到要先解决。

全站层面的例行检查可以一起做，桌面爬虫能查出的12类问题清单是配套动作。

做法是三步。第一步，把robots.txt里所有User-agent值抄下来，去掉通配的星号，得到一份名字清单。第二步，在日志里逐个搜这些名字，记下每个名字的请求数——注意搜的时候要求名字后面跟着斜杠、空格或者分号，避免短名字误命中长名字。第三步，数一下有请求的占几成。

命中率在七成以上，名单是健康的，不用管。落在三到七成之间，说明有一批名字该清了，但不着急。低于三成，基本可以断定这份名单是整段抄来的，值得从头重写一遍——重写比逐条排查快。

要注意日志窗口的长度。用七天日志算出来的命中率会明显偏低，因为周期长的爬虫没来得及出现。至少要一个月，两个月更稳。

一个真实的清理过程

保哥去年帮一个做宠物用品的独立站看技术问题，顺手翻了robots.txt，名单上有六十多个名字。问站里谁加的，答案是历任三个人各加过一批，最早那批在建站的时候就有了。

这类工作的交付标准最好写清，达标定义与违约责任怎么写有几个真实纠纷案例。

这类清理通常是审查的一部分，从抓取到AI可见度的完整诊断框架可以拿来当清单。

按上面那个办法跑了一遍：从日志里拉出真实来访的抓取程序，再和文件里的名字对。结果是六十多个名字里，两个月内出现过的不到十个，而日志里请求量排前几位的几个抓取器，名单上一个都没有。

清理的做法没什么技巧：把日志里真出现过的挑出来，按用途分成放开、限速、拒绝三档重写；六十多个名字里查不到任何公开资料的直接删；剩下几个还活着但不来这个站的，加了注释留着。文件从九十多行缩到三十行出头。

值得说的是清理之后的变化——抓取量、收录、排名都没有任何变化。这恰恰是预期结果：那些被删掉的规则本来就没在起作用，删掉它们不会有任何指标变好。这类工作的收益不体现在指标上，体现在下一次有人打开这个文件时，他能读懂每一行为什么在那儿。这也是它一直排不上优先级的原因。

命中率低，不等于该把没命中的全删掉

有个反向的提醒：低命中率说明名单质量差，但不代表可以按命中率一键清理。

观察窗口不够就下结论很危险，沙盒和学习期到底怎么回事是同类误判。

指标不动不代表工作没意义，流量暴跌的七个元凶与三个诊断案例说明了归因有多容易错。

原因还是那把尺子的边界——某个名字在你的站上没出现，可能是它不抓你这类站，而不是它不存在了。比如广告爬虫在没投放的站上不会出现，社交平台的抓取器在没有图片被收藏的站上不会出现，可它们本身活得好好的。

所以处理顺序应该是：先按命中率判断这份名单值不值得信，再对没命中的名字逐个查它到底还存不存在。查存在性靠官方文档，查活跃度靠日志，两件事不能混。查完确认已经消失的删掉，确认还活着但不来你这的可以留着，也可以删——留着的成本是几个字节，删掉的收益是文件短一点。

不过有例外，而例外正是最有价值的部分

把点名超过25个的11个站单独摊开，会发现它们分成截然不同的两群。

例外往往指向真正的原因，技术做到满分却不涨，问题多半在意图没对齐是另一处。

越熟练越容易漏掉结构性问题，资深团队的技术SEO为什么会失灵讲的正是这类盲区。

同样是三十个名字上下，命中率从84.6%到2.0%，差了四十倍。长度显然不是决定因素。

同样三十个名字，命中率为什么能差四十倍？

把上面那张表里的名单内容打开看，答案立刻就有了。这两群站抄的是两份完全不同年代的清单。

同类工作里排序比努力更重要，500个站实测排出来的优先级可以直接借。

第一种：这两年的AI爬虫清单

命中率高的那几个站，名单内容长这样——GPTBot、ChatGPT-User、OAI-SearchBot、ClaudeBot、Claude-User、Applebot-Extended、Google-Extended、CCBot、PerplexityBot、Bytespider、Meta的几个抓取器、Amazonbot、Diffbot、YouBot。

放开之后怎么铺开，四大模型的差异化布局有具体分工。

还有一种思路是收费而不是拦，要不要向AI爬虫按次抓取收钱已经有平台在做。

放开这些抓取的目的不只是礼貌，从被看见到被AI推荐的三层框架列了具体动作。

这些名字全是最近两三年才出现的，而且都还在正常运营。所以命中率自然高：flyingtiger的26个里22个来过，framebridge的28个里22个来过。

这类名单的特点是它有明确的时代背景——AI公司开始大规模抓取内容，站主要表态。清单虽然也是抄的，但抄的时间近，来源方还在持续更新。

第二种：二十多年前的坏机器人黑名单

命中率低的那几个站，名单完全是另一个世界的东西。看lookfantastic那109个名字里的一部分：

同样年代的东西还有不少，某个跳转方案下线之后的完整迁移路径是一次典型清理。

老配置留下的坑往往很隐蔽，一个看不见的字节头就能让页面白屏是另一种形态。

• 邮件采集类：EmailSiphon、EmailCollector、EmailWolf、ExtractorPro
• 内容抓取类：CherryPicker及其两个变体、LinkExtractorPro、Mata Hari、Mister Pix
• 命名调皮的一批：BunnySlippers、CheeseBot、BuiltBotTough、DittoSpyder、JennyBot、LexiBot、NICErsPRO
• 整站下载类：TeleportPro、WebZIP、WebStripper、Offline Explorer、Microsoft URL Control 5.01.4511

还有更直接的年代标记：Mozilla/4.0（compatible; MSIE 4.0; Windows 95），以及同款的Windows 98、Windows ME、Windows NT、Windows 2000、Windows XP版本，一共六行。

那些工具当年在干什么

顺着这份清单往回看一段，能理解它当年为什么被整理出来，也更容易判断今天还需不需要它。

被误判成坏东西也要有申诉渠道，三大平台的申诉入口和文案可以备着。

当年防扒的另一手是防盗链，两种服务器上的防盗链配法至今还有用。

名单里数量最多的是两类工具。一类是邮件地址采集器，代表是EmailSiphon、EmailWolf、EmailCollector。当年网页上直接写着联系邮箱是常态，这些工具沿着链接爬遍整站，把所有邮箱扒下来卖给发垃圾邮件的人。另一类是整站下载器，TeleportPro、WebZIP、HTTrack、Offline Explorer都属于这一类，功能是把一个网站完整抓到本地硬盘，当年拨号上网按时计费，离线看网页是正经需求。

还有一类数量少但意图明确的，是内容抓取和排名探测工具，比如CherryPicker系列、LinkExtractorPro、Keyword Density。它们服务的是早期的黑帽做法：批量抄内容、批量拿链接。

这三类东西今天基本都不构成主要威胁了。邮箱采集的成本远高于收益，联系方式也早就换成了表单；离线下载的需求消失了；批量抄内容的活现在由更隐蔽的方式完成。所以拦它们不是错，只是不再有意义。

一眼认出老清单的四个特征

不用逐个考据，有几个特征一看就知道这份名单是老的。

老配置文件常一层压一层，重写、缓存、canonical六层怎么排顺序有完整示例。

老配置该逐项过一遍，服务器配置影响SEO的20项清单可以照着核。

第一，名字里带着完整的版本号，形如某个名字加斜杠加1.0。这是从早期日志里直接复制的写法，当时还没有产品令牌的规范说法。

第二，出现Windows 95、Windows 98、Windows ME这类操作系统名。这是最硬的年代标记，没有任何余地。

第三，名字里含Email字样。今天的抓取程序不会用这种命名，那是二十年前的产物。

第四，名字风格拟人化或者调皮，像BunnySlippers、CheeseBot、Mata Hari这种。现在的爬虫命名普遍是公司名加Bot，规整得多。

这四条里命中任意一条，整份清单就该整体怀疑，而不是只怀疑那一行——因为它们通常是整段抄进来的。

这份名单的来路能考据出来

这批名字不是随机的，它们出自2000年代初期一份在站长论坛里广为流传的黑名单。那份清单的目标很具体：当年最猖獗的是邮件地址采集器和整站下载器，前者扒网页上的邮箱去发垃圾邮件，后者把整个网站抓到本地。清单被贴进无数篇教程，也被塞进过各种主机面板的默认配置。

抄示例这件事在各类程序里都有，虚拟文件与物理文件的优先级常被忽略。

问题是这些工具早就不在了。垃圾邮件的获取方式换了，整站下载器也不再是主流威胁。这份清单里的109个名字，在59天日志里只有2个出现过——而那2个后面会讲，它们的出现比没出现更糟。

把Windows 95的浏览器标识当爬虫名，还有一层错

那六行Mozilla/4.0还有个技术层面的问题：它们根本不是产品令牌。

写法层面的检查还是该做，页面骨架的六个维度体检能揪出结构短板。

写法层面的搞混不止这一处，robots.txt和meta robots各管哪一段是最常见的一对。

按标准，User-agent值应该是简短的产品标识，爬虫用自己的产品令牌去匹配。写一整串带括号和版本的浏览器标识，任何爬虫的产品令牌都不会等于它，也不会以它开头。这六行从写下的那一刻起就不可能匹配任何东西——不是因为对象消失了，是因为写法本身不成立。

这也解释了为什么本文要把这9个整串标识型的令牌从统计里剔出去：它们不是收件人不在，是地址栏里填的根本不是地址。

这两年的AI爬虫清单也在过期，只是慢一点

得提醒一句：新清单不等于长期有效。AI相关的抓取标识这两三年变动相当频繁，抄一份两年前的清单，今天也已经有几行是错的。

要跟上变化得有监测面，20款监控工具的评测与选型可以先看这份。

清单类资产都需要年度复核，12个站样本里的冗余与八步瘦身是同一个治理思路。

变动主要有三种形式。一是改名，旧标识停用、新标识启用，本文那些claude-web就属于这一类。二是拆分，原来一个标识负责的事被拆成两三个，训练用一个、用户触发取页用一个、检索索引再用一个——这种拆分对写规则的人影响最大，因为原来一行现在要写三行，而且待遇可能不同。三是新增，某家公司推出新服务就多一个标识。

所以AI爬虫这一块的复核频率要比其它类型高。本文的建议是这一类每半年过一遍对方文档，其余类型一年一次。判断的锚点是对方的官方说明页，而不是任何第三方整理的清单——第三方清单本身也在滞后。

反过来这也说明为什么名单该短：名单越短，复核的成本越低，越可能真的被复核。一份十个名字的清单半小时能核完，一份一百个名字的清单谁都不会去核。

抄清单本身不是错，抄之前问一句是哪年的

说清楚一点：这两群站的做法在结构上是一样的，都是抄清单。区别只在于抄的那份清单是哪一年整理的。

批量套用的东西质量取决于模板，从模板化转向语义化的八步讲了怎么把默认做扎实。

把判断交给自动化之前有前提，数据、方法、人工复核这三条缺一条结论就不能用。

所以判断一份现成名单值不值得抄，有个很快的检验：随机挑三个名字去搜一下，看它们最近有没有公开活动的痕迹——官方文档还在不在、有没有更新过、能不能查到抓取行为说明。三个里有两个查不到，这份清单就该整体放弃。

这个检查花五分钟，能省掉一份躺在文件里十年的死名单。

那几个已经退役的令牌，来的真是它们吗？

接下来这一节是整篇里最出乎意料的部分。

拦截层的实际效果也常与预期不同，防火墙到底拦不拦得住AI爬虫实测出的答案挺意外。

前面说没来过的有204个，那意味着有些退役令牌是来过的。翻开这些请求的具体User-Agent串，才发现问题完全不是想象的那样。

四个退役令牌在日志里的真面目

判断真假靠特征而不是印象，十二项语言特征怎么拆是另一个例子。

换身份看同一个地址是常用手法，对比爬虫和用户看到的页面用的也是这套办法。

四个都是伪造的，判据在标识串本身。

判断伪造不用查IP，看格式就够

先说Anthropic那两个。这家公司现行公开的抓取标识是三个，各有各的用途，格式统一，都带完整的浏览器兼容前缀和一个联系邮箱。而日志里那42次请求的标识是裸的一个词，什么都没有；那15次的格式虽然像样，指向的却是公司官网首页，而不是官方文档里写的那个联系地址。

状态码本身也是判断线索，301、302、404和410分别该在什么场合用是一张速查表。

伪造流量之外还有更直接的骚扰，登录怎么加固才不被爆破是同一批日志里能看到的事。

换句话说，这两个标识都不符合这家公司自己公布的格式。真正的爬虫没有理由用一个官方从未使用过的写法。

Yahoo那个更明显。日志里的串写着Yahoo! Slurp China——Yahoo中国的搜索业务2013年就关了。另外两条的标识末尾带着编码错乱的引号，是从某处复制粘贴时带进来的脏字符。真实的爬虫标识不会有这种东西。

最后那个MSIECrawler，标识里写着IE 5.01加Windows NT 5.0，还带着一个2001年前后的Yahoo工具栏版本号。2026年发出这样一个标识的，只能是拿老UA库随机取值的扫描程序。

再往下查一层：这些请求在找什么

光看标识串还不够，把这些请求的完整日志行拉出来，才看到真正的答案。

密钥和配置文件的暴露面值得系统看一遍，从审查到权限与提示注入防御给了完整清单。

被试探的那些路径要先堵住，五种环境禁掉执行权限的加固写法是最直接的一层。

那15次冒用Claude-Web的请求，状态码全部是404，一次成功都没有。请求的路径是这些：

• /.env.example、/admin/.env——应用的环境变量文件，里面通常有数据库密码和接口密钥
• /.github/workflows/deploy.yml——持续集成的部署脚本，可能含部署凭证
• /service-account.json——云平台的服务账号密钥文件
• /.gitconfig——版本库配置

冒用anthropic-ai的那42次是同一个路子，40个404加2个被服务器直接断开连接，请求的是/gcp-key.json、/server.key、/docker-compose.yaml这一类。

这不是爬虫。这是凭证扫描——挨个试探常见的密钥文件路径，看有没有哪个站忘了把它挡住。

两个不同的名字，用的是同一批地址

更能说明问题的是来源地址。这两组请求分别来自3个和6个地址，而其中两个地址是共用的：一个属于某家公有云的计算实例，另一个属于某个消费级网络代理服务。

要顺着地址往上查，从DNS、线路到CDN的网络层排障给了完整路径。

同一批地址反复来还有别的形态，被攻击时从识别到应急拦截讲的是量级更大的情况。

也就是说，同一个扫描程序换着不同的爬虫名字在敲门。它今天叫Claude-Web，明天叫anthropic-ai，用的是同一台机器。选这两个名字大概率不是随机的——挑一个听起来像正经AI公司的名字，被人工翻日志时更容易被划过去。

另外几个退役令牌的情况类似但动机不同。冒用Yahoo Slurp的14次请求来自5个云主机地址，抓的是首页和一篇文章，看着像内容采集；冒用MSIECrawler的2次来自国内家宽地址，请求的是两个标签页，更像某个老工具的残留。只有WebZIP那1次是访问首页，什么也没做。

于是这条规则的实际效果，是反过来的

把这件事想透会有点不舒服。

规则和对象错位还有另一种，通配组的星号对广告爬虫不生效也是两头落空。

假设你在robots.txt里给claude-web写了一组规则，Disallow: /。你的意图是拦住Anthropic的抓取。实际发生的是两件事：

第一，Anthropic真正在用的那三个标识不叫这个名字，它们不会匹配这一组，会落到通配组或者它们各自的组里去。也就是说你想拦的对象，压根没被这条规则碰到。

第二，唯一会匹配claude-web这个组名的，是那个冒用这个名字的程序。而冒名的程序不读robots.txt——它伪造身份的目的就是绕开限制。

所以这一组规则的效果是：对真实对象无效，对唯一匹配它的对象也无效。它是一条两头都落空的规则，而且写它的人完全有理由相信自己已经把事情办了。

比无效更麻烦的是它带来的安全感

这里有个值得停一下的地方。

看着做完了其实没做成的情况不少，批量内容撞上质量墙的五层工具栈是另一种形态。

假的完成状态最难发现，托管主机可能正悄悄拦掉AI爬虫而监控一声不响。

如果那15次扫描是用一个陌生名字来的，翻日志的人会警觉：这是谁，在找什么。可它用的是一个听起来完全正当的AI公司名字，而且这个名字还写在自己的robots.txt里——名单上有它，说明这事管过。于是这行日志被跳过的概率大大提高。

换个角度说：名单上那个已经不存在的名字，不但拦不住任何东西，还给冒用它的程序提供了一层伪装色。你亲手把这个名字写成了自己认识的、处理过的、不需要再看的东西。

这不是robots.txt的设计缺陷，是名单不保鲜的连带后果。名字一旦失去真实指向，它就成了一个可以被任何人占用的空壳。

真正该做的是把这两件事分开

结论其实很清晰：意愿表达和身份验证是两件事，别指望一个文件同时办。

最外面那层也要配对，端口放行与云安全组怎么配是基础动作。

访问控制该在服务器层做，从版本隐藏、目录权限到访问控制是一份可执行的加固表。

意愿表达用robots.txt，写给对方现行的、公开申报的产品令牌，写完就可以不管——愿意配合的会配合。身份验证在服务器或者边缘层做：对自称是某家爬虫的请求，反查来源地址是否属于对方公布的地址段，或者做一次反向域名解析再正向确认。对不上的按普通可疑流量处理。

顺带一句成本很低的补充动作：那些密钥文件路径本来就不该能被请求到。日志里这些扫描全部返回404是好事，但更好的是在服务器配置里把点开头的文件、常见密钥文件名、部署配置目录统一拒掉，连404都不给。这跟robots.txt无关，但既然扫描已经找上门了，顺手补上比写十行名单实在。

伪造这件事有多普遍，怎么快速筛出来

既然碰到了，顺手量一下这个层面的规模。

恶意方向的手法在演进，三条攻击路径与三层防御值得先了解。

这类筛查适合做成常规，怎么搭一套能在掉量前报警的监控里有可复用的规则。

日志里那4232个无法归类的标识串是重点嫌疑区，它们只贡献了2.2%的请求，却占了标识串总数的一成多。这个比例本身就不正常——正常的浏览器和爬虫标识是高度重复的，几万次请求共用一个串；而伪造流量倾向于每次换一个，于是串多请求少。

快速筛的办法有三条，都不需要工具。

第一条看请求数与串数的比例。一个标识串只出现过一两次，而且格式古怪，基本可以怀疑。第二条看请求的路径。正常爬虫抓的是页面和资源，伪造流量爱试探配置文件、备份文件、后台路径——本文那两组冒名请求就是这么露出来的。第三条看状态码。一整串请求全是404，说明它在猜路径而不是在抓内容。

三条里命中两条，基本就能确定。确认之后不用逐个封禁，把那几个来源地址段加进拒绝列表，或者交给边缘层的规则处理，比在robots.txt里做任何事都有效。

该怎么处理这类名字

旧名字的正确处理方式不是删掉了事，而是查一遍对方现在用什么名字，把规则迁到新名字上。

对方换了名字之后抓取行为的变化会反映在报告里，五类问题URL的占比与排查顺序能帮你确认迁移有没有生效。

拿这个例子说：把claude-web和anthropic-ai这两组删掉，换成对方现行公布的那三个标识，各自按用途给规则——训练用的和检索用的可以给不同待遇。这一步做完，规则才第一次真正对上人。

至于伪造的那部分请求，robots.txt从来管不了它们。要处理得换层：在服务器或边缘层做反向解析校验，确认来源地址是不是真属于对方公布的地址段，不匹配的直接拒。这是另一套机制，跟这个文件没关系。

给不存在的对象，一共写了多少条规则？

点名只是第一步，点完还要写规则。所以还有个数字值得算：这些没有收件人的分组里，一共躺着多少条规则。

规则该写给哪些路径是另一半功课，电商该屏蔽的七类页面里有逐类判断依据。

44个站，215条规则

把所有命中退役令牌、从未存在的令牌、桌面工具令牌的分组挑出来，数它们组内的规则条数：44个站，合计215条，中位数是1条。

成批确认状态有现成流程，死链批量检测与分类提交可以直接跑。

真正需要挡的地址里最难缠的是筛选组合，分面导航产生的海量URL怎么治理单独讲过。

写得最多的几个：framebridge.com 46条，fromourplace.com 33条，lookfantastic.com 19条，pullandbear.com 13条，mango.com 12条。

要说明的是framebridge这个数字不算浪费——它的名单是新的AI爬虫清单，命中率78.6%，那46条里大部分是有对象的。真正空转的是lookfantastic那19条和几个西班牙品牌站的十几条。

其中111条是全站禁抓

更值得看的是这215条里规则类型的分布：有111次写的是Disallow: /，也就是整站禁止抓取。

真需要全禁的场景确实存在，预发布环境被索引之后的八步清除就是其中一种。

禁抓和不收录是两件事，加了标记之后多久才真正消失有六个场景的观测。

这个比例说明了这类规则的写法特征——面对一个不认识或者不想要的爬虫，人的第一反应是全站拉闸，而不是挑几个目录。这个反应本身没问题，问题是拉闸的对象已经不存在了，闸门关在了一个没人走的门上。

那111条全站禁抓，写法上还有个连带风险

全站禁抓这个动作本身没问题，但它跟前缀匹配规则一起用的时候，有个容易忽略的连带效果。

配置的副作用往往不出声，每次reload都通过，Googlebot每8次抓取却有1次撞在301上是同一类沉默。

假设你想拦一个叫做SomeBot的抓取器，结果名字写短了，写成了Some。按前缀匹配，所有产品令牌以Some开头的爬虫都会落到这一组，然后被整站禁抓。如果里面恰好有一个是带流量的搜索抓取器，那这一行就从拦截变成了自伤。

这个风险在名单短的时候几乎不存在——名字少，每个都认真写了。名单一长就开始出现，因为长名单里的名字往往是从别处成段复制的，谁也没逐个核对完整拼写。

样本里没有发现这种误伤的实例，但有几个站的写法离危险不远：把某个厂商名的前几个字母单独成组，同时组内写着全站禁抓。这类写法只要那个厂商未来推出一个带流量的抓取器，就会被顺带拦住，而且拦了不会有任何提示。

还有个容易忽略的连带影响：这些分组会让文件变得难以diff。改版的时候想比较两个版本的robots.txt差异，一百行里有七十行是无效内容，真正的变化很容易被淹没。把无效内容清掉之后，每次改动都一目了然——这对需要评审配置变更的团队来说，价值比省几个字节大得多。

这些规则的代价，不在服务器上

跟上一类问题一样，这215条不消耗任何资源，也不影响收录。爬虫读到不属于自己的分组会直接跳过。

换架构时这些包袱最难搬，这套基建换了架构就得自己重搭是提前的提醒。

冗余配置最后都会变成读不懂，插件与主题各输出一套标记怎么归一是同一种病。

代价在两个地方。一是文件长度，一个原本二十行的文件因此变成八十行，可读性下降；二是它制造了一种覆盖感——名单上有一百个名字，看上去防线很密，实际上密的是名字不是防线。这种覆盖感会让人不再去看日志，而日志才是唯一能看到真实抓取情况的地方。

被点名最多的那个爬虫，为什么本站几乎见不到？

交集数据里有一组反差特别大的对比，值得单独拆。

广告落地页那条链路自己也有讲究，文案原料全在落地页上说明了它为什么被单独抓。

74个站点名，59天来了4次

被点名最多的令牌是adsbot-google，157份文件里有74个（47.1%）提到它。这个数字的来源不神秘——它出自主流电商平台的默认模板，用平台建店就自带。

投放期的抓取节奏确实不一样，大促与日常SEO的八维度差异有时间轴可参考。

平台默认带来的东西不止这一行，平台内置、通用工具与专属应用的三层框架能帮你分清哪些该接管。

而它在这份59天日志里一共发了4次请求。

紧随其后的几个也类似：mj12bot被34个站点名，来了418次；按AhrefsBot与AhrefsSiteAudit的说明，后者是站主自己在工具后台授权的审计爬虫，只会去授权它的站，本文日志里它来了11350次；pinterest被27个站点名，一次没来。

这种反差不是矛盾，是结构差异

解释很简单，但值得说清楚，因为它揭示了名单该怎么读。

同一个动作在不同站上的效果差很多，三平台和300个站的收录速度实测能看出差距。

广告爬虫只抓有广告投放的落地页，本文这台服务器没有投放，所以它几乎不来。Pinterest的抓取集中在被用户保存过图片的页面上，一个中文技术博客不在它的范围里。而Googlebot、bingbot、AI公司的抓取器不挑站，所以它们出现在几乎所有日志里。

所以正确的读法是：被点名的次数反映的是模板的分发量，请求次数反映的是这个站的真实处境，两者本来就不该相等。

不同类型的站，爬虫构成能差多少

把这个差异具体化一点。本文这台服务器是中文技术内容站，它的爬虫构成大致是：网页搜索抓取占大头，AI相关的抓取器紧随其后，SEO工具类中等，社交与聚合类少，广告类几乎为零。

内容形态决定谁来抓，帮助中心怎么做索引控制与AI引用是另一种典型。

站的结构决定爬虫怎么走，架构怎么搭才不让爬虫找不到产品页是更上游的决定。

换成一个投了搜索广告的英文电商站，构成会明显不同：广告爬虫会成为常客，因为它必须核对每一个落地页；商品比价和购物聚合类的抓取会出现；社交平台的抓取会因为商品图被收藏而增加；而中文搜索引擎的抓取基本消失。

再换成一个企业官网，量级整体下降，但结构更集中——主要就是几家搜索引擎和几个安全扫描服务，AI抓取的比例反而可能更高，因为企业信息是模型爱抓的内容类型。

这三种构成没有哪个是标准答案。所以一份放之四海皆准的爬虫名单在逻辑上就不成立，它只能是某个特定站在某个特定时期的观察结果。

这里有个本文测不了的问题，得说清

还有一层必须承认的局限：那74个点名广告爬虫的站，究竟有多少真在投广告，本文没法知道。

测不了的时候要说清边界，site命令能查什么、什么时候会误判也是这个态度。

如果一个站确实在投放，那这一行是有意义的——广告爬虫会去抓它的落地页，规则写对了位置就能起作用。所以不能一概说这74行都是空转的。

能确定的只有两件事：一是这一行来自平台默认模板而不是站主的判断，二是在没有投放的站上它不产生任何效果。至于每个站属于哪种情况，只有站主自己看后台能确认。这个区分很重要——本文量的是名单和现实的偏差，不是每一行的对错。

把两个方向的差集放在一起看

到这里两个方向的数字都有了，摆在一起才看得出这件事的全貌。

两头都变的时候最难解释，流量下降怎么跟老板交代有一套完整口径。

两个方向的差集在别处也有，同域、跨域、参数变体六类重复怎么治可以对号入座。

三行数字合起来说明一件事：名单和现实的重叠部分，比两边各自的规模都小得多。一份典型的robots.txt名单，大部分内容对应不到真实抓取行为，而真实抓取行为里又有一大块不在名单上。

这个结构决定了维护方式。如果偏差主要来自存量老化，那定期清理就够；如果偏差主要来自增量缺失，那必须建立从日志到名单的通道。而本文的数据显示两种偏差都很大——所以两件事都得做，而且后者更重要，因为它对应的是正在发生的抓取。

推论：名单不该照抄，因为你的站和别人的站不一样

这一节最实用的推论在这里。既然爬虫的抓取范围取决于站点自身的类型、语言、投放和内容形态，那么任何一份现成名单都不可能适配你的站。

按自己站的情况排序才有效，三类站点各自的高回报修复项可以直接借。

投了广告的电商站需要管广告爬虫，不投的站写了也是空转；有大量图片被社交平台收藏的站需要管社交爬虫，纯文字站不需要；做英文内容的站会被更多AI爬虫盯上，纯中文站的抓取者构成完全不同。

这个差异没法靠抄清单解决，只能靠看自己的日志。这也直接引出了后面那一节。

日志里那批谁都没点名的爬虫，该管吗？

反过来查一遍更有意思：日志里那些确实来过的抓取程序，有多少在157份robots.txt里压根没被提到。

要限速得先想清副作用，限速规则拒掉的第4个请求正好是robots.txt会让全站抓取停十几个小时。

137个标识，89202次请求

结果是137个自称爬虫的标识串，合计89202次请求，没有任何一个站在名单里写过它们。

这类量级的请求会影响运维安排，增量备份与快照怎么做才不出事是配套功课。

这些请求的累积影响未必有声音，抓取速率被调低的那几天日志里一条错误都没有就是这种情形。

请求量排在前面的几个：

这份清单里最值得注意的是新面孔

LinkupBot、CodexResearchBot、ShapBot、GeneralCrawlBot、HeyBlogBot、AwarioSmartBot、FindFiles、DuckAssistBot这些名字，绝大多数是最近一两年才出现的。它们不在任何一份流传的清单里，因为清单的整理速度跟不上新服务的出现速度。

要不要对它们放开取决于回报，四大AI搜索引擎的分引擎策略有具体判断。

新服务出现的速度确实快，10款主流AI搜索工具的实测对比能看出这两年的密度。

这就构成了名单的第二个结构性缺陷：它不但会留下已经消失的对象，还会漏掉正在活动的对象。前者是存量问题，后者是增量问题，而后者的影响更实际——真正在消耗你带宽的往往是那些没人点名的。

还有个判断上的细节值得提：这137个里有一部分是同一个服务的不同版本，比如命令行工具的三个版本号、Python几个HTTP库的不同版本。按标识串数它们是好几个，按对象数其实是一个。所以看到这个数字不用紧张，真正需要区分对待的对象比137少得多。

反过来也有需要合并看的：某些服务会同时用两三个标识，分别对应不同用途。判断的时候按对象合并，比按标识串逐个处理省事，也更不容易漏。

这137个里面，哪些该管哪些不用管

清单拉出来之后总要做决定。按三个问题分，基本就够了。

先估值再决定拒绝是通用做法，八步有毒外链审计是同一个流程结构。

外链工具的爬虫是典型的纯消耗方，反链工具怎么选与竞品反链拆解解释了它们为什么抓得勤。

第一个问题是它带不带回报。搜索类和AI检索类的抓取会带来曝光，哪怕名字陌生也该先查清是谁，再决定。本文这份清单里的LinkupBot、DuckAssistBot属于这一类，它们背后是检索服务，拦掉等于自断一条曝光渠道。

第二个问题是它耗不耗资源。SEO工具的外链爬虫、通用研究爬虫属于纯消耗——它们抓走的数据用于别人的产品，对你没有直接回报。这类的处理取决于量：请求量小可以不管，大到影响服务器就限速。

第三个问题是它说不说得清自己是谁。清单里有几个标识只有一个名字加版本号，没有说明地址，也查不到任何公开资料。这类应该按可疑处理——不是因为它一定有害，而是因为无法评估。

按这三问过一遍，137个里通常只有十个上下需要真正处理，其余的记录下来下次再看就行。

新爬虫出现和被写进清单之间，差多久

还有个值得估一下的量：一个新抓取服务出现之后，多久才会进入公开流传的清单。

格局变化的速度决定清单的寿命，全球搜索引擎格局与多平台优化给了一份比例参照。

从本文的数据能大致推断。日志里那些新面孔多数是最近一两年出现的，请求量已经不小；而157份robots.txt里没有任何一个站点名过它们。也就是说滞后至少是以年计的。

这个滞后是结构性的，不可能通过更勤快地看文章解决。清单的生产链条是这样：新爬虫出现，被少数站主在日志里注意到，有人写成文章，文章被读到，被抄进文件。这条链每一环都要时间，走完通常一年以上。

而你自己的日志是零延迟的——它在爬虫第一次来的当天就记下了。所以真正能跟上现实的名单只有一种：从自己的日志长出来的那种。这也是下一节要说的做法。

还有一类不该忽略：命令行工具和脚本

请求量最大的其实是curl，三个版本合计42688次，超过Googlebot的三分之一。加上Python的几个HTTP库，脚本类请求相当可观。

脚本请求打上来时缓存层最吃力，字节码缓存怎么调能扛住一部分。

脚本请求扎堆会直接反映在负载上，负载飙高怎么定位到进程是应急时的路径。

这类请求robots.txt完全管不了——它没有产品令牌可以匹配，写规则也无处安放。它们的处理方式只有服务器层：按频率限速、按来源封禁、或者对可疑标识返回验证挑战。

把这一层认清有个好处：你会明白robots.txt能覆盖的范围其实是有限的。它只对那些既自报身份、又愿意遵守规则的程序有效。日志里那些用命令行工具和脚本库发出的请求，从一开始就不在这个文件的管辖范围内，数量还不小。

令牌到底怎么写，才会真的被匹配到？

前面反复出现过写法层面的问题，这里集中说清楚。名单里有相当一部分行，不是对象不在，是写法本身不成立。

写法细节决定成败这件事到处都有，URL结构与slug的九个细节是另一处例子。

匹配的是产品令牌，不是整串标识

标准里的规则是：爬虫用自己的产品令牌，去和文件里的User-agent值比对，不区分大小写，取匹配得最具体的那一组。产品令牌是简短标识，比如Googlebot、GPTBot、ClaudeBot，不带版本号，不带括号里的描述。

同样的列举法用在链接上也管用，一次扒清链接结构与扣分项有现成输出格式。

各家的硬边界都该记在一张表里，抓取体积上限的实测拆解给了具体数值。

所以下面这几种写法都不会命中：

带版本号的写法为什么不行

样本里有22个令牌写成了名字加斜杠加版本的形式，像iaskspider/2.0、propowerbot/2.14、harvest/1.5这样。

一个字符的差别能让整块失效，一个尾逗号就能让整页标记失效是同类的静默错误。

写的人大概是从日志里直接复制了标识串的一段。问题是匹配用的产品令牌不含版本——对方申报的是名字本身，版本号是运行时附加的。所以写上版本号之后，这一组就永远匹配不到它想匹配的对象。

正确做法是只写名字，版本号去掉。这样无论对方升到哪个版本都能匹配。

带空格的令牌有例外，得看对方怎么申报

含空格的令牌需要分开看。像Sogou web spider、Screaming Frog SEO Spider这两个，对方申报的产品令牌里确实带空格，写上去是有效的——日志里也证实了它们的请求。

国内引擎的申报方式确实不同，做搜狗SEO绕不开的那套生态可以顺带看看。

但样本里另外那些带空格的，比如Black Hole、Mata Hari、Kangaroo Bot、Download Ninja，属于前面说的老黑名单，对象本身就不存在了。

判断办法只有一个：查对方的官方说明，看它自己怎么写这个名字。查不到说明的，八成不该写进去。

空分组和空Disallow，各是什么意思

还有两个写法容易被混淆，它们的含义正好相反。

一字之差含义相反的情况不少，自定义错误页与软404的正确配法最容易配错。

这个文件常被用来解决它管不了的事，用robots.txt拦UTM参数的危害就是一例。

一个分组只写了User-agent，下面一条规则都没有，这一组等于什么都没说——对方匹配到它，然后发现没有任何限制，于是全部允许。这种空组在样本里不算少，多半是删规则的时候把组名留下了。

另一种是写了Disallow但值为空，也就是冒号后面什么都没有。按标准这明确表示允许抓取全部内容，跟写Allow斜杠效果相同。它跟Disallow斜杠只差一个字符，含义完全相反——前者是全部允许，后者是全部禁止。

这两种写法本身都是合法的，但在长名单里很危险：一个本意是禁抓的分组，只要那一行的斜杠掉了，就从全禁变成全放，而文件看上去毫无异常。检查的办法很简单，把所有Disallow后面为空的行找出来，逐个确认是不是有意为之。

名字写错了会怎样，有没有兜底

还有个常被问到的问题：如果名字拼错了，会不会造成事故。

不同工具的判定口径本就不同，爬虫报的死链和Googlebot抓的从来不同解释了差异来源。

结论是不会造成事故，但会静默失效。拼错的名字匹配不到任何爬虫，那一组规则就永远不执行，效果等同于没写。没有报错，没有告警，文件照样合法。

不过有一种情况需要留神——拼错的方向。如果把名字写短了，比如本想写某个完整令牌却只写了前几个字母，按前缀匹配它会命中所有以这几个字母开头的令牌，范围可能远超预期。所以拼错的两个方向后果不同：写长了或者写错字母是失效，写短了是扩大范围。

至于兜底，唯一的兜底是通配组。任何没有匹配到专属分组的爬虫都会执行通配组的规则，所以通配组应该写得足够完整——把真正不希望被抓的路径都放进去。这样即使某个专属组因为名字写错而失效，对象也会落回通配组，而不是落到一个什么限制都没有的状态。

同一个名字写在两个分组里会怎样

长名单还常出现另一种情况：同一个爬虫名在文件里出现了两次，分属两个不同的分组，规则还不一样。

同一件事声明两遍就会打架，跨页场景下的八种冲突有对应诊断办法。

标准对这种情况的处理是合并——匹配到同一个名字的多个分组，规则会被当成一组来执行。但不同解析器在细节上未必完全一致，尤其当两组规则互相冲突的时候，谁优先取决于实现。

所以这种写法应该避免，它属于把结果交给运气。检查方式是把所有User-agent值排序去重，看有没有重复项。样本里有几个站存在这种重复，都是名单增长过程中重复添加造成的——加的时候没搜一下文件里有没有。

大小写不用纠结，前缀匹配要留神

两个容易多虑或者漏掉的细节。

分布和范围的把握是另一种功课，从锚文本分布看过度优化风险是同类判断。

大小写完全不影响匹配，写GPTBot、gptbot、GPTBOT效果一样，不用为此纠结。

前缀匹配则要留神：如果写了一个较短的名字，它会匹配到所有以它开头的令牌。比如只写Google，会同时命中Googlebot、Googlebot-Image、Google-Extended、GoogleOther这一整批——这可能不是你的本意。要精确控制就写完整的名字，一个一组。

名单该怎么维护，才不会落后于现实？

问题诊断到这里已经很清楚：抄来的名单会同时犯两个错，留下死的、漏掉活的。那正确的做法是什么。

例行动作最好挂成定时任务，用cron把备份、sitemap、缓存这些活自动化有可直接改的脚本集。

顺序反过来：先看日志，再写名单

核心只有一句：名单应该是日志的产物，不是文章的产物。

从原始数据里挖结论是同一个套路，用正则从后台挖AI搜索提问也是这么做的。

不过不是所有事都该自动化，哪些能交给工具、哪些不能划了一条比较清楚的界。

具体做法是先从自己的日志里把真实来访的抓取程序列出来，按请求量排序，然后逐个决定怎么对待。这样得到的名单天然满足两个条件——它上面的每个名字都是真的会来的，而且都是真的来过你这个站的。

一条命令拿到自己的爬虫清单

从日志提取爬虫标识不需要工具，一行管道就够：

想让它定期跑起来，把定时表达式写对的具体办法可以直接生成。

awk -F'"' '{print $6}' /www/wwwlogs/example.com.log |
grep -Ei 'bot|spider|crawl|slurp|fetch|python|curl' |
sort | uniq -c | sort -rn | head -40

输出是按请求量排序的标识串清单。日志格式不同的话，调整取字段那一步就行。

拿到清单之后做三件事：把请求量最大的十几个挑出来，逐个查清是谁、抓什么用途；对照现有robots.txt，看名单上有没有它们；把文件里那些日志中从未出现的名字标记出来，等一个观察周期再决定是否删除。

多久复核一次，复核什么

名单不是一次性工程，但也不需要频繁维护。按本文观察到的变化速度，一年一次足够，赶上大变动的时候临时加一次。

复核这件事在外链侧已经工程化了，反链流失监控与回收的SOP可以借它的节奏。

复核节奏要落到协作流程里，内容运营与SEO协作的七个动作点有可抄的表格。

复核的时候只做三件事。一是重跑那条日志命令，看有没有新面孔冒出来，请求量大的挑出来查清身份。二是把文件里的名字逐个对日志，标出这一年一次都没来的，连续两次复核都没来的可以删。三是查一遍那些还在名单上的对象有没有改名——这一步靠去对方官方文档看现行令牌，AI公司这两年改名相当频繁。

三件事加起来一两个小时，一年一次。比起那些在文件里躺了二十年的名字，这个投入实在不算什么。

这件事该由谁负责，放在什么节点做

最后说落地。这类维护工作最常见的死法不是没人会做，是没人认领。

跨角色的活得有交接口径，后端与SEO协作的七个动作点把责任切得比较清楚。

没人负责往往不是态度问题，团队怎么搭、考核怎么对上才是根子上的事。

robots.txt横跨几个职责：名字和用途判断偏SEO，日志提取偏运维，是否拒绝AI训练偏内容策略甚至法务。三方都能改，三方都觉得是别人的事，结果就是只增不删。

比较可行的安排是把它挂在一个已经存在的固定节点上，而不是新设一项任务。三个现成的节点都合适：一是季度技术审查，顺手把日志命令跑一遍；二是每次改版上线前的检查清单里加一项，因为改版时本来就要动这个文件；三是当抓取量出现异常、有人去翻日志的时候——那时候数据已经摊在眼前，顺手核对名单几乎不增加成本。

关键是别把它做成一个独立的季度任务，那种任务的第一次执行往往也是最后一次。挂在别的事情上，它才活得久。

名单多长算合理

按本文的数据给一个参考区间：十个上下。

把时间省在该省的地方，六大耗时任务的自动化方案能腾出复核的时间。

投入该怎么分配也是同一类取舍，内容、技术、外链三类分工与配比有几种现成结构。

理由是请求量的集中度——前十个令牌占了总请求量的87.7%。也就是说十个名字能覆盖住绝大部分真实抓取行为，再往后加的每一个名字对应的都是极小的量。

当然这个数字跟站的类型有关。做多语言、多市场的站会多几个区域搜索引擎；投放广告的站要加广告爬虫；有大量图片的站要加社交平台的抓取器。就算全加上，二十个也差不多到顶了。

反过来说，如果你的名单超过三十个名字，而其中大部分不是这两年的AI爬虫，那几乎可以肯定它里面有大段抄来的内容。这时候最快的处理不是逐条核对，是清空重写——从日志重新长一遍，通常半小时就能完成，而且结果比原来那份可信得多。

怎么决定一个爬虫该给什么待遇

拿到名字之后，判断给什么规则可以按四个问题走。

放开的收益能不能量化，3000条数据揭开的引用认知差可以当参照。

放开之后还要确认对方读得懂，让AI爬虫抓得到、读得懂、引得出是技术端的落地清单。

第一问，它带不带流量。搜索引擎和AI搜索的抓取器会带来曝光，这类通常应该放开，甚至要检查有没有被误拦。第二问，它抓的东西会不会被拿去训练模型。这属于价值取向，想拒绝就针对训练用的令牌单独写规则。第三问，它是不是自己人。SEO工具的审计爬虫是你自己授权的，限它等于限自己。第四问，它耗不耗资源。真的抓得太凶而且不带任何回报的，才是限速或者禁抓的对象。

四问答完，规则自然就有了，而且每一条都能说出理由——这比一份一百行的名单有用得多。

留一行注释，写清依据和日期

最后一步跟处理失效字段一样：每个分组上面加一行井号注释，写这个爬虫是谁、为什么这么对待它、什么时候确认过。

改版时最容易丢掉这些依据，改版不掉SEO的完整防护清单里有对应的检查项。

这一步的价值在两年后显现。到时候某个爬虫可能改名了、某家公司可能关掉了这个服务，而有注释的行能让接手的人判断该不该动，没注释的行只能继续留着。本文那些活了二十年的名字，缺的就是这一行。

这份名单在整套防护里，到底是什么位置？

最后把层次理一遍，因为名单最大的风险不是写错，是被当成了防线。

相邻那一层是响应头，X-Robots、缓存和Vary几个头的实际机制值得整体过一遍。

它是分流器，不是闸门

robots.txt的作用是对愿意配合的程序做分流：告诉守规矩的爬虫哪些地方值得抓、哪些地方别浪费时间。它对不配合的程序没有任何约束力，这一点标准本身就承认——遵守是自愿的。

分层这件事在缓存侧最直观，八维决策树与规则迁移是同一种思路。

没有头部标签的资源只能靠响应头，接口和feed这类地址拿什么说自己不想被收录量过一次。

所以它能解决的是抓取效率和意愿表达问题，解决不了访问控制问题。前面那个伪造claude-web的例子就是最好的说明：唯一匹配那条规则的对象，恰好是最不可能遵守它的对象。

名单只是分组名，真正起作用的是规则

最后纠正一个容易搞混的地方。这篇讲的都是名单，但名单本身不产生任何效果——它只是分组的标题。真正起作用的是分组里那几行规则。

在自己代码里认爬虫是另一条路，五种识别搜索引擎蜘蛛的写法里含反向验证。

这个区分有实际意义。名单上多一个已经消失的名字，代价是文件长了一行；而分组里的规则写错，代价可能是一批页面被拦住不被抓取。所以清理的优先级应该是：先检查规则，再清理名字。

顺着这个思路，前面提到的分组不继承那件事就更值得警惕了：给某个爬虫单开一组，它就完全脱离通配组的规则。名单越长，单开的组越多，脱离通配组的对象也越多。一份点了三十个名字的文件，等于三十个各自独立的规则集，其中大部分组内只写了一两行——这些对象实际上得到的是比通配组宽松得多的待遇。

所以长名单不只是冗余，它还会悄悄放宽限制。这也是本文建议把名单控制在十个上下的另一个理由：分组少，规则的实际效果才好预测。

四层各管什么

每一层各管一段，某个安全策略头的配置与回滚两条路是典型的分层例子。

最外那层能做的事不少，在CDN边缘改SEO的原理与落地形态给了几种现成形态。

这四层的顺序不能颠倒着用。想拦住伪造身份的抓取，写多少行名单都没用；反过来，想让Googlebot别浪费预算去抓筛选页，用防火墙硬拦也是错的手段。

身份验证那一层，具体怎么落

四层里最容易被跳过的是身份验证，因为它需要动服务器配置。这里给一个最小可用的做法。

加固清单照抄也会出事，一行响应头把嵌进来的地图和支付按钮变成摆设是真实案例。

要在代理层做这些判断，反向代理的完整配置场景是前置知识。

思路是对自称是主流爬虫的请求做一次来源核实。做法可以照着已验证爬虫的判定方式来，核心是反向解析加正向确认：拿请求的来源地址做反向域名解析，看得到的域名是不是属于对方声明的域，再把这个域名正向解析回地址，确认和来源地址一致。两步都通过才认。

这套逻辑在nginx里通常配合map和自定义变量实现，或者交给边缘层的现成规则——多数边缘服务已经内置了已验证爬虫的判断，打开开关就行，比自己写解析靠得住。

做不到这一步的话，退一档也有用：把各家公开的地址段抄下来做成白名单，自称是它但来源不在段内的直接拒。缺点是地址段会变，需要定期更新；优点是实现简单，一条规则就能挡掉本文那种冒名扫描。

还有个更简单的补充动作，成本几乎为零：把点开头的文件、常见密钥文件名、部署配置目录在服务器层统一拒掉。这跟爬虫名单无关，但既然日志里已经能看到有人在挨个试探这些路径，顺手补上比写十行名单实在得多。

顺便说一个心态上的调整。做完这套动作，多数人会发现自己原来的名单里大部分内容都没用，然后产生一种白忙一场的感觉。其实不必——那份名单在被抄下来的那一刻是有依据的，只是依据留在了别人的日志里，而且早就过期了。这不是谁的疏忽，是这类配置天生缺一条反馈通道。补上这条通道，就是这篇讲的全部内容。

如果只做一件事，做哪件

这篇给的动作不少，如果时间只够做一件，那就做提取日志这一件。

把精力放在真有产出的事上，这一行的慢性透支比多数人以为的严重附了一套自查办法。

分层提问这个习惯用处很广，收录、排名、流量是三件事，先分清卡在哪是最常用的一版。

理由是它同时解决两个方向的偏差：它告诉你哪些名字该留下，也告诉你缺了哪些名字。而其它所有动作——查文档、分类型、写注释、定复核周期——都建立在你先知道谁真的来过这个前提上。没有这份清单，后面每一步都只能凭猜。

成本也确实低：一条管道命令，输出一份按请求量排序的清单，五分钟。剩下的时间花在查前十个是谁上面，一个小时能查完。这一个多小时的产出，比照抄任何一份清单都可靠——因为它是关于你这个站的。

一句话的判断顺序

把整篇压成一条链：先问这个名字是谁、能不能在对方的官方说明里查到；再问它在自己的日志里出现过没有；再问它带来的是曝光还是消耗；最后问要拦的话，这一层拦不拦得住。

收件人各认一套的例子还有，一键退订必须写两层，少一层整个域名就被限流也是同一个道理。

出问题时也是靠这种链式排除，四类原因的诊断决策树能快速缩小范围。

四问全过才写进文件，写完加一行注释注明日期。这套动作的成本是每个名字两三分钟，收益是名单从此不再是一份没人敢动的存量档案。

说到底，robots.txt里的名字不是一份愿望清单，它应该是一份来访记录的回执。谁来过、来干什么、你怎么答复——三样都对得上，这个文件才算写对了。

常见问题解答

怎么快速判断自己robots.txt里的爬虫名单过没过期？

看两个信号，一分钟就能出结论。第一个信号是名单长度：超过三十个名字而且大部分不是这两年的AI爬虫，基本可以断定里面有整段抄来的内容。第二个信号是内容特征——名字里带完整版本号、出现Windows 95这类操作系统名、含Email字样、或者用了拟人化的调皮名字，命中任意一条就该整体怀疑。要更硬的判据就算命中率：把名字逐个在日志里搜一遍，看有请求的占几成，低于三成说明这份名单该重写。本文157个站里，点名超过30个的6个站命中率只有26.0%，最长那份109个名字只有2个来过。

名单上的名字在日志里一次没出现，可以直接删吗？

不能只凭这一条就删。某个爬虫没来过你的站，可能是它不抓这类站，而不是它已经消失了——广告爬虫在没投放的站上不会出现，社交平台的抓取器在没有图片被收藏的站上不会出现，但它们都活得好好的。正确顺序是先用命中率判断整份名单值不值得信，再对没命中的名字逐个查存在性：存在性查官方文档，活跃度查日志，两件事不能混。确认已经消失的删掉，确认还在但不来你这的留着也无妨，成本就是几个字节。

爬虫改了名字，旧规则该怎么处理？

不是删掉了事，而是查清对方现在用什么名字，把规则迁过去。以Anthropic为例，本文样本里有7个站还在写claude-web、7个站写anthropic-ai，而这家公司现行公开的是另外三个标识，分别用于训练抓取、用户触发的取页和检索。迁移的时候正好可以按用途分开给待遇——允许检索用的来抓，同时拒绝训练用的。旧名字那两组直接删除，它们不会匹配到任何真实对象。这一步做完，规则才第一次真正对上人。

日志里出现了名单上那个已经退役的名字，说明它还活着吗？

大概率相反，说明有人在冒用它。本文查到冒用claude-web的15次请求全部返回404，请求的是环境变量文件、部署脚本和云平台密钥这类路径；冒用anthropic-ai的42次是同一个路子，而且两组请求共用同一批来源地址。判断伪造不用查地址，看标识串格式就够——真实爬虫会用官方文档里公布的那种格式，冒用者往往只写一个裸名字，或者指向公司官网首页而不是文档里的联系地址。这类请求robots.txt管不了，得在服务器层做来源核实。

AI训练爬虫该不该全部拦掉？

先把训练和检索分开，这是这个决定的前提。同一家公司通常有两套标识：一套抓内容用于训练模型，一套在用户提问时实时取页用于生成回答。拦掉前者只影响你的内容会不会进模型，拦掉后者会直接影响你能不能被AI引用——后果完全不同。所以常见的选择是拒绝训练、放开检索。要注意各家的令牌名字不一样也在变，做这个决定之前得去对方文档确认现行的名字都有哪些，别照着两年前的文章写。

平台模板自带的那些名字，比如广告爬虫，要不要删？

不投广告的站可以删，投的话留着并检查规则。这一行在本文样本里被74个站写着，占47.1%，几乎全部来自电商平台的默认模板。而它在本文这台没有投放的服务器上59天只来了4次。要说明的是，本文没法知道那74个站里有多少真在投放，所以不能一概说这一行是空转的。判断标准很简单：自己看广告后台有没有在投，投了这一行就有用，没投就是模板留下的痕迹。

名单控制在多少个名字比较合理？

十个上下，做多市场或投广告的站可以到二十。这个区间的依据是请求量集中度：本文62个来过的令牌里，前5个占了总请求量的73.9%，前10个占87.7%，剩下52个加起来不到13%。也就是说十个名字能覆盖绝大部分真实抓取行为，再往后加的每一个对应的都是极小的量。另外分组越多，脱离通配组的对象也越多——单开一组就意味着这个爬虫完全不受通配组规则约束，长名单会悄悄放宽限制。

既然拦不住伪造身份的爬虫，这个文件还有什么用？

它管的是另一件事。robots.txt对愿意配合的程序做抓取分流，告诉它们哪些地方值得抓、哪些地方别浪费预算，这个作用是实在的——主流搜索引擎和AI公司的抓取器都遵守它。它同时是一份公开的意愿声明，在内容授权这类话题上有表态价值。它不能做的是访问控制，因为遵守完全靠自愿。所以正确的用法是分层：意愿表达和抓取分流用这个文件，身份验证和限速在服务器或边缘层做，两件事别指望一个文件同时办。

权威参考资料