Search Consoleのクエリ分類ルールを作る方法｜指名・非指名・比較・地域でKPIを分ける

監修: 菊地 将（リブランディング株式会社）

Search Consoleには、企業名を含む指名検索、課題を探す非指名検索、比較検討、地域名を含む検索など、目的の異なるクエリが同じ一覧に並びます。すべてを合算すると、ブランドを指定しない検索で接点が広がったのか、ブランド検索が伸びたのか、比較段階の需要が増えたのかを判断しにくくなります。重要なのは、毎月担当者の感覚で仕分けるのではなく、分類軸・辞書・例外・更新ルールを先に固定することです。本記事では、同じクエリに複数の特徴があることを前提に、再利用できるクエリ分類ルールを作る手順を解説します。

結論｜「指名・非指名・比較・地域」を1列に押し込まず、複数軸で分類する

Search Consoleのクエリ分類では、「指名」「非指名」「比較」「地域」を1つの排他的なカテゴリとして扱わないことが重要です。指名・非指名は「ブランドとの関係」、比較は「検索目的」、地域は「検索条件」という別の性質を持つためです。

クエリ分類を含むSEO計測全体の見方は、SEOの効果測定と改善方法で整理しています。

指名・比較・地域は排他的な分類ではありません。同じ検索クエリへ複数の属性を付けることで、検索目的や条件を残したまま集計できます。

たとえば「Example社 SEO 比較 東京」というクエリは、指名検索であり、比較検討でもあり、地域条件も含みます。これを1つだけに分類すると、どこかの情報が失われます。

実務では、最低でも次のように列を分けます。

この形なら、「非指名×比較」「非指名×地域」「指名×比較」といったKPIを同じデータから作れます。分類の目的は検索語をきれいに並べることではなく、SEO成果を目的別に比較できる状態を作ることです。

Search Console標準機能でできる分類と、自社ルールが必要な分類を分ける

2026年のSearch Consoleには、ブランドクエリと非ブランドクエリを自動的に分ける「Branded / Non-branded」フィルタがあります。Googleは、ブランド名だけでなく表記揺れ、スペルミス、ブランドに密接な商品・サービスまでAI支援システムで判定すると説明しています。

一方、この分類は正規表現による固定ルールではなく、文脈に応じて判定されます。Google自身も誤分類が起こる可能性を案内しており、サブプロパティや表示回数が少ないサイトでは利用できません。

また、Search Console Insightsには、似たクエリをAIでまとめる「クエリグループ」があります。ただし、グループは高水準の傾向把握を目的としており、時間とともに変化する可能性があります。自社の「比較」「地域」「料金」などの固定KPI分類を置き換えるものではありません。

Googleの標準機能は「確認用」、自社分類は「継続計測用」と役割を分けると運用しやすくなります。

手順1｜最初に「何を評価したいか」をKPIの問いとして固定する

分類辞書を作る前に、クエリを分ける目的を決めます。目的がないまま細かく分類すると、使わないカテゴリが増え、担当者によって判断が変わりやすくなります。

たとえばBtoBサイトなら、次の4つの問いから始められます。

• 非指名検索の表示回数・クリックは増え、ブランドを指定しない検索での接点が広がっているか
• 指名検索の表示回数・クリックは増え、ブランドを指定して探す需要が伸びているか
• 比較・検討系クエリのクリックは増え、意思決定に近い検索へ接点を持てているか
• 地域系クエリの表示回数・クリックは増え、商圏内の検索需要を取れているか

「東京 SEO会社 比較」のように、地域と比較が同時に現れるクエリがあります。検索意図には情報・ナビゲーション・取引などの古典的分類がありますが、AI検索を含む現在の情報探索では新しい分類枠組みも研究されています。GSC運用では、学術分類をそのまま使うより、自社の意思決定に必要な軸へ変換する方が実用的です。

手順2｜指名・比較・地域の「分類辞書」を作る

分類辞書は、誰が実行しても同じ結果になる文字列一覧として管理します。高表示回数・高クリックのクエリから作り、毎月未知語を追加します。

指名辞書は企業名だけでなく、表記揺れ・サービス名まで含める

指名辞書には、少なくとも次を入れます。

• 企業名・ブランド名
• ひらがな、カタカナ、英字などの表記揺れ
• 略称
• よくあるスペルミス
• 固有の商品名・サービス名
• ドメイン名の主要部分
• 旧名称が検索される場合は旧名称

GoogleのBrandedフィルタも、ブランド名だけでなく表記違い、誤記、ブランド固有の商品・サービスを対象にしています。自社辞書を作る際も、この範囲を確認すると漏れを見つけやすくなります。

ただし、一般名詞と同じサービス名は注意が必要です。一般語としても使われる名称を単独で指名扱いすると、非指名検索を誤分類する可能性があります。こうした語は例外辞書で扱います。

