本文へ移動
リライトレーダーRewrite Radar
メニュー

公開

サーチコンソールの合計が合わない、クエリ一覧に出ない検索語の正体

Search Consoleの検索パフォーマンスで、クエリ一覧を全部足しても画面上部の合計クリック数に届かないのは正常です。Googleが「2〜3か月に数十人を超えるユーザーが使っていない検索語」をプライバシー保護のため表から除いているためで、そのクリックはグラフの合計には残ります。報告に使うべき数字まで書きました。

この記事のまとめ

Search Console の検索パフォーマンスで、クエリ一覧を全部足した数が、画面上部の合計クリック数に届かないのは正常です。Googleはごく少数の人しか使っていない検索語を、プライバシー保護のためにクエリの表から除いているためです(公式には「2〜3か月の間に数十人を超えるユーザーからは実行されていないクエリ」と定義されています)。除かれた語のクリックはグラフの合計には含まれたままなので、内訳だけが足りません(Google公式ドキュメントの説明用の例では、内訳の合計450クリックに対し、全体は550クリックです)。やってはいけないのは、クエリ一覧の合計をサイト全体の実績として報告することで、報告に使うのはグラフ側の合計です。リライトの判定に使う「ページ」の数字は、この除外の対象として公式に名指しされていません。

検索パフォーマンスのクエリをCSVに落として、表計算ソフトでクリック数を合計したとします。その数字は、画面上部に出ている合計クリック数より少なくなります。

エクスポートの手順を間違えたわけでも、絞り込みが残っているわけでもありません。Googleが意図的に、一部の検索語をクエリの表から除いています。そして除いた語のクリックは、上部の合計には入ったままです。

つまり「消えた」のではなく「内訳が言えない」状態です。なぜそうなるのかと、どちらの数字を報告すべきかを書きます。

なお、リライトの優先順位を決めるときに使うのは「ページ」の数字です。こちらはページのCSVをそのまま判定にかけることもできますが、先に合計が合わない理由のほうを書きます。

次に直す記事を自分のデータで調べる

Search ConsoleのZIPを読み込むと、候補の判定と1記事分の診断カードを無料で確認できます。登録は不要です。ZIPが無い場合は、診断カードの見本を確認できます。

症状: 内訳を足しても、合計に届かない

起きていることを、Google公式ドキュメントに載っている例で確認します。あるサイトのクエリ一覧が、次のようになっているとします。

クエリクリック数
classic literature150
poetry125
science fiction100
non fiction75
表の合計450
グラフの合計550

※ Google検索セントラルのブログに載っている説明用の例の数字です(私や特定のサイトの実績ではありません)。

表を足すと450、グラフの合計は550。100クリックぶんの行がどこにもありません。公式は、この差は「一覧に出ていないクエリからのクリック」だと説明しています。

もう1つ、同じ原因で起きる現象があります。クエリで絞り込んで「◯◯を含む」と「◯◯を含まない」を足しても、絞り込まないときの合計に届きません。上の例なら、fiction を含む175と含まない275を足しても450にしかならず、550にはなりません。

なぜ足りないのか: Googleが少数の検索語を表から抜いている

サーチコンソールでは匿名化された少数の検索語が行ごと表から除外され、内訳の合計が上部の合計に届かない仕組みの図解

ここがこの記事の中心です。現象ではなく、仕組みの話をします。

Googleは匿名化されたクエリ(anonymized queries)という考え方を持っています。公式の定義はこうです。

匿名化されたクエリとは、2〜3か月の期間に、数十人を超えるユーザーからは実行されていないクエリのことです。プライバシー保護のため、実際のクエリは検索パフォーマンスのデータに表示されません。(Google検索セントラル ブログ / 筆者訳)

「検索した人が少なすぎる語は、語そのものを見せない」という仕組みです。理由は単純で、めったに検索されない語をサイト運営者に見せると、その語と、それを検索した個人が結びついてしまうおそれがあるからです。

重要なのは、これが「計測していない」ではなく「表示していない」という点です。公式ヘルプは、匿名化された結果は「表から除外されますが、クエリフィルタが適用されていない限り、グラフの合計数に含まれます」と書いています。数はある。ラベルが無いだけです。

「行ごと消える」ことの証拠

画面のクエリタブには、匿名化されたぶんをまとめた「その他」のような行がありません。だから合計を出す側からは、差がどこから来たのか見えません。

一方、Search Console の一括データエクスポート(BigQueryへの書き出し)にはis_anonymized_query という真偽値の列があります。公式リファレンスによれば、この値が true のときクエリの列は null(長さがゼロの文字列)になります。

行は存在し、クリック数も表示回数も入っていて、検索語だけが空という形です。これが「消えたのではなく伏せられている」ことの、いちばんはっきりした裏づけになります。

ロングテールが多いサイトほど、差は大きくなる

