robots规则的星号对AdsBot无效，广告落地页照抓

摘要：你在robots.txt里写下的那行星号，管不到决定你广告能不能投的那几个爬虫。AdsBot-Google、AdsBot-Google-Mobile、Mediapartners-Google和APIs-Google这四个，官方文档里逐个写着同一句话——全局用户代理会被忽略。这事两个方向都咬人：你以为拦住了其实没拦住；你以为放行了，其实某条针对目录的规则把广告落地页一起挡住了，而报错不出现在你查robots的地方。更麻烦的是名字本身：日志里看得见的和robots里写得下的不是同一套字典。

你写的那行Disallow，到底管住了谁？

这个问题看起来有标准答案：robots.txt里写了User-agent冒号星号，下面跟一行Disallow，那就是对所有爬虫生效。绝大多数人是这么理解的，多数场合下这么理解也不会出事。

但官方文档里有四个例外

谷歌把自己的抓取客户端分成了三份清单，其中一份叫做特例爬虫。这份清单里的条目，每一个下面都跟着同一句话：全局用户代理会被忽略。

要把这一堆名字先认全，爬虫识别器与120种UA分类加真假Googlebot验证那篇把常见的用户代理分了类，可以当一份速查表用。

前四个是“只认自己的名字”，最后一个是“谁的名字都不认”。而这五个里有三个直接决定你的广告业务能不能跑。

为什么会有这种例外

官方给的理由写在这份清单的开头：特例爬虫服务于特定的谷歌产品，这些产品与被抓取的站点之间存在关于抓取过程的约定。文档举的例子正是AdsBot——它在广告发布者许可的前提下忽略全局用户代理。

谷歌还有一整类抓取器压根不看robots.txt，这次改名只是把它推到了台前那篇讲的就是第三份清单那一类。

翻译成人话：你开了广告账户、提交了落地页，这个动作本身就构成了让AdsBot来检查这一页的许可。它不是在无视你的意愿，它是在执行你另一处已经表达过的意愿。

这个设计是有道理的

设想一下反过来的情况：如果AdsBot听全局规则，那么任何一个为了省抓取预算而写了大范围Disallow的站，都会在自己不知情的时候让所有广告落地页变成不可检查的状态。

为省抓取预算写大范围Disallow是常见做法，分面导航产生的海量URL怎么治理那篇讲的正是这类需求。

而广告落地页不可检查的后果不是“少收录一个页面”，是广告直接投不出去。把这个开关交给一条为搜索抓取设计的规则来控制，风险显然更大。

但它制造了一个盲区

你在robots.txt里做的判断，覆盖范围小于你以为的范围；而覆盖之外那几个，恰好是后果最直接的那几个。

同一个形状的盲区在网页那边也有，Googlebot只读前2MB而超出的部分等于不存在那篇量了46个电商站。

这个盲区在两个方向上都会出事。想拦的时候拦不住，想放的时候可能忘了放。后面会分别讲这两种。

先说一个容易混淆的地方

特例爬虫忽略的是全局用户代理那一组规则，不是忽略整个文件。如果你显式写了针对AdsBot-Google的规则组，它是听的。

robots.txt的语义细节比想象的多，网站突然从谷歌消失多半是robots.txt写废了那篇把机制讲得比较完整。

换句话说：它不是不受管，是只受专门针对它的管。这个区分很重要，因为它意味着你确实有办法控制这些爬虫，只是那个办法不是写星号。

三份清单各是什么

普通爬虫、特例爬虫、用户触发的抓取器。第一份是为搜索索引和产品抓取服务的，全部遵守robots.txt；第二份就是前面那几个；第三份是由用户的某个动作触发的抓取。

要弄清楚日志里那些UA各是谁，AI Agent抓取日志解码的8类UA实测那篇做过一份22周的访问账本。

三份清单的开头都写着同一句话：本清单并非穷尽，它只覆盖那些更可能出现在日志里、以及我们收到过提问的请求方。这句话值得记一下，它意味着你按清单做的白名单，天然是不完整的。

本文要处理的三件事

第一，把日志里能看见的名字和robots.txt里能写的名字这两套字典对齐一次。第二，讲清楚拦错了在广告侧会表现成什么样，以及为什么那个报错不会指向robots。第三，反向验证那一层为什么会把AdsBot判成假冒。

日志里那个自称Googlebot的请求不一定真是它，每5次Googlebot抓取就有1次IP不属于谷歌那篇实测过反向验证。

贯穿全文的判据只有一句：一条规则的作用范围，取决于执行它的那个系统怎么理解它，不取决于你写它时候想的是什么。

这件事在两个方向上都会咬人

方向一是你想拦却拦不住。写了全站Disallow想临时下线，AdsBot照抓不误；给测试环境加了防爬，广告检查照样进得来。

拦与不拦的分寸最难拿捏，Nginx拦AI爬虫与限速怎么不误伤GoogleBot那篇给了具体的配置写法。

方向二更常见也更贵：你根本没打算拦它，但某条针对目录或者频率的规则顺手把它挡在了外面。这一种的特点是没有人做过“要不要拦AdsBot”这个决定，所以事后复盘的时候找不到任何一个可以追问的人。

没有决定者的失败

这是本文和前面两篇共同的形状。字节被截断的时候没有决定者，退订链接看不见的时候没有决定者，AdsBot被误伤的时候同样没有。

另一个没有决定者的失败在响应头那边，照着加固清单加的一行响应头把地图和支付按钮一起变成了摆设那篇讲的是同一种形状。

所有这类失败的共同前提是：造成它的那个动作，在做的时候看起来完全正确，而且在它自己的语境里确实是正确的。写白名单的人在防伪造，写Disallow的人在省预算，写限速的人在护服务器，三个人都对。

顺便把robots.txt这个文件本身的地位说清楚

它不是一道门，是一张告示。协议本身没有强制力，遵守与否取决于抓取方自己的选择，而正规的抓取方之所以遵守，是因为不遵守的名声代价太大。

防采集要靠另外一套东西，robots加UA加WAF三层选型框架那篇把三层各自能干什么讲清楚了。

所以用robots.txt来防采集从来都是无效的——真正想采你的人不看这个文件，甚至会专门去看这个文件来找出你不想被人看的目录。防采集要用防护规则和限速，那是另一套东西，而本文说的误伤恰恰发生在那一套里。

这个区分为什么重要

因为它决定了当你想拦某个东西的时候，该去哪一层动手。想表达意愿，写robots.txt；想真的拦住，用防护规则。

robots.txt能表达的意愿是有边界的，robots.txt挡不住AI训练的4条路那篇把这些边界摊开了。

两者的失败模式完全不同：robots.txt的失败是对方不听，防护规则的失败是误伤了不该拦的。而这两种失败在你排查的时候会互相干扰——你以为规则没生效，其实是它生效在了别处。

两套字典逐条摊开对齐一次

日志里出现的是用户代理字符串，robots.txt里写的是用户代理令牌。这两样东西看着像同一件事，实际上是两套独立维护的名字。

普通爬虫这一份

这一份就是普通爬虫清单，它把每个爬虫的用户代理、robots令牌和受影响的产品并排列了出来。

要拿这些字符串去实测自己的站，User-Agent生成器模拟Googlebot测站那篇讲了做法和那条改不动的反向验证。

这张表里有两处不对称

