Google.com/goto: Googleのアンチスクレイピング更新で、すべての検索結果の抽出が困難に

Googleは検索結果と遷移先ページの間に追加リクエストを挿入し、大規模に結果URLを収集するツールとの直接的な対立を生み出した。google.com/goto: Google's anti-scraping updateとして知られるこの変更では、多くの直接的なオーガニックリンクが、不透明なGoogleのリダイレクトアドレスに置き換えられる。

人間が見る検索結果は、これまでとほぼ変わらない。タイトル、表示ドメイン、ファビコン、説明は引き続き表示される。しかし、その背後にあるリンクは、パブリッシャーのページではなくgoogle.com/goto?url=...を指すようになり得る。

この違いは重要だ。エンコードされた値からは、完全な遷移先URLを確認できない。ブラウザはGoogleに自動解決を求められる一方、スクレイパーは追加リクエストを送り、レスポンスを処理し、Googleの防御策の発動を避けなければならない。

Googleはこの展開を、不正利用に対する技術的措置と説明している。この変更は自動収集を完全に阻止するものではない。代わりに、低コストなHTML解析作業を、Googleが観測できる、よりノイズの多いリクエスト連鎖へと変える。

ここに中核的な対立がある。検索ユーザーには信頼できる外部リンクが必要だが、Googleは検索結果への自動アクセスをより厳密に管理したい。SERP API企業、SEOプラットフォーム、研究者、AI開発者はいま、この緊張関係の中で活動している。

Google.com/goto: Googleのアンチスクレイピング更新がリンク層を変える

Googleはオーガニック検索結果に表示する内容を変えていないが、ソフトウェアがその遷移先へ到達する方法を変えた。

従来のGoogle検索結果では、アンカー要素のhref属性に遷移先ページが直接含まれていた。ソフトウェアは検索結果ページを1回ダウンロードし、そのHTMLを解析するだけで、複数の完全なURLを抽出できた。

新しい構造では、Googleが管理するリダイレクトが挿入される。検索結果のアンカーは、しばしばCAESで始まる値を含む/gotoアドレスを指す。この値は遷移先を表すものの、可読テキストとして公開されない。

ユーザーが結果をクリックすると、ブラウザは/gotoアドレスをリクエストする。Googleはその後、ブラウザを実際のページへ送るHTTPリダイレクトを返す。この遷移は通常、検索ユーザーが気付かないほど速い。

Googleは2026年8月26日、この展開を確認した。広報担当者は、サービスとユーザーを保護するため、進化する不正利用に対する技術的措置を同社が定期的に導入していると述べた。この確認では、リダイレクトもそうした措置の一つと説明された。

同社はトークンの技術仕様を公開していない。また、どのブラウザ、地域、セッションで書き換えられたリンクを受け取るかを決めるすべてのシグナルについても説明していない。

確認前から初期の観測報告は出ていた。検索分野の専門家は6月と7月、このパターンを限定的なテストのように見えるものとして報告していた。8月下旬までには、複数のデータプロバイダーがより広範な展開を確認していた。

展開の確認では、複数の住宅用IPプロバイダーでほぼ完全なカバレッジが報告された。この推計はGoogleではなく、順位追跡会社NozzleのDerek Perkinsによるものだ。

検索データAPIプロバイダーのAutomも、似た進行を報告している。同社チームは当初、結果ページのごく一部で/gotoに遭遇した。その後、ログアウト状態およびプライベートブラウジングのセッションで、この形式を一貫して確認した。

同プロバイダーの技術的説明によれば、不透明なパラメーターは通常のローカルデコードでは遷移先に変換できない。遷移先は代わりに、リダイレクトレスポンスを通じて取得される。

この形式は、Googleの従来の/urlラッパーとは異なる。従来のラッパーには、クエリ文字列に可読なURLエンコード済みの遷移先が含まれることが多かった。ソフトウェアはGoogleへ再度問い合わせることなく、その値を抽出できた。

