robots.txt指令有没有人读？35.7%的站白写了

摘要：157份真实robots.txt逐行拆开，56个站（35.7%）至少写着一条没人读的指令，合计146条。Crawl-delay最典型：47个站写了129行，只有16行落在会读它的爬虫能看到的位置，另有2行直接写给了明确说过不读它的Googlebot。还有10个站在写Host，收件人是一个自己都弃用了它的搜索引擎；2个站在写Noindex，这条路Google在2019年9月1日就关了。这些行不报错、不消失，也没有工具会提醒你。

先说一件反直觉的事：一条规则失效的时候，它不会告诉你。

代码写错了会抛异常，配置填错了服务起不来，证书过期了浏览器会拦在前面。这些失败都有声音。可robots.txt里一条指令失效，没有任何声音。文件照样返回200，语法照样正确，那一行字照样躺在原地，你每次打开都能看见它。唯一变了的东西，是它不再有任何效果——而这件事，文件本身不会写给你看。

这次把211个海外品牌独立站的robots.txt全抓了一遍，一行一行按标准语义拆开，就是想看看这种沉默的失效到底有多普遍。结果比预想的更值得说：问题不在于有人写错了语法，而在于几乎所有人都默认，写下去的规则会有人读。

一条指令写下去之后，究竟是谁负责读它？

robots.txt有一件特别容易被忽略的性质：它不是配置文件，它是一封公开信。

同一件事该用哪个手段也常被搞反，robots.txt和meta robots各管哪一段里有清楚的分工。

这份文件写废了的后果不小，整站从谷歌搜索结果里消失的那类事故就是最直接的样本。

配置文件的接收方是你自己的程序，改完重启就生效，生效与否有明确的反馈。而robots.txt的接收方是别人的爬虫，几百家，各写各的解析器，各有各的支持清单。你把文件放上去，谁来读、读到哪一行、读懂几个字段，全部由对方决定。你能做的只有一件事：把话说清楚，然后等。

效力不在语法里，在对方的解析器里

这就带来一个和普通配置完全不同的判断方式。一条指令有没有效，跟它写得对不对关系不大，跟谁读它关系很大。同一行字，在Bing那里生效，在Google那里被跳过；同一个字段，五年前有人读，今天没人读了。文件本身一个字都没变，效力却已经变了。

要弄清对面到底是谁，120种爬虫UA的分类与真假验证是个可以直接照做的方法。

生成器给的预设并不总跟规范对齐，通配符判定会和标准打架的那几种情况值得先看一眼。

这种变化的方向几乎总是单向的：字段会被弃用，爬虫会退役，支持清单会变短。很少有哪个搜索引擎宣布，从今天起我们开始读一条以前不读的老指令。

这个文件没有版本号，也没有兼容性声明

更麻烦的是，robots.txt连一个声明兼容性的地方都没有。它没有版本号，没有schema，没有类似HTML里那种文档类型声明。爬虫排除协议在2022年才有了正式的标准文档，编号RFC 9309，而在那之前的二十多年里，各家一直在事实标准上各自加料。加进去的那些字段，有的进了标准，有的没进，有的进了又被移出去。

这些字段各自作用在哪一环，抓取、索引、排名三步的分工讲得比较完整。

结果就是，你打开一份陌生的robots.txt，光看内容根本判断不出哪些行是有效的现役规则，哪些行是历史沉积。它们的排版、语法、缩进完全一样。

沉默不是缺陷，是标准明文要求的行为

这里有个关键机制，弄清它之后前面所有现象就都顺理成章了。

判断某项标记有没有人读也是同一个问题，结构化数据对AI搜索到底有没有用里有官方说法和实测。

同样的沉默在结构化数据里更狠，一个尾逗号就能让整页标记失效而页面照样正常显示。

爬虫排除协议的正式标准里有一条明确规定：解析器遇到自己不认识的字段，必须忽略它，继续处理后面的内容。不是报错，不是中止，是静默跳过。

这条规定是有道理的。robots.txt是给几百个互不相干的实现读的公开文件，如果某个实现遇到陌生字段就报错或者中止，那么任何一家新增一个私有扩展，都会让别家的解析器集体失灵。为了让这个生态能往前走，标准必须要求大家对陌生的东西保持宽容。

但同一条规定，从写文件这一端看，效果就变了：你写下任何一个不存在的字段名、任何一个拼错的指令、任何一个已经作废的老写法，所有爬虫都会礼貌地跳过它，一句话都不会说。沉默不是没人发现，是标准要求它们不许出声。

这个文件的年纪，也解释了为什么这么乱

顺着标准往回看一段历史，也有助于判断某个字段的成色。

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

这套机制1994年就出现了，最初是一封邮件列表里的提案，靠各家自愿遵守运转了二十多年，一直是事实标准而非正式规范。2019年，Google把自己用了二十年的解析器开源，同时向标准化组织提交了草案；2022年，这份草案正式成为编号RFC 9309的标准文档。

标准落地时做的事很克制：只把User-agent、Allow、Disallow这三个字段写进规范，加上一条未识别字段必须忽略的规则。二十多年里各家加过的其他字段，一个都没进去。

这段历史给出一个很实用的判断依据。要确认Google会怎么读你的文件，不用猜也不用只靠在线工具——它的解析器是开源的，可以拿自己的文件在本地跑，得到的是官方实现的真实判定结果。后面会给出用它做差分验证的具体办法，那是本文能提供的最硬的一个动作。

公开信的另一面：写进去的路径谁都能看

把它当公开信还有一层后果，跟收件人问题正好互补：这封信不是只有收件人能读，任何人都能读。

这意味着写进Disallow的每一个路径都是一次公开告示。你想挡住的那个后台入口、那个内部工具页、那个还没发布的活动目录，写进去之后就成了一份索引——想找的人不用扫目录，直接读你的robots.txt就行。

这就构成一个很尴尬的组合：对不遵守规则的抓取程序，这个文件毫无约束力；对想找入口的人，它是一份现成的清单。守规矩的爬虫会绕开，不守规矩的正好照着来。

所以路径要不要写进去，判断标准是它暴露之后有没有风险。纯粹为了省抓取预算的路径，比如筛选参数、站内搜索结果、加入购物车的地址，写进去没问题——它们本来就在页面链接里，不算秘密。真正需要保护的地址不该出现在这个文件里，它们该走访问控制：登录校验、来源限制、地址段白名单。这些手段跟robots.txt的区别是，前者由你的服务器执行，不需要对方配合。

本文前面那几个把管理后台入口写进Disallow的站，其实同时踩了两件事：那个地址在它们自己的域名下压根不存在，所以规则毫无意义；而如果它真的存在，写进去反而是主动指路。两头都不划算。

三种没有收件人的写法，代价完全不同

把这次的数据摊开之后，无效的行其实分得很清楚，一共三种。

边缘层的拦截效果也没那么确定，防火墙到底拦不拦得住AI爬虫实测出来的答案挺意外。

真要拦住某类爬虫得分层来，robots、UA识别、WAF三层的选型框架比只改一个文件靠得住。

第一种是对方公开退出了：这条指令曾经有人读，读它的那一家发过公告说不再支持。这种最容易查，因为公告是公开的、有日期的，查一次文档就有答案。

第二种是对方从来没打算读：这条指令在某一家那里是有效的，你却把它写在了另一家的分组里。规范没错，语法没错，只是寄错了地址。这种查起来要多一步，你得先知道每个字段各自的支持者是谁。

第三种最新，是对方还没来：字段是今年才有人提出来的，提出的那一方希望大家读，但真正承诺读它的还只有几家。这种严格说不算失效，算尚未生效，可从效果上看，跟前两种没有区别。

为什么这类问题在任何工具里都不报错

三种写法有一个共同点，这也是它们能长期活下来的原因：所有校验工具都不会报错。

有些检查天生只能看表层特征，十二项语言特征怎么拆是另一个例子。

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

常规全站审计能覆盖的范围有边界，桌面爬虫能查出的12类问题清单可以对照看缺了哪一块。

robots.txt的测试工具、平台后台的编辑器、各类SEO插件的体检模块，检查的都是语法层面的事——路径写没写错、通配符用没用对、分组有没有匹配到自己。它们不检查、也没法检查一件事：这一行的收件人还在不在。因为收件人在不在，不是文件里的信息。

于是这些行就留下来了。留一年、三年、五年，穿过几次改版、几次迁站、几任负责人。保哥翻过一个户外装备品牌的建站记录，那份robots.txt从2019年到现在改过11次，每次都是在文件末尾追加新规则，没有任何一次是打开文件从头读一遍——这非常正常，正常到几乎所有站都是这么维护的。

157份robots.txt里，究竟有多少行是白写的？

先把样本和口径说清楚，因为这次的分母本身就出过一次问题。

至于哪些页面真该挡，电商该屏蔽的七类页面里有逐类的判断依据。

同一批157份文件还量过另一件事，给单个爬虫开组会丢掉通配组全部规则的中招比例高得离谱。

211个域名，两类文件必须先剔掉

抓取对象是211个海外品牌独立站的主域名，请求/robots.txt，跟随重定向，超时20秒，裸域拿不到就换www再试一次。回来的状态码分布很分散：200有168个，403有21个，连不上13个，404有4个，429有3个，另有400和301各1个。

首页本身能不能被读到也量过，132个独立站首页有28个是空壳。

