Google有一整类抓取器不看robots.txt，这次改名只是把它推到了台前

摘要：7月16日Google把NotebookLM改名成Gemini Notebook，抓取器令牌也从Google-NotebookLM换成了Google-GeminiNotebook。真正值得站长花时间的不是这次改名，而是它所属的那一类——用户触发型抓取器。官方文档白纸黑字写着这类抓取器一般会忽略robots.txt，而且它不在常规抓取器名单里，你写的Google-Extended对它无效。我把官方五份IP清单全部拉下来数了一遍：用户触发型三份加起来1526条前缀，常规抓取器那份只有315条，前者是后者的4.84倍。更要命的是这些清单换过目录，旧地址至今仍返回200，内容却停在4个月前——脚本不会报错，只会悄悄拿旧名单去验新IP。这篇把令牌变更、分类归属、失效日期的真实口径、日志识别方法、三层拦截方案，以及拦掉之后你会失去什么，一次讲清楚。

先说一件小事。我这两天顺手把Google那几份抓取器IP清单重新拉了一遍，本来只是想核对个数字，结果发现同一个文件名、两个地址，返回的内容差了4个多月。旧地址没报404，没报403，规规矩矩返回200，JSON格式完好，只是里面的数据是3月3日的。

如果你的服务器上跑着一个定时任务，按旧地址同步Google的IP白名单，那它现在正拿着一份过期名单去验证今天的请求。这种失效方式最阴险的地方在于：它不出错。监控不报警，日志不飘红，一切看起来都很正常。

而把我引到这份清单上的，是7月16日的一条改名公告。

Google改了个产品名，为什么值得你打开服务器日志看一眼？

7月16日，Google宣布把NotebookLM改名为Gemini Notebook。那篇官方公告通篇讲的是产品定位和用户规模，一个字都没提抓取。

抓取相关的变更发布在完全另一个地方——开发者文档的变更日志里。同一天，那条记录写的是：把NotebookLM的用户代理更新为Google-GeminiNotebook，如果你在代码里硬编码了旧值，请更新字符串以免出现问题。

这个分头发布的习惯，本身就值得记一笔。产品公告面向用户和媒体，抓取器变更面向开发者文档，两边互不引用。你要是只订阅了官方博客，这次变更你收不到；你要是只盯着搜索中心的博客，也收不到，因为它连搜索中心的博客都没上。

所以第一条实用结论：管抓取器的信息源，是开发者文档的变更日志，不是产品公告。那个变更日志是有RSS的，值得单独订一条。

这次到底改了什么，旧的那个还能用多久？

先把事实摆清楚。新令牌是Google-GeminiNotebook，官方给了移动和桌面两条完整的用户代理字符串，分别标着Chrome/138.0.0.0和Chrome/137.0.0.0。旧令牌是Google-NotebookLM。

关于旧令牌什么时候失效，这里有个口径问题，媒体报道普遍没讲清楚。

官方文档的表格里，那一行标注是“旧代理（支持至2026年8月）”。而同一天的变更日志里，Google的说法是：我们会继续支持旧值，以便平稳过渡——没给任何日期。

两处口径不完全一致：表格给了月份但用的是“支持至”，变更日志承诺继续支持但不给期限。有报道把这两条合并读成了“旧的用户代理将在8月停止工作”，这是一个偏强的解读。

那实际该怎么办？很简单：别赌。如果你在任何地方硬编码了Google-NotebookLM这个字符串——防火墙规则、日志分析脚本、爬虫白名单、报表分类——现在就把新令牌加上，两个并存。加一行的成本是零，赌错的成本是你的拦截规则某天悄悄失效。

官方那句“一般会忽略robots.txt”，到底该怎么读？

这是整件事里最该被读懂的一句话。官方对用户触发型抓取器的说明原话是：因为这次抓取是用户请求的，所以这些抓取器一般会忽略robots.txt规则。

