Google 搜尋 URL 參數：2026 年哪些還能用

大約從 2025 年 9 月開始，很多 SEO 工具和自訂腳本都默默失靈了。罪魁禍首是什麼？Google 不再穩定支援 num=100 這個參數，而這個功能原本讓進階使用者能一次抓取每頁 100 筆結果，大家也已經依賴它很多年了。當時並沒有正式的下架公告——只有一位發言人對 Search Engine Land 表示，這個參數「從未被正式支援」。差不多同一時間，Google 也開始在舊有的 tbm 垂直搜尋之外，推出更多 udm 模式，並宣布國碼網域會逐步重新導向到 google.com，同時還表示 AI Overviews 的月活躍用戶已達 25 億以上。

如果你一直在建立搜尋 URL、追蹤排名，或是利用 Google 的 URL 參數自動化研究流程，那你現在有一部分工作流很可能已經在不知不覺中退化了。在 Thunderbit，我們整理了 Google 現行文件、近期變更公告、逆向工程資料與實際即時測試結果，試著把穩定可用的控制項和情境式參數分開來。這篇文章會提供一份有時效性、而且「先測再上線」的 Google 搜尋 URL 參數參考，涵蓋 2026 年真正重要的內容，包括 tbm / udm 對應關係、用於城市等級地理定位的 uule 編碼公式，以及能幫你省下大量除錯時間的參數衝突問題。

什麼是 Google 搜尋 URL 參數？

Google 搜尋 URL 參數就是出現在 Google 搜尋網址中 ? 後方的 key=value 配對。它們可以控制你搜尋的內容、看到哪個國家的結果，以及結果類型是圖片、新聞還是一般藍色連結。

一個典型的 Google 搜尋 URL 大致如下：

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

• 基礎網址： https://www.google.com/search
• ? 代表查詢字串開始
• q=best+crm+software 是搜尋詞（空格會編成 +）
• & 用來分隔各個參數
• hl=en 把介面語言設為英文
• gl=us 讓 Google 顯示彷彿你在美國搜尋的結果
• tbs=qdr:m 將結果限制為過去一個月

這裡有個很重要的區別：像 site:、filetype:、intitle: 這類搜尋運算子，是寫在 q= 的值裡面，也就是你的查詢內容本身；而 gl、hl、tbs 這類URL 參數則是網址中獨立的 key，用來控制 Google 如何處理與呈現結果。兩者都很重要，而且會一起發揮作用，但本質上不是同一件事。

Google 從來沒有針對這些參數發布過一份完整且版本化的正式規格。有些來自 進階搜尋表單，有些來自 Custom Search API，還有一些則是透過觀察 Google 自己的網址逆向推導出來的。也就是說，你現在讀到的內容是根據實測和已記錄的行為整理而成，不是官方 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 不再可靠。 舊的每頁結果數技巧在 2025 年 9 月開始不穩定失效。Google 沒有正式宣布淘汰它；發言人只是說這個參數從未被正式支援。
2. ccTLD 重新導向是遷移過程，不是已完成的切換。 Google 在 2025 年 4 月宣布 各國國碼網域（像 google.co.uk、google.de 等）會逐步導向 google.com。Google 沒有發布完成公告，所以目前不能假設所有地區行為都完全一致。
3. AI Overviews 改變了 SERP。 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	安全搜尋控制	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	知識圖譜實體／功能視圖	各種值	⚠️ 情境式（一般不建議使用）
ei、ved、sxsrf、sclient	工作階段／追蹤／遙測	各種值	🔒 內部參數（忽略即可）
gbv	基本 HTML 檢視（舊用法）	gbv=1	❌ 2026 年不可靠

請把任何你儲存或分享的 URL 中的 ei、ved、sxsrf、sclient 去掉。這些是 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 編碼。引號、冒號和斜線都需要正確編碼，否則很容易把網址弄壞。

hl — 介面語言

hl 用來控制 Google 介面的語言（按鈕、標籤，以及「People also ask」等標題），也會影響 Google 優先顯示哪些結果。它使用 ISO 639-1 代碼，例如 en、fr、de、ja，或像 en-gb、pt-br 這類 BCP 47 標籤。

