サイト内検索は改善ネタの宝庫｜次の一手をAIで見つける

検索窓に言葉を打ち込む訪問者は、目的がはっきりしています。Forrester Researchの調査では、サイト内検索で関連性の高い結果がすぐに得られた訪問者は、コンバージョンに至る可能性が2〜3倍高いと報告されており、サイト内検索サービス各社の分析でも、検索利用者のCVRが非利用者を上回る傾向は繰り返し確認されています。しかも入力された語句は、アンケートのような設問の誘導が一切かかっていない、訪問者が自分の語彙で残した要望そのものです。つまりサイト内検索のログは、放っておいても毎日たまり続ける、バイアスのかかっていない無料の顧客調査なのです。ところが多くのサイトでは、検索窓は設置されたきりで、ログを見る運用がありません。本記事では、GA4での計測設定からクエリ分析の3つの観点、記事企画やFAQ強化への落とし込み、AIを使った分類・示唆出しと月次運用化まで、サイト内検索データを改善の起点に変える手順を解説します。なお本記事で扱うのは自社サイト内の検索窓のデータであり、Google検索のクエリ分析とは別物です。

サイト内検索データとは：訪問者が「自分の言葉」で残す一次データ

サイト内検索データとは、自社サイトに設置した検索窓に入力された語句（クエリ）と、その検索回数・検索後の行動の記録です。同じ「検索」でも、Search Consoleで見るGoogle検索のクエリとは性質がまったく違います。Google検索のクエリはサイトに来る前の人の言葉ですが、サイト内検索のクエリはすでにサイトに来た人が、それでも見つけられなかったものの言葉です。つまり1件1件が「御社のサイトを見たうえで、これが見つからない・これが知りたい」という具体的な申告になっています。

この申告には2つの意味があります。1つは需要の証拠です。検索されたということは、少なくともその訪問者はそのテーマの情報を自社に期待しています。もう1つは導線の診断です。コンテンツが存在するのに検索されているなら、ナビゲーションやページ内リンクからたどり着けなかったということであり、クエリの一覧はそのままサイト構造の弱点マップとして読めます。アクセス解析の多くの指標が「結果」を示すのに対し、サイト内検索は「理由」を言葉で教えてくれる数少ないデータです。

なぜCVに近いのか：検索利用者の価値

冒頭のForrester Researchの調査が示すとおり、関連性の高い検索結果に即座にたどり着けた訪問者はコンバージョンに至る可能性が2〜3倍高いとされています。理由は行動の性質を考えれば自然です。トップページから何となく回遊する人と違い、検索窓を使う人は探しているものを言語化できるほど目的が具体的だからです。BtoBサイトなら「料金」「導入事例 製造業」「セミナー」といったクエリは、検討が進んだ訪問者からのシグナルそのものです。

裏を返すと、検索して見つからなかったときの損失も大きくなります。サイト内検索サービス各社の分析では、検索結果が0件だった訪問者は「このサイトには存在しない」と判断して離脱しやすいことが指摘されています。目的が明確な人ほど、代わりのページを探して回遊してはくれません。もっとも見込みの高い訪問者を、もっとも確実に取りこぼすのが0件ヒットです。

もう1つ押さえたいのは、母数が小さくても価値があるという点です。サイト内検索の利用者は訪問者全体の一部にすぎず、月に数十件しかログがないサイトも珍しくありません。それでも1件1件が具体的な要望である以上、数千セッションの直帰率を眺めるより、50件のクエリを読むほうが次の一手につながることは多いのです。量ではなく濃度で価値を測るデータだと考えてください。

大手ECの調査が示す現実：0件ヒットの半数は放置されている

サイト内検索がどれだけ手つかずの領域かを示す調査があります。検索サービスを提供する株式会社DGビジネステクノロジーが2026年1〜3月に実施した「大手ECサイト100社のサイト内検索調査2026」では、ネット通販売上高上位100サイトのうち94サイトをスマートフォンで目視確認し、5指標25項目で採点しました。その結果、表記ゆれへの対応は2023年の33%から78%へと大きく改善した一方で、同義語への対応スコアは32%にとどまり、0件ヒット時に候補キーワードの提示やおすすめ商品への誘導を行っていないサイトが47サイト（50%）ありました。