第一处：Googlebot News和Google-Extended在日志里没有自己的名字。前者用各种Googlebot的字符串抓，后者官方原文写的是“抓取由现有的谷歌用户代理字符串完成，robots.txt里那个令牌只用于控制”。

名字与能力对不上的情况不止这一处，接口和feed这类地址拿什么说自己不想被收录那篇讲的是另一种缺位。

第二处：有些爬虫认多个令牌，命中任何一个规则就适用。官方原话是你只需要匹配其中一个令牌，规则就会生效。所以写了Googlebot那一组，图片、视频、新闻和检查工具都跟着受管。

第一处不对称的后果

你翻遍日志也找不到Google-Extended，因为它从来不在那里出现。你能不能拒绝它，完全取决于你有没有在robots.txt里写下一个你从没见过的名字。

日志能回答的问题是有限的，AI爬虫到底有没有抓你的站那篇讲了日志分析能挖到哪一步、挖不到哪一步。

日志这条证据链在这里断了：它记录的是谁来过，而能被拒绝的身份和来过的身份不是同一套编号。

这跟很多人的工作方式正好冲突。正常的做法是先看日志、发现异常、再写规则；对这一类爬虫，这个顺序永远不会启动，因为第一步就没有输出。

第二处不对称的后果

它会让规则的实际覆盖面比你写的宽。写一条针对Googlebot的Disallow，你以为管的是网页抓取，实际上图片搜索、视频搜索、新闻和Search Console的检查工具全都跟着受影响。

一条规则的连带影响经常超出预期，那4张没露出来的商品图Googlebot也不会去翻那篇是另一个连带损失的例子。

这一条在做局部屏蔽时特别容易出事：屏蔽一个目录不让网页抓取，结果那个目录下的图片也从图片搜索里消失了。

特例爬虫那一份

前面已经列过，这里补三条细节。第一，它们从与普通爬虫不同的IP段来，官方分别发布了两个不同的地址清单文件。

robots.txt该怎么写才不踩坑，WordPress robots.txt 2026怎么写那篇讲了虚拟与物理文件的优先级和AI爬虫的拦放。

第二，它们的反向DNS掩码不一样。普通爬虫是crawl加四段IP再加googlebot.com，或者geo-crawl开头的地理版本；特例爬虫是rate-limited-proxy加四段IP再加google.com，里面根本不含googlebot这个词。

第三，退役清单里还有几个值得看一眼的，比如那个曾经服务安卓应用广告的AdsBot-Google-Mobile-Apps，它遵守AdsBot-Google的规则但忽略全局；还有Web Light，官方明写它忽略robots.txt的理由是“它只用于真人访客的显式浏览请求，而robots规则是用来阻止自动抓取请求的”。

最后那条理由值得单独记

robots.txt管的是自动抓取，不管人触发的取回。这条原则解释了第三份清单——用户触发的抓取器为什么单独成类。

人触发的抓取只会越来越多，AI浏览器之战打响搜索入口正在碎裂那篇讲的正是这个趋势。

所以判断一个抓取要不要听robots，判据不是它是不是程序发起的，是它背后有没有一个正在等结果的人。这个区分在AI工具大量代人访问网页的今天，只会越来越常被用到。

把两套字典对齐的实操办法

做一张三列表：日志里见过的用户代理、它对应的robots令牌、它影响哪个产品。第三列最重要，因为它决定了拦掉的代价是什么。

把一堆散落的检查项做成一份表是审计的基本功，企业网站SEO审计从抓取、内容到AI可见度那篇给了完整框架。

做完之后你会发现表里有几行的第一列是空的——那几行就是你永远不会从日志里发现、只能从文档里知道的。把这几行单独标出来，它们是这套体系里最容易被漏掉的部分。

为什么谷歌要维护两套名字

因为它们解决的是两个不同的问题。用户代理是HTTP协议里的一个字段，它的作用是让服务器知道对面是什么客户端；robots令牌是robots.txt协议里的标识符，它的作用是让规则能指向一组特定的抓取行为。

HTTP这一层的字段各有各的职责，X-Robots、缓存与Vary的响应头SEO机制那篇把它们的分工拆开了。

两者的粒度天然不同。一个用户代理字符串可能被多个产品共用，一个产品也可能用多个用户代理来抓不同类型的资源。硬要把两者做成一一对应，反而会让规则表达能力变差。

这个设计的代价落在谁身上

落在你身上。设计者拿到了表达能力，使用者拿到了一张需要对照着读的表。

设计者省的事最后都落在使用者身上，独立站CMS第一年SEO隐性失分排查那篇列的12项多半是这个性质。

而绝大多数人不会去读那张表，他们的工作方式是从日志倒推——看见谁来了，再决定要不要管。这个工作方式对九成的爬虫有效，对剩下那一成完全失效，而那一成恰好包含了最需要被明确表态的那几个。

顺带说说robots.txt本身的匹配规则

按RFC 9309的规定，用户代理的匹配是不区分大小写的前缀匹配，而且只会有一组规则生效——最具体的那一组。写了针对Googlebot-Image的组之后，Googlebot那一组对图片爬虫就不再生效了。

通配符的判定和你想的可能不一样，robots.txt生成器的预设别照抄那篇实测过通配符判定与规范打架的地方。

这一条经常被误解成规则会叠加。它不叠加，它是选一组。所以如果你给某个爬虫单独写了组，那一组里就必须包含所有你想对它生效的规则，不能指望通用组来兜底。

一个具体的例子

假设通用组里有五条Disallow，然后你为Googlebot-Image单独写了一组只放行某个目录。结果是图片爬虫完全不受那五条约束，因为它匹配到了更具体的那一组。

电商站到底该屏蔽哪些页面，这7类加Shopify实操那篇给了一份可以直接对照的清单。

想确认某个路径对某个令牌到底是允许还是拒绝，最硬的办法是拿谷歌开源的那个解析器跑一遍，它就是线上那套判定逻辑本身。这个坑造成的通常不是拦不住，是放得太开。而放得太开这件事在检查的时候很难被发现，因为你去测的往往是你想拦的那条路径对Googlebot生不生效，而不是对每一个令牌分别生效。

把这张对照表做出来要花多久

照着官方两份清单抄，一小时以内。真正花时间的是第三列——它影响哪个产品，这一列官方给了，但要翻译成你自己业务里的说法。

比如Storebot-Google影响的是“谷歌购物的所有界面”，翻译到你的业务里可能是“我们那批走购物广告的商品”；GoogleOther影响的是“不影响任何具体产品”，翻译过来是“不知道”。把不知道如实写成不知道，比写一个猜出来的答案有用。

这张表放在哪

建议直接放在robots.txt文件旁边，用注释写进去。理由是这个文件是唯一一个所有相关方都会打开的地方——运维改防护规则的时候会看，SEO调收录的时候会看，出问题排查的时候也会看。

把定期核对交给定时任务是最省心的，用cron把独立站运维自动化那篇给了完整脚本。

一份放在文档系统里的表，半年后没人找得到；一份写在配置文件注释里的表，任何一个来改这个文件的人都会被迫看到。

为什么AdsBot可以不听你的星号？

前面给了官方的理由，这一节把它拆开，因为理解这个逻辑之后你才知道哪些规则该写、哪些不该写。

约定这个词是关键

特例爬虫这份清单的定义句是：这些爬虫服务于特定的谷歌产品，被抓取的站点与该产品之间存在关于抓取过程的约定。

