Google Searchの検索結果が、ただの見た目の変更では済まない動きを見せています。検索結果のリンク先がそのままHTMLに出るのではなく、google.com/goto を経由する形に変わりつつある、というのが今回の話です。検索する側にはほとんど気づかれない一方で、検索結果を機械的に集めている側にはかなり重い変更になります。Autom はこの変化を観測し、自社のGoogle Search APIをすでに追随させたと説明しています。
google.com/goto に変わったAutom の記事が伝えているのは、Google Search が自然検索のリンクを google.com/goto?url=... のようなリダイレクトURLに書き換え始めた、ということです。検索結果のHTML上では、もはや目的地のURLがそのまま露出しません。クリックするとGoogle側の /goto に飛び、そこから実際のページへ転送されます。
ここで重要なのは、古い google.com/url?q=[URL-encoded destination] と同じ感覚では扱えない点です。以前の形式は、クエリ文字列を見れば行き先が読めました。ところが新しい goto 形式では、url= の中身をオフラインで復号して目的地を取り出すことはできない、と記事は説明しています。中身はGoogle独自の符号化で、単純な base64 ではないそうです。実際には、Googleのインデックスにあるページ記録への、あいまいな参照のように見える、と書かれています。
また、Googleがページを描画するためには、当然ながらリンク先を知っていなければなりません。なので検索結果の画面上には、ドメイン名や favicon、表示用の属性など、URLの一部は残っています。とはいえ、それは検索結果を人間が見るための情報であって、スクレイピングで本当の遷移先を抜き出す話とは別だ、と記事は切り分けています。Autom は、Location ヘッダーを読む形で実際のURLを取り出すべきだと案内し、/goto をそのまま追わないようにと述べています。
この変更は late August 2026 時点で、ログアウト状態や private mode ではかなり広く見えるようになっている、と記事は報告します。まだ実験段階の可能性には触れているものの、少数のSERPだけに出る限定テストではなくなった、という見立てです。Autom は最初は一部でしか見えなかったため慎重だったが、今ではより一貫して観測されるので、Google Search のパイプラインを更新し、google.com/goto を解決して最終的な遷移先URLをAPI応答に戻すようにした、と説明しています。
私はこの変更を、単なるUI調整ではなく、Googleが検索結果の大量収集にかけるコストを上げる一手だと見ています。記事でも、対象はAI crawlerやSEO scraperのように、SERPから結果URLをまとめて抜き出し、自前の索引を作ろうとする自動化システムだと明言されています。平文のリンクなら、HTMLを一度取れば何千件でもURLを抜けます。Googleに戻る必要はありません。goto になると、各結果についてGoogleに再度問い合わせて行き先を知る必要が出る。遅くなり、通信も増え、同じクライアントが何百件も連続で解決していることもGoogleに見えやすくなる。そこが狙いなのだと思います。
この手口は、スクレイピング全体でよく見える「安く取れる情報を少しずつ高くする」流れの一部にも見えます。記事は、&num=100 の削除や BotGuard/SearchGuard の強化にも触れています。つまりGoogleは、検索結果を大量に抜く人たちに対して、1回の取得では済ませにくい設計へじわじわ変えているわけです。派手なブロックではなく、地味に面倒くさくする方向です。こういうやり方は、正面からの停止よりも運用上の効果が大きいことがあります。
ただし、ここには少し気になる点もあります。検索結果を機械で集める行為には、悪質なものだけでなく、競合調査や学術研究、検索品質の観測のような用途も混じります。Googleから見れば全部まとめて「負荷をかける自動収集」かもしれませんが、利用者側からすると用途の差は大きい。goto はその差を見分けず、まとめて取り回しを悪くします。私は、これが「悪いスクレイパーだけを困らせる」設計ではない、と感じます。
Autom の対応はかなり現実的です。彼らは google.com/goto を見つけた時点で、まず小さな割合のSERPで試験的に出ていた段階から監視を続け、今はパイプラインを更新して Location を読むようにしたと書いています。ここで大事なのは、ユーザー向けのAPIの返却形式を変えずに済ませていることです。顧客は Google Search の結果から実用的な destination URL を受け取り続けられ、統合コードを直さなくてよい、と説明されています。
この「インターフェースを変えないまま中身だけ吸収する」対応は、SERP API を提供する会社にとってはかなり重要だと思います。利用者は検索結果の裏でGoogleがどうURLを包み替えたかまで追いかけたくありません。そこを吸収できる事業者が強い。逆に言えば、Googleの変更が進むほど、API事業者の価値は「単に取る」ことから「変化に追随する」ことへ移っていきます。Autom の記事は、その競争の土俵がもう変わっていることを示しています。
一方で、こうした対応がうまくいくのは、Googleの挙動がまだ観測可能だからです。goto が今後さらに複雑化したり、条件ごとに違う形式を出し分けたりすると、解決はもっと面倒になります。Autom は「また形式が変わるかもしれない」と警戒していますが、その前提はかなり現実的です。Googleが本気で対抗している相手が自動収集なら、固定の抜け道は長く続かないはずだからです。
この話で面白いのは、Googleが検索結果そのものを消しているわけではない点です。人間に見える検索体験は保ちつつ、機械が安易に持ち出せる部分だけを薄くしている。つまり戦場は「検索できるか」ではなく、「検索結果を機械で再利用できるか」に移っています。これは、検索エンジンの公開インターフェースが、以前よりずっと制御された資源になったことを示しています。
私は、ここで勝負がつくとは思いません。スクレイパー側は Location を読む方法に移るし、Google側はそれをまた塞ぐでしょう。いたちごっこです。ただ、そのいたちごっこは無意味ではなく、やる側の規模を絞り込みます。雑に大量取得していたプレイヤーはコストに負け、きちんと運用体制を持つ事業者だけが残る。Googleにとってはそれで十分なのかもしれません。検索結果の再配布を簡単にさせない、というメッセージだからです。
同時に、こうした変更が進むほど、検索データを外部からどう扱うかという設計思想も問われます。誰でも見られるページだから自由に集めてよい、という発想は通りにくくなっている。今後は、取得の可否よりも、どういう頻度で、どの粒度で、どのような追跡信号を残すのかが問題になるはずです。Autom の記事は、その変化をかなりはっきり示していると思います。