Search Console × BigQuery × Looker StudioでSEO分析基盤を作る手順

Search ConsoleはSEO担当者がまず最初に整える計測基盤です。Google検索における表示回数・クリック数・順位・インデックス状況を、Google自身の数値として確認できる唯一の公式ツールで、無料で使えます。基本的な使い方は Google Search Consoleとは？ にまとめました。

ただし、運用を続けるうちにUIの限界に当たります。検索パフォーマンスのテーブルは最大1,000行までしか表示されず、過去のデータも約16ヶ月までしか遡れません。クエリの一部はプライバシー保護のため匿名化され、UI上では見えなくなります。検索パフォーマンスデータの細かい挙動は、Googleの A deep dive into Search Console performance data filtering and limitsに整理されています。

この壁を越える標準的な構成が、Search ConsoleのBulk Data ExportでBigQueryにデータを流し、Looker Studioで可視化する3点セットです。本記事では、設定手順、エクスポートされるテーブルの中身、基本のSQL、ダッシュボード化までを公式ドキュメントに沿って整理します。

01.なぜSearch Console単体では足りないのか

Search ConsoleのUIとAPIには、いずれも明確な制限があります。日々の確認には十分ですが、SEO戦略や経営報告で踏み込んだ分析をしようとすると、すぐに壁に当たります。

APIの制限は、Googleの Search Console API Usage Limitsと、データ取得方法の Getting your performance dataが一次情報です。Bulk Data Exportの位置づけと意義は、リリース時のアナウンス Bulk data export: a new and powerful way to access your Search Console dataにまとまっています。

02.3ツールの役割分担

Search Console / BigQuery / Looker Studioは、それぞれ「データの発生源」「データの保管庫」「データの表示レイヤー」と役割が分かれます。1つのツールで全部やろうとせず、3点セットで分担するのが、長期運用のしやすい構成です。

Looker StudioにはSearch Consoleコネクタも存在し、BigQueryを経由せず直接つなぐことも可能です。ただしSearch ConsoleコネクタはAPI経由なので、1日あたり50,000行 / サイト / 検索タイプの上限を引き継ぎます。短期のラフなダッシュボードならコネクタ直結でも足りますが、ロングテールクエリの掘り下げや年単位の比較を続けるなら、BigQueryに一度落としてから可視化するのが現実的です。

03.Bulk Data Exportを有効化する手順

設定は2段階に分かれます。Google Cloud側でプロジェクトとIAM権限を整え、その後Search Console側のプロパティ設定でエクスポート先を指定します。Googleの公式手順は 新しい一括データのエクスポートを開始すると BigQueryへのSearch Consoleデータの一括エクスポートについてにまとまっています。

03-1. Google Cloud側の準備

まずGoogle Cloudで、エクスポート先のプロジェクトを用意します。すでにGA4のBigQueryエクスポートなどで使っているプロジェクトを流用しても構いません。

このサービスアカウントは、Google側があらかじめ用意している共通アカウントです。自社で作成したサービスアカウントではない点に注意します。アカウントが追加できると、Search Console側からBigQueryへの書き込み権限が確立します。

03-2. Search Console側で開始

対象プロパティの所有者（owner）アカウントで、Search Consoleの「設定」→「一括データのエクスポート」を開きます。Cloud プロジェクトIDとデータセットの保存ロケーションを指定して保存すると、エクスポートのキューに入ります。

日本のユーザー・読者を主対象とするサイトであれば、ロケーションは asia-northeast1（東京）または asia-northeast2（大阪）が標準的な選択です。Looker Studio や GA4 など他のデータセットと組み合わせて分析する場合は、ロケーションを揃えておくとクエリのコストとレイテンシが安定します。ロケーションは後から変更できないため、最初の設定時に決めておきます。BigQuery で利用可能なロケーションは BigQuery のロケーション一覧を参照してください。

03-3. 開始後の確認

最初のエクスポートは、Googleの公式説明では48時間以内に開始される目安です。設定直後に空でも焦らず、翌日以降にBigQueryの該当プロジェクトを開いて確認します。