同一批域名上做过的另一项实测是，142个站里只有52个回得出304。

168份里还得再剔一层。有9份的状态码是200，正文却是一整页HTML——路由没为这个路径准备处理，请求落到了单页应用的兜底页上。这9份对爬虫来说等同于空文件，也就是全部允许抓取，但它比404更难被发现，因为监控只看状态码的话，200看起来完全正常。

剔掉之后，有效样本157份。下面所有比例的分母都是157。

尺子先失效了一次：把403的响应体也当成了规则

这里有个必须交代的返工。第一遍统计的时候，分母算出来是161，比157多了4。原因很朴素：统计脚本是按目录里的文件枚举的，而抓取脚本无论状态码是多少都把响应体落了盘。于是403页面里那几行纯文本、429返回的限流提示，全都被当成robots.txt参与了统计。

用别人的工具时更该先校准，第三方数据准不准的六步校准法能挡掉大部分噪声。

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

差4份不影响结论方向，但它是这类工作里最典型的一种错：用文件系统里有什么当分母，而不是用抓取记录里成功了哪些当分母。后来改成先按状态码筛出成功清单，再按清单去读文件，数字才对上。

说白了，量别人配置里的失效之前，得先确认自己的尺子没失效。这句话在这个项目里已经不是第一次应验了。

结果：56个站、146条、中位数2条

157份文件里，至少有一条指令属于上面三种情况之一的，有56个站，占35.7%。合计146条。

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

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

按每站条数看，中位数是2条，也就是说踩到的站通常不是系统性写错，而是零星留了一两行。少数几个站留得比较多：italic.com有7条，awaytravel.com和wayfair.com各6条，eufy.com有5条。

字段名一共只有9种，问题全部发生在这9种里面

有个数字挺意外：157份文件里出现过的字段名，去重之后只有9种。

字段少不等于没得做，把FAQ这类标记用对的八步也是在有限字段里做深。

字段之外还有例外规则要留意，通配组的星号对广告爬虫不生效就是最容易漏的一条。

这张表其实就是全文的骨架。前三行是现役规则，占了全部行数的绝大多数；中间三行是本文要讲的沉默失效；最后三行是刚出生还没有收件人的新写法。

没有拼写错误，这件事本身值得说一句

值得注意的是，9种字段名里一个拼写错误都没有——没有Disalow，没有User-agents，没有把冒号写成等号的。157份文件、12771行指令，语法层面干净得出乎意料。

真出语法级问题时症状反而很明显，一个看不见的字节头就能让页面白屏是另一种极端。

这从侧面印证了前面那个判断：出问题的地方从来不是语法。语法有人管，编辑器会提示，平台会校验，抄来的模板本身也是对的。没人管的是收件人。

12771行里，绝大多数在做同一件事

把这12771行按字段拆开看比例，能看出这个文件真正的用途分布。

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

这一万多条禁止规则最终服务的目标是预算，抓取预算优化的十二项实操按优先级排过序。

Disallow一项就占了10017行，78.4%；Allow 1874行，14.7%；Sitemap 729行，5.7%。这三项加起来99%不到一点。剩下的一百多行才是本文讨论的对象——Crawl-delay 129行，Host 10行，Noindex 7行，加上5行新字段。

换个说法：robots.txt在现实里几乎是一个单一用途的文件，它绝大部分内容在回答哪些地址不要抓。剩下那1%在试着表达别的意思——限速、不要收录、指定主域名、说明用途授权。而恰恰是这1%，命中无效的概率最高。

这个分布有个直接的实操含义：审查一份robots.txt的时候，不必逐行读那一万多条Disallow，先把非Disallow、非Allow、非Sitemap的行拎出来单独看。这些行数量少、每一行都承载着一个特定意图，也最容易出问题。157个站的数据说明，这么筛一遍，就能覆盖掉全部146条无效行。

还有一类沉默：Sitemap行指向的地址不通

顺带说一个同类现象。Sitemap行是全局的，不属于任何分组，写在文件哪儿都一样。145个站写了它，合计729行，说明这一项的普及度很高。

批量确认地址还在不在有现成办法，死链怎么批量查出来再分类提交可以直接套用。

这一行指向的文件本身也有一堆写法讲究，2400个站踩出来的sitemap坑基本都在那份清单里。

但Sitemap行也有它自己的沉默方式：地址写错、指向的文件已经不生成了、或者返回404，robots.txt本身照样是合法的，没有任何提示。它跟前面讲的失效指令属于同一类问题的不同表现——指令本身有人读，但它指向的东西不在了。检查方式很简单，把每一行Sitemap的地址取出来请求一次，看返回码和内容开头是不是XML。这一步花的时间和抽查Disallow路径差不多。

Crawl-delay写给了谁，读它的人真的看得见吗？

Crawl-delay是这批数据里最值得单独拆开的一个字段，因为它同时踩到了前面说的第一种和第二种情况，而且大多数人对它的印象是错的。

要看清谁在真抓你的站，5000个站样本里的爬虫伪造与抓取预算实测是更硬的参照。

限速这件事做在服务器上也有反噬，限速规则拒掉的第4个请求正好是robots.txt会让全站抓取停十几个小时。

47个站129行，取值10占了82行

先看规模。157份文件里有47个站写了Crawl-delay，合计129行。取值分布很集中：

抓取节奏被压下去往往悄无声息，抓取速率被调低的那几天日志里一条错误都没有就是这种情形。

取值10是绝对主流，占了63.6%。这个数字很有来历——它不是算出来的，是抄出来的。二十年前的一批模板里就写着10，后来一层层抄下来，成了默认答案。

顺便算一下代价：一个有5万个可抓地址的电商站，如果某个爬虫真的按10秒一个的节奏走，抓完一轮要将近6天。促销页上线三天才被读到，这个后果比大多数人以为的严重。

先弄清一件事：Crawl-delay不是废弃指令

网上流传最广的说法是Crawl-delay已经废弃了，这个说法不准确，而且这种不准确会直接导致判断错误。

国内引擎又是另一套口径，提交了为什么还不收录从抓取和索引机制拆起。

至于真正吃掉带宽的那一批，AI爬虫抓取量已经超过Googlebot好几倍改变了限速这件事的优先级。

既然它主要对Bing有效，这个被长期低估的第二搜索引擎怎么做值得单独花点时间。

准确的情况是这样：Google在自己的robots.txt文档里明确写着不支持这一行，读到会直接跳过；Bing认，并且在自家站长工具里同时提供了抓取控制的后台设置；Yandex曾经认，后来也改成了后台设置；至于第三方工具类爬虫，AhrefsBot和MJ12bot都在自己的文档里说明会读，各家对数值的解释还不完全一样。

所以它不是一条死指令，它是一条收件人各不相同的指令。判断它有没有用，不能问这条指令还有效吗，得问我这一行写给谁看，那个人读不读。

129行的收件人分布：热门收件人不是搜索引擎

把129行各自所在的分组拆开，收件人的样子就出来了。这129行分布在54个不同的User-agent令牌上，被点名最多的几个是：

被点名最多的那几个其实是外链工具的爬虫，反链分析工具怎么选与竞品反链拆解解释了它们为什么抓得那么勤。

把日志按对象拆开看会很清楚，8类UA的22周访问账本是一份可对照的样本。

这张表里最有意思的是排序。写Crawl-delay的人心里想的多半是搜索引擎，可实际写下去的行，绝大多数落在了SEO工具和社交平台的爬虫身上。写给bingbot的只有5行，而bingbot恰好是主流搜索引擎里唯一会读它的那个。

清单里还有一个自摆乌龙的对象值得单独指出来：AhrefsSiteAudit被25个站写了限速。这个爬虫和排在它前面的AhrefsBot不是一回事——前者是站主自己在工具后台点了按钮之后，工具派来审计自家站点的；后者是全网抓取用的。

给自己叫来的审计爬虫限速到每10秒一个地址，后果是自己的全站审计要跑好几天才出结果。这不是没效果，是效果打在自己身上了。这25个站里大概有一部分人后来在工具后台抱怨过扫描太慢，却未必想到是这一行造成的。

只有16行落在了会读它的对象能看到的位置

还有一层更细的错位。robots.txt的分组是不继承的，爬虫只执行匹配得最具体的那一组。所以一行Crawl-delay对bingbot有没有效，取决于它写在哪个分组里：写在bingbot自己的组里，有效；写在通配组里且这个站没给bingbot单开组，也有效；可要是站里既有通配组又有bingbot专属组，而Crawl-delay只写在通配组，bingbot就读不到它。

位置和分布决定效果这件事到处适用，从锚文本分布看过度优化风险是另一处例子。

写对了位置也未必等于对方进得来，robots.txt说允许，仍有10个站把GPTBot挡在门外是另一层错位。

按这个口径算，47个写了Crawl-delay的站里，能被bingbot真正读到的只有13个：5个写在bingbot组里，8个写在通配组且没有单开bingbot组。折算成行数是16行，占129行的12.4%。

剩下34个站，把Crawl-delay全写给了别的对象——SEO工具爬虫、社交平台爬虫、离线下载软件。这些行不是全无用处，AhrefsBot那25个站确实会被限速，但如果写的人本意是压搜索引擎的抓取频率，那这34个站的目标一个都没达成。

写给Googlebot的那两行

129行里有2行是直接写给Google的爬虫的，这是最干净的白写案例，因为Google的文档里就明确写着不支持。

