2025年9月ごろ、SEOツールや自作スクリプトの一部が、ひっそり動かなくなりました。原因は、長年上級ユーザーが1ページ100件の結果取得に頼ってきた num=100 パラメータを、Googleが安定して尊重しなくなったことです。正式な廃止告知はなく、Search Engine Landに対してGoogleの広報担当者が「正式にはサポートしていない」と説明しただけでした。同じ時期に、Googleは旧来の tbm に加えてより多くの udm モードを導入し、国別ドメインは順次 google.com にリダイレクトされる方針を発表し、AI Overviews の月間利用者数が 25億人超 に達したと報告しました。
GoogleのURLパラメータを使って検索URLを組み立てたり、順位計測をしたり、リサーチを自動化しているなら、今まさにいくつかのワークフローが気づかないうちに精度低下している可能性があります。Thunderbitでは、Googleの最新ドキュメント、直近の変更発表、逆解析された参考情報、実機での確認をもとに、安定して使える制御と文脈依存の制御を切り分けました。この記事は、2026年に重要となる Google 検索URLパラメータの、古くても「試してから本番投入すべき」実用リファレンスです。tbm / udm の対応関係、都市レベルの地域ターゲティングに使う uule のエンコード式、そしてデバッグ時間を大きく短縮できるパラメータ衝突まで網羅しています。
Google検索URLパラメータとは？
Google検索URLパラメータとは、Google検索URLの ? の後ろに並ぶ key=value 形式の値です。何を検索するか、どの国の結果を表示するか、画像・ニュース・通常の青いリンクのどれを出すか、といった挙動を細かく制御できます。
典型的な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が米国にいる前提の結果を表示するよう指定tbs=qdr:mが直近1か月の結果に絞り込み
ここで押さえておきたいのは、検索演算子（site:、filetype:、intitle: など）は q= の中に入るという点です。つまりクエリ本文の一部です。一方、URLパラメータ（gl、hl、tbs など）は、Googleが結果をどう処理しどう見せるかを制御するURL上の別キーです。どちらも重要で、相互に作用しますが、役割は異なります。
Googleはこれらのパラメータについて、単一の版管理された仕様を公開していません。一部は 高度な検索フォーム、一部は Custom Search API、残りはGoogle自身のURLを観察して逆解析したものです。つまり、この記事は公式API契約ではなく、実測と公開済み挙動に基づくものです。
2026年にGoogle検索URLパラメータが重要な理由
URLパラメータは開発者だけの話ではありません。SEO、マーケティング、営業、オペレーション、プロダクトなど、特定のクエリについて、特定の市場で、特定の時点のGoogle結果を知りたい人にとって、これらは重要なツールです。
どんな用途に効くのかを簡単に整理すると、次の通りです。
| Use Case | Who Benefits | Key Parameters |
|---|---|---|
| 各国のSEO順位計測 | SEO・マーケティングチーム | gl, hl, uule, pws |
| 日付別の競合監視 | 戦略・オペレーションチーム | tbs, q with site: |
| 特定市場での広告モニタリング | 有料メディアチーム | gl, hl, udm |
| ローカルSEO監査（都市レベル） | ローカルビジネスの運営者 | uule, gl |
| コンテンツ調査 / トレンド追跡 | コンテンツチーム | tbs（日付フィルタ）、lr |
| 検索データをAI/LLMアプリに取り込む | プロダクト・データチーム | 複数パラメータ + 構造化抽出 |
2026年を大きく変えた要素は3つあります。
num=100はもはや安定していません。 旧来の「1ページ100件取得」テクニックは、2025年9月以降、信頼できなくなりました。Googleは正式に廃止したわけではなく、広報担当者は「そもそも正式サポートではなかった」と述べています。- ccTLDのリダイレクトは移行中で、完了ではありません。 Googleは2025年4月に 国別ドメイン（google.co.uk、google.de など）を順次 google.com にリダイレクトすると発表しましたが、完了告知は出ていません。したがって、まだ全ロケールが完全に同じ挙動になるとは限りません。
- AI Overviews がSERPを変えました。 Googleは AI Overviews の利用者が月間25億人超 に達し、200以上の国と地域 に展開したと発表しています。逆解析された
udmモードで一部の状況では結果面を変えられますが、AI Overview を確実に切り替えるスイッチではありません。
もしワークフローをこの変化に合わせて更新していないなら、気づかないうちに精度が落ちた結果や、誤解を招く結果を見ている可能性があります。
Google検索URLパラメータ早見表（2026年版）
詳しい解説に入る前に、まずは最新の一覧を載せておきます。ぜひブックマークしてください。
| Parameter | What It Does | Example Value | Status |
|---|---|---|---|
q | 検索語句（内部で演算子を使える） | q=best+crm+software | ✅ Active |
hl | 表示言語 | hl=en, hl=ja | ✅ Active |
gl | 国 / 市場の文脈 | gl=us, gl=jp | ✅ Active |
lr | 結果を特定言語に限定 | lr=lang_en | ✅ Active |
cr | 結果を特定のホスト国に限定 | cr=countryUS | ✅ Active |
start | ページネーションのオフセット | start=10（2ページ目） | ✅ Active |
num | 1ページの件数（旧来） | num=100 | ⚠️ 正式サポートなし。2025年9月以降は不安定 |
udm | 文脈依存の表示モード | udm=14（従来のWeb） | ⚠️ 逆解析。文脈で変動 |
tbm | 検索縦型 | tbm=isch（画像） | ⚠️ まだ観測されるが、udm と併せて検証推奨 |
tbs | 時間フィルタ、並び替え、verbatim | tbs=qdr:w | ✅ Active |
safe | セーフサーチ制御 | safe=active | ✅ Active |
filter | 重複結果のフィルタリング | filter=0 | ✅ Active（確認済み） |
nfpr | 自動修正を無効化 | nfpr=1 | ✅ Active（確認済み） |
pws | パーソナライズを無効化 | pws=0 | ✅ Active |
uule | 都市 / DMA レベルの地域ターゲティング | uule=w+CAIQICI... | ✅ Active（逆解析） |
as_q, as_epq, as_eq, etc. | 高度な検索フォームの各項目 | Various | ✅ Active |
as_sitesearch | ドメインを限定（高度な検索） | as_sitesearch=example.com | ✅ Active |
as_filetype | ファイル形式を限定（高度な検索） | as_filetype=pdf | ✅ Active |
ie, oe | 入出力エンコード | ie=UTF-8 | ✅ Active（通常は不要） |
kgmid, si, ibp | Knowledge Graph エンティティ / 機能表示 | Various | ⚠️ 文脈依存（一般利用向けではない） |
ei, ved, sxsrf, sclient | セッション / トラッキング / テレメトリ | Various | 🔒 内部用（無視してよい） |
gbv | ベーシックHTML表示（旧来） | gbv=1 | ❌ 2026年は不安定 |
保存したり共有したりするURLからは、ei、ved、sxsrf、sclient を外してください。これらはGoogleが自動付与するセッション状態やテレメトリで、検索URLを組み立てるうえでは不要です。
まだ使えるGoogle検索URLの基本パラメータ
以下は、2026年半ば時点で実際にテストしたものです。最もよく使う項目です。
q — 検索クエリ
q パラメータには検索語句を入れます。スペースは + または %20 にエンコードされます。ここに Googleが公式に案内している検索演算子 を入れます。別のURLパラメータではなく、q の値の中に書くのがポイントです。
例をいくつか挙げます。
- 完全一致フレーズ:
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のUI言語（ボタン、ラベル、「他の人はこちらも質問」など）を制御し、Googleがどの結果を優先するかにも影響します。en、fr、de、ja のような ISO 639-1 コード や、en-gb、pt-br のようなBCP 47タグを使います。
hl は、すべての結果文書をその言語に強制するものではありません。強いシグナルではありますが、関連性が高ければ他言語の結果も表示されます。コンテンツ言語を限定したい場合は、代わりに lr を使ってください。
gl — 国 / 地域
gl は、検索している国をシミュレートします。ISO 3166-1 alpha-2 コード（us、gb、jp、de など）を使います。ccTLDが順次 google.com にリダイレクトされる ため、今では国別結果を取るための主要な手段です。
同じクエリでも gl の値が違うだけで、結果、強調スニペット、ローカルパックが大きく変わることがあります。例えば q=best+bank&gl=us と q=best+bank&gl=jp では、表示される銀行がかなり違ってきます。
ワンポイント: 正確なローカライズ結果を得るには、gl と hl を必ずセットで使うのがおすすめです。gl=jp と hl=en を組み合わせると、日本市場の結果を英語UIで見る形になり、国際SEO監査に便利です。
lr と cr — 言語制限と国制限
この2つはよく混同されます。違いは重要です。
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はセーフサーチをオンにします。safe=offでオフになります。ただし、アカウント設定、管理者ポリシー、ネットワーク構成、地域法規がこの設定を上書きすることがあります。filter=0はGoogleの重複結果フィルタを無効にします。通常なら統合されるような近似重複も含め、Googleが持っている結果をすべて見たいときに便利です。
nfpr — 自動修正を止める
nfpr=1 は、スペルミスだとGoogleが判断したときにクエリを書き換える強制修正を防ぎます。独特な綴りのブランド名、技術用語、あるいは競合が狙っている意図的な誤字クエリの追跡に役立ちます。
ただし、nfpr=1 が止めるのは強制的な書き換えだけです。類義語の展開、スペル変更、その他の自動変更まで含めて広く制御したい場合は、後述の tbs セクションで扱う tbs=li:1（verbatim モード）を使ってください。
tbm から udm への移行：何が変わり、今は何を使うべきか
これは近年で最も大きいパラメータ変更のひとつであり、同時に過大評価しやすい変更でもあります。
tbm は10年以上にわたり、Googleの検索縦型を切り替える一般的な方法でした。画像、ニュース、動画、ショッピングなどです。Googleはこれに重なる、あるいは追加のモードを持つ数値型 udm システムも導入しています。ただし、Googleは安定した一般公開レジストリを出していないため、これをきれいな完全置換ではなく、文脈依存の対応表として扱ってください。
tbm と udm の完全対応表
以下の対応は、2026年8月12日時点で観測されたUI挙動と実機確認を組み合わせたものです。匿名リクエストでは複数の値が削除または書き換えられたため、本番利用するアカウント、地域、クライアントごとに必ず検証してください。
| Old Parameter | Old Value | New Parameter | New Value | Status |
|---|---|---|---|---|
tbm=lcl | Places/Local | udm=1 | Places/Local | ⚠️ 文脈依存 |
tbm=isch | Images | udm=2 | Images | ⚠️ 文脈依存 |
tbm=vid | Videos | udm=7 | Videos | ⚠️ 文脈依存 |
tbm=nws | News | udm=12 | News | ⚠️ 文脈依存 |
| — | — | udm=14 | 従来のWeb（AI Overviewなし） | 🆕 新規、tbm の対応なし |
| — | — | udm=18 | フォーラム | 🆕 新規、tbm の対応なし |
tbm=shop | Shopping | udm=28 | Shopping | ⚠️ 文脈依存 |
tbm=bks | Books | udm=36 | Books | ⚠️ 文脈依存 |
| — | — | udm=39 | ショート動画 | 🆕 新規、tbm の対応なし |
| — | — | udm=50 | AI Overview モード | 🆕 新規、tbm の対応なし |
Googleは安定した udm レジストリを公開していません。ここは重要な注意点です。これらの値は、Google自身のUI挙動を観察して逆解析 されたものです。URLの受け入れ可否は、アカウント、地域、クライアント、Cookie、実験対象グループによって変わります。 私のテストでは、匿名HTTPリクエストでは削除された udm 値が、ブラウザの対話セッションでは問題なく動くことがありました。どの値も普遍的に動くと思わないでください。
udm=14 は何をするのか（そしてSEO担当が好む理由）
udm=14 はSEOコミュニティでかなり人気の高い指定になっています。Android Centralは これを、AI Overviews なしの従来型Web結果を呼び出す方法として紹介しました。多くのセッションでは昔ながらの青いリンクのSERPが出ますが、公式で普遍的に保証されたものではありません。
なぜ重要かというと、順位計測やSEO監査では、AI Overviews がオーガニック結果を折りたたみ以下に押し下げ、順位の把握を難しくすることがあるからです。Googleがそれを尊重してくれる場面では、udm=14 により見やすい結果面を得られます。
とはいえ、udm=14 があらゆる文脈で動く保証はありません。2026年8月12日の実機確認では、リクエスト条件によって udm 値が削除されたり書き換えられたりするケースがありました。セッション、アカウント、地域、クライアント、実験対象グループ次第で結果は変わります。
udm=50 は AI Mode / AI結果の文脈で観測されていますが、任意のクエリに対してAI Overview を強制する確実な方法だと説明すべきではありません。
どう対応するか：tbm から udm へワークフローを更新する
私のおすすめは次の通りです。
- 新規実装:
udmは実験的・文脈依存の入力として扱い、フォールバックを用意する - 既存ワークフロー: 完全移行済みと決めつけず、必要に応じて
tbmとudmの両方をサポート・検証する - 両方を同時に使わない: URL内に
tbmとudmの両方があると、挙動は予測不能です。私のテストでは、Googleが両方を削除して通常のクエリに戻すことがありました。詳しくは後半の衝突セクションへ
tbs の完全な書式：カスタム日付範囲、日付順ソート、verbatim
tbs はGoogle検索URLツールキットの中でも特に強力なパラメータのひとつですが、多くの解説記事は表面的なところしか触れていません。時間フィルタ、日付順ソート、verbatim モードなどを、カンマ区切りの単一値にまとめて扱えます。
標準的な時間フィルタ
tbs Value | Meaning | Example URL Fragment |
|---|---|---|
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年Q1に競合は価格について何を公開したのか？」といった調査に使えます。コロンとスラッシュはエンコードが必要なので、全体をURLエンコードするのを忘れないでください。
実務上の注意として、Googleの日付関連付けは必ずしも正確ではありません。検索結果に表示される日付はGoogleの推定であり、実際の公開日とは限りません。必ず遷移先ページで日付を確認してください。
日付順ソートと verbatim モード
ここからは、競合記事があまり扱っていない領域です。
sbd:1 は結果を日付順（新しいものから）に並べ替えます。単独でも便利ですが、特に強いのは時間範囲フィルタと1つの tbs 値で組み合わせられる点です。
&tbs=qdr:m,sbd:1
これで、直近1か月の結果を日付順で、新しい順に取得できます。あるテーマで直近公開されたものを探す最速手段です。私は競合コンテンツの監視でこの組み合わせを頻繁に使っています。
li:1 は verbatim モード、つまりGoogle検索画面の「Verbatim」を押したのと同じ効果をURLで指定するものです。verbatim モードでは、自動修正、類義語展開、スペル変更、その他の自動クエリ変更が無効になります。
li:1 と nfpr=1 の違いは範囲にあります。
nfpr=1: 強制的なスペル / クエリ書き換えだけを抑止する（例: 「teh」を「the」に直すのを止める）tbs=li:1: スペル、類義語、関連語、パーソナライズ調整など、あらゆる自動変更を無効化する
複数の tbs 値を重ねることもできます。たとえば tbs=qdr:m,sbd:1,li:1 は、直近1か月の結果を日付順で、verbatim マッチ付きで返します。私のテストではこの組み合わせは動きましたが、tbs は非公開構文なので、対象クエリで実際に確認することをおすすめします。
都市レベルの地域ターゲティング用 uule を作る方法
gl が国レベルのズームレンズなら、uule は都市レベルの顕微鏡です。ローカルSEOで、自社がデンバーとダラスでどう順位変動するか、あるいは東京の渋谷にいる検索者には何が見えるかを調べるなら、gl だけでは精度が足りません。
上位記事の多くは uule の存在には触れても、どう作るか は説明していません。以下で完全に分解します。
gl / uule / cr はいつ使い分けるべきか
| Parameter | Granularity | Typical Use Case | Requires Encoding? |
|---|---|---|---|
gl=us | 国レベル | 手早い国シミュレーション | No |
cr=countryUS | 国レベル（限定） | ホスト国で絞り込む | No |
uule=w+CAIQICI... | 都市 / DMA レベル | ローカルSEO順位確認 | Yes |
uule のエンコード手順（ステップバイステップ）
uule パラメータは、エンコードされた場所名シグナルを使います。この生成方法はGoogleが公式に文書化しているわけではなく逆解析 ですが、SEOコミュニティでは広く検証されています。
よく転記されている簡易手順に頼るより、小さな Protocol Buffers のペイロードをエンコードする方が安全です（非ASCII文字で失敗しにくいため）。流れは次の通りです。
- Googleの正規の地名を取得する。 Google Ads API の地理ターゲティングデータで、Googleは正規化された地名を公開しています。Google Ads API geographic targeting data を参照してください。例:
New York,New York,United States - 名前を UTF-8 バイト列としてエンコードする。
- 名前とそのバイト長を含む小さな protobuf ペイロードを作る。
- ペイロードを 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
#Example
print(build_uule("New York,New York,United States"))
#Output: w+CAIQICIeTmV3IFlvcmssTmV3IFlvcmssVW5pdGVkIFN0YXRlcw
これをURLに入れるときは、w+ の + がURLライブラリによって %2B に正しくエンコードされるようにしてください。多くの URLSearchParams や urllib.parse.urlencode は自動で処理してくれます。
正しく構築した uule でも、あくまで複数の地域シグナルの1つに過ぎません。IPアドレス、アカウント設定、デバイス、実験対象グループを上書きするものではありません。都市レベルの順位を断定するためではなく、ローカルSEOの方向感を確認する用途で使ってください。
Google検索URLパラメータが静かに衝突するケース
パラメータの組み合わせは、何も言わずに失敗することがあります。Googleが片方を無視したり、URLを書き換えたり、別の表示面を返したりするのです。以下の衝突チェックは、あらゆる検索リンクのワークフローに組み込む価値があります。
競合記事でパラメータ同士の相互作用を扱っているものはほとんどありません。しかし、複数のパラメータを使って検索URLを作っているなら、どの組み合わせが相性良く、どれがぶつかるのかを知っておく必要があります。
gl + uule: どちらが優先される？
両方がある場合、uule の方が gl より具体的な位置シグナルになります。gl=uk としていても uule が東京を指していれば、UKではなく東京寄りの結果になります。
推奨: uule を使うなら、gl は入れないか、uule の都市を含む国に合わせてください。矛盾するシグナルは送らないのが基本です。
tbm + udm: 両方使わない
私のテストでは、同じURLに tbm と udm が両方あると、Googleが両方を削除して通常のWebクエリに戻すことがありました。挙動はセッションやアカウントによって不安定です。
推奨: 新規実装では udm のみを使ってください。旧来ワークフローを支援する必要がある場合でも、どちらか一方にしてください。両方は不可です。
lr + cr: 二重フィルタでゼロ件になることがある
これは見落としやすい罠です。lr=lang_en は英語コンテンツに限定し、cr=countryJP は日本にホストされたページに限定します。両方を組み合わせると、「日本にホストされた英語ページだけ」という、非常に狭い範囲になります。
推奨: 両方の交差条件が本当に必要でない限り、どちらか一方にしてください。組み合わせる場合は、結果が大幅に減ることを想定しましょう。
num + start: 壊れたページネーション
num=100&start=0 を使う旧スクリプトは、今では静かに約10件しか返しません。num はもはや尊重されません が、エラーにはならず、ただ無視されるだけです。
推奨: すべてのURLから num を削除してください。start を10ずつ増やしてページ送りし、ページ間で重複を除去しましょう。
衝突の早見表
| Combination | What Happens | Recommendation |
|---|---|---|
gl + uule | uule の方が具体的なシグナル | 国と都市を合わせるか、gl を省略 |
tbm + udm | 不安定。両方削除されることがある | udm のみ使用 |
lr + cr | 絞り込みが強すぎて、結果がほぼゼロになることがある | どちらか一方 |
num + start | num が無視され、約10件のみ返る | num を削除し、start でページ送り |
nfpr=1 + tbs=li:1 | 関連するが同一ではない制御 | 対象クエリで検証 |
hl + lr | UI言語 ≠ コンテンツ言語制限 | 意図的に使う。hl はコンテンツフィルタではない |
Google検索URLパラメータから構造化データ抽出へ
ここまでで、クエリ、国、日付範囲、従来型Web結果まで正確に指定した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— 英語UIgl=us— 米国市場の文脈tbs=qdr:m,sbd:1— 直近1か月、日付順udm=14— 従来のWeb結果（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構造は頻繁に変わり、クラス名は難読化され、ブラウザで見えるものが生のHTTPレスポンスにそのまま現れるとは限りません。
開発者でない人向けのより簡単な方法は、作成した検索URLをChromeで開き、ブラウザベースの抽出ツールで可視ページから構造化データを抜き出すことです。Thunderbitでは、まさにこの用途のために Chrome拡張機能 を作りました。AI Suggest Fields を使って、結果タイトル、遷移先URL、スニペット本文、表示順位などの列を自動識別し、パーサーを書かずにスプレッドシートへ抽出できます。
もちろん、これだけが方法ではありません。大規模・定期的な抽出が必要なら、コードベースの方法も有効です。ただし、その場限りのリサーチ、監査、単発の競合分析なら、ブラウザベース抽出にすればHTMLパースの脆さを回避できます。
公式APIを使うべきタイミング
責任ある使い方の話は重要です。
Googleの利用規約 は、保護手段を回避する自動アクセスを禁止しています。また Google Search Help では、順位確認のために自動クエリを送る検索スクレイパーやソフトウェアを明確に自動トラフィックと分類しています。本番規模のGoogleスクレイパーを動かすと、IPブロック、CAPTCHA、潜在的な法的問題に直面する可能性があります。
本番規模・大量の検索データが必要なら、より良い道は公式APIです。Google Custom Search JSON API は新規利用者の受付を終了しつつあります。既存ユーザーには2027年1月1日までの移行期間があり、その後は1日100クエリ無料、以降は1,000クエリあたり5ドル です。今後、制御されたサイト内検索には Vertex AI Search が推奨されています。
自社サイトであれば、Search Console の Search Analytics API が、クリック数、表示回数、CTR、平均掲載順位を得る第一選択です。スクレイピングは不要です。
URLパラメータの知識は、診断・リサーチ用のツールとして考えてください。精密な検索リンクの作成、手動監査、Googleの表示理解には非常に有効ですが、大規模運用の公式API代替ではありません。
Google検索演算子：クエリの中に入るパラメータ
検索演算子は q= の中に入りますが、URLパラメータの重要な相棒です。以下の表では、Googleが現在ドキュメント化しているもの に加え、実際には今も使えるいくつかを載せています。
| Operator | What It Does | Example |
|---|---|---|
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 の中の演算子と外側のURLパラメータを組み合わせることにあります。
q=site:competitor.com+intitle:pricing+after:2026/01/01&tbs=sbd:1&gl=us&udm=14
これは、competitor.com 内でタイトルに「pricing」を含み、2026年1月以降に公開され、日付順で、米国市場の従来型Web結果として出す、かなり精密な競合調査クエリです。URLパラメータと演算子だけで、ここまで作れます。
Googleは site: 結果が完全である保証はない と明言しています。site: クエリをインデックス済みページの完全目録として扱わないでください。
責任ある利用：Googleの利用規約とレート制限
短いですが重要な注意点です。
Googleの利用規約 は、悪用的なアクセスや保護手段の回避を禁じています。Google Search Help でも、検索スクレイパーや自動順位確認ソフトは自動トラフィックの例として明記されています。違反すると、IPブロック、CAPTCHA、アカウント制限、場合によっては法的措置につながることがあります。
URLパラメータの知識は、次の用途で使うのが最適です。精密な検索URLを手作業で作る、チーム向けのブックマーク可能な検索リンクを作る、小規模な監査をブラウザで行う、Google検索UIの仕組みを理解する。大規模な自動処理には、Googleの公式API、あるいは Brave Search API のようなライセンス済みのサードパーティ検索データ提供元を使ってください。
Thunderbit の ブラウザ拡張機能 は、ユーザーが起点となって可視ページから抽出する用途向けであり、大量のGoogle自動クエリ向けではありません。その違いは非常に重要です。
2026年版 Google検索URLパラメータの要点
要点だけまとめると、次の通りです。
- ローカライズのシグナルには
gl+hlを使う。Googleのリダイレクト移行中はccTLDだけに頼らない - 必要に応じて
udmとtbmの両方を検証する。どちらも安定した版管理APIではない udm=14はAI Overviews なしの従来型Web結果を求めるのに使える可能性がある が、Googleが削除・書き換えすることもある- 都市レベルの地域ターゲティングには
uuleを使う。上記のprotobufエンコード式で生成する tbsを使いこなす と、精密な日付フィルタ (cdr:1,cd_min:...,cd_max:...)、日付順ソート (sbd:1)、verbatim 検索 (li:1) ができる- パラメータ衝突に注意:
glとuule、tbmとudm、lrとcr num=100は不安定で、正式サポートもされていなかった。安全な基本はstartを10ずつ増やすこと- 構造化されたSERPデータが必要なら、単発作業には Thunderbit のようなブラウザベースツールを使い、本番規模では公式APIを使う
- Googleの利用規約を尊重する。URLパラメータはリサーチツールであり、スクレイピング許可証ではない
Googleは今後も告知なしにパラメータを変える可能性があります。この記事は変化に合わせて更新していきます。ブックマークして、また確認してください。
さらに詳しく
- 2026年版ベストSEO API 9選（1リクエストあたりの実コスト比較付き）
- 検索エンジンスクレイピングを極める方法：完全ガイド
- ウェブサイトの順位を分析・監視するためのツール27選
- 効率的な抽出のためのWeb Scraperのページネーション活用法
- 検索自動化とは？ 利点・ツール・戦略
FAQ
Google検索URLで udm=14 は何をしますか？
udm=14 は、AI Overviews なしの従来型Web結果を求める指定として使われることがあり、SEO担当者の間で人気です。ただし、これは逆解析されたもので、公式に文書化されたGoogleの契約ではありません。セッション、アカウント、地域、クライアント、実験対象グループによって、Googleが削除・書き換えする場合があります。
num パラメータは2026年もまだ動きますか？
頼らないでください。Googleは2025年9月に num=100 を安定して尊重しなくなり、広報担当者はこのパラメータがそもそも正式サポートではなかったと説明しています。ページ送りは start を10刻みで使う方が安全です。また、Googleは結果件数を書き換えたり制限したりすることがあるので、返ってきた件数も必ず確認してください。
特定の都市からのGoogle検索を再現するには？
エンコード済みの都市名を uule パラメータで指定します。上のエンコードセクションで、protobufベースの手順とPython例を紹介しています。Googleの正規地名（Google Ads の地理ターゲティングデータ で取得可能）を用意し、それを uule 値、たとえば uule=w+CAIQICIeNew+York,New+York,United+States のような形に変換します。
gl、lr、cr の違いは何ですか？
この3つは、地理・言語ターゲティングの異なる側面を制御します。gl は国レベルで検索場所をシミュレートし、順位やローカル結果に影響します。lr は特定言語で書かれたページに結果を限定します。cr は特定の国にホストされたページに限定します。組み合わせることはできますが、lr=lang_en + cr=countryJP のような矛盾する組み合わせは、結果を大幅に狭めます。
1つのURLに複数の tbs 値を入れられますか？
はい。1つの tbs パラメータ内でカンマ区切りにします。たとえば tbs=qdr:m,sbd:1 は直近1か月に絞り、日付順（新しい順）に並べます。li:1 を加えて tbs=qdr:m,sbd:1,li:1 にすることもできます。tbs の構文は非公開なので、意図した通りに動くか、実際のクエリで検証してください。