/gotoでは、目に見える検索結果と実際に利用できる遷移先が別々のデータになる。Googleは人間が結果を評価するのに十分な情報を表示し続ける。しかし、ページソースから再利用可能な外部URLが得られるとは、もはや保証されない。

これが本質的な変更だ。Googleは遷移先の解決を静的HTMLから、自社サーバーとの対話へ移した。

たった1回の追加リダイレクトが検索データプロバイダーを圧迫する理由

このリダイレクトは、解決される各検索結果に限界コストを発生させ、そのコストは大規模な収集システムで累積する。

以前の基本的なスクレイパーなら、検索結果ページへの1回のリクエストで複数のオーガニックな遷移先を収集できた。新形式では、元のリクエストに加え、ユニークな/gotoトークンごとに1回の解決リクエストが必要になる可能性がある。

地域、デバイス、言語をまたいで多数のクエリを監視するサービスを考えてみよう。各クエリで複数ページを収集し、その収集を1日に何度も繰り返すことがある。結果ごとに追加される1リクエストは、すぐに大きなインフラ運用負荷となる。

コストは帯域幅だけにとどまらない。各解決処理には、レイテンシー、接続管理、リトライロジック、そして新たな障害機会が加わる。また、Googleのリダイレクトエンドポイントに向けられる、識別可能なリクエストストリームも生み出す。

Googleは、あるクライアントがどの速さでリンクを解決するかを観測できる。こうしたリクエストを、Cookie、ネットワークID、ブラウザ特性、過去の検索活動と比較することも可能だ。Googleはここで用いるシグナルを明らかにしていない。

つまり、この更新は単なる新しい解析形式ではない。結果ページを取得してから、すべての正確な遷移先を知るまでの間に、サーバー側のチェックポイントを設けるものだ。

従来型の順位追跡は、この圧力をよく示している。順位追跡ツールは、単にどのドメインが表示されるかではなく、どのページがあるクエリで順位を得ているかを特定しなければならない。同じトピックで複数ページが競合するサイトでは、正確なパスが重要になる。

パブリッシャーURLではなくGoogleリダイレクトを保存するツールは、誤解を招く記録を生成しかねない。結果の欠落を報告したり、異なるページを統合したり、ランディングページの変更を順位変動のように見せたりする可能性がある。

検索APIも関連する課題に直面する。顧客はクリーンで構造化された遷移先URLを期待している。顧客がGoogleの現在のリンクラッパーを理解したり、形式変更のたびに連携機能を書き換えたりする必要はないはずだ。

Automは、既存のレスポンスフィールドを維持しながら/gotoリンクを解決するようパイプラインを修正したと述べている。このアプローチでは、互換性に関する負担がAPI顧客からデータプロバイダーへ移る。

ただし、この修正は、収集側からGoogleのリダイレクトサービスを引き続き利用できることに依存する。また、現在のレスポンス挙動が安定して維持されることも前提となる。Googleは、いずれの条件についても約束していない。

AI検索・リサーチ製品は、別の形の圧力にも直面する。一部のシステムは商用検索APIを利用し、別のシステムは独自インフラで結果ページを収集する。どちらのアプローチも、ソースURLへの予測可能なアクセスに依存している。

このリダイレクトは、誰かがURLを提供した後にモデルが遷移先を読むことを妨げるものではない。影響を受けるのは、分析が始まる前にソースを見つけ、順位付けし、取得する上流の発見プロセスだ。

ナレッジワーカーは、この影響を間接的に受ける可能性がある。リサーチアシスタントは、検索コネクターがリダイレクトURLを適切に処理できない場合、ソースを見落とす可能性がある。また、ユーザーが安定したパブリッシャーリンクを期待する場所に、Googleラッパーを保存してしまうこともある。

これはプロベナンスの検証を難しくする。信頼できるリサーチ記録は、検索エンジンが所有する一時的なルーティングアドレスではなく、主張を裏付けたページを保持すべきだ。