同一家的爬虫内部也分工，移动优先索引下的渲染机制决定了它以哪个身份来抓。

想拦训练数据的话这一行更不够用，内容进模型的四条路在一份诉讼材料里被摊开过。

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

其中一个站的写法特别值得看：gillette.com把42个AI相关的爬虫令牌堆在同一个User-agent组里，从GPTBot、ClaudeBot、Applebot-Extended一直排到Meta的几个抓取器，组里写了一行Crawl-delay: 10。

这42个令牌里混进了Google-Extended和GoogleOther，于是这一行就成了写给Google的Crawl-delay。整组的意图很明确——想给AI爬虫统一限速。可这批爬虫的公开文档里，绝大多数一个字都没提支持Crawl-delay。

想压抓取频率，该把话说到哪里

那如果确实需要降速呢？按对象分开处理，能落地的只有这几条路。

临时降速会用到的状态码也有讲究，301、302、404和410分别该在什么场合用是一张速查表。

在服务器上动手要防误伤，拦AI爬虫与限速怎么不把Googlebot一起拦掉有具体的匹配写法。

对Google，去Search Console的设置里调抓取速率，或者在服务器端对它的请求返回503配合Retry-After做临时降速——注意这是临时手段，长期返回5xx会被当成站点故障。对Bing，站长工具后台有抓取控制面板，比robots.txt里那一行更明确。对SEO工具类爬虫，Crawl-delay确实有用，写在它们各自的分组里就行。对AI爬虫和不认识的抓取器，Crawl-delay基本无效，真要限速得在服务器层做请求速率限制。

换句话说，Crawl-delay不是没用，是能用它的地方比大多数人想的窄得多。

限速这件事，本该在哪一层做

再往深一层看，Crawl-delay之所以这么容易被误用，还有个原因：它把一个服务端的问题，写到了一个客户端自愿遵守的文件里。

这些闸门放在边缘层实现更省事，在CDN边缘改SEO的原理与落地形态给了几种现成形态。

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

抓取压力大是个真实的运维问题——数据库连接被打满、TTFB变长、真实用户受影响。可robots.txt里那一行是在请求对方配合，不是在限制对方。愿意配合的会配合，不愿意的、或者不读这个字段的，一点影响都没有。真正扛压力的手段全部在服务端。

这张表想说明的是分层。上面两行是打招呼，下面三行是设闸门。打招呼很有价值——它让守规矩的爬虫按你的节奏来，成本几乎为零；但如果你的真实处境是服务器已经被抓爆了，那就得往下走，光把数字从10改成20不会有任何变化。

顺着这个思路还能解释一个常见困惑：为什么有人写了Crawl-delay之后感觉抓取量确实下来了。多半是因为他点名的对象里恰好包含了AhrefsBot、MJ12bot这类真读它的第三方爬虫，而这些工具爬虫本来就是抓取量大户。压下来的是它们，不是搜索引擎。

同样写一个10，各家的理解是一样的吗？

假设你运气不错，Crawl-delay写对了位置，收件人也确实会读。还有一个问题在等着：这个数字对方怎么理解。

定义不清的指标最容易误导判断，从指标体系到异常诊断的完整做法可以拿来搭自己的口径。

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

标准里没有这个字段，所以也没有语义定义

这是个容易被忽略的前提。爬虫排除协议的正式标准文档里，一共只定义了User-agent、Allow、Disallow这三个字段，以及Sitemap这个事实上通用的扩展。Crawl-delay不在其中。

标准写没写这件事，影响的不只是robots.txt，语义化HTML到底影响不影响抓取也是拿样本页跑出来的。

不在标准里，意味着没有任何一份权威文档规定它的单位、取值范围、以及超出范围之后怎么处理。每家实现自己解释，而且不同实现的解释确实不一样。

三种常见解释，结果差几十倍

把各家的公开说明和实际观察对照，Crawl-delay: 10至少存在三种不同的执行方式。

同一个指标不同平台的口径也不同，三平台和300个站的收录速度实测能看出差距有多大。

解释不同会直接反映到报告上，抓取报告里五类问题URL的占比与排查顺序能帮你分清是谁的问题。

Bing在自家文档里用的是第二种表述，把它描述成对抓取节奏的划分而不是简单的秒数间隔，还提示取值过大会影响新内容被发现的速度。第三方工具类爬虫多数走第一种或第三种，AhrefsBot的文档明确说会读这个值并据此放慢，但不承诺精确的换算关系。

取值上限也是各家自定的

还有个实操细节：不是所有实现都接受任意大的数值。有些实现对超出自己上限的取值直接按上限处理，有些干脆忽略整行。所以写Crawl-delay: 86400想让某个爬虫一天只来一次，很可能什么都不会发生。

超过上限之后会发生什么很关键，页面体积超出之后商品链接被截在外面是实测过的后果。

各家自定上限这件事在别处也有，Googlebot那个2MB抓取上限就是一条硬边界。

样本里最大的取值是30，出现1次；有2个站写了0。写0这件事挺有意思——按第一种解释，0就是不限速，那这行等于没写，但它占着一个位置，让人以为限速已经配置过了。

数值型指令的通用判断

这一节想说的其实不止Crawl-delay。凡是往别人系统里写数值的场景，都有同一个问题要问：这个数字的单位和语义，是谁定义的，写在哪儿。

服务器上那些数值配置同样值得逐条问一遍，服务器配置影响SEO的20项清单可以照着核。

定义在标准里，各家实现基本一致，可以放心写；只在某一家的文档里有定义，那就只对这一家有效，别指望别人按同样方式理解；哪儿都没有定义，这个数字就只是一个愿望值。Crawl-delay属于第二种和第三种的混合体，这也是它最容易被误用的原因。

robots.txt里的Noindex，Google到今天还认吗？

不认。而且这件事有一个非常明确的日期，明确到可以写进检查清单里。

这两个手段能不能一起用也常被问到，noindex和canonical同时用的九种场景判断给了明确结论。

换成有效手段之后还得等，页面加了noindex要多久才从搜索结果里消失有六个场景的实测。

2019年那份公告，一次点掉了三个字段

2019年7月初，Google在搜索开发者博客上发了一篇很短的通告，主题是robots.txt里那些从未被写进文档的规则。文章说得直白：这些规则从来没有出现在Google的官方文档里，代码里的支持是历史遗留，现在要把它们清掉，生效日期是2019年9月1日。

官方砍功能这件事不是第一次，FAQ富结果被砍之后这套标记还该不该写是同类决策题。

被点到名的一共三个：noindex、nofollow、crawl-delay。这就是为什么前面那节要专门说清Crawl-delay的处境——它和Noindex是同一份公告里的同一批被清理对象，只不过Crawl-delay在别家还活着，Noindex在任何一家都没活下来。

这份公告的意义不只是宣布三个字段作废。它顺带说明了一件更重要的事：robots.txt里有一部分字段的支持，从头到尾就没有写在文档里。写的人是从别人的文件里看到的，用了之后好像有效，就一直用着。等到哪天对方清理代码，效果就无声无息地消失了。没有报错，没有提示，也没有任何回归测试能发现。

样本里只剩两个站，一共7条

157份文件里还在写Noindex的只有2个站：sostrenegrene.com写了1条，路径是分享链接的参数；wayfair.com写了6条。合计7条。

这些页面真进了索引会拖累全站，大量没用的页面怎么诊断和处置有一张决策矩阵。

这个数字小得让人有点意外，说明这几年清理得相当彻底。也正因为剩得少，剩下的这几条才更值得看一眼——它们不是随便留的，写的时候有明确意图。

那6条挡的正是最该挡的页面

