Google 搜索 URL 参数：2026 年哪些还能用

大约从 2025 年 9 月开始，不少 SEO 工具和自定义脚本悄悄失灵了。罪魁祸首是什么？Google 不再稳定支持 num=100 这个参数——多年来，进阶用户一直靠它把每页结果拉到 100 条。Google 没有正式发布弃用公告，只是有一位发言人对 Search Engine Land 表示，这个参数“从未被正式支持”。同一时期，Google 在旧有 tbm 垂类之外又引入了更多 udm 模式，并宣布国家/地区顶级域名会逐步重定向到 google.com；同时还表示 AI Overviews 的月活已达到 25 亿以上。

如果你一直在搭建搜索链接、追踪排名，或者利用 Google 的 URL 参数做自动化研究，那么很有可能你的一部分流程现在已经在不知不觉中退化了。在 Thunderbit，我们查阅了 Google 现有文档、近期变更公告、逆向分析资料，并做了实时抽查，目的就是把稳定可控的参数和仅在特定场景有效的参数区分开来。最终整理出这份带时间标记、适合先测试再上线的 Google 搜索 URL 参数参考，涵盖 tbm/udm 映射、用于城市级地理定向的 uule 编码公式，以及能帮你节省数小时排错时间的参数冲突清单。

什么是 Google 搜索 URL 参数？

Google 搜索 URL 参数，就是出现在 Google 搜索链接中 ? 后面的键值对。它们能控制你搜索什么、看到哪个国家/地区的结果、以及结果是图片、新闻还是经典蓝色链接。

一个典型的 Google 搜索 URL 可以拆成这样：

https://www.google.com/search?q=best+crm+software&hl=en&gl=us&tbs=qdr:m

• 基础 URL： https://www.google.com/search
• ? 表示查询字符串开始
• q=best+crm+software 是搜索词（空格会被编码成 +）
• & 用来分隔各个参数
• hl=en 将界面语言设为英文
• gl=us 让 Google 按“你在美国搜索”的视角展示结果
• tbs=qdr:m 将结果限制为过去一个月

这里有个很值得区分的点：像 site:、filetype:、intitle: 这类搜索运算符，是写在 q= 的值里面的，也就是查询词本身。像 gl、hl、tbs 这样的Google 搜索 URL 参数则是 URL 里的独立键，用来控制 Google 如何处理和展示结果。两者都重要，而且是相互配合的，但本质上不是一回事。

Google 从未公开过一份统一、带版本号的参数规格说明。部分参数来自 高级搜索表单，部分来自 Custom Search API，另一些则是通过观察 Google 自己的 URL 逆向推出来的。这也意味着，你现在读到的内容基于实测和已公开行为，而不是官方 API 合约。

为什么 Google 搜索 URL 参数在 2026 年依然重要

URL 参数不只是开发者才会关心的东西。无论你在 SEO、营销、销售、运营还是产品岗位，只要你需要知道 Google 在某个具体时间、某个具体市场、针对某个具体查询到底展示了什么，这些参数就是你的工具箱。

下面简单拆解一下谁会受益，以及怎么受益：

使用场景	受益人群	关键参数
跨国家/地区的 SEO 排名跟踪	SEO 与营销团队	gl、hl、uule、pws
按日期监控竞争对手	战略与运营团队	tbs、带 site: 的 q
特定市场的广告监控	付费媒体团队	gl、hl、udm
本地 SEO 审计（城市级）	本地商家	uule、gl
内容研究 / 趋势追踪	内容团队	tbs（日期筛选）、lr
将搜索数据喂给 AI/LLM 应用	产品与数据团队	多个参数 + 结构化提取

2026 年之所以和以前明显不同，有三大变化：

1. num=100 不再可靠。 过去那个“每页 100 条结果”的技巧在 2025 年 9 月后就不再稳定 了。Google 并没有正式弃用它；发言人的说法是，这个参数从来就没有正式被支持。
2. 国家顶级域名重定向是迁移过程，不是已经彻底完成的切换。 Google 在 2025 年 4 月宣布 ，各国/地区域名（如 google.co.uk、google.de 等）会逐步重定向到 google.com。Google 目前并未发布完成通知，所以不要默认所有地区表现都已经完全一致。
3. AI Overviews 改变了搜索结果页。 Google 表示，AI Overviews 的月活已达到 25 亿以上，覆盖 200 多个国家和地区。逆向分析出来的 udm 模式在某些场景下确实会改变结果展示，但它并不是一个稳定、官方的 AI Overview 开关。