抓取这件事正在变成一种可以谈条件的关系，Cloudflare按次抓取是什么那篇讲的是把它明码标价的尝试。

约定这个词把它和普通抓取区分开了。普通抓取是单方面的：谷歌想收录你，你用robots.txt表达同意或者拒绝。特例抓取是双方面的：你先主动加入了某个产品，抓取是这个产品的组成部分。

三个产品各自的约定是什么

主动提交与被动收录是两条路，免费产品收录怎么做那篇讲了不投广告也能上购物的那条。

三行的共同点：第二列那个动作全都是你主动做的，而且做的时候你很清楚自己要什么。把这份许可再交给robots.txt确认一遍，是重复的，而且是有风险的重复。

那为什么Storebot-Google不在这份清单里

因为购物商品的收录不完全依赖你主动提交——谷歌也会从网页上发现商品。它更接近普通抓取，所以它遵守全局规则。

产品数据源到底归谁管是个老问题，这份被丢给投手的数据正决定你在自然搜索和AI购物里露不露脸那篇讲透了。

这一条对做购物广告的人是个重要区分：你的商品数据源提交给了Merchant Center，但Storebot-Google对你站点的抓取仍然受robots.txt管，包括那条星号规则。两者的许可来源不一样。

怎么显式控制这几个爬虫

写一个专门针对它的规则组。写法和普通爬虫完全一样，只是用户代理那一行要写它的令牌名。

写一条Disallow之前先想清楚代价，站内搜索URL该Disallow吗那篇比较了四种方案的后果。

要注意的是这么写等于把它彻底关掉，而关掉的后果是那个产品不工作。把AdsBot全站Disallow，等于所有广告落地页无法通过质量检查；把Mediapartners-Google关掉，等于AdSense只能投放不相关的广告。

什么情况下真的需要显式拦

保哥能想到的合理场景只有三种。第一，测试环境或者预发布环境被误配了广告，需要临时切断。第二，某个目录下有大量参数化的动态页，AdsBot的抓取造成了实际的服务器压力。第三，你已经停投了这条业务线，但历史配置还在。

有时候拦你的不是你自己，托管主机可能正悄悄拦AI爬虫那篇讲的是这种你没参与过的决定。

除此之外，绝大多数站点不该显式拦这几个。它们的抓取量通常很小，而拦掉的代价是直接的收入损失。

更常见的需求其实是限速不是拦截

如果问题是抓取压力，正确的做法是用crawl-delay之类的方式或者在服务器侧限速，而不是Disallow。这两者的区别在于前者延后，后者拒绝。

限速规则最怕把robots.txt自己限了，限速拒掉的第4个请求是robots.txt全站抓取会停12小时那篇量过这个后果。

顺带说一句：限速规则如果不小心把robots.txt本身也限了，后果比任何一条Disallow都严重，因为爬虫拿不到规则文件的时候会采取保守策略。这一条保哥在别处专门写过。

这套逻辑推广到别家

其他搜索引擎和广告平台也有各自的特例。判断办法是一样的：凡是你主动加入了某个产品、而那个产品需要访问你的页面才能工作的，它的抓取多半有一条独立的规则。

今天要打交道的抓取方比过去多得多，AI爬虫抓取量已超Googlebot 3.6倍那篇给了当前的构成。

所以每接入一个需要读你页面的产品，就该去查一遍它用什么身份来、听不听全局规则。这个动作应当写进接入检查里，而不是等出事之后再查。

把这条逻辑倒过来用

既然特例爬虫的许可来自你在别处做过的动作，那么撤销许可的正确位置也在别处——停投广告、撤掉AdSense代码、退订API推送。

广告侧的开关应该在广告后台，四步把Google Ads出价目标算到能赚钱那篇讲的是那一侧该怎么调。

在robots.txt里拦它，等于在一个不负责这件事的地方表达一个应该在另一个地方表达的意愿。它能生效，但它绕开了那个产品自己的关闭流程，而绕开的后果是两边的状态不一致。

状态不一致会怎样

广告账户里那条广告还是启用状态，落地页检查却一直失败；系统会持续重试、持续标记异常，而你在账户里看不出任何配置错误。

两个系统各写各的、状态对不上是常态，装了SEO插件却冒出两个canonical那篇是另一个例子。

这种情况保哥见过一次，是团队里有人为了做压测临时加了AdsBot的Disallow，压测结束忘了删。三周之后有人来问为什么这几条广告一直审核不过，而所有人翻的都是广告账户的设置。

临时改动的通病

robots.txt是个很容易被临时改的文件：它是纯文本、不需要发版、改完立刻生效、也不会有人审。这几个特性让它成了临时措施的首选，也让它成了遗留配置的重灾区。

临时方案变成长期配置这件事到处都是，那套AI自动化从第二周就开始走形那篇讲的是同一种腐化。

建议的做法是给每一条非常规规则加一行注释，写清楚是谁在什么时候为什么加的。注释在robots.txt里用井号开头，不影响解析，成本是零。

注释这个做法的真实收益

不是为了让别人看懂，是为了让三个月后的你敢删。一条没有注释的规则，谁都不敢动，因为不知道删了会怎样。

配置文件越长越没人敢动，Apache .htaccess SEO 6层综合治理那篇把一堆历史规则重新理了一遍。

结果就是这类文件只会越来越长，里面躺着一堆没人知道用途的行。而每一行都可能在某个你想不到的地方生效。

关于压测那件事的后续

那个团队后来给robots.txt加了一条流程：任何改动必须在提交信息里写明预计什么时候回滚，没有回滚时间的改动不许合并。

改动前后各查一遍是最朴素的防线，改版不掉SEO的完整防护清单那篇的检查项可以直接扩展。

这个规则的实际作用不是逼人按时回滚，是逼人在加规则的那一刻先想一遍这条到底是临时的还是长期的。很多遗留配置的成因就是这个问题当时没被问过。

拦错了会在哪个后台报错？

这一节讲后果，而且重点在“报错出现在哪里”——因为这决定了你要花多久才能找到原因。

四种典型的错法

配置文件语法检查通过不代表行为正确，Nginx每次reload都通过Googlebot每8次抓取却有1次撞在301上那篇是个典型。

四种里只有第一种能在robots.txt测试工具里被发现。后面三种都发生在robots之外的层，而你排查的时候第一反应一定是去查robots。

广告后台的话术不会提robots

落地页无法访问、目标网址无效、网站无法抓取——这几种表述里没有一个词会让你想到robots.txt或者WAF规则。它们描述的是现象，不是原因。

报错的表述和真实原因经常隔着好几层，GA4直接流量突然暴增的六类成因排查决策树那篇给了一套排除顺序。

而且这些提示通常出现在单条广告或者单个广告组的层级上，如果只有一部分落地页在被拦的目录下，你看到的是“有几条广告出问题了”，而不是“有个规则出问题了”。这个差别会让你朝完全错误的方向排查。

AdSense那一侧的表现更隐蔽

Mediapartners-Google被拦掉之后，AdSense不会报错，它会继续投广告——只是那些广告与页面内容不相关，因为它读不到内容。

慢慢下滑的数最难被认出来，多触点归因模型怎么选才不被最后一次点击骗走预算那篇讲的是同一类噪声问题。

你看到的现象是收入慢慢下滑、点击率变低。而这两个数天天都在波动，慢慢下滑这件事要好几周才能从噪声里被认出来。