売上上位の大手ECですらこの状態です。検索機能そのものは高度化しても、「検索されたのに応えられなかった瞬間」への手当ては半数が空白のまま。逆に言えば、高価な検索エンジンを入れることより、ログを見て穴を塞ぐ運用のほうが先に差がつくということです。本記事で扱うのはまさにこの運用の部分であり、特別なツールがなくてもGA4と表計算とAIがあれば始められます。

全体の流れ：計測から施策までの4ステップ

進め方の全体像を先に示します。サイト内検索データの活用は、次の4ステップの繰り返しです。一度回してしまえば、2周目からは分析と施策だけで済むので、負荷は月に1時間程度に収まります。

以降のセクションで、各ステップを実務の粒度まで分解していきます。まずは土台になる計測設定からです。

STEP1：GA4の拡張計測でview_search_resultsを有効にする

GA4には、サイト内検索を自動計測する仕組みが標準で用意されています。管理画面の「データストリーム」から対象ストリームを開き、「拡張計測機能」の設定でサイト内検索がオンになっていることを確認してください。オンになっていれば、訪問者が検索結果ページを表示したときにview_search_resultsというイベントが自動で記録され、検索語句がsearch_termというパラメータに入ります。GA4のレポートでは「検索キーワード」というディメンションで確認できます。

重要なのは、このイベントの発生条件です。GA4公式ヘルプによると、view_search_resultsは検索ボタンのクリックを検知しているのではなく、表示されたページのURLに検索用のクエリパラメータが含まれているかどうかで判定されます。つまり計測が正しく動くかは、自社の検索結果ページのURLの形式に完全に依存します。次のセクションで、この確認方法を見ていきます。

クエリパラメータ設定の実務：まず自社の検索URLを確認する

最初にやることは単純で、自社サイトの検索窓に適当な語句を入れて検索し、結果ページのURLを見ることです。GA4公式ヘルプによると、既定ではq・s・search・query・keywordの5つのパラメータが監視対象で、URLにこのいずれかが含まれるとview_search_resultsが発生します。たとえばWordPressの標準検索は「?s=語句」という形式なので、既定のままで計測されます。一方、検索システムによっては「?kw=語句」「?search_word=語句」のような独自パラメータを使っており、その場合は拡張計測の詳細設定で自社のパラメータ名を追加登録しないと、検索がまったく計測されません。

もう1つの注意は優先順位です。既定の5つは「最初に一致したパラメータのみが使用される」仕様で、URLに複数のパラメータが並ぶと意図しない値が記録されます。アナリティクス支援会社プリンシプルの検証記事では、「keyword=検索語句&s=Mサイズ」のようなURLで、検索語句ではなく絞り込み条件の「Mサイズ」が記録されてしまう例が紹介されています。sやqは絞り込みやページ制御に使われがちな短い名前なので、自社で検索に使っていない既定パラメータは監視対象から削除しておくのが安全です。

設定を変えたら、必ず自分で検索してDebugViewかリアルタイムレポートでview_search_resultsの発生とsearch_termの中身を確認します。ここで5分使うだけで、1か月後に「データが全部欠けていた」という最悪の事態を防げます。

計測の落とし穴：SPA・文字コード・URLに残らない検索

拡張計測は便利ですが、仕組み上どうしても拾えないケースがあります。第一に、ページ遷移なしで検索結果を書き換えるSPA型のサイトです。URLが履歴APIで切り替わるだけの構成では、page_viewは計測されてもview_search_resultsは発生しません。この場合はGoogleタグマネージャー（GTM）で検索イベントを別途実装する必要があります。第二に、検索語句を送るときの文字コードです。UTF-8ではなくShift_JISでエンコードされたクエリは、GA4が正しく検出できないことが検証で報告されています。古い検索システムを使っているサイトほど、日本語クエリが欠落していないかの確認が必要です。

第三に、そもそもURLにパラメータが付かない検索です。入力途中に結果が出るインクリメンタル検索や、POST送信で結果を返す検索は、URLに痕跡が残らないため拡張計測では拾えません。心当たりがある場合は、計測できている件数が実際の検索利用数より大幅に少ない可能性を疑ってください。

