Search Console の API はクリックの1割しか拾わなかった。BigQuery の一括エクスポートと比べた

趣味の個人ブログを運営しています。記事は80本ほど、PV は月に1万弱の小さなブログです。

Search Console（Google が無料で出している、検索結果での表示回数・クリック数・順位の管理画面）の数字を、API（プログラムからデータを取り出す窓口）で自動で取り込んで、記事の改善に使っていました。

ところが、ある日、画面の数字と突き合わせてみたら、API のクリック数は画面の1割ほどしかありませんでした。

この記事では、次の3つを書きます。

• 何を取ると、なぜ落ちるのか

• BigQuery の一括エクスポートに切り替えて、画面とどこまで合ったか

• 切り替えたあとにもう一度つまずいた、# 付き URL の行のこと

先に結論

• API で「記事 × 検索語 × 日」の細かさで取ると、クリックは画面の7〜12%、表示回数は35〜37%しか拾えませんでした（8月の2日分で突き合わせ）

• 3か月分を記事ごとに見ると、拾える割合は記事によって 1.8% から 34.9% までばらばらでした。API の数字では記事どうしを比べられません

• BigQuery の一括エクスポートに替えると、記事ごとの合計は画面とほぼ一致しました。ただし URL に # が付いた行を除かないと、表示回数が3倍に膨らみます

• 検索語ごとの集計は、BigQuery でも表示・クリックとも5割弱までです

• いまは、合計・CTR・判定には BigQuery の記事ごとの数字、「どんな検索語が来ているか」には API、と使い分けています

何が起きたか: API と画面の突き合わせ

2026年8月に、API から取り込んで手元に溜めていたデータと、Search Console の画面から書き出した数字を、日ごとに並べてみました。

• 8月9日: 画面は 2,374回表示・170クリック。API は 835回表示・21クリック（表示35%、クリック12%）

• 8月14日: 画面は 2,041回表示・117クリック。API は 745回表示・8クリック（表示37%、クリック7%）

表示回数が3分の1というだけでも困りますが、クリックが1割前後というのは、週ごとの増減を見るのにも使えない水準です。

それまで私は「表示回数の絶対値はずれるけれど、相対比較には使える」と思っていました。この突き合わせで、その考えを取り消しました。

なぜ落ちるのか: 匿名化された検索語

原因は、取り方の細かさだと考えています。

私が API で取っていたのは、記事（ページ）ごと・検索語ごと・日ごとの行です。

// Search Analytics API に渡している指定（抜粋）
dimensions: ['page', 'query', 'date'],
rowLimit: 25000,     // 1回で返してもらう行数（API の上限）
maxRows: 200000,     // 上限に当たるまで続きを取りに行く
dataState: 'final',  // 確定した日のデータだけ

行数の上限にひっかかって切れているわけではありません。続きを取りに行く処理も入れています。それでも落ちるのは、検索する人がごく少ない検索語は、Google が個人が特定されないよう匿名化して、一覧から外してしまうためです（匿名化クエリと呼ばれます）。ブログのように1つの検索語あたりのクリックが少ないサイトでは、細かく分けるほど、この外される行が増えます。

画面の合計には外された分も入っているので、API の合計との差がそのまま「落ちた分」になります。

記事ごとに見ると、捕捉率が20倍近くばらつく

次に、2026年5月19日〜8月18日の3か月分を、同じ期間で記事ごとに突き合わせました。

• 全体: 画面 110,243回表示に対して API は 23,104回（21.0%）

• 拾える割合がいちばん高い記事: 34.9%（画面 19,731回に対し API 6,885回）

• いちばん低い記事: 1.8%（画面 1,765回に対し API 31回）

「8月の2日分で表示35%」という平均だけを見て、補正すればよいと考えていたのですが、平均は記事ごとの比較に使えません。

これで壊れた判断がありました。API では54回しか表示されていなかったので「この記事は孤立していて、ほとんど検索されていない。このまま置く」と決めていたのですが、画面では833回表示されていました。別の記事も、API では31回で「弱い」と判断していたものが、画面では1,765回表示・144クリックの、ふつうに健全な記事でした。

API の数字を「どの記事が強いか」の判断に使うのは、やめました。

BigQuery の一括エクスポートに切り替える

Search Console には、検索データを BigQuery（Google のクラウド上にあるデータベース。SQL で集計できる）に毎日自動で書き込む「一括データエクスポート」という設定があります。API が返す要約ではなく、日ごとの全量が入る仕組みです。行数の制限もありません。

設定と運用の流れは、概要だとこうです。

• Search Console 側で、一括データエクスポートを有効にする。保存先は BigQuery のデータセット。私は置き場所を米国（US）にしました