如果你的工作流没有跟上这些变化，你很可能已经在不知情的情况下拿到了失真或误导性的结果。

Google 搜索 URL 参数速查表（2026）

在深入讲解之前，先给你一张目前我能整理出的最新速查表。建议收藏。

参数	作用	示例值	状态
q	搜索词（可在内部使用运算符）	q=best+crm+software	✅ 可用
hl	界面语言	hl=en、hl=ja	✅ 可用
gl	国家/市场上下文	gl=us、gl=jp	✅ 可用
lr	限定结果内容语言	lr=lang_en	✅ 可用
cr	限定结果托管国家/地区	cr=countryUS	✅ 可用
start	分页偏移量	start=10（第 2 页）	✅ 可用
num	每页结果数（历史参数）	num=100	⚠️ 未正式支持，2025 年 9 月后不稳定
udm	上下文内容模式	udm=14（经典网页）	⚠️ 逆向分析得出，视场景而定
tbm	搜索垂类	tbm=isch（图片）	⚠️ 仍可见，需与 udm 一起测试
tbs	时间筛选、排序、逐字匹配	tbs=qdr:w	✅ 可用
safe	SafeSearch 控制	safe=active	✅ 可用
filter	去重过滤	filter=0	✅ 可用（实测）
nfpr	关闭自动纠错	nfpr=1	✅ 可用（实测）
pws	关闭个性化	pws=0	✅ 可用
uule	城市/DMA 级地理定向	uule=w+CAIQICI...	✅ 可用（逆向分析）
as_q、as_epq、as_eq 等	高级搜索表单字段	各种	✅ 可用
as_sitesearch	限定到某个域名	as_sitesearch=example.com	✅ 可用
as_filetype	限定文件类型	as_filetype=pdf	✅ 可用
ie、oe	输入/输出编码	ie=UTF-8	✅ 可用（通常很少需要）
kgmid、si、ibp	Knowledge Graph 实体 / 功能视图	各种	⚠️ 视上下文而定（不建议通用使用）
ei、ved、sxsrf、sclient	会话 / 跟踪 / 遥测	各种	🔒 内部参数（忽略即可）
gbv	基础 HTML 视图（历史参数）	gbv=1	❌ 2026 年不可靠

把 ei、ved、sxsrf 和 sclient 从你保存或分享的任何 URL 中删掉。它们是 Google 自动附加的会话和遥测状态参数，对构造搜索链接没有意义。

目前仍然有效的核心 Google 搜索 URL 参数

下面这些参数我都在 2026 年中做过实测，也是你最常会用到的。

q —— 你的搜索词

q 参数承载你的搜索词。空格会被编码成 + 或 %20。Google 官方文档中的搜索运算符 就是放在这里——它们是写进 q 的值里，而不是单独作为 URL 参数。

几个例子：

• 精确短语： q=%22google+search+url+parameters%22
• 限定站点： q=site%3Aexample.com+pricing
• 限定文件类型： q=filetype%3Apdf+annual+report+2026
• 组合查询： q=site%3Acompetitor.com+intitle%3Apricing+after%3A2026%2F01%2F01

一定要把整个查询值都做 URL 编码。引号、冒号和斜杠都必须正确编码，否则 URL 很容易坏掉。

hl —— 界面语言

hl 控制的是 Google 界面的语言，比如按钮、标签、以及“相关问题”等标题的语言，它也会影响 Google 更偏向展示哪些结果。它使用 ISO 639-1 代码，比如 en、fr、de、ja，也可以用 BCP 47 标签，如 en-gb 或 pt-br。

hl 不会强制所有结果页面都必须是该语言。它只是一个强信号，但如果其他语言的页面相关性更高，Google 仍可能展示它们。若要限制内容语言，请使用 lr。

gl —— 国家 / 地理位置