购物那一侧会直接掉商品

Storebot-Google是遵守全局规则的，所以一条针对商品目录的星号Disallow会直接影响购物侧的抓取。表现是商品在Merchant Center里被标记为有问题，或者干脆不再展示。

商品结构化数据的字段这两年还在加，Google给商品结构化数据加了个category那篇讲的是最近这一次。

这一条的好处是报错相对明确，Merchant Center的抓取要求里写清了判据，后台也会给出具体的诊断信息。坏消息是很多人根本不看Merchant Center的诊断，只在销量掉了之后才去翻。

最贵的一种是间歇性的

限速导致的间歇失败最难查，因为它不是稳定复现的。今天检查通过，明天不通过；这个落地页没事，那个有事。

间歇性的问题最难定位，SEO抓取速率被调低的那几天服务器日志里一条错误都没有那篇是个极端例子。

面对间歇性故障，多数团队的第一反应是重试和等待，而这两个动作恰好会让问题持续存在而不被定位。唯一有效的办法是去看服务器日志里那个用户代理的状态码分布。

怎么快速定位

三步。第一步，在日志里按用户代理筛出AdsBot，看状态码分布，出现403、429、503就说明被拦或被限了。

按用户代理和状态码分组看日志是标准动作，读懂Googlebot抓取与预算浪费那篇给了完整读法。

第二步，如果日志里压根没有AdsBot的记录，问题在更外层——CDN或者WAF把请求挡在了到达服务器之前。第三步，用robots.txt测试工具单独测AdsBot-Google对那个路径的判定。

顺序很重要：先看日志再看规则。因为日志告诉你请求有没有到，规则只告诉你规则怎么写的，而这两件事经常对不上。

零记录是最坏的情况

日志里那个用户代理一次都没出现过，通常意味着两种可能：要么它真的从来没来过（你的广告可能压根没在跑），要么它被挡在了你看不到日志的那一层。

日志本身配得不对的话你什么都查不到，LogFormat、CustomLog与CDN真实IP实战那篇讲了怎么配才查得清。

后一种更常见，也更麻烦。因为你查遍自己能查的地方都是干净的，而问题在一个你可能都不知道存在的防护规则里。

再说一遍这几种错法的排查顺序

先日志、再规则、最后测试工具。理由是这三样东西回答的是三个不同的问题。

分层排查是网络类问题的通用办法，从DNS、线路到CDN的网络层排障那篇的顺序可以直接借用。

倒过来查是最常见的错误：先去测robots，测出来是允许的，于是排除掉这个方向，然后再也不回来。而实际上问题在前面三层的任何一层都可能发生，且robots那一层确实是干净的。

一个能省很多时间的动作

用命令行工具伪装成AdsBot的用户代理去请求那个落地页，看返回什么。这一步能在三十秒内区分“页面本身有问题”和“这个身份被特殊对待了”。

换个身份再看一遍是这类故障唯一的排查方式，渲染对比器揪出爬虫和用户看到的页面不一样那篇讲了做法。

要注意的是这么测只能证伪不能证实：如果伪装之后被拦了，说明确实有按用户代理的判断；如果没被拦，也不代表真的AdsBot不会被拦，因为还可能有按IP段的规则。

为什么很多站根本没有这一步

因为改用户代理去请求自己的站，这个动作在多数人的工具箱里不存在。浏览器要开发者工具切换，命令行要记参数，两者都比“打开页面看一眼”麻烦。

这类动作基本都能用免费工具完成，预算为零也能做好SEO的免费工具清单那篇整理过一批。

而问题恰恰在于：打开页面看一眼这个动作，用的永远是浏览器身份。所有按身份区别对待的故障，对这个动作都是隐形的。

这一条可以固化成一个脚本

写一个小脚本，拿五六个常见的爬虫用户代理依次请求同一个网址，把状态码和响应长度打印出来。跑一次十几秒。

把脚本挂上定时任务就变成了监控，把sitemap、排名和清缓存交给定时任务那篇给了写法。

这个脚本的价值在改版之后、上新防护规则之后、换CDN之后各跑一次。它不能替代监控，但它能在三十秒内回答一个平时要查半天的问题：我的站现在对不同身份的访客一视同仁吗。

这几层的日志各自在哪

服务器日志在你自己的机器上，CDN和WAF的日志在服务商的控制台里，而这两处的保留时长通常不一样。前者可能存三个月，后者可能只存七天。

所以遇到这类问题要先去看保留时间短的那一层，否则等你查到那一步的时候，证据已经过期了。这一条听起来很基础，但它是本文所有排查建议里最容易被忽略的一条。

一个滑板站是怎么把自己的广告投停的？

品类是滑板与轮滑装备，主力是长板、鱼板和护具，另外卖轴承、轮子这些配件，市场在北美和西欧，团队9个人。这个品类的特点是SKU组合极多——板面、桥、轮子可以自由搭配，站上有一整套自定义配置的页面。

起因是一次很合理的加固

他们被采集困扰了很久：竞品在批量抓他们的配置页和价格。运维同事做了一套防护，按用户代理和访问频率两个维度拦截，规则写得很规范，白名单里放行了几家主流搜索引擎。

加固这件事本身没错，Apache服务器怎么安全加固那篇从版本隐藏讲到访问控制，方向都是对的。

白名单的写法是反向DNS解析之后，主机名以googlebot.com结尾的放行。这个写法是从一份被广泛引用的验证教程里抄来的，逻辑上完全正确。

问题在两周后浮出来

投放同事发现有一批广告的状态变成了目标网址无法访问，而且都集中在自定义配置那个路径下。她第一反应是页面本身出了问题，用浏览器打开，一切正常。

落地页出问题的表现方式很多，AI来的流量转化率是自然搜索好几倍可你的落地页接不住那篇讲的是另一种。

第二反应是页面加载太慢导致超时，跑了一遍速度测试，也正常。她在这里卡了三天，因为她能想到的所有排查方式，用的都是浏览器身份。

破局的过程

是运维同事在做另一件事的时候撞上的。他在统计那套新防护规则的拦截量，想看看效果如何，顺手把被拦请求按用户代理分了组。

日志里藏着大量还没被读出来的信号，5000站爬虫伪造与抓取预算实战那篇讲了怎么把它们捞出来。

排在第三位的是一个含AdsBot-Google的字符串，两周被拦了一万多次。他当时的原话是：这个是谷歌的吧，怎么会被拦。

发现它的是一个在统计拦截效果的人，不是在排查故障的人。他看的是拦住了谁，而故障那边看的是页面为什么打不开——两拨人在同一件事的两端，各看各的。

为什么白名单会漏掉它

因为AdsBot走的是特例爬虫那套基础设施，反向DNS掩码是rate-limited-proxy加四段IP再加google.com，里面完全不含googlebot这个词。

按身份区别对待的规则最容易出意外，人机验证屏被谷歌当正文索引那篇是另一个误伤案例。

那条以googlebot.com结尾的判断，对它的返回值是假。于是防护规则把它归类成了伪造Googlebot的采集器——而这恰恰是这套规则最该拦的那一类，所以它拦得非常坚决。

拆开之后的账

广告侧的账要算清楚不容易，Meta广告iOS 14归因失真怎么救那篇讲了怎么重建一条被打断的链路。

最后两行是运气。如果他们接了AdSense，那两周的收入下滑会被归因到淡季；如果Storebot也用了同一套反解，购物侧会同时出事。