• 設定した日以降のデータしか入りません。過去には遡りません。 設定した翌日以降に最初のバッチが動くので、最初の数日はテーブル自体がなく「データがありません」と出ます。それで正常です

• 自動で取り込むためのアカウント（サービスアカウント）に、BigQuery の権限を2つ付けます。クエリを実行する権限（ジョブユーザー）と、データを読む権限（データ閲覧者）です

• あとは SQL で集計して、手元のデータベースに毎日取り込みます

過去に遡れないのが、いちばんの注意点です。やるなら早いほうがよい、と思いました。

課金については、この記事では扱いません。自分のプロジェクトの料金と無料枠を、公式の説明で確認してください。

切り替えたあとの落とし穴: # 付き URL の行

切り替えて、画面と合うかを確認しました。最初は合いませんでした。

表示回数が3倍になっていた

BigQuery の URL 別テーブルは、1行が1つの URL です。検索結果には、記事の見出しに飛ぶジャンプリンク（/#toc3 のような、URL の末尾に # と見出しの名前が付いたもの）が表示されることがあります。このジャンプリンクが、記事本体とは別の行として積まれます。

取り込みのとき、これを除いていませんでした。8月25日〜9月2日の9日間で数えると、こうでした。

• # 付きの行: 1,104行・表示 48,626回・クリックは5

• 記事本体の URL だけ: 435行・表示 25,190回・クリック 1,553

# 付きの行が表示回数の66%を占めているのに、9日間でクリックは5しか生んでいません。 除外せずに CTR（クリック率。クリック数 ÷ 表示回数）を出すと、分母が3倍近くになって、CTR は3分の1ほどに潰れます。検索語ごとの集計でも、同じ行を合算するので、表示回数が1.6倍になっていました。

取り込みの SQL に、1行足して直しました。

SELECT data_date AS date, url AS key,
       SUM(clicks) AS clicks, SUM(impressions) AS impressions
  FROM （URL 別のテーブル）
 WHERE data_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
   AND STRPOS(url, '#') = 0     -- ここ。`#` を含む URL を除く
 GROUP BY date, key

すでに取り込んでいた # 付きの行は削除して、取り直しました。この集計を読むレポートは、まだ作っていなかったので、過去の報告に誤りは広がっていませんでした。

除外したら、画面とほぼ一致した

# を除いた BigQuery の記事ごとの数字と、画面の数字を比べると、こうなりました。

• 1日あたりの表示回数: BigQuery 2,750回・画面 2,521回（画面は8月31日時点の直近7日の窓）

• 1日あたりのクリック: BigQuery 170・画面 167

API が1割だったクリックが、ほぼ全量になりました。画面の窓が7日、BigQuery が9日分の平均と、期間が少し違うので、数字がぴったり同じにはなりません。それでも、合計の水準は同じと言ってよいところまで来ました。

検索語別は、BigQuery でも5割弱

一方、検索語ごとに集計すると、同じ BigQuery でも全量にはなりません。

• 表示: 1日あたり 1,200回（記事ごとの合計に対して 44%）

• クリック: 1日あたり 80（47%）

一括エクスポートでも、匿名化された検索語は検索語ごとの集計には入ってきません（私はこの理由を、API と同じ匿名化が効いているためと見ています）。ですので、検索語ごとの数字は「合計」としては使えず、「どんな語が来ているか」の目安として使うことにしました。

どの数字を何に使うか

いまの使い分けは、これです。

• 記事ごと・サイト全体の表示・クリック・CTR: BigQuery の記事ごとの数字（# 付きを除く）。これが正です

• タイトル変更などの効果の判定: 同じく BigQuery の記事ごとの数字

• どんな検索語が来ているか、その順位: API から取った行を使う。ただし表示回数・クリックの絶対値は見ない

• 検索語ごとの合計や CTR: 目安にとどめる。BigQuery でも5割弱しか入っていない

• 順位は、表示回数で重みを付けた平均にする。単純平均だと、2位ほどずれることがありました

• 「この記事は Search Console に出ていない」と言い切らない。API に載っていないだけのことがあります

数字の正を決めてから、記事の強弱の見え方も、リライトの判定も、変わりました。

おわりに

Search Console の数字は、どの細かさで取るかによって、拾える量が大きく変わります。 画面と一度、日ごとに突き合わせてみることをおすすめします。ずれが見つかったら、そのずれを前提にして判断を組み直すほうが、あとで効きます。

私のブログでは、この BigQuery の数字を使って、検索結果のタイトルを書き換えた実験の効果を判定しています。その判定のしかた（差の差分法）は、1本目の記事に書きました。実験台帳の話は、次の記事で続けます。