gl 用 ISO 3166-1 alpha-2 国家代码（如 us、gb、jp、de）来模拟你正在从哪个国家搜索。随着 国家/地区顶级域名逐步重定向到 google.com，gl 现在已经成为获取国家/地区特定结果的主要方式。

同一个查询，只要 gl 不同，返回的结果、精选摘要和本地结果包都可能完全不一样。例如，q=best+bank&gl=us 和 q=best+bank&gl=jp 看到的银行结果会差很多。

实用建议：gl 最好和 hl 搭配使用，这样本地化结果更准确。比如 gl=jp 搭配 hl=en，就能看到日本市场结果，但界面是英文——这对国际 SEO 审计很有用。

lr 和 cr —— 语言限制与国家限制

这两个参数经常被混淆，但区别很关键：

• lr=lang_en：把结果限制为英文页面（内容语言）
• cr=countryUS：把结果限制为托管在美国的页面（服务器所在地 / 国家归属）
• gl=us：模拟“从美国进行搜索”（影响排序、本地结果和广告）

lr 和 cr 都可以在 Google 的 高级搜索表单 里找到。组合时要小心——lr=lang_en + cr=countryJP 的意思是“只看托管在日本的英文页面”，范围会非常窄。下面的冲突章节会再细讲。

start —— 分页

start=10 表示从第 11 条结果开始显示（第 2 页），start=20 是第 3 页，以此类推。由于 num=100 已经不再可靠，默认每次按 10 递增 start 是更安全的做法——但 Google 仍然可能重写或限制分页。

过去用于拉满 100 条结果的 num=100&start=0 技巧已经 不再可用。如果你的脚本里还保留着 num，建议删掉——它现在会被悄悄忽略。

pws —— 关闭个性化

pws=0 用来请求 Google 关闭基于账户的个性化结果。这对 SEO 排名跟踪非常重要，因为你不希望结果被自己的搜索历史、点击记录或账户偏好污染。

但要提醒一点：pws=0 只能降低个性化影响，并不能消除所有上下文因素。Google 也说明了，结果仍可能因时间、位置、语言和设备而变化。严格来说，根本不存在真正“中立”的 Google SERP。

safe 和 filter —— 安全搜索与去重过滤

• safe=active 会开启 SafeSearch；safe=off 则关闭。注意，账户设置、管理员策略、网络配置或地区法律都可能覆盖这个参数。
• filter=0 会关闭 Google 的重复结果过滤。当你想看到 Google 拥有的全部结果，包括那些通常会被折叠的近似重复页面时，这个参数很有用。

nfpr —— 关闭自动纠错

nfpr=1 可以阻止 Google 在它认为你拼写有误时强行改写你的查询。这对追踪拼写特殊的品牌词、技术术语，或者竞争对手故意投放的错拼词非常有用。

需要注意的是，nfpr=1 只会抑制强制改写。如果你想更全面地控制搜索结果——包括禁用同义词扩展、拼写变体和其他自动修改——应该使用 tbs=li:1（逐字匹配模式），下面的 tbs 章节会详细讲。

tbm 到 udm 的迁移：到底变了什么，现在该用什么

这是近年来最重要的参数变化之一——也是最容易被夸大的一个。

tbm 长期以来一直是切换 Google 搜索垂类的常用方式，比如图片、新闻、视频、购物等。与此同时，Google 也引入了一个数字化的 udm 体系，包含了部分重叠和新增的模式。由于 Google 并未公开一个稳定的消费者版映射表，所以更合适的理解方式是：把它看作上下文映射，而不是一个干净、彻底替代关系。

完整的 tbm 到 udm 映射表

下面的映射综合了界面行为观察和截至 2026 年 8 月 12 日的实时抽查。由于匿名请求里有些值会被删除或重写，所以每一行都应该在实际使用的账户、地区和客户端环境中做测试：