しきい値が「数十人」である以上、1語あたりの検索人数が少ない語が多いサイトほど、多くの行が匿名化に落ちます。ニッチな専門ブログや、質問形の長い検索語で読まれている記事は、この影響を受けやすい構造です。

逆に、少数の太いキーワードにトラフィックが集中しているサイトでは差は小さく出ます。差の大きさはサイトの健全さとは関係がなく、検索語の散らばり方を映しているだけです。差が大きいことを問題として報告する必要はありません。

合計が合わない理由は、もう2つある

匿名化がいちばん大きい理由ですが、単独ではありません。公式ヘルプは、グラフと表がずれる理由を3つ挙げています。

理由何が起きるかずれる向き
匿名化されたクエリごく少数の人しか使っていない語が、クエリの表から除かれる表のほうが少ない
データの切り捨て表は1,000行まで。内部的な制限により、重要な行だけが保存・表示される表のほうが少ない
集計単位の違いグラフは常にプロパティごと、ページの表はページごとに集計される表のほうが多くなることがある

3つ目は向きが逆になるので、少し補足します。公式ヘルプによれば、グラフの数字は常にプロパティごとの集計で、1つのクエリに対して同じサイトから2件の検索結果が表示された場合、グラフでは1回の表示回数として数えられます。

ところが表のほうは、選んだディメンションで集計の単位が変わります。クエリ・国・デバイス・日付はプロパティごと、ページと検索での見え方はページごとです。同じ検索で自サイトの2ページが出たなら、ページの表では2行に1回ずつ計上されます。

つまりページの表は、匿名化で減る方向と、ページごと集計で増える方向の両方が同時に効くということになります。合わせて合計と一致させようとしても、原理的に噛み合いません。

1,000行の上限そのものについてはSearch ConsoleのCSVエクスポート手順と「ページ」CSVはどの期間で落とすかに書いてあります。ページのCSVが手元にあるなら、ZIPのまま入れて判定を確かめるほうが早いです。合計を合わせる作業は、そもそも必要ありません。

直す記事と作業内容を決める

Search ConsoleのZIPを読み込むと、候補の判定と1記事分の診断カードを無料で確認できます。登録は不要です。ZIPが無い場合は、診断カードの見本を確認できます。

ページ・国・デバイスでも同じことが起きるのか

ここは確認できた範囲だけを書きます。推測で埋めると、読者が合わない数字を追いかけて時間を溶かすからです。

  • クエリ … 匿名化の対象として公式に名指しされているのは、ここだけです。ヘルプの文言も「表のクエリタブでは」と限定されています
  • ページ … 匿名化の名指しはありません。効くのは1,000行の上限と、上に書いたページごとの集計です。また、重複URLがクリックされたときは正規URLのほうにカウントされます
  • 国・デバイス・検索での見え方 … Google検索セントラルは、クエリやURLのディメンションを含まないリクエスト(国、デバイス、検索での見え方など)では、すべてのデータが表示・エクスポートされると書いています。行数で切られる心配はここにはありません

一方で、匿名化されたクエリぶんのクリックが、国やデバイスの各行の中に含まれているのかどうかは、公式ドキュメントで明示を確認できませんでした。含まれるとも含まれないとも書かれていないので、この記事では断定しません。国別・デバイス別の内訳合計を、上部の合計に一致させようとしないでください。

リライトの判定に、この欠落はどう効くか

結論から書くと、影響は間接的です。

リライトの優先順位を決めるときに読むのは「ページ」の行(URLごとのクリック数・表示回数・CTR・掲載順位)です。匿名化はクエリの表で起きるので、ページ側の数字を直接削るものではありません。

私のツールも、判定に使うのは掲載順位4.0〜20.5位・表示回数100回以上のページの行だけです。クエリ側の欠落で判定結果が変わることはありません。

効いてくるのは、その次の工程です。「このページはどの検索語で表示されているのか」を調べるときには、見えていない語がある前提で読む必要があります。

  • 「この記事はこの3語でしか拾えていない」と結論しない。表示されている語は、そのページを支えている語の一部です
  • クエリ一覧に出ていない語を「取れていない語」と扱わない。数十人未満で取れている語は、取れていても表に出ません
  • ページのCTRと、そのページのクエリ一覧から計算したCTRを比べない。分母も分子も別の集計なので、一致しないのが普通です

そして、やってはいけない使い方が1つあります。クエリ一覧の合計を、サイト全体の実績として報告することです。公式の例で言えば、550のところを450と報告することになります。報告に使うのは、絞り込みをかけていないグラフ側の合計です。

クエリとページをそもそもどう使い分けるかはサーチコンソールのクエリとページの違いに、4つの数字を見る順番はサーチコンソールの見方に分けて書いてあります。

よくある質問

結局、レポートにはどちらの数字を書けばいいですか