怎么修的

把白名单的判据从“主机名以googlebot.com结尾”改成“主机名以googlebot.com或者google.com结尾，且正向解析回来的IP与来源IP一致”。改动是一行正则加一次双向校验。

按用户代理做拦截的老代码最容易出事，WordPress拦截恶意User-Agent那篇复盘过一次这样的迁移。

更稳妥的做法是直接用官方发布的两份IP段清单做匹配，普通爬虫一份、特例爬虫一份，定期更新。他们最后两种都做了：反解做快速判断，IP段清单做兜底。

代价与后续

改完之后采集防护的效果没有明显下降——被误伤的那部分本来就不是采集流量。9天停投的损失他们算过一个数，但保哥不打算写出来，因为那9天里他们还调了出价，归因分不干净。

归因分不干净就别硬算，增量测试是什么那篇讲了怎么把本来就会发生的部分剥出去。

能干净归因的只有一件：那37条广告在规则改完后的第二天全部恢复正常状态，没有任何其他改动。这件事只跟白名单那一行有关，没有第二个变量。

他们后来加的一条

在防护系统里做了一个被拦请求的用户代理排行榜，每周自动发一封邮件，列出前二十个。规则很简单，但它把一个本来需要有人主动去查的数据变成了一个会自己送到眼前的数据。

把一个数变成会自己送上门的东西，新网站SEO目标管理的3里程碑加量化任务清单那篇是同一种思路。

半年里这个排行榜抓出过两次误伤，第二次是某个支付服务商的回调地址被限速规则命中。它的价值不在于它多聪明，在于它把“拦住了谁”这个问题从被动变成了主动。

这次复盘里最该记住的一句

那条白名单没有写错。它写的是“放行Googlebot”，而它真正需要表达的是“放行谷歌”，两者在中文里差一个字，在实际效果上差着一整份清单。

规则的字面和人心里那个概念差得很远，9条查得到出处、8条数字对不上那篇追过一批这样的偏移。

这句话值得多想一层。规则的表达能力是有限的，而人写规则的时候脑子里想的往往是一个比规则更宽的概念。规则落到系统里之后，执行的是它字面的意思，不是你心里那个概念。

为什么三天没查出来

因为投放同事所有的排查动作都用的是浏览器身份：她打开页面、跑速度测试、检查跳转，每一次请求都带着一个正常的浏览器用户代理。

按身份或按地区区别对待的故障对自查免疫，按IP自动跳转语言版本正在悄悄让半数页面进不了索引那篇是同类。

而故障的判据恰恰是用户代理。所以她越排查越确信页面没问题——她的每一次验证都在证明这一点，而且证明得完全正确。

这类故障的通用特征

凡是按身份区别对待的故障，都对“用自己的身份去看一眼”这个动作免疫。同类的还有按地区的差异、按设备的差异、按登录状态的差异。

搞清楚每一步各自会发生什么，搜索引擎抓取和渲染DOM分几步那篇把整条链拆得很细。

它们的排查方式只有一种：换一个身份再看一遍。而这个动作不在任何一条默认的排查路径上，因为默认路径假设的是“故障对所有人都一样”。

那个排行榜为什么管用

它把一个需要主动去问的问题，变成了一个会自己送到眼前的答案。运维同事不是在找故障，他是在看统计；那个名字自己跳了出来。

最难发现的问题都是被不相干的动作撞出来的，揪出购买路径上那些看不见的摩擦力那篇里的案例也是这么被发现的。

所有真正难被发现的问题，最后都是被一个跟它无关的动作顺手撞出来的。而你能做的不是提高警觉，是多设几个会自己送答案上门的地方。

顺带说这个案例里的运气成分

他们没接AdSense，也没有用同一套反解去判断Storebot，所以损失只落在广告一侧。如果这两件事任何一件不成立，问题的范围会大得多，而且更难被归因。

把边界如实写出来比把结论说满有用，调研数据里没有一个非会员那篇也是这么处理的。

把运气成分写出来是有必要的：一个案例里如果不写清楚哪些是运气，读者会把这个损失量级当成这类问题的上限，而它其实只是下限。

如果当时有那张排行榜会怎样

第一周就会被发现。那一万多次拦截不是均匀分布的，第一周就有五千多次，足以让AdsBot出现在前二十名里。

预防和发现的成本差十几倍这件事到处成立，A/B测试样本量怎么算才能避免假胜利那篇算过这笔账。

成本对照很清楚：做那张排行榜是半天工程量，而实际发生的是三天排查加九天停投。这类问题的成本结构永远是固定的——预防很便宜，发现很贵，中间那段时间白白送掉。

这个品类还有一个特殊之处

滑板配件的自定义配置页天生就是采集的重点目标——竞品想知道的正是各种组合的定价规则。所以那套防护规则的方向完全正确，误伤只是它的副作用。

大批量页面被区别对待的后果可以很严重，阿里国际站590万AI页面清零那篇复盘过一次。

而副作用之所以没被预料到，是因为设计规则的时候考虑的是“要挡住谁”，没有人问过“这会顺带挡住谁”。这两个问题的答案往往不在同一个人的知识范围里。

反向验证为什么会把AdsBot判成假冒？

上一节那个案例的根因值得单独展开，因为那条白名单写法在行业里流传极广，而它在特例爬虫这里是错的。

反向验证的标准做法

拿到来源IP，做一次反向DNS解析得到主机名，检查主机名是不是在允许的域下，再对这个主机名做一次正向解析，确认解析出来的IP与来源IP一致。这一套叫做双向验证，是防伪造的标准手段。

这个流程本身没有任何问题。出问题的是中间那一步的判据——允许的域到底该写哪些。

三套掩码

第三行是关键。它的结尾是google.com而不是googlebot.com，所以任何一条以googlebot.com为判据的规则，对它一律返回假。

为什么这个坑这么普遍

因为绝大多数讲反向验证的教程，讲的都是怎么识别真假Googlebot。这个需求确实最常见，而googlebot.com这个域也确实是标准答案。

被广泛引用的做法未必覆盖你的场景，转化率、排名周期、流量占比该对标多少那篇讲了引用行业数据时的边界。

问题在于这些教程写的是“验证Googlebot”，读的人理解成了“验证谷歌的爬虫”。这两个短语在中文里差一个字，在实际效果上差着一整份清单。

正确的判据怎么写

两条路，建议都做。第一条是把域判据放宽到同时接受googlebot.com和google.com，并且保留双向验证——因为双向验证本身就足以防伪造，域判据只是加一层。

凭据校验该怎么做有通用原则，SSH密钥、禁root、sudo与fail2ban实战那篇讲的是另一处校验。

第二条是直接用官方发布的两份IP段清单做匹配。这条更硬，因为它不依赖DNS，也不受解析延迟影响。代价是要定期更新那两份文件，通常挂一个定时任务每天拉一次就够。

不建议只放宽域判据

因为google.com这个域比googlebot.com宽得多，如果你的双向验证做得不严，放宽之后确实会引入风险。

放宽一个判据之前先确认别的防线还在，robots.txt能禁止UTM追踪参数吗那篇讲的是另一种想当然的用法。

所以顺序应该是：先确认双向验证真的在做（很多实现只做了反向那一半），再放宽域判据。只做前半段的双向验证是可以被伪造的，这一点比域判据重要得多。

还有一个更省事的思路

