Googleは、パーソナライゼーションを無効にした場合でも、リクエストの地理的な発信元に応じて、同じクエリに対して異なるオーガニック結果を提供します。ニューヨークのデータセンターIPから「best coffee beans」というクエリを送信した場合と、ベルリンのレジデンシャルIPから同じクエリを送信した場合では、異なるSERPが返されます。その違いは表面的なものではありません。これは、Googleの地域別ランキングアルゴリズム、コンテンツのローカライゼーション、およびgl（国）、hl（言語）、cr（国制限）パラメータの相互作用によって強制されます。これらのメカニズムを理解せずに地域ターゲットのSEOモニタリングを実行すると、誤解を招くデータが得られることは間違いありません。この記事では、SERPが地域によって異なる理由、プロキシローテーションが検出を軽減する方法、および30以上の市場でランキングを追跡するための運用ワークフローについて説明します。
地域ごとにSERPが異なる理由 — ccTLD、gl、hl、およびパーソナライゼーション
Googleは、複数のシグナルの組み合わせによって「ローカル」SERPを決定します。最も単純なものは、検索ドメインのTLDです — google.deとgoogle.co.jp。しかし、ccTLDを使用するだけでは不十分です。Googleはglパラメータも読み取り、想定される国を上書きします。たとえば、google.com?gl=DEはグローバルドメインでもドイツの結果を強制します。hlパラメータはインターフェース言語を設定し、結果の言語には影響しますが、地理的な重み付けには影響しません。hl=en&gl=JPを使用したリクエストは、英語で日本語の結果を返します — これはよくある混乱の原因です。
パラメータ以外にも、GoogleはIPベースのジオロケーションを適用します。米国のIPからgoogle.deにリクエストを送信した場合、GoogleはIPの発信元を検出するため、英語とドイツ語の結果が混在して表示される可能性があります。これがSEOモニタリングの核心的な問題です。IPアドレスがユーザーの位置情報を漏洩してしまうのです。pws=0を使用してパーソナライゼーションを無効にしても、ユーザーの履歴は削除されますが、位置情報の推測は無効になりません。ローカルユーザーをシミュレートする唯一の信頼できる方法は、ターゲット市場に属するIP（理想的にはレジデンシャルIP）を経由してトラフィックをルーティングすることです。
レジデンシャルIPとデータセンターIP — 検出とCaptcha回避
GoogleはIPレンジを積極的に分類しています。AWS、GCP、DigitalOceanなどのデータセンターIPは、数秒以内に非人間としてフラグが立てられます。当社の内部テストでは、glパラメータを使用してGoogleにクエリを送信した場合、データセンターIPの60～80%が失敗し、多くのリクエストでcaptchaまたは簡略化されたSERPが返されました。一方、レジデンシャルIPは通常のトラフィックに溶け込みます。しかし、レジデンシャルプロキシプールには、高レイテンシ、帯域幅の制限、ジオロケーション精度のばらつきといった独自の問題があります。プロキシプロバイダの「レジデンシャル」IPが、実際にはモバイルキャリアのNATであり、Googleが別の地域にマッピングする場合もあります。
Captcha回避は「隠す」ことではなく、実際のブラウザを模倣することです。正しいUser-Agent、Accept-Languageに一致するhl、およびセッションごとに新しいCookie jarを送信します。Googleのボット検出はリクエストのタイミングも監視します。同じIPから2秒間に100件のクエリがバーストすると、captchaがトリガーされます。IPごとに1分間に1～2リクエストに制限します。市場ごとに少なくとも50のIPプールを使用してスループットを維持します。トレードオフは、レイテンシとコストが高くなる代わりに、captcha率が低くなることです。当社では5～10%のcaptcha率を正常とみなし、別のIPで再試行します。
30か国以上でのランクトラッキングのワークフロー
運用パターンは単純です。市場ごとに1つのIP、クエリごとに1つの新しいセッションです。市場をまたいでクッキーを再利用しないでください。次のシェルスニペットは、レジデンシャルプロキシを使用したドイツのSERPに対する最小限のcurlベースのプローブを示しています。
#!/bin/bash
# Query Google for "SEO tools" with German gl and English hl, via a residential proxy
PROXY="http://user:pass@residential-proxy-pool:8080"
curl -s --proxy "$PROXY" \
-H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36" \
-H "Accept-Language: en-US,en;q=0.9,de;q=0.8" \
-H "Cookie: NID=...; CONSENT=..." \
"https://www.google.com/search?q=SEO+tools&gl=DE&hl=en&pws=0&num=10" \
| grep -oP '(?<=&url=)[^&]+' | head -10これにより、上位10件のオーガニックURLが取得されます。本番システムでは、静的プロキシを、リクエストごとに新しいIPを返すローテーションエンドポイントに置き換えてください。proxy-chainのようなツールや、IPごとにセッションを持つrequestsを使用したカスタムPythonスクリプトが適しています。各市場のプロキシリストを別々のファイルに保存し、循環的にローテーションします。
30か国以上の場合、30以上のプロキシプールが必要です。各プールには、レート制限を回避するために少なくとも20～50のIPが含まれている必要があります。グローバルIPの単一プールでは、Googleのジオロケーションが誤ったルーティングを行うため不十分です。当社では、国コードをプロキシエンドポイントにマッピングする設定ファイルを使用しています。
{
"DE": "http://user:pass@de-residential.zone:8080",
"JP": "http://user:pass@jp-residential.zone:8080",
"BR": "http://user:pass@br-residential.zone:8080"
}各市場のクエリは、個別のスレッドまたは非同期タスクで実行され、10リクエストごとにIPごとに60秒のクールダウンが設けられます。このペースにより、ほとんどの市場でcaptcha率を3%未満に抑えられます。難しいのはコードではなく、検証済みのジオロケーションを持つ信頼性の高いレジデンシャルプロキシを調達することです。多くのプロバイダは「DE」を謳っていますが、フランクフルトのデータセンターを経由します。IPのASNを確認し、Googleの位置情報推測（たとえば、X-Robots-Tagヘッダーや既知のローカル結果を使用）と比較して検証してください。
トレードオフ：鮮度とコスト
レジデンシャルプロキシを使用して30市場を毎時間実行する場合、プロキシ料金だけで月額約200～500ドルのコストがかかります（プロバイダとデータ量によって異なります）。Googleの監視がそれほど厳しくない市場（通常は小規模な国）では、データセンターIPを使用することでコストを削減できます。ただし、データのノイズが増加します。別の方法として、24時間の更新サイクルを受け入れ、captcha率が低下する夜間にクエリをバッチ処理することもできます。無料のランチはありません。30か国にわたる毎日のランクトラッキングが必要な場合は、レジデンシャルプロキシと堅牢な再試行メカニズムに予算を割り当ててください。それ以下では、正確に見えて根本的に間違った結果が得られます — それはデータがないことよりも悪いことです。