• 検索クエリには氏名やメールアドレスなどの個人情報が入力されることがある。レポートを社外や広い範囲に共有する際は該当行を除外する
• GA4公式ヘルプによると、セッション固有の値が検出された場合はunique_search_termというパラメータのみが送信される仕様がある。見慣れないパラメータが出ても異常ではない
• 計測設定の変更は過去にさかのぼって適用されない。分析の開始時期は設定完了日からになる

STEP2：データを1か月ためて、一覧に落とす

計測が動いたら、次はデータの確認です。日常的には、レポートの「エンゲージメント＞イベント」でview_search_resultsの件数を見れば、検索がどれくらい使われているかが分かります。分析用の一覧を作るには「探索」機能を使い、ディメンションに検索キーワード、指標にイベント数を設定した表を作ります。これで「どんな語句が・何回検索されたか」のランキングが手に入ります。検索キーワード×ページ（検索が発生したページ）を掛け合わせると、どの画面で困った人が多いかも見えてきます。

ためる期間は最低1か月が目安です。週単位では件数が少なすぎて傾向とノイズの区別がつきません。逆に、拡張計測が最初から有効だったサイトなら、過去1年分をさかのぼって分析できるので、今日からでも始められます。一覧ができたら探索レポートからCSVでエクスポートしておきます。この後のAI分析でそのまま使うためです。月末に同じ条件でエクスポートする、という手順だけ決めておけば、収集の工数はほぼゼロになります。

STEP3：分析は3つの観点で読む

クエリ一覧を前にして「さて何を見るか」で止まらないように、観点を3つに絞ります。それぞれ見るものと打ち手が違うので、先に対応表で全体像をつかんでください。

観点	何を見つけるか	主な打ち手
コンテンツギャップ	検索されているのに該当コンテンツがない語句	新規記事・資料の企画、既存記事への追記
0件ヒット	検索結果が0件になる語句	コンテンツ追加、0件時の誘導改善、同義語登録
表記ゆれ・同義語	同じ意図なのに表記が割れている語句群	同義語辞書の整備、タイトルへの表記追加

1つ目のコンテンツギャップは、もっとも売上に直結する観点です。検索されたということは需要の証拠であり、該当コンテンツがなければその需要を毎回取りこぼしています。BtoBサイトでよく見つかるのは「価格」「料金」「事例＋業種名」「テンプレート」「比較」のような検討段階のクエリです。クエリごとに実際に自社サイトを検索し、まともな受け皿ページがあるかを1件ずつ確認していくのが基本動作になります。ギャップが見つかったら、それは読者がいると分かっている状態から始められる記事企画です。キーワード調査から始める企画より、はるかに確度が高い出発点になります。

観点の深掘り①：0件ヒットは機会損失の最前線

0件ヒットの見つけ方はサイトの実装によって変わります。検索結果0件のページが専用URL（0件用のパラメータや文言）を持つなら、そのページの表示回数で機械的に検出できます。専用URLがない場合は、エクスポートしたクエリの上位から順に自分で検索してみるのが確実です。地味な作業に見えますが、上位50件を確認するだけなら30分もかかりません。検索回数が多いのに0件になる語句が1つでも見つかれば、その30分の元は取れます。

対処は2段構えです。まず、その語句に応えるコンテンツを作るか、既存ページに語句を含めて検索にかかるようにします。次に、0件ヒット自体をなくせなくても、0件ページに人気コンテンツやカテゴリ一覧・問い合わせへの誘導を置いて、行き止まりを分岐点に変えます。前述のDGBTの調査では大手ECの50%がこの誘導を置いていませんでした。裏返せば、0件ページに誘導を置くだけで、半数の大手より丁寧なサイトになれるということです。

観点の深掘り②：表記ゆれ・同義語で「あるのに見つからない」を潰す