不按爬虫身份做放行，按路径做放行。把广告落地页所在的路径整个从防护规则里排除掉，谁来都放行。

按路径放行对内容型页面通常成立，GEO技术端这样优化AI爬虫才能抓得到那篇讲了这类页面该怎么开放。

这个做法的前提是那些路径本身不含敏感数据，也不是采集的重点目标。对多数站点来说，广告落地页恰好是最希望被广泛访问的那批页面，所以这个前提通常成立。

顺带说说用户代理这个东西本身

官方在两份清单的开头都放了同一句警告：用户代理字符串是可以被伪造的。这句话的含义是用户代理只能用来分类，不能用来授权。

按用户代理做判断这条路历史上翻过车，JS判断移动端并自动跳转的SEO最佳实践那篇复盘过其中一次。

换句话说：用它决定“这个请求归到哪一组统计里”是合适的，用它决定“这个请求能不能进来”是不安全的。而现实中大量的防护规则恰好是按第二种方式在用它。

Chrome版本号那一条小坑

官方文档里那些用户代理字符串里有一段占位的版本号，代表Googlebot当前使用的Chromium版本，它会随时间上涨。

工具和真实爬虫的行为经常对不上，SEO爬虫报的死链和Googlebot抓的从来不是同一批URL那篇量过这个差别。

文档专门提醒：如果你要在日志里搜索或者在服务器上按用户代理过滤，请对版本号使用通配符，不要写死一个具体版本。写死的后果是某一天Googlebot升级之后，你那条规则悄无声息地不再匹配——又是一个不会报错的失败。

还有一层容易被忽略的：谁在做这个判断

反向验证通常不在你的应用代码里，它在CDN、WAF或者某个安全插件里。这意味着判据的写法可能是你选的一个预设选项，而不是你写的一行代码。

插件和预设背后的逻辑通常不写在界面上，Yoast、Rank Math、AIOSEO横评那篇把几家的默认行为对比过。

预设选项的问题是它不会告诉你它的判据是什么。一个叫做“允许搜索引擎爬虫”的开关，背后到底放行了哪些域、用不用双向验证、更不更新IP段，界面上通常一个字都不写。

怎么查一个预设到底做了什么

最直接的办法是实测：从一个已知的特例爬虫IP段里挑一个地址不现实，退而求其次是看被拦日志——如果日志里出现了含AdsBot的用户代理，那这个预设就没覆盖它。

看输出反推行为是唯一可行的办法，服务器把没改过的页面对爬虫重发了几百遍那篇也是这么查出来的。

这又回到了那张排行榜。它不只是发现误伤的工具，也是反推预设行为的唯一手段：你没法读到那个预设的逻辑，但你能看到它的输出。

顺带一提用户代理字段本身

User-Agent这个请求头在HTTP协议里的定位一直很尴尬。它诞生的目的是内容协商，后来被用来做特性检测，再后来被用来做统计，现在还被用来做访问控制。

HTTP这一层的每个字段各有分工，301、302、404和410该怎么选那篇讲的是状态码那一组。

一个可以由客户端随意填写的字段，被逐步赋予了它承担不了的职责。官方那句“用户代理字符串可以被伪造”，本质上是在提醒你别把它当凭据用。

那什么才是凭据

IP段和双向DNS验证。这两样东西的共同点是它们依赖发起方控制不了的东西——IP地址的归属和DNS记录的所有权。

这也是官方同时发布用户代理清单和IP段清单的原因：前者给你分类，后者给你验证。把两者的用途搞混，就会写出那条只看名字的白名单。

只有令牌没有用户代理的那几个怎么办？

这一节处理本文开头提到的那个盲区：Googlebot News和Google-Extended在日志里没有自己的名字。

Google-Extended到底是什么

官方定义：它是一个独立的产品令牌，网站发布者可以用它来管理谷歌从站点抓取的内容是否可以用于训练未来的Gemini模型，以及用于Gemini应用和Vertex AI上的搜索接地。

内容能不能被模型引用是个策略问题，四大AI搜索引擎GEO优化策略那篇按引擎分别讲了怎么做。

接地这个说法值得解释一句：它指的是在提示时把搜索索引里的内容提供给模型，以提高事实性和相关性。换句话说，它管的不只是训练，还包括模型回答问题时能不能引用你的内容。

它明确不影响什么

官方写了一句很关键的话：Google-Extended不影响站点在谷歌搜索里的收录，也不作为谷歌搜索的排名信号。

广告、引用和自然结果各走各的通道，5万商业词说三条通道各走各的那篇量过它们的重合度。

这句话的分量在于它解除了一个顾虑。很多人不敢屏蔽它，是担心屏蔽之后搜索排名受影响；官方把这条路堵死了，屏蔽与否是一个纯粹的内容授权决定，不掺杂搜索的考量。

那该不该屏蔽

这是个业务判断不是技术判断，保哥不给统一答案，但可以给判据。

内容授权这件事正在变成一门单独的功课，内容溯源与C2PA那篇讲的是可验证出处这条新赛道。

如果你的内容本身就是获客手段，被模型引用等于多一个曝光渠道，那就别屏蔽。如果你的内容是付费产品的一部分，或者你靠内容本身的稀缺性挣钱，那屏蔽是合理的。关键是这个决定要被明确做出来，而不是因为不知道有这么个令牌而默认放行。

默认放行这件事本身值得说

你没有设置的规则不等于没有规则，只等于它是别人设的。而这个默认值，恰好对设它的那一方最有利。

默认值决定了大多数人的实际选择，出海独立站怎么选同意管理平台那篇讲的是另一处默认值的博弈。

这不是指控谁，默认值总要有一个。但它意味着凡是存在默认值的地方，你都应该主动去看一眼那个默认值是什么，而不是等到有后果的时候才发现自己一直在用它。

Googlebot News那一个

它没有独立的用户代理，抓取用各种Googlebot字符串完成，但robots.txt里有独立令牌，而且它也听Googlebot那一组规则。

不同产品面的收录规则各不相同，视频SEO在AI搜索时代怎么做那篇讲了Google改规则之后老打法怎么失效的。

实操含义是：如果你想只屏蔽新闻而保留网页搜索，必须写一条针对Googlebot-News的规则；反过来如果你屏蔽了Googlebot，新闻也一起没了。前者需要主动，后者是连带发生的。

Google-InspectionTool这个容易误伤

它服务的是Search Console里的网址检查和富媒体结果测试。官方明写它对谷歌搜索和其他产品没有影响。

要批量确认收录状态得用接口，GSC URL检查API怎么批量监控收录那篇讲了2000条配额下的管线。

但它同时也听Googlebot这个令牌。所以一条针对Googlebot的Disallow会让你自己在Search Console里检查那个网址时得到“被robots.txt阻止”的结果——这一条经常被误读成索引出了问题，实际上只是检查工具被同一条规则挡住了。

GoogleOther这一族

官方说它不影响任何具体产品，是各产品团队用来抓取公开内容的通用爬虫，可能用于一次性的内部研发抓取。

不知道对方在干什么的时候保守一点，SPA站AI爬不到的真相那篇讲的是另一类看不清的抓取行为。

这个描述给的信息量不大，但它至少说明了一件事：拦掉GoogleOther的直接后果是不可预期的，因为没人告诉你它在为什么服务。保哥的建议是除非它造成了实际的服务器压力，否则不动它。

把这几个整理成一个决策表

