Google重写抓取预算指南：独立站SEO别再只盯Googlebot

如果服务器日志里突然出现 Google-Agent、Google-GeminiNotebook，或者运维团队发现 Google 的 IP 列表换了目录，最危险的处理不是“没看见”，而是把所有名字里带 Google 的请求都当成 Googlebot：要么全部放行，要么全部拦截。

Google 在 2026 年连续更新抓取基础设施文档。7 月 22 日，它重新梳理了抓取预算指南；7 月 16 日把 NotebookLM 抓取器更新为 Google-GeminiNotebook；5 月开始提供实验性的 Web Bot Auth 验证方法；3 月又新增了代表用户执行网页操作的 Google-Agent。

这些变化不是一次新的排名算法更新，也不意味着网站需要“讨好更多爬虫”。真正的信号是：Google 访问网站的目的已经不只包括建立搜索索引，还包括 Shopping、广告、Gemini 产品以及用户触发的 Agent 操作。 独立站需要把抓取管理从一条 Googlebot 规则，升级为“识别请求类型、控制 URL 库存、保护服务器容量、验证真实身份”的技术体系。

先说结论：这次不是排名更新，但有三类网站需要行动

Google 的 7 月 22 日 changelog 明确说，本次对抓取预算指南的改动是润色、澄清术语和改善行文，并没有宣布抓取算法或排名系统发生变化。因此，不要把一次文档更新包装成“Google SEO新规则”。

但下面三类网站应该立即检查配置：

1. 写死 User-Agent 的网站 ：WAF、CDN、防火墙或日志规则中仍只识别旧的 Google-NotebookLM ，或依赖带错误分号的 Google-InspectionTool 字符串。
2. URL 数量膨胀的网站 ：Shopify筛选页、站内搜索页、排序参数、跟踪参数和重复分类组合不断生成，导致 Google 把请求浪费在低价值 URL 上。
3. 开始承接 AI Agent 访问的网站 ：B2B价格页、产品页或结账流程可能被用户触发型 Agent 访问，但团队仍用只针对自动爬虫的 robots.txt 逻辑判断流量。

小型 B2B 官网如果只有几百到几千个稳定页面，通常不需要做复杂的抓取预算项目。保持 Sitemap 更新，并定期检查Search Console页面索引报告是否出现异常，往往比研究“如何让 Google 多爬”更有价值。

2026年Google抓取文档到底更新了什么？

关键判断是：“文档改了”不等于“算法改了”，“抓取器改名”也不等于“排名信号新增”。 只有当网站的访问控制、日志解析或白名单依赖旧字符串和旧地址时，才需要立即修改技术配置。

Google访问网站的请求，不再只是Googlebot

Google 官方把爬虫与抓取器分为三类。它们的触发方式、robots.txt 行为和验证方式并不相同。

1. 普通爬虫：自动发现内容，并遵守robots.txt

Googlebot、Googlebot-Image 和 Storebot-Google 等普通爬虫用于建立搜索索引、处理图片或支持特定 Google 产品。它们在自动抓取时遵守 robots.txt，IP 通常来自官方 common-crawlers.json。

对于 SEO 团队，这仍然是搜索收录的主路径。Sitemap、内部链接、规范化、状态码和服务器稳定性仍然决定 Google 能否高效发现与重新处理重要页面。

2. 特殊爬虫：基于具体产品关系访问

AdsBot 等特殊爬虫服务于特定产品，可能不会遵守全局 User-agent: * 规则。网站在使用相应广告或产品功能时，已经与 Google 存在特定访问关系。

这意味着“robots.txt 已经禁止全部爬虫”不一定能解释所有 Google 请求。广告落地页异常时，也不能只检查 Googlebot 是否被允许。

3. 用户触发型抓取器：由用户动作发起，通常忽略robots.txt

Google-Agent、Gemini Notebook、Google Messages 和 URL 检查等请求，是用户在某项 Google 产品内触发的单次访问。Google 官方说明，这类抓取器通常忽略 robots.txt，因为请求来自用户操作，而不是自动遍历网站。

其中：

• Google-Agent 由托管在 Google 基础设施上的 Agent 使用，代表用户浏览网页或执行操作；
• Google-GeminiNotebook 访问用户主动添加到 Gemini Notebook 项目中的来源 URL；
• Google-InspectionTool 与 Search Console URL 检查和部分测试工具有关。

因此，Cloudflare Content Signals或 robots.txt 不能被当作统一的“AI访问总开关”。是否允许访问，需要先看请求属于自动爬虫、特殊爬虫还是用户触发型抓取器，再看 CDN/WAF、登录权限与业务规则。

Google抓取预算真正由两部分决定：容量上限与抓取需求