注意“一般”这个词。官方用的是留有余地的措辞，不是“完全无视”，也不是“永远不读”。我倾向于把它理解成：默认不受robots.txt约束，但Google没把话说死，保留了在某些情况下仍然读一读的空间。

写到自己的技术文档里时，建议照抄这个措辞，别自己加强。加强了别人事后拿反例来打脸，你还得解释。

更关键的是对照组。官方在描述常规抓取器时用的是另一句话：在自动抓取时，它们始终遵守robots.txt规则。

“始终遵守”对“一般忽略”，两句话摆在一起，这条分界线就清楚了。同样是Google的抓取器，分在哪一类，决定了你那份robots.txt对它有没有约束力。这也是robots协议本身的机制决定的：它从来就是一份君子协定，不是一道门锁。

为什么用户触发型抓取器天生就不归robots.txt管？

这不是Google耍赖，背后有一套说得通的逻辑，理解了它你才知道哪些抓取器将来也会归到这一类。

robots.txt管的是自动化抓取——机器自己决定去抓谁、抓多少、多久抓一次。站长通过robots.txt对这套自动决策表达偏好，引擎自愿遵守。

而用户触发型抓取是另一回事：有个真人坐在那里，把你的URL复制粘贴进了输入框，然后点了确认。从产品的角度看，这更接近“用户自己打开了这个网页”，只不过是借Google的服务器打开的。

浏览器打开网页时不读robots.txt，这一点没人有意见。用户触发型抓取器把自己类比成浏览器，逻辑链条就成立了。

这个类比成立不成立，可以再吵二十年。但对你来说，重要的是它的推论：凡是“用户主动指定了这个网址”的功能，未来大概率都会落进这一类。链接预览、朗读、代理浏览、AI助手替你打开一个页面——只要有个人在前面点了一下，它就有理由不看你的robots.txt。

这份名单上现在有多少个，都是干什么的？

很多人以为这次只是多了一个AI抓取器。实际上用户触发型这份名单已经不短了，Gemini Notebook只是最新一个。

看完这张表你会发现一件事：这一类里有一半是老面孔，而且大多数站长从来没意识到它们不受robots.txt管。真正变化的不是规则，是这一类里开始出现能大规模消费内容的AI产品了。

名单里那个Google-Agent，为什么比这次改名更值得留意？

Gemini Notebook抓你，是因为有个用户手动把你的链接贴了进去——这个动作有天然的量级上限，一个人一次贴不了多少条。

Google-Agent不一样。官方对它的描述是：跑在Google基础设施上的代理，替用户执行网页动作。注意是“动作”，不是“读取”。

这两个词的差别很大。读取是抓一份文本回去，动作意味着它可能点按钮、填表单、翻页、走完一个流程。对一个电商站来说，这是完全不同的负载模型，也是完全不同的风险模型。

我还注意到一个细节：官方文档里Google-Agent那一条原本举了个产品例子，后来这个例子被删掉了，因为那个产品在2026年5月退役了。条目留着，例子没了——说明这个位置是留给后续产品的，不是给某一个具体产品的。

换句话说，Google-Agent是一个占位符式的通道。今天走的是这个产品，明天可能是别的。技术端为AI抓取做的那些准备，需要把这条通道单独算一格。

我把官方五份IP清单全拉下来数了一遍，结果有点反直觉

光看名单还不够。抓取器公布IP段是为了让站长验证真伪，那这些IP段各自有多大？我把官方文档列出的五份JSON全部拉了下来，逐个数了前缀条数。

五份文件的生成时间都是7月17日，属于同一批快照，可以横向比。

把后三份加起来是1526条，常规抓取器那份是315条。那个不受robots.txt约束的类别，IP面是老老实实遵守robots.txt那一类的4.84倍。

就算把特例抓取器也算进遵守方那一边，585对1526，仍然是2.61倍。

这个比例我看到的时候愣了一下。我们这行讨论了这么多年robots.txt该怎么写、AI爬虫该拦哪个，而Google自己那套IP基础设施里，铺得最开的恰恰是不看robots.txt的那一类。