絞り込みをかけていない状態の、グラフ側の合計です。こちらには匿名化されたクエリのクリックも含まれているため、実績としてはこちらが正しい数字になります。クエリ一覧を足した数は「内訳として説明できるぶん」であって、サイト全体の実績ではありません。クエリ一覧を資料に載せるなら、「上位クエリの内訳(合計とは一致しません)」のように但し書きを付けるのが安全です。

匿名化されたクエリを、あとから見る方法はありますか

検索語そのものを見る方法は、確認できていません。画面の表に出ないのは行数の切り捨てと匿名化の2つが原因で、このうち切り捨てのほうは、公式が「クエリの最も完全なリストは、一括データエクスポートを使用してエクスポートできる」と案内しています。ただし一括データエクスポートの側にも is_anonymized_query という列があり、true の行ではクエリの値が null になります。つまり行は増えても、匿名化された語の中身は伏せられたままです。

期間を長くすれば、合計は合うようになりますか

合うようにはなりません。匿名化のしきい値は公式には「2〜3か月の期間に数十人を超えるユーザー」という形で説明されています。判定の窓は「2〜3か月」で固定なので、レポートの表示期間を延ばしても匿名化の判定条件そのものは変わりません。むしろ期間を延ばすとロングテールの語の種類が増えるぶん、表に出ない語は増えます。差をゼロにする操作は無いと考えてください。なお期間を延ばすと掲載順位は期間全体の平均になるという別の副作用もあります。

絞り込みを外したのに数字が変わりません。故障ですか

差が残るのは正常です。絞り込みを外しても、匿名化されたクエリの行が表に現れることはありません。表に1,000行の上限があることも変わりません。表の合計とグラフの合計は、別々の作り方をした数字だと考えるのが正確です。

まとめ

  • クエリ一覧を足した数が合計に届かないのは正常。 Googleがごく少数の人しか使っていない検索語を、プライバシー保護のため表から除いている
  • 公式の定義は「2〜3か月の間に数十人を超えるユーザーからは実行されていないクエリ」。除かれた語のクリックはグラフの合計には含まれたままで、内訳だけが無い
  • ずれる理由は他に1,000行の切り捨てと集計単位の違い。ページの表はページごと集計なので、逆に多く出ることもある
  • 匿名化として公式に名指しされているのはクエリの表だけ。国・デバイス・検索での見え方はすべてのデータが表示・エクスポートされると明記がある。ただし匿名化ぶんが国やデバイスの行に含まれるかは確認できなかった
  • リライトの判定に使うのはページの行なので、クエリ側の欠落は直接は影響しない。ただし「このページはどの語で出ているか」を調べるときは、見えていない語がある前提で読む
  • クエリ一覧の合計をサイト全体の実績として報告しない。報告に使うのは絞り込みなしのグラフ側の合計

ここから先は、私が作ったツールの話です。

合計を突き合わせる作業をやめて、ページ単位の判定だけを機械にやらせるツールを作りました。 Search Console のエクスポートをZIPのまま落とすだけで、掲載順位4.0〜20.5位・表示回数100回以上のページだけを拾い、改善余地スコア(表示回数 × 期待CTRとの差)の大きい順に並べます。読むのはページの行だけなので、この記事で書いたクエリ側の欠落は判定に影響しません。判定と候補3記事の改善余地スコアの確認、そのうち1記事分の診断カードまでは無料で、残りの診断カードが2,980円(税込)の買い切りです。月額課金や自動更新はありません。ログインも不要です。CSVファイルそのものはブラウザの外に出ません(診断カードを出すときに選んだ1ページのURL・数値・入力したキーワードを、「ページタイトルを取得する」を押したときに判定に出たページのURLを最大10件送ります)。

⚠️ ただし、向かない人がいます。知りたいのが「どの検索語で表示されているか」である場合、このツールは答えません。ページの数字しか読まないからです。クエリ単位で見たい人は Search Console の画面をそのまま使うほうが確実です。表示回数が2桁で止まっているサイトでも、判定できるページが出ません。合計が合わない原因の切り分けそのものを自動でやる機能もありません。

Search ConsoleのZIPで無料判定する

Search ConsoleのZIPを読み込むと、候補の判定と1記事分の診断カードを無料で確認できます。登録は不要です。ZIPが無い場合は、診断カードの見本を確認できます。

この記事の内容をツールにしています

Search Console の「ページ」CSVを貼ると、改善余地のある記事を順番に出します。 判定とご自分の記事1件分の診断カードは無料です。ログイン不要。CSVファイルはアップロードせず、ブラウザ内で解析します。

リライトレーダーで無料診断する

関連する記事

この記事を書いた人

みやこし

ブログのリライトで「どの記事を直すか」を数字で決めるSEOライター向けツールを作っています。 掲載順位ごとの平均クリック率、AI Overviewによるクリック減の補正、タイトルの直し方など。

noteQiitaZenn

ブログの一覧に戻る