wayfair那6条的路径是这样的：/filters/、*/filters/、/*quick_view、/roomplanner/*、/decorator/*、/roomplanner3d/*。

这些页面的另一个毛病是正文占比太低，模板和广告稀释主体内容的七个陷阱有对应的量法。

筛选组合页最大的问题是内容重复，同域、跨域、参数变体六类重复怎么治可以对号入座。

看一眼就知道意图：前三条是分面导航和快速预览，后三条是房间规划、软装搭配这类交互工具页。这些恰恰是家居电商最典型的URL膨胀来源——一个筛选组合能生成成千上万个地址，每个地址都是一个可抓取页面，内容却高度重复。用noindex把它们从索引里挡掉，是完全正确的判断。

手段无效，判断正确。这种组合比判断本身就错更难发现，因为你复盘的时候会先看意图，意图一看就对，很容易直接跳过去。

更麻烦的是，同一批路径还被Disallow挡了一遍

把这个站的文件完整读一遍，会发现6条Noindex不是孤零零写在那儿的。同样这几个路径，在文件里还有对应的Disallow：

分页那一层也有同样的取舍，分页页面五种处理方案的对比列了各自的代价。

不同类型的页面该给什么指示是分开的，五类页面的meta robots与canonical差异可以拿来对照自己的模板。

这就构成了一个双重失效。第一层，robots.txt里的Noindex本身没人读；第二层，就算它有人读，Disallow也已经把爬虫拦在门外了——被禁止抓取的地址，爬虫连页面都取不到，自然也无从执行任何不收录的指示。两条规则里任何一条单独存在都不会有效果，两条一起写反而让人更确信这件事办得很稳。

还有个更细的痕迹：这几行里有两行写成了Noindex : /roomplanner/*，字段名和冒号之间多了一个空格。多数解析器会把两边的空白去掉，所以这不影响解析，但它说明这些行是手工敲上去的，不是模板生成的。

同一份文件里还有一行Allow: /roomplanner3d/$——用美元符号做精确结尾匹配，放开目录首页本身，同时用Disallow挡掉目录下的其他地址。这是相当熟练的通配符用法，能写出这一行的人，对robots.txt的语法掌握得比平均水平好得多。

这个对比才是这一节最值得记住的地方：语法水平和收件人判断，是两件互不相关的事。熟练的人一样会写下没人读的指令，因为语法能靠工具校验，收件人只能靠查文档。

为什么这一条比其他白写的行更危险

Crawl-delay白写了，后果是抓取频率没降下来——不好，但不致命。Host白写了，后果是主域名选择这件事没人管——通常有别的机制兜着。Noindex白写了，后果是一批你以为已经从索引里拿掉的页面，其实一直在索引里。

这类假完成状态最容易骗过例行检查，后台那些数字为什么人人都读错讲了几处常见误读。

页面到底在不在索引里要看后台状态，八种未编入索引状态各自意味着什么是判断的起点。

差别在于，前两种是没得到想要的收益，第三种是拿到了一个假的完成状态。你在项目文档里勾掉了这一项，团队里所有人都以为分面页已经处理过了，实际上它们还在搜索结果里跟主要商品页抢位置。这种问题往往要等到收录量异常、或者有人偶然搜到一个筛选页时才被发现。

正确的替代路径，顺序不能反

要让一个地址不出现在搜索结果里，只有两条真正有效的路：页面头部的meta robots标签，或者响应头里的X-Robots-Tag。后者对非HTML资源尤其重要，因为PDF、接口返回的JSON、feed这类东西没有地方放meta标签。

非网页资源只能靠响应头下指示，PDF怎么做SEO与六个优化点里有具体做法。

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

响应头这一层能做的事比想象中多，X-Robots、缓存和Vary几个头的实际机制值得整体过一遍。

关键是顺序，这一步错了会前功尽弃：先允许抓取，让爬虫能读到noindex，等页面从索引里消失之后，再考虑要不要在robots.txt里加禁止抓取来省预算。反过来做——先在robots.txt里禁掉——爬虫就永远读不到那个noindex标记了，这个地址反而可能以没有摘要的形式长期留在索引里。

对wayfair那6条路径来说，正确做法是在这些页面模板的头部输出noindex，或者在服务端按路径规则给响应头加X-Robots-Tag。robots.txt里那6行可以直接删掉，它们现在唯一的作用是让人误以为事情办完了。

按路径下发不收录指示，服务端两种写法

分面导航这类页面有个共同特点：数量多、由参数组合生成、模板可能是共用的。逐个页面改模板容易漏，更稳的做法是在服务端按路径规则统一下发。

要注意缓存层会不会把这个头一起缓住，全页缓存怎么配以及怎么清里有对应的处理。

Apache环境下这类规则常和别的层叠在一起，重写、缓存、canonical六层怎么排顺序有完整示例。

nginx里加一段位置匹配就行，注意用always参数，否则非200响应上这个头不会输出：

location ~* ^/(filters|roomplanner|decorator)/ {
    add_header X-Robots-Tag "noindex, follow" always;
}

Apache环境用mod_headers，按目录或正则匹配都可以：

<IfModule mod_headers.c>
  <LocationMatch "^/(filters|roomplanner|decorator)/">
    Header set X-Robots-Tag "noindex, follow"
  </LocationMatch>
</IfModule>

两处都写了follow，这是有意的。noindex加nofollow会让这些页面上的链接也不被跟随，而分面页往面上常常挂着通往正常商品页的链接，全部掐掉反而损失内链。除非确实不想让爬虫顺着往下走，否则保留follow更稳妥。

配完必须验证一次，验证方式是直接看响应头有没有这一行。用命令行请求的时候记得用GET而不是只取头部，有些服务端对不同方法的响应头处理不一致，只查头部会漏掉实际存在的字段。

Host指令是写给谁的，写它的人知道吗？

接下来这一条最能说明抄来的规则是怎么在文件里过日子的。

选哪个版本最终还是搜索引擎自己判断，它挑选规范网址的九条决策逻辑解释了为什么你的声明有时不被采纳。

接管这件事的是另一套机制，canonical该怎么设的九个决策点是现在的主力手段。

10个站写了Host，其中9个连Yandex的分组都没有

157份文件里有10个站写了Host，每站1行，值全都是自己的主域名，8个带www，2个不带。

要不要管某个搜索引擎得看它的实际份额，全球搜索引擎格局与多平台优化给了一份比例参照。

Host从来不是通用指令，它是Yandex的私有扩展，作用是在多个镜像域名之间声明哪一个是正主。所以判断这一行是不是有意为之，只需要看一件事：这个站有没有在管Yandex。

结果是10个站里只有1个（pullandbear.com）给Yandex的爬虫单开过分组，其余9个站的文件里，Yandex这个词一次都没出现过。它们写了一行只有Yandex会读的指令，同时没有任何迹象表明它们在意Yandex怎么抓自己的站。

这一行原本要解决的问题，今天由别的机制接管了

Host要解决的问题是真实存在的，而且现在依然存在：一个站可能同时能从带www和不带www的地址访问，或者同时有http和https版本，搜索引擎需要知道哪个是主版本。

这套声明自己也会打架，跨页场景下canonical的八种冲突有对应的诊断办法。

协议版本的选择也属于同一类问题，从HTTP迁到HTTPS怎么才能不掉排名是完整的迁移路径。

只是这件事早就搬家了。今天负责回答这个问题的有三样东西：服务端的301重定向、页面里的canonical标签、以及各家站长平台后台的域名设置。这三样所有主流搜索引擎都读，Yandex自己也在文档里说改用重定向来判断。

所以Host这一行的处境很特殊：它不是需求消失了，是需求换了地方办理。这两种情况在文件里长得一模一样，但处理方式完全不同——需求消失的行直接删，需求搬家的行删掉之前得先确认新地方已经办好了。

它是怎么进到文件里的

把这10个站的文件放在一起看，来路基本能推出来。这些行的位置很有规律：大多紧跟在Sitemap行的旁边，或者贴在文件最末尾，与上下文的缩进风格不完全一致。

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

这是典型的从示例里整段抄的痕迹。很多年前流传得很广的一批robots.txt模板文章，为了显得完整，会把Host和Crawl-delay一起写进示例。抄的人不需要知道Host是给谁看的，示例里有，抄过来就是了。之后每次改版都只在末尾追加新规则，没人会回头审这一行。

顺着这条线索还能解释另一个现象：为什么Crawl-delay取值10的比例那么高。它们大概来自同一批示例。二十年前有人在一篇教程里写了10，后来抄的人不知道该填几，就照着填了10。这个数字一路传到了2026年的品牌独立站上。

一个能立刻做完的判断动作

遇到一行不确定来路的指令，有个很快的办法：在自己的文件里搜一下这个指令的目标对象名字，看它在别处出现过没有。

两个方向的跳转都要验一遍，双向301在两种服务器上的写法都在一起。

确认主域名跳转是不是通的更实际，多域名统一301到主域名的完整配置可以照抄。

写了Host，就搜Yandex；写了给某个爬虫的Crawl-delay，就搜那个爬虫的名字。如果整个文件里只有这一处提到它，那这行几乎肯定是抄来的——因为一个真在管某个爬虫的人，通常不会只对它说一句话。

被挡住的那个目录，今天还在吗？

前面几节讲的都是收件人不在。还有一种失效方向正好相反：收件人在，规则也有效，可要挡的那个东西已经没了。

改版之后这类地址会成批出现，一次揪出全站404与重定向链有现成的工具流程。

这批地址在后台会以另一种形式冒出来，404报告怎么修以及软404怎么排查是配套的动作。

这个方向以前没量过，这次顺手做了一遍，结果比预想的夸张。

实验怎么做：从通配组里抽具体路径，直接请求

做法很朴素。157份文件的通配组里一共有5539条Disallow，其中不带星号、不带美元符号、不带问号的具体路径有1903条，占34.4%。这1903条是可以直接拼成地址去请求的。

换身份请求同一个地址是常用手法，模拟爬虫身份测站的具体做法里有可直接用的串。

想知道某个目录在不在索引里还有别的探法，site命令能查什么、什么时候会误判说清了它的边界。

每个站抽3条——第一条、中间一条、最后一条，避免只抽到同一类。最后得到358条，覆盖127个站。用普通浏览器的User-Agent逐条请求，跟随重定向，记下最终状态码、重定向次数和最终地址。

这里要说清一件事：普通用户访问不受robots.txt约束，这个文件约束的是自动抓取程序。所以用浏览器身份去看一眼这些地址存不存在，本身没有越界，量也控制得很小。

这次抽样有三条边界，得先划清楚

这个53.4%要用得住，边界必须说明白，否则很容易被外推成一个错的结论。

第一条，只抽了通配组里的路径。各个专属分组里的Disallow没有参与，因为专属组大多由平台模板生成，路径高度重复，混进来会把比例带偏。

第二条，只抽不含通配符的路径。带星号或美元符号的规则没法拼成一个确定地址去请求——它们匹配的是一类地址而不是一个。这一类在通配组里占了65.6%，也就是说本次实验覆盖的只是三分之一。

第三条，每个站只抽3条。这是为了把请求量压到最低，代价是单站结论不可靠：某个站三条全404，只能说明它这几条过期了，不能断定整份文件都失效。

所以这个数字的正确读法是：在robots.txt里那些指向具体地址的禁止规则中，能测出结果的部分有一半以上指向了不存在的地址。它不等于所有Disallow有一半失效，也不等于某个具体站点有一半规则没用。把范围说窄一点，结论反而更结实。

能判定的176条里，一半以上指向不存在的地址

358条里有182条没法判定——被边缘防护挡了，返回403、406、422这类。剩下176条能看出结果：

不同工具报出来的死链也常常不是一批，爬虫报的死链和Googlebot抓的从来不同解释了差异来源。

返回什么状态码这件事本身要配对，自定义错误页与软404的正确配法最容易配错。

把前两行合起来，94条（53.4%）挡的是一个不存在的地址。真正原地命中的只有32条，不到五分之一。

还有9个站的3条抽样全部404，一条都没命中：assos.com、buckmason.com、columbia.com、dji.com、lookfantastic.com、purple.com、soundcore.com、stokke.com、weber.com。这几个站的robots.txt多半已经很久没有对着实际站点结构核对过了。它不是一份现役配置，是一份存量档案。

404的路径长什么样，一看就知道它经历过什么

把404的清单摊开，路径名本身就是一部简史。

测试环境留下的地址更麻烦，预发布环境被索引之后的八步清除是一套应急流程。

路径名本身也是资产，URL结构与slug影响抓取和排名的九个细节值得在改版前定好。

有一类是老技术栈的遗留：gillette.com挡着/postreview.php和/account.php，两个都是PHP时代的地址，站早换过架构了，现在请求前者会被兜底路由送回首页，后者会跳到新的登录页。canyon.com挡着两条Demandware平台的商店路径，实际访问会跳到语言子目录。

有一类是测试和临时页：buckmason.com挡着/testing，dji.com挡着/cache/，assos.com挡着/poll/和/report/。这些名字看起来就是当年临时开的，用完就删了，规则忘了收。

还有一条堪称本次抽样的最佳画面：assos.com在robots.txt里写着Disallow: /404/，而这个地址返回的正是404。挡一个专门用来显示找不到页面的目录，而那个目录本身也找不到了。

另一类是带店铺编号的：bollandbranch.com挡着/11547838/orders，burrow.com挡着/93232202030/orders。这是电商平台早期版本的订单路径格式，平台自己升级之后这个编号段就不用了。

把404清单按来路归一下，正好四类：

最后一类值得多说两句。这几个站用的是托管电商平台，管理后台根本不在自己的域名下，而是在平台自己的域名上。也就是说/admin这个地址从来就不存在于这个站点，挡它不会有任何效果，也不会有任何风险——它纯粹是一种防护姿势。

这类行的心理来源很好理解：写的人见过别的站挡后台入口，觉得挡一下总不吃亏。问题是它给了一种已经加固过的错觉。真正需要确认的是那个后台入口实际在哪儿、有没有做访问限制，而这件事robots.txt既回答不了也管不着——它本来就不是安全机制，任何人都能读到它，把敏感路径写进去反而是给人指路。

模板路径和自定义路径的过期率，几乎一样

这里有个反直觉的结果。原本猜测平台模板带来的路径（/cart、/checkout、/admin、/services/login_with_shop这一类）过期率应该更高，因为它们不是站主自己写的，跟自家结构未必对得上。

结构一改这些路径就集体过期，独立站架构怎么搭才不让爬虫找不到产品页是更上游的决定。

实际数字是：模板常见路径165条，404率25.5%；其它自定义路径193条，404率24.4%。基本没有差别。

这说明过期不是模板的问题，是时间的问题。自己写的规则一样会过期，而且因为是自己写的，你更不会怀疑它。

那182条测不出来的，本身就是一个发现

358条里有一半（50.8%）被边缘防护挡住了，返回403、406或422。这个比例高得出人意料，也顺带说明了一件很实际的事：你想验证自己的规则对不对，第一道障碍可能是自家的防护把验证请求也当成了可疑流量。

自家防护的口子在哪要自己清楚，端口放行与云安全组怎么配是最基础的一层。

从外面测不通还有很多别的成因，从DNS、线路到CDN的网络层排障能帮你分清卡在哪一层。

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

这不是无解的。自查的时候直接在服务器上对本机发请求，或者带上内网来源和白名单UA，就能绕开边缘层。要点在于意识到这一层存在——不然你会以为自己的地址全都好着，实际上你测到的只是防护的反应，没测到应用的反应。这跟前面那个分母算错的返工是同一类问题：先确认自己量的是什么。

自己的站怎么把这一遍跑完

同样的检查在自己站上跑一遍不需要写程序，一段命令行就够。思路是从通配组里取出具体路径，逐条请求，把状态码打出来：

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

这种检查适合挂成定时任务，用cron把备份、sitemap、缓存这些活自动化有一份可直接改的脚本集。

curl -s https://example.com/robots.txt |
awk 'BEGIN{IGNORECASE=1}
     /^user-agent:[[:space:]]*\*/{f=1;next}
     /^user-agent:/{f=0}
     f&&/^disallow:/{print $2}' |