旧参数	旧值	新参数	新值	状态
tbm=lcl	地点/本地	udm=1	地点/本地	⚠️ 视场景而定
tbm=isch	图片	udm=2	图片	⚠️ 视场景而定
tbm=vid	视频	udm=7	视频	⚠️ 视场景而定
tbm=nws	新闻	udm=12	新闻	⚠️ 视场景而定
—	—	udm=14	经典网页结果（无 AI Overviews）	🆕 新模式，无对应 tbm
—	—	udm=18	论坛	🆕 新模式，无对应 tbm
tbm=shop	购物	udm=28	购物	⚠️ 视场景而定
tbm=bks	图书	udm=36	图书	⚠️ 视场景而定
—	—	udm=39	短视频	🆕 新模式，无对应 tbm
—	—	udm=50	AI Overview 模式	🆕 新模式，无对应 tbm

Google 并没有公开一个稳定的 udm 注册表——这一点非常关键。这些值都是通过观察 Google 自己的界面行为 逆向推导 出来的。URL 是否生效会因账户、地区、客户端、Cookie 和实验分组不同而变化。 我在测试中发现，有些 udm 值在匿名 HTTP 请求里会被删掉，但在交互式浏览器会话中又能正常使用。不要假设每个值都能通用。

udm=14 的作用（以及为什么 SEO 圈都爱它）

udm=14 已经成了 SEO 社区里的“心头好”。Android Central 曾把它描述为 一种在不显示 AI Overviews 的情况下请求经典网页结果页的方法。在很多会话中，它确实会生成传统的蓝色链接 SERP，但这并不是官方、也不是绝对稳定的保证。

为什么这很重要？如果你在做排名跟踪或 SEO 审计，AI Overviews 可能会把自然结果挤到首屏下方，让你更难判断真实排名。若 Google 接受 udm=14，它能让你看到更干净的页面。

但也要说明：udm=14 并不保证在任何上下文里都有效。在 2026 年 8 月 12 日的实测中，Google 有时会根据请求环境删除或重写 udm 值。最终表现会因会话、账户、地区、客户端和实验分组而异。

另外，虽然观察到 udm=50 和 AI Mode/AI 结果有关，但它不应被描述为“对任意查询都能强制显示 AI Overview”的稳定手段。

该怎么做：把工作流从 tbm 迁移到 udm

我的建议是：

• 新项目： 把 udm 当作实验性 / 上下文型输入，并做好兜底方案。
• 现有工作流： 在相关场景里同时支持并测试 tbm 和 udm，不要默认迁移已经完成。
• 绝对不要同时用两者： 当 URL 里同时出现 tbm 和 udm 时，行为是不可预测的。在我的测试里，Google 有时会把两者都删掉，然后返回普通查询结果。这个问题在下面的冲突章节还会讲。

完整的 tbs 语法：自定义日期范围、按日期排序和逐字匹配

tbs 是 Google 搜索 URL 工具箱里最强大的参数之一，但大多数教程都只讲了皮毛。它能处理时间筛选、按日期排序、逐字匹配等功能，而且全都被压缩在一个逗号分隔值里。

标准时间筛选

tbs 值	含义	示例 URL 片段
qdr:h	过去 1 小时	&tbs=qdr:h
qdr:d	过去 24 小时	&tbs=qdr:d
qdr:w	过去 1 周	&tbs=qdr:w
qdr:m	过去 1 个月	&tbs=qdr:m
qdr:y	过去 1 年	&tbs=qdr:y

这些是大多数指南都会讲到的基础内容，但 tbs 还能做得更多。

自定义日期范围

如果你需要某个具体时间窗口内的结果，可以使用 cdr:1,cd_min:MM/DD/YYYY,cd_max:MM/DD/YYYY 语法：

&tbs=cdr:1,cd_min:01/01/2026,cd_max:06/01/2026

这会把结果限制在 Google 认为日期介于 2026 年 1 月 1 日和 6 月 1 日之间的页面。对于竞争研究非常有价值，比如“竞争对手在 2026 年第一季度都发了哪些关于定价的内容？”不过要记得把整个值做 URL 编码，因为冒号和斜杠都需要编码。

一个实用提醒：Google 对日期的关联并不总是准确。搜索结果里显示的日期只是 Google 的最佳推测，不一定是真实发布日期。一定要回到目标页面上再次核实。

按日期排序与逐字匹配模式

下面这一段，是很多竞品文章都没覆盖到的内容。