Google 将抓取预算定义为一组 Google 能够抓取并且想要抓取的 URL。它由两个不同因素共同决定。

抓取容量上限：服务器能承受多少请求

抓取容量上限反映 Google 在不压垮服务器的前提下可以建立多少并行连接、保持多久。下面这些信号会让容量下降：

• TTFB 与整体响应延迟持续上升；
• 大量出现 5xx 服务器错误；
• 频繁返回 429 Too Many Requests ；
• CDN、源站或渲染服务不稳定；
• 页面加载与渲染需要过多资源。

如果网站健康且抓取需求存在，Google 会逐步提高容量。反过来，服务器变慢时，Google 会主动减少请求。提升抓取能力的第一步不是提交更多 URL，而是先解决源站健康、缓存与响应效率。

抓取需求：Google为什么要再次访问这些URL

不同爬虫有不同需求。例如，投放动态广告时 AdsBot 的访问需求可能更高；Merchant Feed 中的商品会提高 Google Shopping 对相应产品的抓取需求；Googlebot 则会结合网站规模、更新频率、内容质量、相关性、流行度和页面新鲜度决定是否重新抓取。

最可控的因素是 URL 库存。如果 Google 发现大量重复、过期或低价值 URL，即使服务器很快，也可能把请求消耗在错误的位置。

还要注意两个细节：

• Google 按 hostname 计算抓取容量， www.example.com 与 docs.example.com 会被视为不同站点；
• 不同爬虫有各自的抓取需求，但同一 hostname 的容量上限由它们共享。一个产品的高需求可能挤占其他抓取任务可用的服务器容量。

哪些网站才需要把“抓取预算”当成专项？

Google 给出的判断范围是：

• 约100万以上独立页面，并且内容每周有中等频率变化；
• 约1万以上独立页面，并且内容每天快速变化；
• Search Console 中大量 URL 长期处于“已发现 – 尚未编入索引”。

这些数字只是粗略分类，不是硬阈值。更实用的判断如下：

如果网站没有快速变化的海量页面，并且新页面通常当天就能被抓取，就不要把“抓取次数”当 KPI。Google 多访问一次，不会自动带来排名、引用或询盘。

独立站如何减少无效抓取？

1. 先治理URL库存，而不是先扩服务器

优先排查：

• 商品筛选、排序和分页组合；
• 站内搜索结果；
• UTM、广告点击和会话参数；
• 同一商品的多路径 URL；
• 重复语言、国家或货币页面；
• 已删除但仍返回 200 的 soft 404；
• 多层重定向链。

重复内容应优先合并并设置正确的规范 URL；永久删除的页面返回 404 或 410；不希望被抓取的无限滚动或排序页面可按规则在 robots.txt 中阻止。

2. 不要用noindex“节省抓取预算”

Google 必须先请求页面，才能读取 noindex。如果目标是让某类 URL 不再被抓取，用 noindex 反而会继续消耗请求。robots.txt 适合阻止长期不希望 Google 访问的路径，但不能用来临时“腾出额度”，因为除非网站已经撞到容量上限，Google 不一定把省下的请求自动转移给其他页面。

3. 让更新信号可信

Sitemap 只保留真正希望抓取的规范 URL，并为实际发生重要变化的内容维护 <lastmod>。不要每天把全站日期刷新一遍。虚假的更新信号会让 Google 反复请求没有变化的页面。

支持 304 Not Modified、减少重定向链、优化服务器响应与页面渲染，都能降低网站和 Google 双方的资源消耗。

不要只看User-Agent：Google-Agent需要分层验证

User-Agent 是请求方自己声明的字符串，任何人都可以伪造。把 Googlebot 或 Google-Agent 作为唯一白名单条件，等于给攻击者留下一个容易复制的通行证。

更稳妥的验证顺序是：

1. 读取 User-Agent，只用于初步分类；
2. 将请求 IP 与 Google 官方发布的 JSON 范围匹配；
3. 对单次可疑访问做反向 DNS，再把得到的域名做正向 DNS，确认最终回到原 IP；
4. 如果 CDN/WAF 支持，识别 Web Bot Auth 签名。

Web Bot Auth 是一种实验性的加密验证协议。部分 Google-Agent 请求会以 https://agent.bot.goog 身份签名，从而减少仅靠字符串与 IP 带来的伪造风险。但 Google 明确说明：并非所有 Agent、也并非每一次请求都已签名。因此现阶段不能只允许带 Web Bot Auth 的流量，仍要保留 IP、DNS 和 User-Agent 的兼容验证。

多数独立站不需要自己实现签名校验。先询问 CDN、WAF 或 bot management 服务是否已支持；只有在请求量大、访问策略复杂且团队有安全开发能力时，才考虑自建验证逻辑。