grep -v '[*$?]' | grep '^/' | sort -u |
while read p; do
  c=$(curl -s -o /dev/null -w '%{http_code}' -L "https://example.com$p")
  echo "$c $p"
done | sort

输出按状态码排好序，404那一段就是要处理的清单。几点提醒：把域名换成自己的；路径很多的话先取前二三十条看看趋势；如果大批返回403或者406，说明请求被自家边缘防护挡了，换到服务器上把域名改成127.0.0.1并带上Host头再跑。

跑完之后不用急着删。先把404的那批路径拿去问一个问题：这个目录当年是干什么的，现在那件事由哪个地址承担。答得出来就改成新地址，答不出来就是纯遗留，可以删。

这些死规则要不要清，代价在哪里

先说不用紧张的部分：挡一个不存在的地址，不浪费抓取预算，也不会带来收录问题。爬虫读到规则只是记下来，不会去试探这个地址存不存在。所以从性能和收录角度看，这些行的直接危害接近于零。

要让清理这件事持续下去得留痕，把变更做成日志的十三类信号讲的就是这套办法。

同样的决策在内容侧更常遇到，上千篇旧内容的留、改、并、删、转怎么定是一套可复用的判据。

代价在别的地方，而且是长期的。一份有一半路径已经失效的robots.txt，会让所有读它的人对它失去判断力。下次有人要加一条规则，他不敢删任何旧行——因为分不清哪些还有用；他也不会通读全文——因为读了也判断不了。于是文件只能往下追加，越长越不可读，越不可读越只能追加。

这份157个站的样本里，光通配组的Disallow就有5539条，平均每份35条。那些一眼看不到头的文件，基本都是这么长起来的。

平台默认模板，会替你写下没人读的行吗？

用建站平台的站主最关心这个问题：文件不是我写的，锅要不要我背。

把模板之外的部分单独审一遍更高效，从抓取到AI可见度的完整诊断框架可以拿来当清单。

平台自带、通用工具、专属应用各管一段，这三层怎么分工与选型能省掉不少重复投入。

67个站出自同一套平台模板

157份文件里，有67份带着同一套平台模板的特征——给广告爬虫单开分组、屏蔽购物车和结算路径这几个组合一起出现。占比42.7%，跟前一轮统计的41.4%基本吻合。

平台默认给的东西不止这一个文件，128种标记类型里该怎么挑也是接管前要弄清的。

这套模板在别的地方也有默认判断，集合页分页的索引判断与canonical设置是最常需要接管的一处。

这个比例值得记一下：接近一半的独立站，robots.txt的第一版不是人写的。

模板本身是干净的，有问题的行是后来加的

然后看这67个站里有多少存在前面说的那些无效行：27个，占40.3%。剩下40个一条都没有。

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

人后加的那一层最容易和默认打架，插件与主题各输出一套标记怎么归一是同一种病。

这个分布本身就是答案。如果模板自带无效指令，那67个站应该全中，因为它们用的是同一套生成逻辑。实际只中了四成，说明那些行不是模板给的，是站主或者服务商后来自己加进去的。

换句话说，模板把基础写对了，然后有人在上面加了一层自己也不确定有没有用的东西。这个顺序很关键——它意味着排查的时候，应该重点看模板之外的那几行，那才是人写的部分。

模板不带Crawl-delay，但加它的人特别多

顺着这条线索还能看出加的是什么。写了Crawl-delay的47个站里，绝大多数点名的对象是Pinterest、AhrefsBot、AhrefsSiteAudit、MJ12bot这四个，被点名次数分别是27、25、25、24次。

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

这四个对象凑在一起出现，几乎可以断定来自同一份流传很广的清单。有人整理过一份限速名单，包含这几个吃流量的第三方爬虫，后来被大量转载和照抄。抄的人各自把它贴进了自己的文件里。

这批行有意思的地方在于它一半有效一半无效：AhrefsBot和MJ12bot确实会读，Pinterest那27个站则是彻底白写。同一份清单里既有真收件人也有假收件人，抄的人无法分辨——因为清单本身不写这个信息。

接管模板之前，先想清楚接管的是什么

要不要把平台生成的robots.txt改成自己维护的版本，判断标准只有一条：你有没有一个明确的、模板满足不了的需求。

如果是自建程序，责任边界从一开始就在自己这边，从主机、插件到核心指标的完整做法可以对照排期。