sbd:1 会按日期排序结果（最新优先）。单独使用时，它很有用，但算不上特别惊艳。真正的技巧是，你可以把它和时间范围筛选 合并到一个 tbs 值里：

&tbs=qdr:m,sbd:1

这样你得到的就是过去一个月、按日期排序的结果，最新内容排在最前面。这是查找某个主题刚发布内容最快的方法。我在监控竞争对手内容时经常用这个组合。

li:1 会开启逐字匹配模式——效果等同于在搜索界面里点击 Google 的“逐字匹配（Verbatim）”工具。它会关闭自动纠错、同义词扩展、拼写变体，以及其他自动查询修改。

li:1 和 nfpr=1 的区别在于覆盖范围：

• nfpr=1：只抑制强制性的拼写/查询改写（例如阻止 Google 把“teh”改成“the”）
• tbs=li:1：关闭所有自动修改——包括拼写、同义词、相关词和个性化调整

你甚至可以叠加多个 tbs 值。例如，tbs=qdr:m,sbd:1,li:1 会返回过去一个月、按日期排序、并且逐字匹配的结果。我的测试里这个组合是可用的，但由于 tbs 本身是未公开语法，还是建议结合你的具体查询再验证一遍。

如何构建用于城市级地理定向的 uule 编码

如果说 gl 是国家级的放大镜，那 uule 就是城市级显微镜。对于本地 SEO——比如查看你的业务在 Denver 和 Dallas 的排名差异，或者 Tokyo 涩谷区的搜索者会看到什么——只靠 gl 远远不够精确。

很多高排名文章只会说“有这个参数”，却没人真正讲清楚怎么生成 uule 编码。下面就是完整拆解。

什么时候用 gl、uule 和 cr

参数	精度	典型用途	需要编码吗？
gl=us	国家级	快速模拟某个国家	否
cr=countryUS	国家级（限制）	按托管国家过滤	否
uule=w+CAIQICI...	城市 / DMA 级	本地 SEO 排名检查	是

uule 编码算法（步骤版）

uule 参数使用的是一种编码后的地理位置名称信号。这个构造方法是 逆向推导 出来的，Google 并没有官方文档说明，但 SEO 社区已经广泛验证过。

更稳妥的做法是编码一个小型 Protocol Buffers 载荷，而不是依赖网上常见的简写方法（后者在处理非 ASCII 字符时容易出错）。具体步骤如下：

1. 获取 Google 认可的标准地点名称。 Google 会通过 Google Ads API 地理定向数据 提供标准地名。例如：New York,New York,United States
2. 把这个名称编码为 UTF-8 字节。
3. 构造一个小型 protobuf 载荷，包含名称及其字节长度。
4. 对载荷进行 Base64url 编码，并在前面加上 w+。

下面是一段可以实现这一点的 Python 代码：

import base64

def encode_varint(value: int) -> bytes:
    out = bytearray()
    while True:
        byte = value & 0x7F
        value >>= 7
        if value:
            out.append(byte | 0x80)
        else:
            out.append(byte)
            return bytes(out)

def build_uule(canonical_name: str) -> str:
    name = canonical_name.encode("utf-8")
    payload = b"\x08\x02\x10\x20\x12" + encode_varint(len(name)) + name
    encoded = base64.urlsafe_b64encode(payload).decode().rstrip("=")
    return "w+" + encoded

# 示例
print(build_uule("New York,New York,United States"))
# 输出: w+CAIQICIeTmV3IFlvcmssTmV3IFlvcmssVW5pdGVkIFN0YXRlcw

把它放进 URL 时，要确保 w+ 里的字面 + 被你的 URL 库正确编码成 %2B。大多数 URLSearchParams 或 urllib.parse.urlencode 实现都会自动处理。

即便 uule 构造正确，它也只是众多地理信号中的一个而已。它并不能覆盖 IP 地址、账户设置、设备类型或实验分组。请把它用于方向性的本地 SEO 检查，不要把它当成能精准保证城市级排名的开关。

当 Google 搜索 URL 参数发生“静默冲突”时会怎样