前缀条数多，是不是就等于抓得多？

不等于，这里必须刹一脚车。

IP前缀数量反映的是网络地址分配的规模，不是请求量。一个/24前缀和一个/21前缀在这份统计里都算一条，但后者的地址空间是前者的8倍。而实际发出多少请求，跟地址空间大小也没有必然关系——完全可能是1000条前缀里只有几十个IP在真正干活。

所以4.84倍这个数字，准确的读法是：Google为这一类抓取器预留的网络面，比常规抓取器大得多。它说明的是投入和预期，不是当期流量。

这个区分很重要。你要是拿着4.84倍去跟老板说“不遵守robots.txt的爬虫流量是Googlebot的五倍”，第一个把日志翻出来的人就能把你驳倒。

真正的当期流量，只能从你自己的access日志里数。任何行业数字都替不了这一步。

你那套验证真假Googlebot的脚本，为什么漏掉了这一整类？

这一条是我认为最容易踩、也最少被人提起的坑。

大多数站点验证Googlebot的做法是反向DNS：拿到IP，反查主机名，看是不是以googlebot.com结尾，再正向解析回去比对。这套方法很成熟，几乎是标准动作。

问题是，用户触发型抓取器的反向DNS根本不落在googlebot.com上。

四类三种后缀。你那个只认googlebot.com的脚本，遇到Gemini Notebook的请求会判定为“伪造的Googlebot”，然后按你设的策略——很可能是直接拦掉或者标记成可疑流量。

这会带来两个方向的错误。一是把合法请求当成攻击拦了，二是你的爬虫报表里这一整类根本不出现，你以为没人抓，其实只是没认出来。

如果你手上有按用户代理做爬虫分类和真伪验证的那套工具链，现在正是把这三种主机名形态补进去的时候。

那份IP清单换过地址，你的定时任务知道吗？

回到开头那件事，现在可以说完整了。

官方那五份JSON的目录改过。旧目录在搜索接口那一支下面，新目录在抓取文档这一支下面。而且文件名也动过——旧的叫googlebot.json，文档里现在写的是common-crawlers.json。

我把新旧两个地址的同一个文件拉下来对比：新地址的代理类清单是7月17日生成的，20条前缀；旧地址返回200，JSON完好，生成时间是3月3日，4条前缀。

差了5倍的数据量，4个多月的时效，而HTTP状态码是200。

这就是我说它阴险的原因。要是旧地址干脆404，你的定时任务当天就报错，你当天就修了。它偏偏返回一份格式正确的旧数据，于是脚本安静地跑了4个月，白名单一直是旧的。

顺手做三件事：把同步脚本里的地址换成文档当前写的那个；在脚本里加一条对生成时间的断言，超过一定天数没更新就告警；把googlebot.json这个旧文件名也一并换掉。

那这个抓取器到底会抓走多少东西？

这里又有一个口径被普遍讲小了的地方。

Gemini Notebook里有个功能叫来源发现，用户描述一个主题，它去网上找资料。不少报道说这个功能“最多抓10个来源”。

但官方介绍这个功能时的原话是：它会在几秒内搜集数百个潜在的网络来源，分析之后挑出最相关的，然后呈现最多10条推荐。

搜集数百个，呈现10条。这两个数完全不是一回事——10是给用户看的展示条数，不是抓取请求的分母。

你日志里可能出现的请求量级，参照的应该是“数百”那一头，不是“10”。这个差别在你估算负载、判断这类流量值不值得单独限速的时候，会直接影响结论。

这也是读厂商信息的一条通则：凡是给了一个小数字的地方，先问它是产品界面上的数，还是后台真实发生的数。这两个数经常差一到两个数量级。

它抓走的到底是什么，会不会把你的图和视频也搬走？

官方帮助文档在这一点上讲得很具体，值得原样记下来。