接管的范围有时比预想的大得多，这套基建换了架构就得自己重搭是个提前的提醒。

有需求就接管，接管之后这份文件的全部内容都归你负责，包括平台后续更新的那部分你再也拿不到了。没需求就别动，尤其别为了看起来更专业而加几行不确定的规则——本文这56个站的146条无效行，绝大多数就是这么来的。

刚发明的那几个字段，眼下有人在读吗？

数据里还有一批行，方向和前面完全相反：它们不是被弃用的老字段，是刚出生的新字段。

要判断这些新约定值不值得投入，先把爬虫的真实抓取偏好逆出来比看提案更实在。

同一家还在推另一套给机器读的交付方式，用内容协商给AI直接送Markdown是更进一步的做法。

5个站写了三种全新写法

157份文件里，出现了三个此前从没在这批样本里见过的字段名，一共5个站在用：

整体该怎么排先后，从AI搜索到结构化数据的实施顺序有一版可执行的策略。

这些表态最终服务的是同一个目标，让AI爬虫抓得到、读得懂、引得出是技术端的落地清单。

Content-Signal的来路，以及承诺读它的是谁

Content-Signal不是某个搜索引擎提出来的，是一家边缘网络服务商在2025年发起的一套内容信号约定。核心想法是把用途拆开表态：允许被搜索索引，不代表允许被拿去训练模型，也不代表允许在AI回答里被当作即时输入。

有时候替你做决定的是主机商，托管主机可能正悄悄拦掉AI爬虫而监控一声不响。

这个拆分回应的是一个真实痛点。老的robots.txt只有允许抓和不允许抓两种表态，而站主真正想说的是可以抓但别拿去训练——这句话在旧语法里没法表达。

问题在收件人。这套约定的推动方能替自家网络上的站点自动加上这一行，但它没法替任何AI公司承诺会读。目前明确表态会尊重的只有少数几家，大多数抓取方要么没回应，要么只在自己的文档里另立一套控制方式。

Llms和Llm-Policy：同一个想法的两种拼法

另外三个站写的是指向llms.txt的引导行。llms.txt本身是一份民间提案，想法是给站点准备一份专供大语言模型阅读的精简说明文档，把最重要的信息按机器友好的方式列清楚。

新写法要不要跟，得看它能不能带来引用，3000条数据揭开的引用认知差可以当参照。

提案有一定影响力，但两件事都没定：一是没有任何主流厂商公开承诺会去读这份文件；二是连字段该怎么拼都没统一——这三个站分别写了Llms和Llm-Policy两种，路径也分别放在根目录和well-known目录下。

三个站，两个字段名，两个路径位置。这种分歧本身就说明它还处在很早的阶段。

那份被指向的文件里，通常写着什么

顺着这三个站给的地址看过去，llms.txt的内容结构大体是统一的：开头一行站点名称，接一段这个站是干什么的说明，然后按主题分成几个区块，每个区块下面列出若干个地址，每个地址后面跟一句这是什么的解释。整份文件用最朴素的标记语法写，不含样式和脚本。

真正影响被引用的还是内容本身的组织方式，七种更容易被引用的结构有实测对比。

给机器准备一份精简说明这个思路，帮助中心怎么做索引控制与AI引用早就在实践了。

它和sitemap的分工可以这样理解：sitemap回答的是我有哪些地址，追求全量和机器可解析；这份文件回答的是我最重要的内容是哪些、各自讲什么，追求的是让读它的模型少走弯路。前者是索引，后者更像一份导览。

需要说清的是，目前没有任何主流抓取方公开承诺会去读它。有些站点观察到AI相关的抓取器请求过这个路径，但请求过不等于会按它行事，更不等于会持续这么做。

如果决定做一份，成本该控制在哪儿

建议是可以做，但把它当一次性投入，不要变成需要长期维护的第二套内容体系。

维护成本这件事要提前算，内容新鲜度的五条实战法则说明了哪些内容值得持续更新。

与其多做一份文件，不如先提高事实密度，提升引用率的七个动作投入产出更清楚。

具体说：内容只列真正稳定的东西——品牌介绍、主要品类入口、政策条款、常见问题这类一年不会大改的；每条说明写一句话，不要写成营销文案；不要把商品列表放进去，那种东西一更新这份文件就过期了。做完之后在自己的排期里放一个半年后的复核提醒，到时候看看有没有厂商真的开始读它，再决定是加投入还是删掉。

反过来说，如果你现在的精力还不够把页面本身的结构化数据和正文可读性做扎实，那就别急着做这一份。读得到你正文的抓取方是确定存在的，读这份文件的还不确定存在——投入的顺序不该反。

新字段和死字段的失效方式，一模一样

把这三行新字段和前面那些老字段并排放着看，会发现一个挺有意思的对称：它们失效的方式完全相同。

要判断某个标记的成色，看它在知识图谱里怎么被消费比看文档更直接。

有些标记提出来很久也没等到广泛支持，用两个链接类标记提升内链效果就是这种处境。

都是语法正确，都不会报错，都不会被工具提示，都得靠去查对方的文档才能知道有没有人读。唯一的区别是时间方向——老字段的收件人已经走了，新字段的收件人还没到。

这个对称给出了一条通用判据，比记住哪些字段作废了更耐用：不要问这个字段是不是有效的，要问现在有谁承诺会读它，以及在哪儿能查到这个承诺。能查到就写，查不到就当它是一个心愿，别当成一道防线。

那到底该不该写

该写，但要清楚写的是什么。

真正决定能不能进候选池的是技术侧，突破AI候选池的五步技术优化是更该先做的。

表态之外还有更要紧的准备，从被看见到被AI推荐的三层框架列了六步行动。

写这几行的成本几乎为零，多几个字节而已，不会有任何副作用。它的收益也是真的：一旦哪天某家厂商开始读，你的表态已经在那儿了，不需要临时补。这跟提前把话说清楚是一个道理，成本低、时机不吃亏。

不能做的是把它当成已经生效的控制手段。如果你的真实需求是不想让内容进训练集，那么在今天这个时点，能起作用的仍然是老办法——在robots.txt里针对各家公开的训练爬虫令牌明确写Disallow，加上服务器层的访问控制。新字段是表态，老办法才是拦截。两件事不能互相替代。

robots.txt测试工具为什么查不出这些行？

看到这里可能会有个疑问：这么多现成的检测工具，怎么一个都没发现？

每类工具的能力边界都不一样，五大类工具各自能回答什么可以拿来配自己的组合。

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

工具校验的是语法，不是收件人

把常见的几类工具过一遍就明白了。搜索平台自带的robots.txt测试器，做的事是模拟自家爬虫对某个地址的匹配结果，回答的是这个地址我抓不抓；各类在线校验器，检查字段拼写、路径格式、通配符用法；SEO插件的体检模块，检查文件能不能取到、有没有意外屏蔽重要目录。

工具盲区这件事各处都有，六个工具盲区里的捡漏方法是同一种思路的应用。

语法层的检查还是该做，页面骨架的六个维度体检能揪出标题层级和图片说明的短板。

这三类工具都没有回答本文这个问题的能力。因为一行指令的收件人还在不在，不是文件里的信息，它在别人的文档里、在别人的更新公告里、在你自己的服务器日志里。工具读不到这些。

还有一层更微妙的：搜索平台自带的测试器只回答自家的行为。你在Google的工具里测，它当然不会告诉你写给bingbot的那一行有没有效——那不是它的事。

几个在线校验器的结论为什么会互相矛盾

还有个现象经常让人困惑：同一份文件丢进三个在线校验器，得到三种说法。有的说某一行无效，有的一句话不说，有的甚至报语法错误。

原因不复杂。这些工具各自实现了一套解析逻辑，而它们参照的对象不一样——有的对齐标准文档，只认三个字段，其余全标成不支持；有的对齐某一家搜索引擎的实际行为；还有的对齐一份很多年前的字段清单，把Crawl-delay、Host一律当合法字段放过。三套参照物，三种结论。

所以工具报了不支持，不等于这一行对所有人都无效；工具没报错，更不等于它有效。要判断的还是那个老问题——你在意的那个收件人怎么读。工具能替你查语法，替不了你查收件人。

实操上有个折中办法：拿两类工具交叉看。一类是官方出的测试器，它代表这一家的真实行为；一类是对齐标准的校验器，它能告诉你哪些字段不在规范里。两边的差集，基本就是需要人工判断的部分。

平台后台的编辑器同理，甚至更少

建站平台后台那个robots编辑框，通常只做两件事：语法不合法时不让保存，覆盖平台关键规则时给个警告。它不会告诉你新加的那个爬虫名字是不是真实存在的令牌，也不会告诉你Crawl-delay对你点名的对象有没有意义。

后台的告警也需要分级看，三平台后台告警怎么分级诊断给了一套处理顺序。

这也解释了为什么无效行在用平台的站点上一样常见——保存按钮不报错，就等于通过了。

唯一能证明生效的证据，在自己的日志里

要确认一条规则有没有起作用，能拿到的最硬证据只有一个地方：服务器访问日志。日志能回答两个问题——这个爬虫来没来过，以及它有没有去请求你禁止的路径。

想确认某个AI爬虫有没有来过，从日志一步步挖真相是唯一可靠的路子。

日志读起来枯燥但信息量最大，怎么从日志里读懂抓取与预算浪费有一步步的示例。

