プロキシで Google 検索結果をスクレイピングする（SERP、2026年）

2026年6月12日公開 · 約9分で読めます

Google は主要なターゲットの中で最もスクレイピングが難しく、その理由は単純です。誰よりも多くのトラフィックを見ているため、本物の検索者がどう見えるかについて最も豊富なモデルを持っているのです。データセンター IP からある程度の量でアクセスすれば、429、「sorry/index」ページ、あるいは結果が静かに減っていくソフトブロックが返ってきます。本ガイドでは、実際に何が Google のブロックを引き起こすのか、そして 2026 年に SERP スクレイパーを生かし続けるプロキシとレート制限の戦略を解説します。

Google のブロックを引き起こすもの

Google は単一のシグナルに頼りません。複数を積み重ね、その合算スコアが一線を超えるとバンします。

IP/ASN レピュテーション — データセンターのレンジ（AWS、GCP、Hetzner、OVH）は即座に自動化としてスコアリングされます。これは SERP スクレイピングにおける単独で最大の要因です。
IP あたりのリクエストレート — 一つの exit から速すぎる大量のクエリは典型的なトリガーです。Google は人間のペースを許容しますが、ループのペースは許容しません。
クエリのフィンガープリント — 同一のパラメータ、Cookie なし、リファラーなし、機械速度での逐次ページネーション。
JS なし / ヘッドレスの痕跡 — Google は JS でゲートされたレイアウトをますます配信しており、純粋な HTML フェッチは古く見えたり、同意/チャレンジの壁を引き起こしたりします。

ここでは住宅用が絶対条件

ほとんどのターゲットでは、公開データに対してデータセンター IP で乗り切れます。Google は例外です。その ASN レピュテーションスコアリングは十分に攻撃的で、データセンタープロキシはほぼ即座にスロットルされます。住宅用 exit — 本物の消費者向け ASN — こそが SERP スクレイパーに量を維持させてくれるものです。データセンターは他のすべてに取っておき、住宅用の予算は実際に効果がある場所に使いましょう。

ローテーションするが、exit ごとにレート制限する

ローテーションは負荷を分散して、どの単一 IP もボットに見えないようにしますが、生き残らせてくれる規律はプールのサイズだけでなくexit ごとのレートです。1000 個のプロキシでも、全部を一気にフルスロットルで撃てばバンされます。各 exit を人間のようにペース配分しましょう。

import time, random, itertools
from curl_cffi import requests   # browser TLS fingerprint, see notes below

PROXIES = [
    "socks5h://USERNAME:[email protected]:913",
    "socks5h://USERNAME:[email protected]:913",
]
pool = itertools.cycle(PROXIES)

def serp(query, page=0):
    proxy = next(pool)
    params = {"q": query, "start": page * 10, "hl": "en"}
    r = requests.get("https://www.google.com/search", params=params,
                     impersonate="chrome",
                     proxies={"http": proxy, "https": proxy}, timeout=30)
    if r.status_code == 429 or "/sorry/" in r.url:
        raise RuntimeError("rate-limited - back off and rotate")
    return r.text

for q in queries:
    html = serp(q)
    parse(html)
    time.sleep(random.uniform(2.0, 5.0))   # human-paced gap between queries

ランダム化された遅延は実際に役立っています。固定の sleep(3) はそれ自体がフィンガープリントです。それを変動させ、クエリを exit 全体に分散させて、各 exit が Google の IP あたりのしきい値を下回るようにしましょう。

スティッキーセッションとジオロケーション

ローカライズされた結果（ランキング、言語、通貨）は exit の場所に依存するため、測定したいジオグラフィにあるプロキシを選び、複数ページのクエリではスティッキーセッションを保持して、1 つの検索の全ページが同じ場所から来るようにしましょう。クエリの途中で exit を混ぜると、異なるロケールから継ぎはぎされた結果になり、ランクトラッキングには役に立ちません。

フィンガープリントを忘れずに

Google はあなたの TLS ハンドシェイクも読みます。素の requests 呼び出しは Python だと叫ぶような JA3 を送り、IP スコアをさらに悪化させます。curl_cffi（上で使用）または本物のブラウザで本物のブラウザフィンガープリントを送りましょう — curl_cffi で TLS フィンガープリンティングを回避するを参照してください。Google が JS 同意の壁でゲートし始めたら、Turnstile ガイドで扱っているように本物のブラウザエンジンにエスカレートしましょう — 同じ「JS ランタイムが必要」というロジックが当てはまります。

ブロックを上手にさばく

429 / /sorry/ — その exit への接続を止め、ローテーションして、指数的にバックオフします。フラグの立った IP を叩き続けるとバンが延びます。
結果が減っていく — ソフトブロックです。ハードブロックになる前に減速しましょう。
同意の壁 — Cookie/同意のリダイレクトを処理するか、ブラウザエンジンに切り替えましょう。

チェックリスト

住宅用 exit を使う — データセンター IP は Google でほぼ即座にスロットルされます。
プールだけでなくexit ごとにレート制限する。クエリ間の間隔をランダム化する。
ブラウザの TLS フィンガープリントを送る。Python の JA3 を IP スコアの上に積み重ねさせない。
測定しているロケールに exit のジオグラフィを合わせる。複数ページのクエリはスティッキーセッションにする。
より長いバンへ再試行を突っ込むのではなく、429 / /sorry/ では強くバックオフする。
スティッキーセッション付きのクリーンな住宅用 exit: jibaoproxy.com、住宅用 $2/GB、自分のクエリで試せる 500MB の無料トラフィック。