帮助中心那一页写明：只有给定网页的文本内容会被抓取用作来源，图片、内嵌视频、嵌套网页不会被导入；付费墙网页不受支持。

三条信息量都不小。第一，这是纯文本抓取，你那些花大力气做的图表、视频、交互组件，它一个都不要。第二，嵌套网页不导入，意味着它不会顺着链接爬开——这跟传统爬虫的行为模型完全不同，它是点对点的。第三，付费墙拦得住它。

还有一条关于存储的：官方把来源描述为你导入文档的一份副本或自动同步版本。也就是说抓完之后，内容在Google那边是有留存的，不是读完就扔。

对做付费内容的站来说，第三条是好消息。对做免费深度内容的站来说，前三条合起来讲的是同一件事：它要的是你的文字，而且只要文字。

它会给你带来引荐流量吗？

这个问题我必须诚实地说：没查到能确认的一手依据。

有报道断言它不产生任何引荐流量。我去查了这个说法的出处，官方开发者文档没有关于引荐来源标头的任何说明，帮助中心也没有，那篇报道本身也没给实测或者官方引用。

所以现在的状态是：这是一个听起来很合理、但公开材料里没有证据支持的说法。

合理在哪？一个笔记类产品，用户是在自己的工作区里读整理好的资料，本来就没有多少点回原站的动线。这个推理站得住。

但推理站得住不等于事实成立。真要确认，只能自己查：在access日志里按新令牌筛出这类请求，记下被抓的URL，然后在流量分析里看这些URL后续有没有来自相关来源的访问。样本够了才能下结论。

这件事我打算自己攒一段日志再说。在有实测之前，我建议大家在内部文档里就写“尚无公开实测”，别跟着转述成结论。

音频概览把你的文章做成播客，这算竞争吗？

Gemini Notebook有个挺出名的功能：把你导入的资料变成两个AI主持人对谈的音频节目。

官方对它的描述是：由AI主持人进行的深度讨论，对上传来源中的关键主题作深入总结，并且设计上是对来源内容的客观反映。

不少人担心这是不是把原文洗成播客还不署名。我去翻了帮助文档，关于对来源网站的署名、链接、归属，官方一个字都没提。

这里要拿捏一下：没提，不等于官方声明不署名。这是资料缺口，不是事实结论。把“文档未说明”写成“官方承认不署名”，是转述里最常见的一种放大。

能确定的只有一点：这个功能确实会把你的文本改造成另一种形态，在另一个界面里被消费。至于这算不算竞争，取决于你的内容值钱在哪——如果值钱在信息本身，那它确实替代了一次访问；如果值钱在你的服务、工具、社区，那被总结一次反而是次曝光。

同样是不看robots.txt，它和那些没礼貌的AI爬虫有什么区别？

这一节可能会有点反直觉。我的看法是：这一类抓取器虽然不受robots.txt约束，但它其实比市面上大多数AI爬虫好对付得多。

差别在四个地方。

一是它有具名令牌。用户代理字符串里明明白白写着自己是谁，还附了一个说明文档的网址。相比之下，不少AI爬虫要么伪装成普通浏览器，要么用一个查不到出处的字符串，你连给它起个名字归类都难。

二是它有官方IP清单。你能拿到一份机器可读的地址表去验证真伪。这一点非常关键——能验证，就意味着你的拦截规则不会被随便一个改UA的脚本绕过去。绝大多数AI爬虫不提供这个。

三是它有触发主体。每一次抓取背后都对应一个具体的人的一次操作，这给了它天然的量级天花板。而无差别扫站的爬虫，量级只取决于对方的机器有多少台。

四是它的行为边界清楚。只取文本、不导入嵌套网页、不跟着链接爬开。你能预判它会做什么、不会做什么。

把这四条合起来看，结论有点意思：“不遵守robots.txt”和“不讲规矩”是两回事。前者是分类规则决定的，后者是行为决定的。真正让站长头疼的从来是后者。