这两个答案合起来才是完整的：如果它来了但不碰禁止的路径，说明规则被执行了；如果它来了还照样请求，说明规则对它无效或者它不遵守；如果它压根没来过，那么无论规则写成什么样都不产生任何差别。

第三种情况在本文的样本里占比高得惊人：同一批文件里点名的爬虫，有相当大一部分从来没在真实日志里出现过。

日志里怎么查一条规则到底有没有被执行

具体做法比想象的简单。先确定要查的对象名字，然后在访问日志里筛出它的请求，看两件事：来了几次，都请求了哪些路径。

日志留多久决定了你能问多远的问题，日志怎么管才不爆盘又查得到是配套要先做的事。

前提是日志本身记全了，访问日志怎么配才查得清问题包括CDN后面的真实来源地址。

grep -i 'bingbot' /www/wwwlogs/example.com.log |
awk '{print $7}' | sort | uniq -c | sort -rn | head -30

把输出里的路径和自己robots.txt里的禁止清单对一下，三种结果对应三种结论：路径里完全不出现被禁的目录，规则被执行了；出现了，说明这个对象不读或者不遵守你的规则；这个名字在日志里一条都搜不到，那么它那一整组规则写成什么样都不产生任何差别。

有两个坑要留意。一是User-Agent可以随便伪造，看到名字不等于真是它，重要判断要反查来源地址是不是属于对方公布的地址段。二是日志通常有保留期，短的只留七天，判断某个对象来没来过之前先确认自己的窗口有多长——用三天的日志得出它从来不来的结论，是不成立的。

用差分法验证一行规则到底有没有被采纳

还有一个办法比日志更快，而且能在上线之前就用上：拿官方解析器做差分。

把差分结果存下来就成了基线，怎么搭一套能在掉量前报警的监控讲的就是这套积累。

差分这个思路在别处一样好用，对比爬虫和用户看到的页面也是靠两次结果相减。

Google把自己用了二十年的robots.txt解析器开源了，编译出来是个命令行程序，喂给它三样东西——一份robots.txt、一个爬虫名、一个要测的地址——它输出这个地址允许还是不允许抓。这是唯一能拿到官方实现判定结果的通道。

关键用法不是单次判定，是差分。步骤只有三步：

第一步，准备一份待测地址清单，覆盖你关心的各类页面，几十个就够。第二步，用原始的robots.txt跑一遍，把每个地址的判定结果存下来。第三步，把你怀疑的那一行删掉，再跑一遍同一份清单，比较两次结果。

判断规则很简单：如果删掉那一行之后所有判定结果完全没变，那这一行对Google就是不起作用的。不需要读文档，不需要猜测，也不受任何人说法的影响——官方实现自己给出了答案。

把这个方法用在本文那些字段上，结果是可预期的：删掉Crawl-delay、Noindex、Host这三种行，判定结果一个都不会变。这不是推测，是标准里那条未识别字段必须忽略的规定所决定的必然结果。反过来，删掉一条Disallow或者一条Allow，一定会有地址的判定发生翻转。

这个办法有它的边界，得说清楚：它只能回答Google怎么读，回答不了Bing和其它爬虫怎么读，因为别家没有开源自己的实现。所以完整的验证还是要分两半——Google那一半用解析器差分，其它爬虫那一半只能靠日志和对方的文档。

这些行为什么能在一个团队里活五年？

技术上讲，删掉一行没人读的指令是几秒钟的事。可实际上它们能待很久，这背后是组织问题不是技术问题。

只进不出这件事在工具栈上更明显，12个站样本里的冗余与八步瘦身是同一个治理思路。

这类活最后往往压在一两个人身上，这一行的慢性透支比多数人以为的严重附了一套自查办法。

这个文件通常没有明确的负责人

问一个独立站团队谁负责robots.txt，答案往往要停顿一下。它躺在网站根目录里，改动方式是提交一次代码或者在后台点一下保存，涉及的知识横跨抓取、索引、服务端配置和内容策略。

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

结果是三方都能改，三方都不认领。前端觉得这是SEO的事，运维觉得这是内容策略的事，做SEO的人经常没有直接改文件的权限，得提需求。一个谁都能改、谁都不负责的文件，最自然的状态就是只进不出。

三个角色看同一份文件，看到的东西不一样

更微妙的是三方的判断依据不同。运维看到一行Crawl-delay，第一反应是这跟服务器负载有关，不敢动；前端看到一个陌生的爬虫分组，觉得应该是有人特意加的，不敢动；做SEO的人看到那些路径，认出是老结构留下的，但他不确定删掉之后会不会影响别的东西，于是只在需求单里写建议清理，然后这条建议排到了下个季度。

人力怎么分也影响谁来管这类文件，内容、技术、外链三类分工与配比有几种现成结构。

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

保哥前年帮一个跨境3C品牌做技术审查，那份robots.txt里有一行给某个不存在的爬虫令牌写的全站禁抓。追下去发现是四年前一次安全事件之后加的，加的人已经离职，工单里只留了一句按安全建议处理。这行字之所以能活四年，不是因为有人认为它有用，是因为没有人能证明它没用。

只增不删，在个体层面是理性的

换个角度看，每一个不敢删的人都做出了对自己最优的选择。删掉一行没人读的规则，收益是零——文件干净一点，没有任何指标会变好；风险不是零——万一它其实有用，出了问题这笔账算在你头上。

排序的依据最好来自实测，500个站实测排出来的优先级比凭经验准。

要打破这个循环得先排出优先级，三类站点各自的高回报修复项可以直接借。

零收益对上小概率大损失，理性选择当然是别碰。这个结构不改变，光靠提醒大家定期清理是没有用的。

把风险从判断改成记录

能打破这个循环的做法，是把删除的风险从个人判断变成集体记录。具体就是前面提到的注释法：任何非常规字段和专属分组上面，必须有一行注释说明依据和确认日期。

内容侧也是靠同一招把责任落到流程上，内容运营与SEO协作的七个动作点有可抄的表格。

这条规矩一旦立起来，文件里的行就分成了两类——有依据的和无依据的。删掉一行无依据的规则不再需要勇气，因为它不符合团队自己定的规矩，责任从个人转移到了流程。

接手一份陌生的robots.txt，头五分钟看什么

换个场景。假设你刚接手一个站，打开robots.txt看到七十多行，完全不知道来路。按什么顺序读最快？

先数分组，不看规则。有几个User-agent组、每组点名了谁，这决定了这份文件的复杂度。只有一个通配组的文件，通常是模板默认状态，基本不用担心；分组超过五个的，说明有人认真管过，也说明踩坑的可能性更高。

然后比条数。通配组的Disallow有多少条，每个专属组有多少条，两边一减。哪个专属组明显少，就把它的路径差集列出来——那些是对这个爬虫放开的地址。

接着挑异常字段。把不是User-agent、Disallow、Allow、Sitemap的行全都拎出来，一行一个地问收件人是谁。本文那9种字段的表可以直接当对照表用。

最后抽路径。挑三条具体路径请求一下，看还在不在。三条里两条是404，就把通读整个文件排进日程。

四步下来五到十分钟，你对这份文件的判断已经比大多数长期维护它的人清楚了。这不是因为方法高明，而是因为绝大多数人从来没有系统地读过它——他们只是一次又一次地往末尾追加。

这条规矩落地时会遇到什么

实际推行的时候会碰到两个具体阻力，提前知道能省不少来回。

责任怎么划清最终要落到文字上，达标定义与违约责任怎么写有几个真实纠纷案例。

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

第一个是存量怎么办。文件里已经有几十行没注释的规则，要求一次性补齐注释，等于要求有人把每一行的来历都考古一遍，这个任务分不下去。可行的做法是只对增量立规矩：从今天起新增的行必须带注释，老行不动。等下一次有人因为别的原因要改到某个区块时，顺手把那个区块的注释补上。半年下来文件会自然地分成有注释的新区和无注释的旧区，旧区越来越小。

第二个是注释会不会泄露信息。robots.txt是任何人都能读的公开文件，注释里当然不能写内部系统名、人名、工单号这类东西。写法上有个简单原则：只写判断依据和日期，不写内部上下文。写某家文档说明支持这个字段，不写某某在某个工单里要求加的。前者对外人无意义，对自己人足够；后者反过来。

还有个额外好处容易被忽略：这些注释行会被所有读robots.txt的爬虫忽略，不影响任何解析结果。井号开头的行在标准里就是注释，各家实现一致跳过。所以这件事的技术风险是零，唯一的成本是打字。

这个办法对付前面讲的新字段同样好用。你今年写下Content-Signal，注释里写清是哪家的提案、当时有谁承诺读、什么时候该回头复核，那么两年后无论这套约定是普及了还是消失了，接手的人都能判断该留还是该删。

五分钟怎么把自己文件里没人读的行找出来？

最后给一套能立刻做完的动作，不需要工具，一个文本编辑器加一个终端就够。

第一步：把字段名列出来数一遍

打开自己的robots.txt，把所有冒号左边的词提取出来去重。正常结果应该只有4到5种：User-agent、Disallow、Allow、Sitemap，可能还有一个Crawl-delay。

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

出现第六种就停下来查。本文157个站的样本里，全部字段名去重后只有9种，多出来的那4种全部属于本文讨论的对象。这一步花不了一分钟，命中率却相当高。

第二步：给每个字段和每个爬虫名写上收件人