参数组合可能会静默失效：Google 可能忽略其中一个输入、重写 URL，或者返回完全不同的展示界面。下面这些冲突检查，值得你加入每一个搜索链接工作流。

几乎没有竞品文章会讲参数之间的交互。但如果你正在用多个参数搭建搜索链接——而你大概率就是这么做的——那就必须知道哪些组合能和平共处，哪些组合会互相打架。

gl + uule：谁说了算？

当两者同时存在时，uule 提供的地理位置信号比 gl 更具体。如果你设置 gl=uk，同时又给了一个指向东京的 uule，最终更可能得到的是受东京影响的结果，而不是英国结果。

建议： 如果你在用 uule，要么完全省略 gl，要么把 gl 设成包含该 uule 城市的国家。不要传递互相矛盾的信号。

tbm + udm：不要同时使用

我的测试发现，当同一个 URL 里同时带有 tbm 和 udm 时，Google 有时会把两者都删掉，直接返回普通网页查询。这个行为会因会话和账户不同而变化。

建议： 新项目只用 udm。如果你必须兼容旧流程，那也只能二选一，千万不要两个都带。

lr + cr：双重过滤可能会返回零结果

这是一个很隐蔽的坑。lr=lang_en 会把结果限制为英文内容，cr=countryJP 会把结果限制为托管在日本的页面。两者叠加后，你要找的是“托管在日本的英文页面”——这在整个网络里只是一小撮。

建议： 除非你明确需要交集结果，否则二者只选其一。如果一定要叠加，也要预期结果数量会骤减。

num + start：分页已经坏了

旧脚本里用的 num=100&start=0 现在会悄悄只返回大约 10 条结果。num 参数已经 不再被真正执行，但它也不会报错——只是被忽略了。

建议： 从所有 URL 中移除 num。分页请统一用 start，每次递增 10，并对跨页结果去重。

快速冲突参考

| 组合 | 会发生什么 | 建议 | |---|---|---|---| | gl + uule | uule 提供更具体的信号 | 国家和城市要对齐，或者干脆去掉 gl | | tbm + udm | 行为不可预测，可能都被删掉 | 只用 udm | | lr + cr | 过滤太狠，经常接近零结果 | 二选一 | | num + start | num 被忽略，只返回约 10 条 | 删除 num，用 start 分页 | | nfpr=1 + tbs=li:1 | 相关但不完全相同的控制项 | 针对具体查询测试 | | hl + lr | 界面语言 ≠ 内容语言限制 | 有意识地使用；hl 不是内容过滤器 |

从 Google 搜索 URL 参数到结构化数据提取

到这里，你已经能构造出一个精准的 Google 搜索 URL 了——查询词对、国家对、日期范围对，而且还是经典网页结果。下一步，就是把这些结果里的数据结构化提取出来。

无论你是在做排名跟踪、监控竞争对手，还是把搜索数据喂给研究流程，看到正确结果只是完成了一半。你还需要把标题、URL、摘要、排名位置和日期放进表格或数据库里。

构建一个有针对性的 Google 搜索 URL（把前面内容串起来）

下面是一个组合了多个参数的完整示例：

https://www.google.com/search?q=site%3Acompetitor.com+intitle%3Apricing&hl=en&gl=us&tbs=qdr:m,sbd:1&udm=14&pws=0

拆解如下：

• q=site%3Acompetitor.com+intitle%3Apricing —— competitor.com 上标题里包含 “pricing” 的页面
• hl=en —— 英文界面
• gl=us —— 美国市场上下文
• tbs=qdr:m,sbd:1 —— 过去一个月，并按日期排序
• udm=14 —— 经典网页结果（无 AI Overviews）
• pws=0 —— 关闭个性化

你也可以用 curl 程序化构建：

curl -L -G 'https://www.google.com/search' \
  --data-urlencode 'q=site:competitor.com intitle:pricing' \
  --data-urlencode 'hl=en' \
  --data-urlencode 'gl=us' \
  --data-urlencode 'tbs=qdr:m,sbd:1' \
  --data-urlencode 'udm=14' \
  --data-urlencode 'pws=0' \
  -H 'User-Agent: Mozilla/5.0'

或者用 Python：

import requests