所以如果你的拦截预算有限，先别急着处理这个有名有姓、有IP清单、有行为边界的，去日志里找那些既不报家门、又扫得最凶的。那才是真正在吃你带宽的。

付费墙拦得住它，这条能不能反过来当工具用？

官方那句“付费墙网页不受支持”，多数人读到的是一条限制。我读到的是一个开关。

它的意思是：你已经有一个现成的、不需要动任何服务器配置的选择性可见机制。放在墙外的，这类工具读得到；放在墙内的，读不到。

这个机制的好处是它跟你的商业模式天然对齐，不需要你为AI抓取单独发明一套策略。你本来就要决定哪些内容免费、哪些付费，这个决定顺带就把AI可见性的边界划好了。

坏处也要说清楚。付费墙挡住的不只是它，还有真正能带来收益的搜索引擎抓取和普通读者。为了防一个用户触发型抓取器而把内容挪到墙后，这笔账几乎肯定是亏的。

所以正确的用法不是“为了拦它而加墙”，而是“既然墙已经在那儿了，就顺便知道墙的这一侧对这类工具是不可见的”。做内容规划的时候，把这一层影响算进去就够了。

还有个更细的点：官方说的是不支持，不是拦截。这意味着用户把一个付费墙页面贴进去，它拿到的多半是那段公开的引子——摘要、前几段、订阅提示。那么这段引子写成什么样，就变成了你在这类工具里的全部形象。如果你的付费墙引子现在只有一句“订阅后阅读全文”，那你在这个场景里等于什么都没说。

老板问“我们要不要拦”，这话该怎么答？

这类问题的麻烦不在技术，在于怎么把一个技术判断讲成一个生意判断。给个我常用的答法。

先把问题拆成两问：这件事现在对我们有多大？我们拦得住吗？

第一问用自己的日志答，别用行业数字。把这一类的请求占比、被抓的页面清单摆出来，通常你会发现量小得可以忽略。这时候老板自己就会觉得这不是当务之急，你也不用去争。

第二问诚实答：robots.txt拦不住，得动CDN或服务器配置；能拦，但拦掉之后，把我们文章贴进笔记本做研究的那批人就看不到我们了。

然后给一句判断，别只摆事实：这批人是我们最想影响的读者，为了省一点带宽把他们挡在外面，划不来。

最后把话头转到真正有产出的那一步：与其纠结拦不拦，不如看看哪些页面被反复贴进去了——那份名单能告诉我们，别人是拿我们的哪几篇内容在做决策。这句话通常比前面所有技术细节都更能让人点头。

出海独立站要不要打个折扣看这件事？

要，而且是往两个方向打。

往轻里打的一面：如果你的主力市场在国内，这个抓取器对你的实际影响接近于零，因为产品本身在国内不是主流工具。这种情况下，前面所有关于拦不拦的讨论，对你都只是背景知识。

往重里打的一面：如果你做的是欧美B2B，那影响要比这篇里描述的更重一档。原因是这类工具在专业研究场景里的渗透率，明显高于它在大众场景里的渗透率。你的客户——采购、工程、咨询——恰恰是最可能用它的那批人。

另外有个实操上的坑值得单说：不少出海站在CDN上按地区做了分流，不同区域走不同的规则集。你在主区域加了拦截或者放行规则，别的区域不一定生效。改完之后至少要从两个区域各验一次，别只在自己最近的节点上测一遍就收工。

还有一层是日志本身。如果CDN在边缘就完成了响应，源站日志里根本看不到这类请求。要看全，得去CDN的日志里查。这个坑我见过不止一次——团队信誓旦旦说日志里一条都没有，结果是查错了地方。

robots.txt拦不住，那还剩哪几层能拦？

既然协议层不管用，能动的就只剩下网络层和应用层。按拦截位置从外到内排一下。

四层里我最推荐前两层的组合：CDN层做主拦截，服务器层留一份兜底，两边都按用户代理匹配。