コンテンツは存在するのに、表記の違いで検索にかからないケースは想像以上に多く発生します。日本語は「見積もり／見積り／お見積り」「問い合わせ／問合せ」のような送り仮名・漢字の揺れに加え、「資料／パンフレット／カタログ」「研修／セミナー／講座」のような同義語の揺れも重なります。EC分野の調査レポートでも、「帽子」で検索する人と「キャップ」「ハット」で検索する人が同じ棚を探している例が紹介されており、揺れの吸収は検索体験の基本要件とされています。前述の大手EC調査で同義語対応スコアがわずか32%だったことからも、ここが業界全体の弱点だと分かります。

対処は検索システム側とコンテンツ側の両面があります。検索システムに同義語辞書やゆれ吸収の設定があれば、クエリログから拾った揺れをペアで登録していきます。設定がない簡易な検索機能の場合は、コンテンツ側で吸収します。具体的には、ページタイトルや本文の初出に主要な表記を併記する（例：見積もり（お見積り）依頼の流れ）、FAQに別表記の質問文を立てる、といった方法です。どの表記で検索されても同じ答えにたどり着ける状態がゴールです。

STEP4：記事企画・FAQ・ナビ改善に落とし込む

分析の仕分けができたら、施策への変換です。1つ目は記事企画。ギャップに分類したクエリを「想定読者・検索意図・既存コンテンツとの重複・優先度」の4項目とセットで企画票にします。検索回数という需要の証拠が付いているので、社内の企画会議でも通しやすいはずです。2つ目はFAQ強化。「〜とは」「〜方法」「〜できない」のような質問形のクエリは、そのままFAQの質問文になります。訪問者の言葉づかいのまま質問文にするのがコツで、社内用語に翻訳してしまうと再び検索されなくなります。

3つ目はナビゲーション改善です。十分な受け皿ページがあるのに検索され続けている語句は、導線の敗北を意味します。その語句のページがナビの何階層目にあるか、リンクの文言が訪問者の語彙と一致しているかを確認し、グローバルナビやフッター、関連リンクの見直しにつなげます。検索窓の利用が特定ページに偏っているなら、そのページに不足している内部リンクのヒントでもあります。

落とし込みの段階でつまずくパターンも決まっています。次の4つは避けてください。

• 一度ログを眺めて満足し、翌月から誰も見なくなる（運用の型がないまま始める）
• 検索回数の多い語句だけ見て、0件ヒットや表記ゆれなどの質的な問題を放置する
• 0件ヒットを検索エンジンの設定だけで解決しようとして、そもそもコンテンツがない事実から目を背ける
• 「こんな検索は少数派だから無視でいい」と感覚で切り捨てる（少数でも検討度の高い訪問者かもしれない）

AI活用①：クエリの分類とタグ付けを任せる

月に数百件のクエリを人手で仕分けるのは現実的ではありません。ここが生成AIの出番です。エクスポートしたクエリ一覧を渡し、意図の分類・表記ゆれのグルーピング・ギャップ候補の抽出までを一度にやらせます。プロンプトの例を挙げます。

あなたはBtoBサイトの分析担当者です。
以下はサイト内検索のクエリと検索回数のリストです（形式：クエリ,回数）。
1. 各クエリを次の5分類に振り分けてください：
   情報収集／比較・検討／料金・導入／サポート・使い方／その他
2. 表記ゆれ・同義語と思われるクエリをグループ化してください。
3. 検索意図に対して該当コンテンツがなさそうなクエリを3つ挙げ、
   想定される訪問者の意図を1行ずつ説明してください。
※件数の合計や集計はしないでください（集計は表計算側で行います）。
---
（ここにエクスポートしたクエリ一覧を貼り付け）

ポイントは役割分担です。数を数える仕事は表計算に、意味を読む仕事はAIに割り当てます。生成AIは集計を間違えることがあるため、合計値や構成比はスプレッドシートのピボットで出し、AIには分類とグルーピングという言語処理だけを任せると、精度と再現性が両立します。また、分類結果のうちギャップ候補は必ず人が実サイトで検索して裏取りしてください。AIは自社サイトの中身を知らないので、ここは推測にすぎません。

AI活用②：同義語辞書の草案と月次サマリーの下書き