そのため、社内リサーチシステムを構築するチームは、ソースIDを発見メタデータから分離しておくべきである。検索可能なAI knowledge baseが有用であり続けるのは、その引用が永続的な文書へ解決される場合に限られる。

直接的な圧力は検索データ仲介事業者にかかる。一方で、下流のリスクは、その出力を信頼できるソースインフラとして扱うあらゆる製品に及ぶ。

本当の競争はオープンな検索結果と制御された解決処理の間にある

Googleは読み取り可能な検索結果ページを公開し続けているが、そのページを再利用可能なデータへ変えるために必要な操作を、ますます自ら管理している。

これは単にGoogleと一社のスクレイピング企業との対立ではない。本質的な競争は、一般公開された検索結果にアクセスするための二つの技術モデルの間にある。

第一のモデルでは、検索結果ページを文書として扱う。クライアントはそれをダウンロードし、HTMLに埋め込まれたリンクを読み、次に何をするかを決める。初期のWebの多くは、この単純なパターンで動いていた。

第二のモデルでは、検索結果をインタラクティブなサービスとして扱う。ユーザーが見る内容には引き続きアクセスできるが、重要な値はプラットフォームが管理する追加リクエストを通じてのみ利用可能になる。

/gotoの展開により、Google Searchは第二のモデルへ近づく。オーガニック検索結果を削除することも、一般ユーザーに新たなワークフローを強いることもなく、この移行を進めている。

この微妙さは重要だ。この更新をスクレイピング禁止と呼ぶのは、その影響を過大評価している。リンクは依然として解決可能であり、独立したテストでは開発者が遷移先を回収できることが示されている。

ScrapingBeeは、ブラウザ、自動化セッション、ネットワーク構成をまたいで/gotoをテストした。同社のリダイレクト実験では、トークンは構造的にデコードできるものの、ローカルだけで元のURLへ変換することはできなかった。

同社によれば、自動リダイレクトを無効にしたHTTP GETリクエストでは、302レスポンスとLocationヘッダーが返された。そのヘッダーには遷移先アドレスが含まれていた。

テストでは、HEADリクエストの挙動が異なることも分かった。必要なlocationヘッダーなしに200レスポンスが返され、収集側は信頼できる解決のためにGETを使わざるを得なかった。

この結果は、Automが当初示した、HEADでlocationを読むという推奨と食い違う。この差異は、挙動の変化、テスト条件、または複数の展開バリエーションを反映している可能性がある。

開発者は、いずれの方法も恒久的な契約として扱うべきではない。防御的な実装では、レスポンスの挙動をテストし、複数のラッパーをサポートし、保存済みURLを破損させずに失敗を記録できる。

ScrapingBeeは、逐次処理した50件の解決で中央値約3.27秒を計測した。同社環境では、5ワーカーを使うと中央値は約1.23秒まで短縮された。

これらの数値は一社のベンダーによるテスト結果であり、普遍的なベンチマークではない。ネットワークの所在地、接続再利用、Googleのレスポンス、スロットリングによって、異なる結果が生じ得る。

それでも、この実験はトレードオフを明らかにしている。この更新は摩擦を加えるが、適度な並行処理でその一部は吸収できる。そのため、この措置はスクレイピングを排除するよりも、コスト構造を変える可能性が高い。

サーバーとの対話は、静的リンクにはなかった選択肢をGoogleに与える。レスポンスの調整、トークン形式の変更、レート制御の適用、クライアント種別の識別が可能になる。

Googleはすでに検索結果ページそのものを管理している。しかし、直接的な外部URLは、クライアントがHTMLを受け取った後の同社の関与を制限していた。/gotoは、その関与を遷移先の解決まで拡張する。

この変更は、大規模な収集を複雑にしてきた他の取り組みに続くものだ。Googleは自動トラフィックに対する防御を強化し、収集側が以前はより大きな結果セットを得るために使っていた検索結果ページのパラメーターも変更してきた。