IP段拦截听着最硬，实际维护成本最高，而且刚才说过清单会换地址。除非你有很强的理由，否则不值得。

还有一个更彻底的方向是给抓取本身定价，让愿意抓的付费而不是一刀切拦掉——按次抓取收费这条路是不是适合你的站，值得单独算一笔账。

动手拦之前，你想清楚拦掉会失去什么了吗？

技术上能拦，不代表应该拦。这一节我想劝一句慢一点。

Gemini Notebook的抓取有个特点：它是被用户主动指定的。有人把你的URL贴进去，说明这个人已经认定你这篇值得当资料看。这跟一个来路不明的爬虫扫全站，性质完全不同。

拦掉它，直接后果是这个用户在他的笔记本里看不到你的内容。他不会觉得是Google拦的，他会觉得是你的站有问题，然后换一篇同题材的看。

而这些人是什么人？愿意把资料喂进笔记本工具做深度整理的，通常是研究者、分析师、做采购调研的、写行业报告的。放在B2B和高客单价的场景里，这批人的分量不轻。

我的建议是分内容拦：

• 付费内容和会员区——本来就在墙后，官方也说了付费墙不支持，不用额外做什么。
• 原创研究、独家数据、深度长文——这是最纠结的一档。我倾向于放行，理由是被贴进笔记本的多半就是这类，拦掉损失的是你最想影响的那批人。
• 大批量生成的页面、商品列表、聚合页——放不放行都无所谓，它也不会顺着链接爬开。
• 确实不想被任何模型碰的内容——那就别只拦这一个令牌，得系统性地做，而且要接受这条路会越走越窄。

怎么在日志里把这类请求准确捞出来？

给一套能直接用的做法，按顺序做四步。

第一步，先按令牌粗筛。在access日志里同时匹配新旧两个令牌，Google-GeminiNotebook和Google-NotebookLM都要，过渡期内两个都可能出现。别只筛新的。

第二步，把整个类别一起筛。光筛这一个意义不大。把Google-Agent、Google-Read-Aloud、GoogleMessages一起筛出来，你才看得到用户触发型这一类在你站上的整体量级。单看一个令牌，永远得不出“这类流量占比多少”的结论。

第三步，验真伪。用户代理是可以随便伪造的，看到这个字符串不代表真是Google。按前面那张表反查主机名，或者拿官方IP清单比对。这一步不做，你统计的可能是一堆冒名的爬虫。

第四步，看被抓的是哪些URL。这一步的信息量最大，也最容易被跳过。哪几篇被反复贴进笔记本，说明这几篇在别人眼里是“值得存档的资料”。这个名单跟你后台的热门文章榜大概率对不上，而这份差异本身就是选题线索。

最后一步做完，你会发现这套动作的产出根本不只是“要不要拦”，而是一份别人替你标注过的内容价值排序。

这套东西该多久看一次，怎么变成常规动作？

一次性排查的价值有限，变成定期动作才有用。我的建议是三个节奏。

订阅开发者文档变更日志的RSS，这是唯一能第一时间知道令牌变化的渠道。频率是被动的，有更新才有。

每季度核一次IP清单地址。重点不是看内容变没变，而是看你脚本里那个地址还是不是文档当前写的那个，以及拉回来的生成时间是不是新的。这一步花不了10分钟。

每月扫一次日志里的未知用户代理。把出现次数排前面、你的分类规则又归不进已知类别的挑出来，逐个查一下。新抓取器出现的时候，往往是先在日志里露面，官方文档才更新。

这三条加起来一个月不到半小时，但能让你不至于某天才发现有个新抓取器已经在你站上跑了半年。

一个做工业配件的出海站，在日志里翻出了什么？

说个保哥这边的实际例子。一家做工业密封件的出海站，产品偏冷门，客户以采购工程师为主，客单价不低但询盘周期很长。