把一堆决定整理成表是落地的第一步，GEO到底怎么落地那篇给了一份从AI搜索到结构化数据的实施顺序。

这张表该怎么用

不是照抄，是照着它做一次自己的决定。每一行问一句：这个爬虫如果被拦掉，我这边会有什么变化，我能不能察觉到那个变化。

自查打分表这种形式很适合这类判断，你的独立站在AI购物代理眼里及格吗那篇给了一份现成的。

第二问比第一问重要。一个拦掉之后有明确后果且后果可见的爬虫，你怎么设置都不算太危险；一个拦掉之后后果不可见的，才是真正需要谨慎的那种。

按可察觉性重排一次

能不能被察觉比后果多大更值得排序，砍掉虚荣指标、定准北极星指标那篇讲的也是这种重排。

这个排序和“后果严重程度”的排序几乎是反的。后果最严重的那个最早被发现，后果说不清的那个可能永远不被发现——而后者才是长期在悄悄付账的。

一条通用的经验

面对一个你不知道它在干什么的爬虫，默认应该是放行加限速，而不是拦截。理由是拦截的代价不可知，限速的代价是可控的延迟。

不知道机制的时候别乱动，手动提交URL能加快Google收录吗那篇把一批想当然的做法验了一遍。

只有当你能说清楚“拦掉它我会失去什么”的时候，拦截才是一个可以做的决定。说不清楚的时候拦掉它，等于在赌一件你没算过的事。

把这套判断固化下来

在robots.txt里给每个非常规规则组加注释，写三样东西：谁加的、什么时候加的、拦掉之后预期会失去什么。第三样最重要，因为它是未来某个人决定要不要删掉这条时唯一的依据。

成本接近零的动作应该优先做掉，11个按性价比排序的速赢清单那篇的排序逻辑和这里一样。

这个做法的成本接近于零，收益是把一份只有作者看得懂的配置，变成一份任何人都能接手的配置。

还有一类没在清单里的

官方那句“本清单并非穷尽”意味着一定存在你在日志里见到、但文档里查不到的谷歌来源请求。遇到这种情况，判断办法是先做双向验证确认它真的来自谷歌，再看它抓的是什么内容。

遇到查不到出处的东西先别下结论，AI经常编造不存在的链接那篇讲了怎么核实这类线索。

抓静态资源的多半是渲染服务在取子资源，抓页面的多半是某个产品在做一次性收集。前者绝对不能拦，后者可以观察一阵再决定。

非谷歌的那些怎么办

其他搜索引擎、AI公司的抓取器、SEO工具的爬虫，各有各的文档和验证方式。判断框架完全一样：先弄清楚它有没有独立的用户代理、有没有独立的令牌、听不听全局规则、怎么验证真伪。

别家的抓取与索引机制自成一套，提交了为什么还不收录那篇拆的是另一家的流程。

这四个问题问完，你就能把任何一个新出现的爬虫放进那张对照表里。框架比清单值钱，因为清单每年都要重做，框架不用。

把这件事和广告排期挂上钩

每次要新开一条业务线、上一批新落地页、或者换一个建站平台的时候，顺手跑一遍那个多身份请求脚本。十几秒的事。

这三个时点的共同特征是：路径变了、模板变了、或者防护策略跟着新环境变了，而这三样恰好都是本文说的那类误伤的诱因。

这份规则该怎么写才不出事？

前面全是机制，这一节给可执行的部分。仍然按“做完能不能一劳永逸”排序。

六件自查动作

第一件带早停：在日志里按用户代理筛出含AdsBot的请求，看状态码分布。十分钟。清一色200就说明你没踩本文最大那个坑，后面五件的紧迫性大幅下降。

带早停的清单更容易被真正执行，谷歌SEO技术清单的5大核心方向那篇也是这么排的。

第二件：把你的robots.txt文件从头到尾读一遍，数一数一共有几个用户代理组。五分钟。只有一个星号组的话，你对特例爬虫是完全没有表达过意见的，而这通常没问题。

第三件：翻出防护规则或者CDN规则里所有按用户代理判断的条目。半天。重点看白名单那一侧的域判据，是不是只写了googlebot.com。

第四件：做一张三列对照表：日志里的用户代理、robots令牌、影响哪个产品。半天。第一列为空的那几行单独标出来。

第五件：去看一眼Google-Extended当前是什么状态，并明确做一次决定。二十分钟。不管决定是什么，做出来比默认着强。

第六件：把两份官方IP段清单接进防护系统做兜底。一天。这一件最费劲，但它是唯一一个不依赖名字判断的方案。

卡点挂在哪里

前面六件都是一次性的。要让这件事不复发，得有一个东西持续把“你拦住了谁”这件事送到眼前。

把重复的统计交给自动化是划算的，做SEO、GEO和广告投放我到底把AI用在哪些环节那篇分了能用和不能用两类。

保哥用的做法是一份被拦请求的用户代理排行榜：防护系统每周自动统计被拦截的请求按用户代理分组，取前二十名发一封邮件。不需要任何判断逻辑，就是一张排行榜。

为什么是排行榜而不是告警

因为你没法提前定义什么是异常。一个新爬虫第一次被拦的时候，没有任何规则能判断它该不该被拦——那需要人的判断。

告警和探索适合的场景不一样，SEO数据分析从指标体系到异常诊断那篇讲了两者该怎么分工。

告警适合已知的失败，排行榜适合未知的失败。这件事属于后者：你不知道下一个被误伤的会是谁，但你一定能在一张按次数排序的表上认出那个不该在上面的名字。

那个滑板站的运维同事之所以能一眼认出AdsBot，不是因为他懂广告，是因为那个名字里有Google三个字母而它出现在了一张“被拦掉的东西”的表上。这张表要求的判断力极低，这正是它能持续起作用的原因。

怎么跟人说这件事

说“你的防护规则误伤了谷歌的爬虫”效果一般，因为运维同事手上有一份白名单，里面明明写了放行谷歌。

跨职能沟通有一套通用的开场方式，前端工程师SEO协作的7个动作点那篇里那几句可以直接照搬。

保哥用的说法是：那批广告显示目标网址无法访问，我在被拦日志里筛出了AdsBot-Google，两周1万多次。它的反解不是googlebot.com结尾，是rate-limited-proxy开头google.com结尾，所以白名单那条判断对它返回假。我想把域判据放宽一格，改完再看一次广告状态。

四句话，三个事实一个提议。没有一个字说白名单写错了——它没写错，它只是覆盖的范围比所有人以为的窄。

护住所有人的第二句

那条白名单是照着标准做法写的，问题不在它身上，在于官方有两套反解掩码而多数教程只讲了其中一套。把焦点从人挪到“文档分散在两份清单里”上，这句话在事实层面也是成立的。

把焦点从人挪到缺少的那个环节上，数据分析师与SEO对账清单的7个动作点那篇给了一套协作机制。

四条边界

第一条：本文只覆盖谷歌自己的抓取客户端。其他搜索引擎、AI公司、SEO工具各有各的身份体系，判断方法可以迁移，具体的名字和掩码不能。

方法可以迁移具体参数不能，出海独立站国际SEO怎么选域名结构那篇也强调过这个区分。

第二条：官方那两份清单明确写着并非穷尽。所以按清单做的白名单天然不完整，这也是建议用IP段清单兜底的原因。

第三条：拦不拦是个业务决定不是技术决定。技术上你可以拦掉任何一个，代价各不相同；本文只负责把代价说清楚，不负责替你决定。