表記ゆれのグループができたら、そのまま同義語辞書の草案づくりに進めます。グループ化された語句群をAIに渡し、「代表語＋同義語リスト」の形式に整形させれば、検索システムの同義語設定にほぼコピーで登録できる下書きになります。自社の商品名・サービス名の略称や旧名称など、社内の人しか知らない揺れを追加で教えてあげると辞書の質が一段上がります。

もう1つの使い道は報告の省力化です。分類結果と前月比を渡して「今月の発見を3点、それぞれ根拠のクエリ付きで」と指示すれば、月次レポートの考察欄の下書きが数分で手に入ります。ただしAIが書いた考察は仮説にすぎないので、数字の確認と最終判断は人が行います。示唆を出す作業が軽くなるほど、人の時間は「どの施策を先にやるか」という優先順位の判断に使えるようになります。これがAIを入れる本当の狙いです。

月次60分の定例運用に組み込む

最後に、ここまでの作業を月次の型にします。おすすめの時間割は60分です。最初の10分でGA4の探索レポートからクエリ一覧をエクスポートし、次の15分でAIに分類・グルーピングをかけ、20分で3観点（ギャップ・0件ヒット・表記ゆれ）の新規発見を確認し、残り15分で施策を起票します。追いかける数字は0件ヒットになった検索の割合、検索経由の遷移先、ギャップ起点で作った記事の本数と成果の3つで十分です。

定着のコツは、新しい会議を作らないことです。既存の月次アクセスレポートに「サイト内検索」の1枚を追加する形にすれば、報告の場も判断者も今のままで回ります。四半期に一度は、頻出クエリとナビゲーションの対応を棚卸しして、導線レベルの改善につなげてください。検索ログを毎月読む会社と読まない会社の差は、1年で記事十数本分の企画力の差になって表れます。

よくある質問

検索が月に数十件しかありません。分析する価値はありますか？

あります。サイト内検索は量より濃度のデータで、数十件でも「見つからなかったもの」の傾向はつかめます。また件数が少ないこと自体が示唆です。検索窓が目立たない位置にある、あるいは訪問者が探し物をする前に離脱している可能性があります。検索窓をヘッダーの見やすい位置に出すだけで件数が増え、データも施策も回り始めることがあります。

高機能なサイト内検索ツールに入れ替えるべきでしょうか？

まずはログを見る運用が先です。大手ECサイト94社の調査でも、機能面の高度化が進む一方で同義語対応や0件ヒット時の誘導は半数近くが不十分なままでした。ツールは揺れの吸収や候補表示を自動化してくれますが、どんなクエリが来ていて何が足りないかを知らないままでは、選定も設定もできません。ログ分析を3か月回して課題が明確になった時点で、その課題を解決できるツールを選ぶのが順序です。

Search Consoleのクエリ分析と何が違うのですか？

見ている場面が違います。Search ConsoleのクエリはGoogle検索での露出、つまりサイトに来る前の需要を示します。サイト内検索のクエリは、サイトに来た人がなお満たせなかった需要を示します。前者は集客の設計に、後者はコンテンツと導線の穴埋めに向いており、併用することで「呼び込み」と「受け止め」の両面が揃います。同じキーワードでも両者で扱いは別物です。

検索窓がないサイトはどうすればいいですか？

コンテンツ数が数十ページを超えているなら、設置を検討する価値があります。WordPressなら標準機能で検索窓を出せて、URLも「?s=」形式なのでGA4の既定設定のまま計測できます。まず標準機能で設置してログを3か月ため、検索の使われ方を見てから精度改善に投資するのが低リスクです。ページ数が少ないサイトでは、検索窓よりナビゲーションの整理が先になります。

まとめ

サイト内検索のデータは、訪問者が自分の言葉で残した要望のリストであり、CVに近い層の声がそのまま録音されている場所です。GA4の拡張計測でview_search_resultsを有効にし、自社の検索URLのパラメータを確認する。1か月ためたクエリを、コンテンツギャップ・0件ヒット・表記ゆれの3観点で読む。見つけた穴を記事企画・FAQ・ナビ改善で塞ぎ、分類と示唆出しはAIに任せて月次60分の定例にする。大手ECの半数ですら0件ヒットを放置している現実は、裏を返せば検索ログを読む習慣そのものが競争力になるということです。今月のログから、次の一手を拾い上げてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。