他们找我本来是问另一件事——网站流量半年没怎么涨，但询盘质量明显变好了，想知道原因。常规的渠道分析没看出名堂，来源构成跟去年差不多。

后来我让他们把access日志按用户触发型这一类的令牌筛了一遍，跨度是最近4个月。

结果有两个。

第一个是量级：这类请求在总请求里占比很低，低到平时根本不会有人注意。所以“它带来多少流量”这个问题，在他们这里答案是几乎没有。

第二个是名单：被反复抓取的页面高度集中，来来回回就是那么几篇。而且不是首页、不是产品列表页、不是他们花钱推的落地页，是几篇讲材料选型和失效分析的技术文章——那几篇在后台的浏览量排名相当靠后，属于写完就没人管的类型。

这个对照很说明问题。浏览量高的页面，是被人看的；被贴进笔记本工具的页面，是被人拿去做决策的。后者的商业价值密度明显更高，而站内的常规数据完全反映不出这一层。

他们后来做了三件事：把那几篇技术文章从“写完就放着”提到了定期更新的序列里；照着同样的题材角度又补了几篇；把这几篇的内部链接结构重新梳理了一遍，让相关产品页更容易被顺带看到。

要说明的是，我没法把后来询盘质量的变化单独归因到这几个动作上，中间他们还改了别的东西，没有对照组。这里能确定的只有一件事：日志里那份被抓取名单，指出了一批他们自己没重视的高价值内容。这个发现本身就值回票价，至于后续效果，得再观察。

这件事上最容易犯的三个判断错误是什么？

把我见到和自己想过的错误路径列一下。

第一个是把改名当成新增威胁。这个抓取器2025年10月就在名单上了，这次只是换了名字。你的站从去年秋天起就一直在被它抓，改名前后没有任何行为变化。所以正确的心态不是“又来一个”，而是“原来它已经在这儿快一年了”。

第二个是以为写了Google-Extended就管住了。这个误会我觉得会很普遍。Google-Extended是用来控制内容用于模型训练和相关用途的令牌，它属于常规抓取器那一份名单。而Google-GeminiNotebook不在那份名单里。两份名单，两套规则，前者管不到后者。

第三个是拿网络面的数字当流量的数字。就是前面说的4.84倍。这个数字说明Google在这一类上的投入很重，但它不告诉你今天有多少请求打到了你的服务器。混着用，早晚要在会议室里被人当场问住。

这类抓取器有没有可能反过来变成流量入口？

值得想一想，因为答案会影响你今天的态度是防守还是布局。

先泼盆冷水：以现在的产品形态看，可能性不大。用户把资料收进笔记本，是为了在一个干净的界面里把它读完、问透，产品设计的目标就是让他不用再跳出去。这条动线上，回访原站是个多余动作。

但有个前提值得注意：这个场景里的用户，是带着明确研究目的来的。他不是随手刷到你，是主动把你收进了资料库。这种关系的质量，比一次泛泛的页面浏览高出不止一个档次。

所以真正的机会不在“把他引回来”，而在“让他在那个界面里读到的东西，足够让他记住是谁说的”。

具体三条。第一，重要结论旁边带上你的品牌名或者产品名，别写成没有主语的通用陈述——纯文本被抽走之后，版式、logo、导航全没了，能留下你名字的只有正文本身。第二，独家数据和方法要在文中交代来源是你，而不是放在页脚的版权声明里。第三，把你能提供而文章本身给不了的东西写清楚，比如工具、数据集、可预约的咨询——这是唯一能让他产生跳出动作的理由。

这三条的共同点是：假设排版全部丢失、只剩纯文字，你的内容还认不认得出是你的。这个自测标准，其实对所有AI消费场景都适用，不止这一个产品。

如果只有十分钟，先做哪三件事？

这篇讲了不少机制，但真要动手，优先级是很清楚的。给一份十分钟能做完的最小清单。