• 指定したデータセット（既定名は searchconsole）配下に searchdata_site_impression / searchdata_url_impression / ExportLog の3テーブルが作成される。
• ExportLog テーブルを開き、当日付の行が記録されているかを確認する。ExportLog は成功したエクスポートのみを記録するため、行が存在しない日はエクスポートが失敗している可能性がある。失敗時は Search Console の「設定」→「一括データのエクスポート」のエラー表示か、Google Cloud Monitoring 側でエラー内容を確認し、IAM 設定を見直す。
• 毎日少しずつ蓄積されるため、初期はサンプルサイズが小さい。意味のある分析が始められるのは数週間後からと見ておく。

04.BigQueryに届く3つのテーブル

エクスポートされるテーブル構造と主なカラムは、Googleの テーブルのガイドラインとリファレンスに整理されています。日々のSEO分析で最も使うのは searchdata_url_impression です。

いずれのテーブルにも is_anonymized_query 列があり、プライバシー保護のため一部のクエリは query 列がNULLになります。匿名化された行も件数・クリック・順位の合計には含めて差し支えありませんが、クエリ別に集計するときだけ除外する、という使い分けが基本です。

search_type 列には WEB / IMAGE / VIDEO / NEWS / DISCOVER / GOOGLE_NEWS が入ります。DiscoverとGoogleニュースもBigQuery上では同じテーブル構造で扱えるため、UIで別レポートに分かれていたデータを1本のSQLで横断できるのが利点です。

05.基本の分析SQL

Googleの クエリガイドラインとサンプルクエリにも代表例が並びますが、現場で最初に書くものは限られます。実務で使う3パターンを示します。プロジェクトIDと日付範囲は読み替えてください。

05-1. 月別のクリック・表示推移

最も基本となる、月次のサイト全体パフォーマンス推移です。Looker Studioの折れ線グラフの元データとしても使います。

SELECT
  FORMAT_DATE('%Y-%m', data_date) AS month,
  SUM(impressions) AS impressions,
  SUM(clicks) AS clicks,
  SAFE_DIVIDE(SUM(clicks), SUM(impressions)) AS ctr,
  SAFE_DIVIDE(SUM(sum_top_position), SUM(impressions)) + 1 AS avg_position
FROM `PROJECT_ID.searchconsole.searchdata_site_impression`
WHERE data_date BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 13 MONTH) AND CURRENT_DATE()
  AND search_type = 'WEB'
GROUP BY month
ORDER BY month;

平均掲載順位は sum_top_position / impressions + 1 で再計算します。Search Console内部では順位は0始まりで保持されているため、+1で1始まりに揃えます。

05-2. ロングテール検索クエリの抽出

UIの1,000行制限を超える、ロングテールのクエリ別パフォーマンスです。匿名化クエリは除外し、クリック数の少ない裾野まで拾い切ります。

SELECT
  query,
  SUM(impressions) AS impressions,
  SUM(clicks) AS clicks,
  SAFE_DIVIDE(SUM(clicks), SUM(impressions)) AS ctr,
  SAFE_DIVIDE(SUM(sum_top_position), SUM(impressions)) + 1 AS avg_position
FROM `PROJECT_ID.searchconsole.searchdata_url_impression`
WHERE data_date BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 90 DAY) AND CURRENT_DATE()
  AND search_type = 'WEB'
  AND is_anonymized_query = FALSE
GROUP BY query
HAVING impressions >= 50
ORDER BY impressions DESC;

HAVING impressions >= 50 のような閾値は、ノイズを切るためのものです。サイト規模に応じて調整します。匿名化された行を含めた合計値を別に出し、クエリ別の足し上げと突き合わせることで、匿名化に流れている量も把握できます。

05-3. ページ別のCTR・順位ランキング

ページ別のクリック率と順位の現状を出し、改善優先度の高いページを発見します。CTRが低くて順位が高いページが、リライト候補です。

SELECT
  url,
  SUM(impressions) AS impressions,
  SUM(clicks) AS clicks,
  SAFE_DIVIDE(SUM(clicks), SUM(impressions)) AS ctr,
  SAFE_DIVIDE(SUM(sum_top_position), SUM(impressions)) + 1 AS avg_position
FROM `PROJECT_ID.searchconsole.searchdata_url_impression`
WHERE data_date BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 28 DAY) AND CURRENT_DATE()
  AND search_type = 'WEB'