params = {
    "q": "site:competitor.com intitle:pricing",
    "hl": "en",
    "gl": "us",
    "tbs": "qdr:m,sbd:1",
    "udm": "14",
    "pws": "0",
}

response = requests.get(
    "https://www.google.com/search",
    params=params,
    headers={"User-Agent": "Mozilla/5.0"},
    timeout=20,
)
print(response.url)

匿名 HTTP 请求访问 Google 时，经常会拿到没有服务端渲染结果的 JavaScript 外壳，或者出现异常流量提示——这正是基于浏览器的提取方式更有优势的地方。

不写解析器，也能提取 SERP 数据

解析 Google 的 HTML 非常脆弱。DOM 结构经常变化，class 名也会被混淆处理，而且你在浏览器里看到的内容，和原始 HTTP 响应里拿到的内容并不总是一致。

对非开发者来说，更简单的做法是：先在 Chrome 里打开你精心构造的搜索链接，然后使用基于浏览器的提取工具，从可见页面中抓取结构化数据。在 Thunderbit，我们就是用 Chrome 扩展 来处理这类工作流的——你可以用 AI Suggest Fields 自动识别结果标题、目标 URL、摘要文本和可见排名位置，然后把它们直接提取到表格里，无需编写解析器。

这并不是唯一方案。基于代码的方式也能做，尤其适合大规模或重复性提取。但如果是临时研究、审计或一次性的竞争分析，基于浏览器的提取可以完全绕开 HTML 解析的脆弱性。

什么时候应该改用官方 API

这里要强调合规性，而且这很重要。

Google 服务条款 禁止绕过保护机制的自动化访问，而 Google Search Help 也明确把搜索爬虫和用于自动查询排名的软件归类为自动化流量。以生产规模运行 Google 爬虫，会让你面临 IP 封禁、验证码，以及潜在的法律风险。

如果你需要生产级、大规模的搜索数据，正确的路径是使用官方 API。Google 的 Custom Search JSON API 正在 停止向新客户开放——现有用户需要在 2027 年 1 月 1 日前完成迁移，之后每 1000 次查询收费 $5，每天前 100 次免费。对于受控站点搜索，Google 现在推荐 Vertex AI Search。

如果是你自己的网站，Search Console 的 Search Analytics API 才是点击、展示、CTR 和平均排名的第一方数据来源——根本不需要抓取。

所以，URL 参数知识更适合作为诊断和研究工具：用来构建精准搜索链接、做人工审计、理解 Google 展示了什么；但它不能替代大规模场景下的官方 API。

Google 搜索运算符：你查询词里的那些参数

搜索运算符写在 q= 里面，但它们是 URL 参数的重要搭档。下面这张表覆盖了 Google 当前文档里有的运算符，外加一些实战里仍然有效的用法：

运算符	作用	示例
site:	限定某个域名	q=site:example.com+SEO
filetype:	限定文件类型	q=filetype:pdf+annual+report
intitle:	词必须出现在标题中	q=intitle:pricing+SaaS
inurl:	词必须出现在 URL 中	q=inurl:blog+marketing
-	排除某个词	q=apple+-fruit
""	精确短语匹配	q=%22google+search+url+parameters%22
OR	二选一	q=scraping+OR+crawling
before:	只看某日期之前的结果	q=AI+before:2026-01-01
after:	只看某日期之后的结果	q=AI+after:2025-06-01
related:	相似网站	q=related:hubspot.com

真正强大的地方，在于把 q 里的运算符和外面的 Google 搜索 URL 参数组合起来：

q=site:competitor.com+intitle:pricing+after:2026/01/01&tbs=sbd:1&gl=us&udm=14

这个查询会找出 competitor.com 上标题里包含“pricing”、发布时间在 2026 年 1 月之后、按日期排序、面向美国市场、并且显示经典网页结果的页面。这是一个完全由 URL 参数和运算符构成的、非常精确的竞争情报查询。

Google 也说明了，site: 的结果并不保证完整——不要把 site: 查询当成某个站点已收录页面的完整清单。

负责任地使用：Google 服务条款与速率限制

这一部分简短但很重要。