对B2B与电商独立站，Agent访问意味着什么？

允许请求进入，只解决了“能不能打开页面”，没有解决“能不能完成任务”。Agent 还需要读懂价格、库存、规格、交付范围、地区限制、退换货、联系方式和下一步行动。

B2B网站常见的问题是：

• 价格完全隐藏，且没有清楚解释询价条件；
• 产品规格只放在图片或下载文件中；
• 登录、验证码或弹窗阻断所有访问；
• 表单字段过多，没有说明必填信息；
• 页面内容与结构化数据不一致。

电商网站还要检查库存、货币、配送国家、促销有效期与 Merchant Feed 是否一致。B2B网站AI Agent可读性的重点不是“放行某个爬虫”，而是让机器和真实采购者都能明确判断：卖什么、适合谁、条件是什么、下一步怎么做。

30天技术SEO行动清单

第1周：盘点请求与配置

• 导出最近30天服务器/CDN日志；
• 分开统计 Googlebot、AdsBot、Storebot、Google-Agent、Gemini Notebook 与 InspectionTool；
• 找出所有写死 User-Agent、IP 地址和旧文档路径的规则；
• 确认旧 Google-NotebookLM 与新 Google-GeminiNotebook 的过渡兼容。

第2周：审计URL库存

• 从 Sitemap、站内链接、Search Console 与日志中合并 URL 清单；
• 按规范页、重复页、参数页、重定向、404/410、soft 404 分类；
• 统计 Google 请求最多却没有搜索、购物或业务价值的 URL 模式；
• 优先修复会无限扩张的筛选和站内搜索路径。

第3周：检查服务器与缓存

• 对照抓取高峰检查 TTFB、 5xx 和 429 ；
• 验证 CDN 缓存、 304 、源站容量与渲染资源；
• 检查关键 HTML、PDF 或数据文件是否过大；
• 确保正文、核心链接、canonical 与转化入口出现在可稳定获取的内容中。

第4周：建立验证与监测

• 自动同步 Google 官方 IP JSON，不维护人工静态列表；
• 对 User-Agent、IP/DNS 验证结果与响应状态分别记录；
• 在支持的 CDN/WAF 上测试 Web Bot Auth，但保留兼容回退；
• 每月把抓取量与有效收录、商品更新、自然流量、AI可见性和询盘一起复盘。

如果团队希望把服务器抓取、技术 SEO、AI 可访问性与内容证据放进同一套执行框架，可参考Google SEO/GEO优化服务。目标不是追求更多爬虫请求，而是确保重要页面能被正确访问、理解、验证，并最终支持品牌可见性与询盘转化。

常见问题

Google在2026年7月更新抓取预算指南，是否代表排名算法更新？

不是。官方 changelog 把这次更新描述为文字、术语和结构上的润色与澄清，没有宣布抓取算法或排名系统改变。

小型独立站需要优化Google抓取预算吗？

通常不需要做专项。只要 Sitemap 更新正常，新页面能及时被抓取，Search Console 没有大规模“已发现 – 尚未编入索引”，应优先改善内容质量、内部链接、状态码与服务器稳定性。

Google-Agent和Googlebot有什么区别？

Googlebot 是用于自动发现和处理内容的普通爬虫，会遵守 robots.txt；Google-Agent 是由用户请求触发、代表用户浏览或执行操作的 Agent，属于用户触发型抓取器，使用专门发布的 IP 范围。

robots.txt能阻止Google-Agent吗？

不能把它当作可靠的统一控制方式。Google 官方说明，用户触发型抓取器通常忽略 robots.txt。需要通过网站访问权限、CDN/WAF、登录与业务级授权控制敏感功能。

是否应该立刻部署Web Bot Auth？

多数独立站不必自研。它仍处于实验阶段，而且并非每一次 Google Agent 请求都签名。先检查现有 CDN/WAF 是否支持，并继续保留 IP、DNS 与 User-Agent 验证。

Google-NotebookLM需要马上从规则里删除吗？

不建议立刻删除。官方说明旧值支持到2026年8月。过渡期应同时识别 Google-NotebookLM 与新的 Google-GeminiNotebook，并在确认日志已完成迁移后再清理旧规则。

参考来源

• Google Crawling Infrastructure：Changelog
• Google Crawling Infrastructure：Optimize your crawl budget
• Google Crawling Infrastructure：Overview of Google crawlers and fetchers
• Google Crawling Infrastructure：List of Google user-triggered fetchers
• Google Crawling Infrastructure：Verify requests from Google crawlers and fetchers
• Google Crawling Infrastructure：Authenticate requests with Web Bot Auth