比較・検討辞書は「比較」だけでなく、意思決定語をまとめる

比較・検討の初期辞書には、次のような語を候補にできます。

比較 / 違い / vs / おすすめ / ランキング / 選び方 / 評判 / 口コミ / 料金 / 費用 / 事例

ただし、「料金」は必ず比較とは限りません。「自社名 料金」は指名後の確認、「SEO 料金」は相場調査という可能性があります。そのため、辞書は「語が入ったら検索意図が確定するルール」ではなく、「比較・検討フラグを付けるルール」として使うと誤判定を減らせます。

地域辞書は都道府県だけでなく、市区町村・駅名・商圏語も管理する

地域分類では、都道府県名だけでは不足します。

• 都道府県
• 市区町村
• 駅名
• 地域の通称
• 「近く」「周辺」などの近接表現
• 自社が営業対象とする商圏名

辞書は自社の商圏に合わせます。地名を含む会社名やサービス名がある場合は、先に例外判定します。

手順3｜「例外 → 各分類軸 → 未分類」の順で判定する

安定した分類には、通常辞書より先に適用する例外ルールが必要です。おすすめの処理順は次のとおりです。

1. 完全一致または明示的な例外ルールを適用する
2. 指名辞書でbrand_classを判定する
3. 比較・検討辞書でcomparisonフラグを付ける
4. 地域辞書でgeo_flagを付ける
5. 必要なら情報収集・行動などのintent_classを付ける
6. 判定できないものはunknownとして残す
7. unknownのうち表示回数・クリックが大きいものから人が確認する

通常辞書より例外ルールを先に適用し、自動判定できないクエリはunknownとして残します。すべてを手作業で確認せず、影響の大きいクエリから確認します。

unknownをゼロにする必要はありません。KPIへの影響が大きい未分類クエリから確認し、低頻度の曖昧語に時間を使いすぎないようにします。

この方式なら「指名か比較か」の二者択一が不要になり、検索ユーザーがどの状態で、何を条件に探しているかを残せます。

手順4｜Search Consoleの正規表現は「抽出」に使い、分類台帳は別に持つ

Search Consoleのクエリフィルタでは正規表現を使えます。Google公式ヘルプによると、構文はRE2で、初期状態は部分一致・大文字小文字を区別しない判定です。複数語は|でOR条件にでき、^で先頭、$で末尾を指定できます。

確認用の初期パターンは、たとえば次のように作れます。

• 指名候補：(example|エグザンプル|exampleサービス)
• 比較候補：(比較|おすすめ|ランキング|違い|vs|評判|口コミ)
• 地域候補：(東京|大阪|名古屋|新宿|渋谷|近く|周辺)

ここで注意したいのが、Search Consoleが採用するRE2では、先読み・後読みなどのlook-aroundや後方参照がサポートされないことです。PCREなどで動く(?=...)を、そのままSearch Consoleへ持ち込まないようにします。

また、正規表現フィルタは「その場で条件に合うクエリを表示する」機能です。毎月同じ分類を再現し、例外や変更履歴まで管理するには、スプレッドシート、Search Console API、BigQueryなどで分類列を持つ方が適しています。

手順5｜データ量に合わせてCSV・API・BigQueryを使い分ける

Search Consoleの画面から直接エクスポートできる表は、代表的なデータの最大1,000行に制限されます。中規模以上のサイトで大量クエリを継続分類する場合、画面エクスポートだけでは不足する可能性があります。

画面出力だけでは大量クエリを扱いきれない場合があります。データ量と更新頻度に応じて、APIやBigQueryへ移行します。

Search Console APIのパフォーマンスデータは、1日・検索タイプ・プロパティあたり最大5万行です。BigQueryへの一括エクスポートでは、匿名化されたクエリを除き、Search Consoleで利用可能なパフォーマンスデータを日次で蓄積できます。

分類辞書をSQLや参照テーブルで管理すれば、同じルールを継続して適用しやすくなります。

手順6｜KPI集計では「合計してからCTRを計算する」

分類後は、クエリ行のCTRを単純平均しないことが重要です。CTRはクエリごとの母数が異なるため、カテゴリ全体ではクリック数と表示回数を合計してから再計算します。

カテゴリCTR = カテゴリ内クリック数の合計 ÷ カテゴリ内表示回数の合計

たとえば、10回表示でCTR50%のクエリと、1,000回表示でCTR2%のクエリを単純平均すると26%になります。しかし実際のクリック数は5回と20回なので、合計CTRは25 ÷ 1,010で約2.5%です。単純平均ではカテゴリの実態を大きく誤認します。

CTRはクエリ行を単純平均せず、カテゴリ内のクリック数と表示回数をそれぞれ合計してから計算します。

月次レポートでは、少なくとも次を同じ条件で比較します。