第一件，全局搜一下Google-NotebookLM这个旧字符串。范围包括Nginx和Apache配置、CDN规则、日志分析脚本、爬虫分类表、内部文档。找到了就把新令牌加上去并存，找不到就说明你从来没管过这一类，那更要往下做。

第二件，检查同步IP清单的定时任务。看两样：地址是不是文档当前写的那个，以及拉回来的生成时间新不新。如果你根本没有这样的任务，那这一步跳过，但要知道你的爬虫验证是靠反向DNS单条腿走路的。

第三件，把用户触发型这一整类的令牌在日志里筛一遍。不为了拦，就为了看看被抓的是哪些页面。这一步的产出跟前两步完全不同——前两步是补漏洞，这一步是拿信息。

三件事做完，你对这件事的掌握程度就已经超过绝大多数同行了。剩下的拦不拦、怎么拦，反倒都是可以慢慢想的。

半年后回头看，这篇里哪些会过期，哪些不会？

保哥习惯在写完一件时效性强的事之后，标一下保质期，免得半年后有人拿着过期结论去做决策。

会过期的是这些：具体的令牌拼写、用户代理字符串里的Chrome版本号、各份IP清单的前缀条数、旧令牌的支持期限、清单文件的地址和文件名。这些全是当期取值，随时会变。

不会过期的是这些：用户触发型这个分类本身及其不受robots.txt约束的逻辑、验证时反向DNS后缀不止googlebot.com一种、清单地址变更后旧地址仍返回旧数据这种失效模式、以及“被贴进笔记本的页面和浏览量高的页面是两批”这个观察。

分清这两组，是判断一篇技术文章还能不能用的通用办法：依赖当期取值的结论，过期；依赖机制的结论，长得多。

顺带说一句，按这个标准回头看，这次改名本身反而是最不重要的那部分。它只是一个把整类问题推到台前的由头。

常见问题解答

我在robots.txt里写了禁止Google-GeminiNotebook，到底有没有用？

按官方说法，用户触发型抓取器一般会忽略robots.txt规则，所以大概率没用。写了不会有坏处，但你不能把它当成已经拦住了。真要拦，得在CDN、WAF或者Web服务器层按用户代理做拒绝，那才是能真正生效的位置。

我已经在robots.txt里屏蔽了Google-Extended，是不是就一起管住了？

管不住。Google-Extended属于常规抓取器那份名单，Google-GeminiNotebook属于用户触发型名单，是两份不同的清单、两套不同的规则。屏蔽前者对后者没有任何约束力。这两个令牌需要分别处理。

旧令牌Google-NotebookLM到底哪天停用？

没有确切日期。官方文档表格里标的是支持至2026年8月，但同一天的变更日志说会继续支持旧值以便平稳过渡，没给期限。两处口径不完全一致。稳妥做法是新旧两个令牌在你的规则里并存，别赌哪一天。

我的服务器日志里根本没见过这个用户代理，是不是就没事了？

先确认是真没有，还是没筛出来。常见原因有三个：只筛了新令牌没筛旧的；日志格式里没记录用户代理字段；或者CDN在边缘就把这类请求处理掉了，源站日志根本看不到。建议把这一整类的令牌一起筛，并且去CDN的日志里也查一遍。

它抓走我的内容之后，会不会影响我的搜索排名？

这是两套系统。用户触发型抓取器抓的内容进的是用户自己的笔记本，跟搜索索引不是一条链路，本身不构成排名信号。真正需要留意的是间接影响：如果你的深度内容在别的界面里被读完了，那次本该发生的网站访问就不发生了。这是流量层面的事，不是排名层面的事。

那我到底该拦还是该放？

分内容看。付费墙后的内容不用管，官方明说不支持。大批量生成的页面拦不拦都无所谓。最需要决策的是原创研究和深度长文这一档——被贴进笔记本的主要就是这类，拦掉损失的恰恰是你最想影响的那批专业读者。除非你有明确理由，我倾向于放行，然后把精力花在从日志里读出哪些内容被当成了决策依据。

权威参考资料