個々の調整は、技術的に回避できる場合がある。しかし、それらが重なることで、非公式なアクセスは予測しにくくなり、保守された収集インフラの価値が高まる。

この変化は、居心地の悪い対称性も浮き彫りにする。Googleは他のWebサイトをクロールしてインデックスを構築する一方で、そのインデックスのGoogleによる表示を収集する自動システムを制限している。

活動の性質は同一ではない。Googlebotはパブリッシャーの制御に従い、検索プロダクトを構築し、文書化されたクロールシステムの下で稼働する。一方、SERPスクレイパーは、しばしばサポート対象のAPI関係の外で、Googleが生成したランキングページを収集する。

それでも、パブリッシャーと開発者はこの不均衡を認識している。Googleはオープンウェブが技術的にアクセス可能であり続けることを期待する一方、自社の集約レイヤーを再利用しにくくする方向へ段階的に進めている。

大きな議論を呼んだコミュニティスレッドは、この対立を反映していた。本記事で参照した時点のスナップショットでは、472ポイントと369件のコメントを集めていた。

一部の参加者は、この更新を妥当なサービス保護策と見なした。別の参加者は、公開ウェブサイトに由来する情報をさらに囲い込む動きだと表現した。政策論ではなく、実務上のエンジニアリング課題に焦点を当てた参加者も複数いた。

最も妥当な解釈は、その両者の中間にある。Googleは検索結果を閉鎖したわけではないが、大量再利用をGoogleが管理するインタラクションにより強く依存させた。

この更新は摩擦を増やすものであり、スクレイピングを完全に遮断するものではない

最大の不確実性は、`/goto`が扱いやすいリダイレクト形式として残るのか、それともより厳格な執行システムの一層になるのかという点だ。

現行の仕組みには明確な限界がある。スクレイパーは各リダイレクトをリクエストし、その転送先を読み取れる。基盤となるURLの一部は、レンダリングされたページ内の別の箇所にも残っている可能性がある。

Googleはドメイン、ファビコン、パンくずリスト、帰属情報を表示するために、転送先の情報を必要とする。結果の形式によっては、収集者はすべてのリンクを解決せずとも、アイデンティティの一部を再構築できる。

ただし、それで正確なランディングページを常に特定できるわけではない。表示されたドメインだけでは、同一サイト内の製品ページとサポート記事を区別できない。パンくずテキストも、パラメーターやパスの構成要素を省略する場合がある。

この展開も一様ではない。ScrapingBeeは、Chrome、Edge、Playwright、および自社の収集環境で/gotoを報告した。同じテストでは、BraveとLibreWolfは直接リンクを返した。

Safariは、同じ/goto形式ではなく別のGoogleラッパーを返した。プロキシの場所を変更しても、リダイレクトを確実に除去することはできなかった。

これらの結果はクライアントごとの差異を示唆するが、Googleの選択ルールを明らかにするものではない。ブラウザーの種類は結果と相関している可能性があるものの、直接的な原因ではないかもしれない。

ScrapingBeeのテストでは、トークンは持ち運び可能にも見えた。ある接続で収集したトークンを、元のCookieやプロキシなしで、後から別のクライアント経由で解決できた。

その実験では、トークンは24時間を超えて利用可能だった。最大有効期間は不明であり、Googleは予告なく可搬性や有効期限のルールを変更する可能性がある。

この不確実性は、エンジニアリング上の判断に反映すべきだ。本番の収集システムは、不透明なトークンを恒久的な識別子であるかのように保存すべきではない。収集時点に近いタイミングで転送先を解決し、検証する必要がある。

診断のため、元のラッパーも保持すべきだ。両方の値を保存することで、ランキング変更とリゾルバーの障害、あるいはGoogleレスポンスの新たなバリエーションをチームが区別しやすくなる。

リトライには慎重な上限が必要だ。積極的な解決は、この変更が表面化させるために設計されたように見えるリクエストパターンを増幅しかねない。無制限のリトライは、部分的な障害時にコストを押し上げる可能性もある。