Google 服务条款 禁止滥用访问和绕过保护措施。Google Search Help 也明确把搜索爬虫和自动排名软件列为自动化流量的例子。违反这些条款可能导致 IP 封禁、验证码、账号限制，甚至法律行动。

URL 参数知识最适合用于：手动构造精准搜索链接、为团队创建可收藏的搜索链接、在浏览器里做小规模审计，以及理解 Google 搜索界面的工作方式。若要做生产级自动化，请使用 Google 的官方 API，或者像 Brave Search API 这样的合规第三方搜索数据服务。

在 Thunderbit，我们的 浏览器扩展 主要用于用户主动触发、在可见页面上提取数据，而不是高频率自动向 Google 发起请求。这一点非常关键。

核心结论：你的 2026 Google 搜索 URL 参数工具箱

简明版总结如下：

• 本地化信号优先使用 gl + hl，Google 迁移重定向期间不要只依赖 ccTLD
• 相关场景下要同时测试 udm 和 tbm——二者都不是稳定、版本化的消费级 API
• udm=14 可能请求不含 AI Overviews 的经典网页结果，但 Google 仍可能删除或重写它
• 用 uule 做城市级地理定向，并配合上面的 protobuf 编码公式
• 熟练掌握 tbs，用于精准日期筛选（cdr:1,cd_min:...,cd_max:...）、按日期排序（sbd:1）和逐字匹配（li:1）
• 注意参数冲突：gl vs. uule、tbm vs. udm、lr vs. cr
• num=100 既不可靠，也从未被正式支持——更安全的默认做法是每次用 start 按 10 递增
• 如果要提取结构化 SERP 数据，临时任务可用 Thunderbit，生产级场景则应使用官方 API
• 尊重 Google 服务条款——URL 参数是研究工具，不是抓取许可证

Google 仍然会在没有公告的情况下不断调整参数。我会继续跟进变化并更新这份参考——建议收藏，之后再回来查看。

延伸阅读

• 2026 年最值得用的 9 个 SEO API（附真实单次请求成本数据）
• 如何掌握搜索引擎抓取：完整指南
• 分析和监控网站排名的 27 款顶级工具
• 如何高效使用网页爬虫分页提取数据
• 什么是搜索自动化？优势、工具与策略

常见问题

在 Google 搜索 URL 里，udm=14 是做什么的？

udm=14 可以请求经典网页结果页，而且通常不显示 AI Overviews，这也是它在 SEO 从业者中很受欢迎的原因。它是逆向分析得出的，并不是 Google 官方文档中明确说明的参数；而且 Google 可能会根据会话、账户、地区、客户端和实验分组，删除或重写它。

num 参数在 2026 年还有效吗？

不要依赖它。Google 在 2025 年 9 月后就不再稳定支持 num=100 了，而且发言人明确表示这个参数从未被正式支持。分页更安全的默认方式是每次递增 10 使用 start，并且要核实返回的结果数，因为 Google 仍可能重写或限制响应。

我怎么模拟某个城市发起的 Google 搜索？

使用 uule 参数，并传入经过编码的城市名称。上面的编码章节提供了基于 protobuf 的算法和 Python 示例。你需要先拿到 Google 的标准地名（可从 Google Ads 地理定向数据 获取），再把它编码成类似 uule=w+CAIQICIeNew+York,New+York,United+States 这样的值。

gl、lr 和 cr 有什么区别？

这三个参数分别控制地理和语言定向的不同层面。gl 在国家级别模拟你的搜索位置（影响排序和本地结果）。lr 把结果限制为某种内容语言的页面。cr 把结果限制为托管在某个国家/地区的页面。它们可以组合使用，但像 lr=lang_en + cr=countryJP 这种矛盾组合，会让结果数量大幅减少。

一个 URL 里可以组合多个 tbs 值吗？

可以——在同一个 tbs 参数里用逗号分隔即可。例如，tbs=qdr:m,sbd:1 会筛选过去一个月并按日期排序（最新优先）。你还可以加上 li:1 开启逐字匹配：tbs=qdr:m,sbd:1,li:1。由于 tbs 语法并未正式公开，建议针对你的具体组合做实际测试，确认它们按预期工作。