• 指名：表示回数、クリック、CTR
• 非指名：表示回数、クリック、CTR
• 比較・検討：表示回数、クリック、CTR
• 地域：表示回数、クリック、CTR
• 非指名×比較：表示回数、クリック、CTR
• 非指名×地域：表示回数、クリック、CTR

指名比率は、非指名検索が伸びるだけでも下がります。比率だけでなく指名検索の絶対数も確認します。

Search Consoleのクエリ合計が全体と一致しない前提でKPIを設計する

Search Consoleでは、プライバシー保護のため匿名化されたクエリが表から除外されます。また、内部制限により表示されない行もあります。匿名化クエリは、クエリフィルタをかけていない場合はグラフ合計に含まれるため、クエリ行を合計しても全体クリック数・表示回数と一致しないことがあります。

そのため、「分類済みクエリの合計＝検索全体」とは考えません。社内レポートでは、次のような補助指標を持つと安全です。

可視クエリクリック被覆率 = 分類対象クエリのクリック合計 ÷ 同期間のSearch Console総クリック

これは「全検索を何％分類できたか」を厳密に示す指標ではなく、Search Console上で確認・分類できるクエリが全体クリックのどの程度を占めるかを見る運用指標です。前月との比較では、期間、検索タイプ、国、デバイスなどの条件を揃えます。

手順7｜分類辞書にバージョンを付け、過去値の意味を変えない

分類辞書は運用すると必ず変わります。新サービスが増える、商品名が変わる、地域を拡大する、誤判定が見つかるといった変更が起こるためです。

辞書を更新したら、最低限次を記録します。

• rule_version
• 更新日
• 追加・削除した語
• 変更理由
• 影響する分類
• 過去期間へ再適用するか
• 更新者

辞書変更だけでKPIが動くことがあるため、継続比較では過去月のルールを保持します。最新定義で比較し直す場合は、対象期間をまとめて同じルールで再集計し、検索行動の変化と辞書変更を分けます。

毎月の運用は「抽出→分類→未分類確認→辞書更新→集計」の5工程に固定する

運用担当者が変わっても再現できるよう、毎月の作業順を固定します。

1. 対象プロパティ、期間、検索タイプなどの集計条件を固定してデータを抽出する
2. 当月のrule_versionで自動分類する
3. unknownと例外候補を、表示回数・クリックの大きい順に確認する
4. 必要な語だけ辞書・例外へ追加し、更新理由を記録する
5. 指名・非指名・比較・地域と組み合わせKPIを集計する

人が確認するのは、新しく現れた重要クエリと、分類結果が不自然なクエリを中心にします。

そのまま使えるクエリ分類台帳の列

最小構成は次のとおりです。

特にmatched_ruleとrule_versionを残すと、「なぜこのクエリが指名扱いなのか」「先月と数字が変わったのは検索行動か、辞書変更か」を追跡できます。

よくある失敗｜分類数を増やすより、再現性を優先する

指名・比較・地域を排他的なカテゴリにする

同じクエリが複数の特徴を持つため、1列だけでは情報が失われます。ブランド軸、検討軸、地域軸を分けます。

担当者が毎月目視で分類する

同じ語でも人によって判断が変わり、過去比較が難しくなります。辞書と例外を先に適用し、人はunknownと重要例外だけを確認します。

辞書を更新しても変更履歴を残さない

分類基準が変わるとKPIの意味も変わります。rule_versionと更新理由を必ず残します。

Search ConsoleのAI分類を自社分類と完全に同一視する

Branded / Non-brandedは便利ですが、GoogleのAI支援分類です。自社が管理する指名定義と一致しないことがあるため、差分が大きいクエリを確認し、必要なら自社辞書を修正します。

クエリグループを固定分類として保存する

Search Console Insightsのクエリグループは、似た検索を俯瞰するには有効ですが、グループは変化する可能性があります。月次KPIは自社ルールで固定し、クエリグループはテーマ発見や異常確認の補助に使います。

まとめ

Search Consoleのクエリ分類は、「指名・非指名・比較・地域のどれか1つを選ぶ」作業ではありません。ブランドとの関係、比較・検討の有無、地域条件などを別軸で持ち、同じクエリに複数の属性を残すことで、SEO成果を目的別に評価できます。

実務では、最初にKPIの問いを固定し、分類辞書と例外ルールを作り、rule_versionを付けて運用します。Search ConsoleのBranded / Non-brandedフィルタやクエリグループは確認・補助に使い、継続レポートは自社の固定ルールで集計します。

まずは直近1〜3か月のクエリを抽出し、指名辞書、比較・検討辞書、地域辞書の3つを作ってください。そのうえでunknownの上位だけを人が確認すると、毎月同じ基準で更新できる分類基盤を作れます。

参考文献・データ元

‹ 親記事: SEOの効果測定とは？見るべき指標・使うツール・改善サイクルの全体像