収集システムは、同一トークンを解決する前に重複排除すべきだ。ScrapingBeeは一部の結果ページ内で繰り返されるトークンを確認しており、不必要な重複リクエストは回避できる。

プロバイダーは複数の境界で監視も必要になる。各ラッパーを使用する結果の割合、解決の成功率、レスポンスコード、レイテンシー分布を追跡すべきだ。

顧客向け出力にGoogle URLが急増した場合、それはパブリッシャーが検索から消えた証拠ではなく、パースのインシデントである。こうした状態を分けて扱うことで、誤ったランキング警告を防げる。

分析チームには別の疑問がある。人間のユーザーがパブリッシャーのサイトに到達した際、このリダイレクトがリファラーの帰属に影響するかという点だ。

サーバーサイドのリダイレクトでも、有用なリファラーシグナルを保ちながら、期待される転送先へ到達できる。実際の帰属は、ブラウザーの挙動、ヘッダー、分析設定、Googleの実装に依存する。

この展開がオーガニック流入の帰属を広範に破壊していると主張するための、検証済みの根拠はない。サイト運営者は、その結論に至る前に自らのランディングリクエストと分析上の分類を確認すべきだ。

Googleの一般的なリダイレクトに関するガイダンスでは、一般的なリダイレクトの種類を同社のクローラーがどう解釈するかが説明されている。そこでは、/gotoは第三者の収集者向け公開統合インターフェースとして文書化されていない。

この違いは重要だ。Google Search Centralのドキュメントは、パブリッシャーが自らのページをどのようにリダイレクトすべきかを示すものだ。Googleの外向き検索ラッパーについて、安定した挙動を約束するものではない。

ユーザーが直面するトレードオフはより小さいが、現実に存在する。検索結果にカーソルを合わせた際、完全な転送先ではなくGoogleのアドレスが表示されることがある。表示ドメインは依然として文脈を提供するが、ブラウザーのステータスプレビューは情報量が減る。

これは、慣れ親しんだセキュリティ確認を弱める可能性がある。慎重なユーザーは、特に似たタイトルのページが複数ある場合、開く前に正確な転送先を確認したいと考えるかもしれない。

Googleは、表示されるドメインラベルと不正利用対策は依然として有効だと主張できる。批判者は、プラットフォームが管理するラベルは実際のリンクを確認することと同じではないと、妥当に反論できる。

どちらの懸念も、この展開が大半のユーザーに害を及ぼすことを証明するものではない。クリック体験が変わらないように見える場合でも、自動化対策が透明性を変え得ることを示している。

現時点の証拠が支持する結論は限定的だ。/gotoは収集コストを増加させ、単純なパーサーを機能不全にし、転送先解決に対するGoogleの管理を強める。

Googleが検索スクレイピングを不可能にしたという、より強い主張を支持するものではない。プロバイダーはすでに機能する解決経路を示しているが、それらの経路には新たな運用リスクが伴う。

Googleのスクレイピング対策アップデートがチームに次に注視させるもの

これが通常のパーサー更新にとどまるのか、検索データ経済における長期的な変化となるのかは、3つのシグナルによって決まる。

1つ目のシグナルはリンク形式のカバレッジだ。プロバイダーは、直接URL、/urlラッパー、/gotoトークンが、ブラウザー、地域、セッション状態ごとにどの程度出現するかを測定すべきだ。

安定した混在状態が続けば、Googleがセグメント化された制御システムを運用しているという見方が強まる。急速に普遍的な/gotoリンクへ移行すれば、スクレイピング対策という解釈が強まる。

直接リンクへの回帰は、より広範な結論を弱めるだろう。互換性の問題、ユーザーの懸念、または実験結果が、追加的な制御を上回ったことを示唆する。

2つ目のシグナルはリゾルバーの挙動だ。チームは、単純なGETリクエストがブラウザーセッションなしでも利用可能な302 Locationヘッダーを返し続けるかを追跡すべきだ。

