何が起きたか:サイト内検索スパムは「品質の問題」になりうる
記事の見出しは「Google May Treat Search Box Pages As A Site Quality Issue(Googleは検索ボックスのページをサイト品質の問題として扱う場合がある)」。リード文には、GoogleのJohn MuellerとMartin Splittが、スパムを流し込まれた検索ボックスのページはハッキングされたものとして扱われ品質の問題になりうると述べた、と要約されています。
Mueller氏の説明では、サイト内検索スパムは、スパムページがインデックスされうる、あるいはインデックス可能な状態にある場合に品質の問題になりえます。同氏は例として、検索ボックスにテキストを入力すると、そのスパム的なテキストを含むウェブページが生成されるケースを挙げています。実際に起こりうる挙動です。
Mueller氏の発言は次のように引用されています。「ただ、検索結果ページで品質の問題にぶつかりうる場所がひとつあります。すなわち、あなたのウェブサイトとまったく無関係なことを人々に検索させてしまい、その検索結果ページにそれらの語が含まれていて、しかもインデックス可能である場合です。……そしてこれは、誰かがあなたのウェブサイトをハックしてこうさせたという話ではあまりありません。あなたのウェブサイトが自由にそれをやっていて、要するに『ああ、写真を検索したんですね、はい写真です』と言っているだけです。しかし、どんな検索語に対してもアクセス可能であるがゆえに、それは突然、負債(liability)になります。他の人があなたを踏み台にスパムするためのベクター(vector)に近いものです」。
記事は、検索ボックスがスパムのベクターになるというこの指摘は、自動生成されたページのインデックスを許している場合には正しい、と補足しています。
Googleはサイト内検索ページを「ハッキング」としてフラグする場合がある
記事がもう一つ有用な情報として挙げるのは、両氏がこうしたスパムを流し込まれたページを、あたかもハッキングされたページであるかのようにフラグすると説明した点です。そしてこの種のページはGoogleの検索結果に現れうる、とされています。
Mueller氏の説明は次のとおりです。「そして、人々がそれを大規模にやるのを我々は見てきました。彼らは、検索結果ページをブロックしていない一般的なCMSを見つけ出そうとし、数千のサイトに、数百万ページ規模でリンクを張っていきます。すべてに、おそらくはアダルト系の語と電話番号、あるいは医薬品と電話番号、あるいは別の何かとTelegramのアドレス、あるいは何らかの連絡手段が載っています。目的は、人々があなたのサイトに来て写真を見ることではなく、検索結果のなかで『この医薬品についてはこの番号に電話』と見せることです。そして、この種のクエリで実際にそれが表示されることがあります。そういう事態を見たとき、我々はそれをハッキングとしてフラグすることがあります。ですからSearch Consoleで、ハッキングとしてフラグされたものが見えることがあるのです」。
ここで重要なのは、原因が外部からの侵入ではなくサイト自身の仕様であっても、Search Console上の見え方は「ハッキング」になりうるという点です。侵入の痕跡を探しても何も見つからないため、原因の切り分けで時間を失いやすい類の問題だといえます。
アルゴリズムで捕まえられても「解決済み」とは限らない
Mueller氏はまた、Googleがこの種のページをアルゴリズム的に捕まえ、検索結果に出ないようブロックできるとも説明しています。サイト運営者の側から見れば、Googleが処理してくれたのだから勝ちのように感じられる場面です。
しかし記事は、Mueller氏がその問題が片付いたと決め込むことに対して警告している、と書いています。検索結果に出なくなったことは、サイト側の穴が閉じたことを意味しません。自動生成ページが引き続き生成・クロール可能なままであれば、原因はそのまま残っています。
防ぎ方:クロールを止める、インデックスを止める
Mueller氏とSplitt氏が推奨した対策は2つに整理されています。クロールを防ぐこと、そしてインデックスを防ぐことです。
第一の推奨はrobots.txtでクロールを止めること
1つめの推奨は、robots.txtを使ってGoogleおよび他の検索エンジンが、自動生成された検索ボックスのウェブページをクロールしないようにすることです。記事は、両氏がrobots.txtでブロックする理由として4点を列挙したと伝えています。
- Googleは検索ページをクロールする必要がない。
- 無限クロールを防げる。
- サーバー負荷を軽減できる。
- クロール予算(crawl budget)の浪費を防げる。
無限クロールについて、Martin Splitt氏は、検索ボックスの実装によっては無限の「クロール空間(crawl space)」に変わりうると述べています。Googleがそれらの検索ページをクロールしたことに反応して発動する「did you mean(こちらの検索ではありませんか)」機能を通じて、検索ボックスがウェブページを自動生成し続けるためです。
Splitt氏の発言は次のように引かれています。「というわけで、ウェブサイト上の検索結果について色々学びました。それらは無限のクロール空間になりえます。なぜなら我々は基本的に、こうしたページを次々に生成できるからです。そして『こちらの検索では?』のようなリンクを張れば、クローラーが沈み込んでいくページをさらに作り出してしまいます。そして、robots.txtやnoindexで比較的簡単に片付けられるようですね」。
記事は、この無限クロール空間の問題が、サーバー負荷の増大とサイトのクロール予算への圧迫にもつながっていると整理しています。
無限のページ数は「王様」にはなれない
John Mueller氏は、無限クロール・サーバー負荷・クロール予算の浪費がどうつながっているかを次のように説明しています。「そしてそれらすべてが意味するのは、要するに我々があなたのサイト上で無限の数のページを見つける、あるいは見つけうるということです。そして、こう考える人がいるのは知っています。『わあ、もしGoogleに無限のページがあったら、自分は王様だろう』と。しかし、Googleに知られているページが無限にあることは良いことではありません。Googleはそれらのページ全部をクロールしようとするからです。そして、Martin Splittから新しく1億ページが見つかったとしたら何が起きるか、想像できるでしょう。我々はそれをクロールしに行きます。そうなると突然、クロール予算が問題になり、サーバー負荷が問題になり、あなたのサーバーは『なんてことだ』となるわけです」。
記事は、これらがMueller氏とSplitt氏がrobots.txtで検索ボックスページのクロールを防ぐよう勧める理由のすべてだとまとめています。そして、より正確には、自動生成される検索ボックスページのあらゆるバリエーションを捕まえられるよう、可能なかぎり広く一般的なrobots.txtのルールを使うべきだと両氏が述べている、と付け加えています。
noindexも言及されているが、robots.txtのほうが簡単で綺麗
Mueller氏とSplitt氏はrobotsのnoindexディレクティブについても言及していますが、検索ボックスのウェブページを扱うには、robots.txtのほうが簡単でもっとも綺麗な方法であると述べたと記事は伝えています。
実務への影響と、今日からできる確認手順
原文が示している範囲で、手を動かせるところを整理します。まず前提として、この問題は外部からの侵入がなくても発生します。原文の言い方では、サイト自身が自由にページを生成しており、どんな検索語でもアクセス可能であるがゆえに負債になる、という構図です。
- 自サイトの検索結果ページがどんなURLで生成されるかを確認する。クエリがURLに載る実装であれば、そのURLパターンが対象です。
- そのパターンを、robots.txtで可能なかぎり広く一般的なルールとしてブロックする。原文は、自動生成される検索ボックスページのあらゆるバリエーションを捕まえられる広いルールを推奨しています。
- Search Consoleで「ハッキング」に関する通知が来ていないかを確認する。原文の説明では、サイト内検索スパムがこの形でフラグされることがあります。
- 検索結果からスパムページが消えていても、それだけで解決とみなさない。原文はGoogleがアルゴリズム的にブロックできる一方で、問題が片付いたと決め込むことに警告しています。
- 「did you mean」のような検索結果からの再生成リンクがあるかを確認する。Splitt氏が無限クロール空間の具体例として挙げた挙動です。
※以下はScale Basics編集部による一般的な実務上の補足です。robots.txtでクロールを止めた場合、すでにインデックスされているURLの扱いは別の話になりますので、既存のインデックス済みページがあるかどうかを先に確認しておくと手順を決めやすくなります。
所感
ここからは記事本文にはない、Scale Basics編集部の見解です。この話が厄介なのは、被害の入口がサイトの正常な機能である点だと考えます。検索ボックスは訪問者のために置いてあるもので、脆弱性ではありません。それでも、クエリがURLに乗り、そのURLがインデックス可能であるという2条件が揃うだけで、第三者がページを量産できる窓口になります。原文がこれを「負債」と表現しているのは的確でしょう。
実務上いちばん怖いのは、Search Consoleに「ハッキング」として現れる点だと見ています。通知を受けた側は当然、侵入経路を探します。ところが原因はサイト内検索の設定であり、サーバーやプラグインを調べても何も見つかりません。原因の切り分けに時間がかかるほど、その間もスパムページは増え続けます。robots.txtの1行で防げる問題としては、失う時間が大きすぎます。
もう一点、Splitt氏の「did you mean」の指摘は見落としやすい落とし穴だと感じます。検索結果ページに関連キーワードのリンクを出す実装はユーザー体験の改善として広く使われていますが、その先が同じ検索結果ページであれば、クローラーにとっては終わりのない通路になります。CMS標準のサイト内検索を使っている場合ほど、生成URLのパターンを一度確認しておく価値があります。
まとめ
・Search Engine Journalが2026年7月31日付で、GoogleのJohn Mueller氏とMartin Splitt氏がSearch Off the Record第113回で語ったサイト内検索スパムの扱いを報じた
・Mueller氏は、サイトと無関係な語を検索させてしまい、その語を含む検索結果ページがインデックス可能である場合、品質の問題になりうると説明し、検索ボックスが他者のスパムのベクターになると述べた
・スパマーは検索結果ページをブロックしていないCMSを見つけて数千サイト・数百万ページ規模でリンクを張り、アダルト系や医薬品の語と電話番号・Telegramアドレスを載せる。Googleはこうしたページをハッキングとしてフラグすることがあり、Search Consoleにそう表示される場合がある
・Googleはアルゴリズム的にこれらのページを捕まえて検索結果から除外できるが、Mueller氏はそれで問題が片付いたと決め込むことに警告している
・推奨される対策はクロールの防止とインデックスの防止で、第一の推奨はrobots.txt。理由は、検索ページをクロールする必要がない、無限クロールを防ぐ、サーバー負荷を減らす、クロール予算の浪費を防ぐの4点。noindexにも言及されているが、robots.txtのほうが簡単で綺麗だとされている
よくある質問
Q1: サイト内検索ページは、なぜ品質の問題になるのですか?
Mueller氏の説明では、サイトとまったく無関係な語を人々に検索させてしまい、その語を含む検索結果ページがインデックス可能である場合に問題になります。これは外部からの侵入ではなく、サイト自身がどんな検索語に対してもページを生成・公開してしまう仕様に起因します。原文はこの状態を「負債」であり、他者があなたのサイトを踏み台にスパムするための「ベクター」に近いと表現しています。
Q2: Search Consoleに「ハッキング」と表示されたら、侵入されたということですか?
必ずしもそうではありません。原文によれば、スパマーが大規模にサイト内検索ページを生成し、それが検索結果に現れる事態をGoogleが検知した場合、ハッキングとしてフラグすることがあり、Search Consoleでもそのように見えることがあります。Mueller氏は、これは誰かがサイトをハックしてそうさせた話ではなく、サイトが自由にそのページを生成している状態だと明言しています。
Q3: 対策はrobots.txtとnoindexのどちらを使うべきですか?
原文では、Mueller氏とSplitt氏の両方がrobots.txtとnoindexに言及していますが、検索ボックスのウェブページを扱うにはrobots.txtのほうが簡単で、もっとも綺麗な方法だとされています。またrobots.txtのルールは、自動生成される検索ボックスページのあらゆるバリエーションを捕まえられるよう、可能なかぎり広く一般的なものにすべきだと述べられています。※以下はScale Basics編集部による一般的な実務上の補足ですが、すでにインデックス済みのURLがある場合は扱いが別になるため、現状のインデックス状況を先に確認しておくと手順を決めやすくなります。
出典:Google May Treat Search Box Pages As A Site Quality Issue(Search Engine Journal、Roger Montti氏、2026年7月31日)https://www.searchenginejournal.com/google-may-treat-search-box-pages-as-a-site-quality-issue/584419/