GROUP BY url
HAVING impressions >= 100
ORDER BY clicks DESC
LIMIT 200;

CTRの目安はクエリ意図によって大きく異なります。順位別の標準的なCTRと、AI Overviewによる変化は CTRとは？SEOにおけるクリック率の意味・目安・改善方法 を参照してください。

06.Looker Studioに接続して可視化する

BigQueryに溜まったデータを、Looker Studioで定点ダッシュボードに仕立てます。接続コネクタは BigQueryへの接続で説明されています。

1. Looker Studioで新しいデータソースを作成し、コネクタから「BigQuery」を選ぶ。
2. プロジェクトIDとデータセット searchconsole、テーブルを選択する。日次粒度を保つ場合は searchdata_url_impression をそのまま、集計後を表示する場合は中間ビューを別途作っておく。
3. レポート側で日付フィルタ・国・デバイス・検索タイプのコントロールを追加し、社内・取引先のレビュー向けに必要な切り口を最初に揃える。

Search Consoleコネクタとの違いを意識して使い分けると、設計が楽になります。

集計済みの中間テーブル（月次サマリ、ページ別サマリなど）をBigQueryで作り、Looker Studioからはそちらを参照する設計にすると、表示速度とクエリ課金の両方を抑えられます。

07.AI検索時代に追加で見るべき切り口

AI（ChatGPT、Claude、Geminiなど）の生成AIが検索体験に組み込まれ、Google検索でもAI Overviewが定着しました。Search Console自体はAI Overviewから個別に分離した数値を出さないため、間接的な指標で動きを掴む必要があります。BigQueryに落としておくと、これらの切り口を後付けで実装しやすくなります。

• クエリの種類別CTR推移（定義系・How-to系・比較系・指名検索の4グループに分けて、AI Overview導入の前後で並べる）。
• 指名検索の表示回数とクリック数の月次推移。AI回答に引用されるとサイト名・ブランド名での指名検索が伸びる傾向があり、ブランド浸透の代理指標になる。
• Discoverの search_type = 'DISCOVER' 行を別ビューにし、検索流入とは別軸で評価する。
• GA4のリファラーで、AI検索ドメインからの流入を別チャネル扱いにする（Search Console側ではAI検索流入は直接見えない）。

なお、Googleはこの状況を変えるSearch Consoleの生成AIパフォーマンスレポートの提供を一部サイト向けに始めました。AI Overviews・AIモードなどでの表示回数を専用レポートで確認できますが、現状は一部サイト限定で、クリックやクエリは含まれません。広く提供されるまでは、上記の間接指標とBigQueryでの蓄積が引き続き有効です。

AI Overviewの仕組みとSEOへの影響は別記事で扱っています。BigQueryに蓄積した時系列データと突き合わせて、自社サイトでの影響を測る出発点にしてください。

08.運用上の注意とコスト管理

BigQueryはストレージとクエリで従量課金が発生します。最新の料金は BigQuery料金に記載されています。Search Consoleのデータ量は他のログデータに比べれば小さく、中小規模のサイトであれば無料枠の範囲に収まることも多いですが、Looker Studioから繰り返し叩いていると気づかないうちにクエリ量が膨らみます。基本の運用ルールを最初に決めておくのが安全です。

BigQueryのエディタはクエリ実行前にスキャン量を表示します。クエリの設計時にこの数値を確認し、不要に大きいクエリは設計を見直すのが習慣として有効です。コスト最適化の考え方は コストの見積もりと管理（BigQuery公式）にもまとまっています。

09.よくある質問（FAQ）

10.まとめ

Search Consoleの計測は無料で始められますが、UI・APIの制限の中だけで運用すると、ロングテール検索クエリや年単位のトレンドが見えません。Bulk Data ExportでBigQueryに蓄積し、Looker Studioで共有可能なダッシュボードを作る3点セットは、Google公式の仕組みを組み合わせるだけで構築できる、現実的な分析基盤です。設定そのものは1〜2時間で終わり、データが溜まるほど分析の自由度が増えます。AI検索時代の指標設計を見据えるなら、できるだけ早い段階で導入しておくのがおすすめです。