第四条，也是最容易被忽略的：这套体系一直在变。清单里那个退役章节就是证据——曾经有过安卓应用广告的爬虫、有过Duplex、有过Web Light，现在都没了。今天你抄下来的表，一年后至少要复核一次。

最后一句

这件事的检查成本是十分钟，代价是你的广告能不能投出去。它和前面两篇讲的事属于同一类：一个不会报错的失败，而检查它比修它便宜一个数量级。

检查成本低而代价高的事该优先做，服务器配置对SEO影响的20项必看清单那篇里还有几件同样性质的。

这三件事放在一起看

本文说的是规则的作用范围比你以为的窄，前面两篇一篇说的是文档被按字节截断、一篇说的是退订入口被显示层吃掉。三个现场完全不同，机制是同一个。

网页那一侧的截断有现成的检查工具，抓取体积检查器与Googlebot上限实测那篇讲了怎么用。

你表达了一个意图，系统执行了一个比它窄或者比它宽的版本，而中间没有任何一个环节会告诉你这两者不一样。字节那篇是窄了，退订那篇是被吃掉了，本篇是范围对不上。

对抗它的动作只有三种

第一种是把重要的东西放到那个不会失效的位置上——在HTML里是往前排，在邮件里是放信头。

把重要的东西放在对的位置上是通用解法，独立站架构搭错了谷歌爬虫根本找不到你的产品页那篇讲的是结构层面的同一件事。

第二种是给自己留一个能看见执行结果的地方——本文那张被拦请求排行榜，就是这一类。

第三种是把判据换成一个能被程序验证的东西——IP段清单之于用户代理字符串，就是这一类。三种都不贵，贵的是发现自己需要它们的那个过程。

最后再说一次那个顺序

先看日志里有没有它，再看规则怎么写的，最后才用测试工具验判定。这个顺序反过来走的话，你会在第一步就得到一个正确但无关的答案，然后把这个方向排除掉。

查错层是最常见的时间浪费，GSC 404错误修复与软404排查实战那篇讲了怎么分清是哪一层的问题。

而那个方向恰恰是对的，只是你查错了层。这一条是本文里最实用的一句，也是最容易被忽略的一句。

把这六件事排进现实的排期里

如果你手上只有半天，就做第一件和第三件：查日志里AdsBot的状态码，翻白名单的域判据。这两件加起来能覆盖本文说的绝大部分风险。

排期有限的时候先做覆盖面最大的，DTC品牌AI工具栈怎么搭那篇的12款测评也是按这个逻辑挑的。

如果有一天，加上第六件——把两份IP段清单接进去做兜底。这一件做完之后，后面所有关于名字的坑就都跟你无关了，因为你不再靠名字做判断。

不建议一开始就做的一件事

不要一上来就重写整个robots.txt。这个文件里躺着的那些历史规则，每一条都可能在某个你不知道的地方生效，一次性重写的风险远大于收益。

一次性重写的风险远大于收益，多个域名要不要合并成一个站那篇讲的是另一个该分步走的大改动。

正确的做法是先给现有的每一条加注释，注释写不出来的先标记成待考证，然后一条一条地查。查清楚一条删一条，比一次删完再等着出事强。

写在最后的一句提醒

这份文档谷歌自己也在改。本文写作时那份退役清单里躺着四个曾经存在的爬虫，一年之后那个清单只会更长。

所以真正该记住的不是那几个名字，是那个问题：我这条规则，执行它的系统是怎么理解的。名字会过期，这个问题不会。

常见问题解答

robots.txt里的星号真的管不到AdsBot吗？

管不到。官方特例爬虫清单里，AdsBot-Google、AdsBot-Google-Mobile、Mediapartners-Google和APIs-Google这四条下面都写着同一句话：全局用户代理会被忽略。Google-Safety更彻底，它完全忽略robots.txt。但要注意区分：它们忽略的是星号那一组规则，不是整个文件；如果你显式写了一个针对AdsBot-Google的规则组，它是听的。所以你不是没办法控制它们，只是那个办法不是写星号。

为什么谷歌要给广告爬虫开这个例外？

官方给的定义是：特例爬虫服务于特定产品，被抓取的站点与该产品之间存在关于抓取过程的约定。你开广告账户并提交落地页这个动作，本身就构成了让AdsBot检查这一页的许可。反过来想更清楚：如果AdsBot听全局规则，任何一个为省抓取预算写了大范围Disallow的站，都会在不知情的时候让所有广告落地页变成不可检查状态，而后果是广告直接投不出去。

我的反向DNS白名单为什么会把AdsBot当成假冒？

因为谷歌有两套反解掩码。普通爬虫是crawl加四段IP再加googlebot.com，特例爬虫是rate-limited-proxy加四段IP再加google.com，后者里面完全不含googlebot这个词。行业里流传最广的验证教程讲的都是识别真假Googlebot，判据写的是以googlebot.com结尾，这条判断对AdsBot一律返回假，于是它被归类成伪造Googlebot的采集器，而这恰恰是防护规则拦得最坚决的一类。

拦错了会在哪里报错？

不会在你查robots的地方。Google Ads会显示目标网址无法访问或者网站无法抓取，这些表述描述的是现象不是原因，没有一个词会让你想到robots.txt或WAF。AdSense那边更隐蔽，它不报错，只是投放的广告与页面内容不再相关，表现为收入慢慢下滑。购物侧因为Storebot-Google遵守全局规则，反而会在Merchant Center里给出比较明确的诊断。

为什么日志里找不到Google-Extended？

因为它没有独立的用户代理字符串。官方原文写的是抓取由现有的谷歌用户代理字符串完成，robots.txt里那个令牌只用于控制。同类的还有Googlebot-News。这意味着你能不能拒绝它，完全取决于你有没有在robots.txt里写下一个你从没在日志里见过的名字——常规的先看日志再写规则那个顺序，对这一类永远不会启动。

屏蔽Google-Extended会影响搜索排名吗？

不会。官方明确写了它不影响站点在谷歌搜索里的收录，也不作为搜索的排名信号。这句话解除了最大的顾虑，把屏蔽与否变成一个纯粹的内容授权决定。判据是你的内容属于哪一类：如果内容本身是获客手段，被模型引用等于多一个曝光渠道；如果内容是付费产品的一部分或者靠稀缺性挣钱，屏蔽是合理的。关键是这个决定要被明确做出来。

一条针对Googlebot的规则会连带影响什么？

比多数人以为的多。Googlebot-Image、Googlebot-Video、Googlebot-News、Google-InspectionTool和Google-CloudVertexBot都同时认Googlebot这个令牌，而官方说明只需匹配其中一个令牌规则就生效。所以屏蔽一个目录不让网页抓取，那个目录下的图片也会从图片搜索消失；你在Search Console里检查那个网址还会得到被robots.txt阻止的提示，容易被误读成索引出了问题。

用什么办法识别爬虫最可靠？

官方在两份清单开头都放了同一句警告：用户代理字符串可以被伪造。所以用户代理只适合用来分类统计，不适合用来授权放行。最可靠的是官方发布的两份IP段清单，普通爬虫一份特例爬虫一份，挂个定时任务每天拉一次做匹配，这个方案不依赖DNS也不受解析延迟影响。次之是双向DNS验证，但要确认反向和正向两半都真的在做。

权威参考资料