接着做一份两列的小表：左边是文件里出现的每一个字段和每一个爬虫名字，右边写谁读它，以及这个说法你在哪儿看到的。

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

每个对象的硬限制也值得记在同一张表里，抓取体积上限的实测拆解给了具体数值。

右边填不出来的，就是要处理的行。注意这里要填的是来源，不是印象——凭印象填等于没填。查不到官方说明的爬虫令牌，通常意味着这个令牌是编的，或者早就改名了。

第三步：抽三条具体路径实际请求一下

从Disallow里挑三条不带通配符的具体路径，直接在浏览器或者用命令行请求。看返回什么。

返回200也不代表内容在里面，抓取和渲染分几步、内容在哪一步丢需要另一套检查。

请求方法选错会得出反向结论，用HEAD查说没配缓存头，换成GET那五个头全在就是这么来的。

如果三条里有两条是404，那么这份文件已经和站点的实际结构脱节了，值得安排一次通读。要注意从外部请求可能被自家防护挡住，出现403、406、422这类状态码时，改成在服务器上对本机请求。

第四步：把判断结果写成注释留在文件里

这一步最容易被跳过，但它决定了这次排查有没有长期价值。

判断依据最好和证据放在一起，把日志收成结构化可检索的形式让复核变得可行。

robots.txt支持用井号写注释。在每个非常规字段和每个专属分组上面加一行注释，写清楚三件事：为什么写它、谁会读它、什么时候确认过。像这样：

# 2026-08 确认：AhrefsBot 官方文档说明会读 Crawl-delay
User-agent: AhrefsBot
Crawl-delay: 10

一行注释的好处是，下一个人打开这个文件的时候，能立刻分清哪些行有依据、哪些行来路不明。少了这行，两年之后连你自己都会犹豫要不要删。

完整的判断顺序

把整篇的判断压成一条链，遇到任何一行不确定的指令都可以照着走：

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

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

先问这一行的收件人是谁——是所有爬虫，还是某一个具体的爬虫。再问这个收件人有没有公开承诺读这个字段，能不能找到那份文档或公告。找不到就当它无效。找到了，第三问是我这一行写的位置，对方按分组匹配规则能不能看到它。最后问，就算它能看到、也愿意执行，我想挡的那个东西现在还在不在。

四问全过，这行才是真正在起作用的规则。四问里任何一环断掉，它就只是一行看起来很负责的字。

这套判断能迁移到别的地方

最后跳出robots.txt说一句。这四问之所以有用，不是因为它跟robots.txt有什么特殊关系，而是因为robots.txt恰好是最典型的那类配置：你写的东西，执行权在别人手里。

链接属性同样是写给别人看的声明，这几个标记到底还传不传权重各家的处理并不一致。

缓存头也是各家客户端各读一部分，怎么配才让回头客秒开又不出改了不更新的事故讲了取舍。

邮件那一侧有个几乎一样的例子，一键退订必须写两层，少一层整个域名就被限流也是收件人各认一套。

符合这个特征的地方还有不少。页面里的结构化数据，各家搜索引擎认的字段不一样；HTTP响应头里的一堆声明，读它的客户端各不相同，有些客户端早就不存在了；给邮件服务商看的域名策略记录，各家的执行严格程度差着级别；Cookie上的各种属性，浏览器之间也不完全对齐。

这些场景共享同一个特点：写下去不会报错，生效与否取决于对面那个你看不到的实现。所以判断方式也共享同一套——先问收件人是谁，再问能不能查到他的承诺，再问自己写的位置对方看不看得见，最后问要处理的那个对象还在不在。

这套问法还有个附带好处：它能挡住一类很常见的时间浪费——为一个根本没有收件人的声明反复调参数。把Crawl-delay从10改成5再改成2，把某个字段换三种拼法试一遍，都属于这一类。收件人不在的时候，参数怎么调都不会有反馈，而没有反馈的调整可以无限进行下去，还会让人觉得自己一直在优化。先确认对面有人，再谈调什么，顺序不能颠倒。

回到开头那句话。一条规则失效的时候，它不会告诉你。所以这件事只能反过来做：不等它告诉你，你主动去问收件人还在不在。这个动作花不了多少时间，麻烦的地方只在于，得先想起来该问。

常见问题解答

Crawl-delay现在到底还能不能写？

能写，但要写清楚给谁。Google明确不读，写给它等于没写；Bing会读，它后台还另有抓取控制面板；AhrefsBot、MJ12bot这类第三方工具爬虫会读，写给它们是有效的。关键是位置——robots.txt的分组不继承，只写在通配组里而站内又给对方单开过分组，对方就读不到。157个站里写了Crawl-delay的有47个，能被bingbot真正读到的只有13个，占27.7%。想压Google的抓取频率，去Search Console调抓取速率设置，或者临时用503配合Retry-After。

怎么判断某个字段今天还有没有人读？

只认一种证据：能找到出处的公开说明。具体做一张两列表，左边写字段名或爬虫令牌，右边写谁承诺读它、这个说法在哪儿看到的。右边填不出来源的就当它无效。这里要防的是凭印象填——很多字段给人的感觉是通用的，实际只有某一家读，比如Host只有Yandex读过，而Yandex后来也改用重定向判断了。补充一个更硬的办法：Google的robots.txt解析器是开源的，拿自己的文件跑一遍，能直接看到它认了哪些行、忽略了哪些行。

robots.txt里的Noindex删掉，页面会不会又被收录？

不会，因为它本来就没在起作用。Google在2019年9月1日之后就不再读robots.txt里的Noindex，这一行在那之后写与不写没有区别。但删之前要确认一件事：你原本想让这些页面不收录的目标，现在有没有别的机制在承担。如果没有，删掉这行的同时要补上真正有效的手段——页面头部的meta robots标签，或者服务端按路径下发X-Robots-Tag响应头。注意顺序：必须先允许抓取，爬虫才能读到不收录的指示，先在robots.txt里禁抓会让它永远读不到。

Host这一行删了，对Yandex有影响吗？

基本没有。Yandex早已改成按301重定向和站长后台设置来判断主镜像域名，Host指令不再是必要条件。判断自己这行是不是有意为之，有个很快的办法：在文件里搜Yandex这个词，看它在别处出现过没有。本文这10个写了Host的站里，只有1个给Yandex的爬虫单开过分组，其余9个全文只在这一行提到过它——那基本就是从示例里抄来的。删之前顺手确认www与非www之间的301是通的、页面canonical写的是主域名，这两件事在位，Host有没有都一样。

Disallow了一个已经返回404的路径，需要清理吗？

不急，但值得记账。挡一个不存在的地址不浪费抓取预算，也不影响收录，直接危害接近于零。真正的代价是可读性：本文抽样的358条具体路径里，能判定存在性的176条有53.4%指向不存在的地址，这种文件会让接手的人失去判断力——分不清哪些行还有用，于是谁都不敢删，只能往后追加，越追加越没法读。建议的做法是给每条留下来的规则加一行注释，写清依据和确认日期，让删除变成一件有据可依的事而不是一次冒险。

Content-Signal和llms.txt这类新写法，现在值得写吗？

值得写，但别把它当拦截手段。写的成本几乎为零，一旦哪天有厂商开始读，你的表态已经在那儿了。问题是目前没有主流抓取方公开承诺会读llms.txt，Content-Signal也只有少数几家表态尊重。所以如果真实需求是不让内容进训练集，眼下能起作用的仍然是老办法：针对各家公开的训练爬虫令牌明确写Disallow，再加服务器层的访问控制。新写法是表态，老办法才是拦截，两件事不能互相替代。写的时候顺手加一行注释，标上是哪家的提案、什么时候该回头复核。

把后台入口写进Disallow，到底算不算加固？

不算，而且方向是反的。robots.txt是任何人都能读的公开文件，写进去的路径等于挂了一份清单：守规矩的爬虫会绕开，不守规矩的正好照着找。真正需要保护的地址应该走访问控制——登录校验、来源限制、地址段白名单，这些由自己的服务器执行，不需要对方配合。robots.txt适合写的是那些暴露了也无所谓、只是不想浪费抓取预算的路径，比如筛选参数、站内搜索结果页、加购地址。本文抽样里那几个把管理后台写进Disallow的站还多踩了一层：那个地址在它们自己域名下压根不存在，规则本身也是空转。

抽样只查了通配组，各个爬虫的专属分组要不要也过一遍？

要，而且专属组比通配组更值得看，因为它是人写的那部分。检查重点有两个：一是组名对不对，也就是那个爬虫令牌今天还存不存在、有没有改名；二是组里的规则条数，跟通配组比一比差多少——分组不继承，专属组少写的那些路径对这个爬虫就是放开的。本文的抽样之所以只取通配组，是因为专属组多由平台模板生成、路径高度重复，混进来会把比例带偏。真要动手排查，顺序应该反过来：先看专属组，再看通配组。

平台生成的robots.txt要不要改成自己维护？

看有没有明确的、模板满足不了的需求。本文157份文件里有67份出自同一套平台模板，这67个里只有27个存在无效指令——说明那些行不是模板给的，是后来有人加的。模板把基础部分写得不差。接管的代价是从此全部内容归你负责，平台后续更新的部分你也拿不到了。所以没有具体需求就别动，尤其别为了显得专业而加几行自己也不确定的规则，本文统计到的146条无效行，绝大多数就是这么进来的。

权威参考资料