hl 不會強制所有結果文件都變成那個語言。它是一個強訊號，但如果其他語言的內容更相關，Google 仍可能顯示不同語言的結果。若要限制內容語言，請改用 lr。

gl — 國家／地理位置

gl 會模擬你正在搜尋的國家，採用 ISO 3166-1 alpha-2 代碼（us、gb、jp、de）。隨著 ccTLD 正逐步重新導向到 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 已不再可靠，現在比較安全的預設是每次把 start 加 10；不過 Google 仍可能重寫或限制分頁行為。

以前那種用 num=100&start=0 一次抓滿 100 筆結果的技巧，現在已經行不通了。如果你的腳本裡還有 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 值 | 意義 | 範例網址片段 | |---|---|---|---| | qdr:h | 過去一小時 | &tbs=qdr:h | | qdr:d | 過去 24 小時 | &tbs=qdr:d | | qdr:w | 過去一週 | &tbs=qdr:w | | qdr:m | 過去一個月 | &tbs=qdr:m | | qdr:y | 過去一年 | &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 的排名差異，或是東京澀谷區的搜尋者會看到什麼，單靠 gl 還不夠精準。

市面上排名靠前的文章幾乎都沒有真正說明要怎麼「建立」uule 編碼——它們通常只說有這個參數，然後就跳過了。下面補上完整說明。

什麼時候用 gl、uule、cr？

參數	粒度	典型使用情境	需要編碼嗎？
gl=us	國家層級	快速模擬某國搜尋	不需要
cr=countryUS	國家層級（限制）	依主機國家篩選	不需要
uule=w+CAIQICI...	城市／DMA 層級	在地 SEO 排名檢查	需要

uule 編碼演算法（逐步說明）

uule 參數使用的是經過編碼的地點訊號。它的構造方式是經過 逆向工程 推導出來的，Google 並沒有正式文件，但 SEO 社群已經廣泛驗證過。

比較安全的做法，是編碼一小段 Protocol Buffers payload，而不是照抄常見的簡化捷徑（因為在非 ASCII 字元下可能會失敗）。流程如下：

1. 取得 Google 的標準地點名稱。 Google 會透過 Google Ads API 的地理目標資料 公布地理目標的標準名稱。例如：New York,New York,United States
2. 把名稱編成 UTF-8 位元組。
3. 建立一小段 protobuf payload，內容包含名稱與其位元組長度。
4. 將 payload 做 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+ 裡面那個字面上的 + 已經被網址工具正確編成 %2B。大多數 URLSearchParams 或 urllib.parse.urlencode 實作都會自動處理。

即使 uule 正確建立了，它也只是眾多地點訊號之一。它不會覆蓋 IP 位址、帳號設定、裝置或實驗分組。請把它當成在地 SEO 的方向性檢查工具，而不是保證精準城市排名的開關。

Google 搜尋 URL 參數何時會悄悄互相衝突？

參數組合有時會默默失敗：Google 可能忽略其中一個輸入、重寫 URL，或回傳不同的結果介面。下面這些衝突檢查，值得你加到每一個搜尋連結工作流程裡。

目前沒有其他文章會完整討論參數之間的互動。但如果你正在建立含有多個參數的搜尋 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 了——正確的查詢、正確的國家、正確的日期區間、傳統網頁結果。接下來要做的，就是把搜尋結果轉成結構化資料。

不管你是在做排名追蹤、監控競爭對手，還是要把搜尋資料送進研究流程，看到對的結果只完成了一半。你還需要把標題、網址、摘要、排名位置與日期，整理成試算表或資料庫可用的格式。

建立一條有針對性的 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)

對 Google 的匿名 HTTP 請求，常常只會回傳 JavaScript 外殼，沒有伺服器端渲染的結果，或是顯示不尋常流量警告——這正是瀏覽器式擷取的優勢所在。

不寫解析器，也能擷取 SERP 資料