この経路が利用可能であり続ければ、経験豊富なプロバイダーは、この更新をインフラコストの増加として扱える。基本的なスクレイパーは壊れるが、保守されたシステムは稼働を続けられる。

新たな認証要件、短いトークン有効期間、厳格なレート制限、またはクライアントに紐付いたトークンは、障壁を大きく引き上げる。それらは、Googleが単にリンクを書き換えているのではなく、チェックポイントを厳格化していることを示すだろう。

HEADとGETの挙動の変化にも注意が必要だ。初期報告が食い違っていることは、プロバイダーが単一の実装レシピに頼らず、直接テストを行う必要性を示している。

3つ目のシグナルは、SEOおよびAIプロダクト内のデータ品質だ。顧客は、ランディングページの欠落、重複したGoogle URL、説明のつかないランキング変動、リダイレクトラッパーで止まる引用を注視すべきだ。

こうした症状は、一部のプロバイダーがまだ完全には適応していないことを示す。出力が安定していれば、ベンダーが顧客への負担を大きく移すことなく変更を吸収したことが示唆される。

検索データの購入者は、ベンダーに具体的な質問をすべきだ。サービスは最終的な転送先を返すのか。正規パラメーターを保持するのか。未解決の結果をどのようにラベル付けするのか。

また、報告された順位がリンク形式によって変化したかも確認すべきだ。ランキングツールは、収集エラーとGoogleの順位付けにおける実際の変動を分離しなければならない。

AIプロダクトチームには、引用に関して同様の確認が必要だ。取得されたすべての主張は最終的なパブリッシャーURLにつながるべきであり、収集失敗は運用者に見える形であるべきだ。

Googleによる次の公式声明も重要だが、同社が追加の詳細をほとんど示さない可能性はある。ユーザー保護や不正利用の分類に関する正式な説明があれば、意図をめぐる議論は絞り込まれる。

現在の声明は、/gotoが保護措置であることを確認している。ただし、AIクローラー、SEOツール、クリック測定、あるいは別の不正利用分類のどれが設計の動機だったのかは明らかにしていない。

法的な対立は、より多くの文脈を提供する可能性がある。Googleは検索結果を収集・再販売する一部の企業に異議を申し立てており、技術的な制御が法的圧力と並行して存在することを示している。

しかし、/gotoは単一の被告よりも広範なクライアントに影響する。研究者、アクセシビリティツール、ブラウザー拡張機能、社内モニタリングシステムも、同じラッパーに遭遇し得る。

今後数か月で、Googleがこうした用途を区別するかどうかが明らかになる。一律の制限は、大規模な解決システムを維持できる中央集権的なデータプロバイダーに有利に働く。

選択的なアクセスは異なる市場を生み得る。サポート対象のパートナーや承認済みインターフェースの重要性が増し、非公式な収集の信頼性は低下するだろう。

開発者にとって、当面の対応は明快だ。検索結果リンクを可変データとして扱い、転送先を検証し、診断用の文脈を保持し、リゾルバーの失敗をランキング変動と分けて監視することだ。

購入者にとっては、検証が課題となる。レポートに予期しない変化が現れた場合、それを信頼する前に、SEO、監視、調査のプロバイダーが適応済みかを確認すべきだ。

ナレッジワーカーは、自動調査システムがGoogleラッパーを返した場合、引用を確認すべきだ。利用可能な回答は、検索エンジンのルーティング層で止まるのではなく、基礎となる情報源へ導くべきである。

Google.com/goto: Googleのスクレイピング対策アップデートは、したがって全面的な封鎖でも、見た目だけのリダイレクトでもない。これは検索データパイプラインの価値ある地点に設置された、アーキテクチャ上の料金所だ。

その料金所が、安価な1回のリクエストにとどまるかを注視すべきだ。より厳格な本人確認、より短命なトークン、あるいはより厳しい制限が加われば、今日のパーサー修正は、より大きなアクセスをめぐる争いへと発展する。