解析 Google 的 HTML 是件很脆弱的事。DOM 結構常常變、class 名稱經過混淆，而你在瀏覽器中看到的內容，未必會原封不動出現在原始 HTTP 回應裡。

對非開發者來說，一個更簡單的方法是：先在 Chrome 中打開你精心構造的搜尋 URL，然後用瀏覽器式擷取工具把可見頁面上的結構化資料抓出來。在 Thunderbit，我們做了 Chrome 擴充功能，就是為了處理這種流程——你可以用 AI Suggest Fields 來辨識像結果標題、目標網址、摘要文字與可見排名這些欄位，然後直接擷取成試算表，不需要自己寫解析器。

這並不是唯一的做法。如果你需要大規模或重複性擷取，程式碼方案當然也可行。但對臨時研究、稽核和一次性的競品分析來說，瀏覽器式擷取可以完全避開 HTML 解析的脆弱性。

什麼時候該改用官方 API？

這裡要提醒的是責任使用，而且這點很重要。

Google 的服務條款 禁止繞過保護措施的自動化存取，而 Google Search Help 也明確把搜尋爬蟲和用來自動發送查詢以判定排名的軟體，歸類為自動化流量。若以生產規模運行 Google 爬蟲，你很可能面臨 IP 封鎖、CAPTCHA，以及潛在的法律風險。

如果你需要的是大規模、可持續的搜尋資料，較好的做法是使用官方 API。Google 的 Custom Search JSON API 正在 停止接受新客戶 ——既有使用者可在 2027 年 1 月 1 日前轉移，之後每 1,000 次查詢收費 5 美元，且每天有 100 次免費查詢。Google 也建議未來針對受控網站搜尋改用 Vertex AI Search。

若是你自己擁有的網站，Search Console 的 Search Analytics API 才是取得點擊、曝光、點閱率與平均排名的第一方來源——完全不需要爬取。

你可以把 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: | 詞語必須出現在網址中 | 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 裡面的運算子，和外面的 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 封鎖、CAPTCHA、帳號限制，甚至法律行動。

URL 參數知識最適合用在：手動建立精準搜尋 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 對 uule、tbm 對 udm、lr 對 cr
• num=100 不可靠，而且從來沒有正式支援——更安全的預設是用 start 每次加 10
• 若要結構化 SERP 資料，臨時工作可用像 Thunderbit 這類瀏覽器工具，正式大規模需求則用官方 API
• 尊重 Google 的服務條款——URL 參數是研究工具，不是爬取授權

Google 仍會在沒有公告的情況下持續調整參數。我會隨著變化更新這份參考——記得收藏，並定期回來查看。

進一步閱讀

• 2026 年最好的 9 個 SEO API（含真實每次請求成本資料）
• 如何精通搜尋引擎爬取：完整指南
• 用來分析與監控網站排名的 27 大工具
• 如何用 Web Scraper 分頁高效率擷取資料
• 什麼是搜尋自動化？優勢、工具與策略

常見問題

在 Google 搜尋 URL 中，udm=14 是做什麼的？

udm=14 可以要求傳統網頁結果畫面，且不顯示 AI Overviews，因此在 SEO 從業者之間很受歡迎。它是逆向工程得出的，不是 Google 官方文件化的合約，而且 Google 可能會依工作階段、帳號、地區、用戶端與實驗分組來移除或重寫它。

num 參數在 2026 年還能用嗎？

不要依賴它。Google 在 2025 年 9 月之後已 不再穩定接受 num=100，而且發言人表示這個參數從未被正式支援。請改用 start 每次加 10 作為較安全的分頁預設，並確認回傳的結果數量，因為 Google 仍可能重寫或限制回應。

我要怎麼模擬某個城市的 Google 搜尋？

請使用 uule 參數，並放入經過編碼的城市名稱。上面的編碼章節提供了基於 protobuf 的演算法與 Python 範例。你需要先取得 Google 的標準地點名稱（可從 Google Ads 地理目標資料 取得），再把它編成像 uule=w+CAIQICIeNew+York,New+York,United+States 這樣的 uule 值。

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 語法沒有正式文件，建議你針對自己的查詢組合實際測試，確認效果符合預期。