Search Consoleの数字を5倍間違えた｜検索流入の測り方で踏んだ罠

目次

• この記事の立ち位置
• 同じ期間で6,251と31,899が出た
• なぜクエリ単位は少なくなるのか
• どちらを使うべきか
• アンカー付きURLは別の行で返る
• この誤りで何を間違えたか
• 最大の流入元が測定対象から抜けていた
• Bing側のAPIで踏んだ罠
• 0を「需要なし」と読む前に
• 分布を見ないと判断を誤る
• 表示と選択を分けて見る
• 順位の平均は扱いに注意が要る
• 日次で記録する仕組み
• 生成AIの回答に引用されているかは別の経路である
• サイトマップと登録状況も数えておく
• 測る前に決めておくこと
• ツールの守備範囲を先に書き出す
• 社内に数字を出すときの書き方
• まとめ

この記事の立ち位置

検索からの流入を測る話は多い。しかし測り方を間違えた記録はあまり出てこない。

編集部は先日、自社サイトの検索実績を集計し、その数字を社内で共有した。そのあと、同じ期間・同じサイトの数字が5倍違うことに気づいた。

どちらもSearch Consoleから取得した正しい数字である。見ている次元が違っただけだった。

この記事は、その誤りと、それが判断に与えた影響の記録である。加えて、最大の流入元が測定対象から丸ごと抜けていた件も併せて書く。

同じ期間で6,251と31,899が出た

直近90日について、同じサイトの表示回数を2通りの方法で取得した。

表示回数で5.1倍、クリック数で6.0倍の差がある。

最初に取得したのはクエリ単位のほうだった。そのまま「サイト全体の90日の表示は6,251」として共有した。これは実態の5分の1である。

なぜクエリ単位は少なくなるのか

Search Consoleは、検索数が非常に少ない検索語をデータに含めない。 個人を特定できる可能性があるためである。この仕様は検索パフォーマンスレポートの説明に記載がある。

影響の大きさはサイトによって違う

重要なのは、この欠落の割合がサイトの性質で変わることである。

多くの記事を持ち、それぞれが少数の検索語から少しずつ流入を得ているサイトでは、欠落の割合が大きくなる。編集部のサイトは726記事あり、まさにこの形である。

逆に、少数のページに検索が集中しているサイトでは、欠落は小さい。「一般にはこれくらい」という数字は当てにならない。自社で両方を取得して比べる必要がある。

クエリ単位の数字が無意味なわけではない

誤解しないでほしいのは、クエリ単位のデータは、それはそれで正しいということである。

「どの検索語で表示されているか」を知るには、これしかない。用途が違う。 全体の規模を知りたいときに使ってはいけない、というだけである。

どちらを使うべきか

用途で使い分ける。

合計を出すときの原則

次元を増やすほど、返ってくる合計は小さくなる。 検索語とページの両方を指定すると、さらに減る。

規模を報告するときは、どの次元で取得したかを数字と一緒に書く。 これを書いていなかったために、編集部では誤った数字が共有された。

アンカー付きURLは別の行で返る

ページ単位で取得する際にもう1つ罠がある。

記事内の見出しへのリンクが、別の行として返ってくる。 検索結果に、記事の特定の節への直接リンクが表示された場合である。

編集部のデータでは、1本の記事について、本体のURLと5つの見出しへのリンクが、合計6行に分かれていた。畳まずに数えると、同じページを6回数えることになる。

対処

集計の前に、URLからアンカー部分（#以降）を落として合算する。これを入れると、返ってきた1,157行が1,157件のユニークなURLではないことが分かる。

この現象自体は有用な情報でもある

見出しへのリンクが表示されているということは、その記事の特定の節が検索語に対応していると判断されていることを意味する。

ただし編集部のデータでは、見出しへのリンクは表示されるがクリックされない傾向があった。936表示でクリック0という行が複数ある。平均順位は5.9で、下位ではない。

この誤りで何を間違えたか

5倍の誤りは、判断を変えた。

間違いその1：記事群の評価

編集部は、特定の題材について95本の記事をまとめて公開している。その効果を評価する際、クエリ単位のデータで「表示765、クリック0」と読んだ。

ページ単位で取り直すと、その題材を含むURL全体で表示1,760、クリック20だった。まとめて公開した95本に絞っても、54本（57%）に表示があり、表示131・クリック5である。

「クリック0」と「クリック20」では、評価が変わる。「効いていない」と「まだ小さいが動いている」の差である。

726記事の全件を測った結果はAIライティングで726記事を運用した結果にまとめている。

間違いその2：全体規模の認識

「90日で140クリック」と「90日で839クリック」でも、投資判断は変わる。前者なら撤退の議論になるが、後者は継続の議論になる。

学び

数字を共有する前に、別の取り方で取り直す。 1つの取得方法だけで報告すると、その方法の癖がそのまま結論になる。

編集部の場合、ページ単位でも取ってみるという手順を踏んでいれば、5倍の差にその場で気づけた。

最大の流入元が測定対象から抜けていた

より根本的な問題がある。

Search Consoleに映るのはGoogleだけである。

実際の流入比

アクセス解析で流入元を確認したところ、編集部のサイトでは次のようになっていた。

最大の流入元はBingだった。 Googleは3番目である。

それまで何をしていたか

編集部は、Search Consoleの数字を日次で記録し、順位の変動を監視し、それに基づいて施策を決めていた。

つまり、全体の15%の経路だけを見て最適化していた。

なぜ気づかなかったか

Search Consoleは高機能で、無料で、情報が豊富である。使い勝手が良いツールがあると、それが見ている範囲を全体だと思ってしまう。

流入元の内訳は、アクセス解析を見れば分かる。見ていなかったわけではなく、Search Consoleの作業とアクセス解析の作業が別々になっていて、突き合わせていなかった。

対策

Bing Webmaster Toolsに8サイトを登録し、APIから日次で実績を記録する仕組みを作った。

これで、Googleと同じ粒度でBingを測れるようになった。

直接アクセスが33.6%という値も疑っている

併せて記録しておくと、直接アクセスの割合が33.6%というのは高い。さらに、この経路の利用者の関与率が16%で、他の経路（63〜67%）と大きく違う。

自動化されたアクセスが混じっている可能性がある。 数字が他と極端に違うときは、まず同じものを測っているかを疑う。

Bing側のAPIで踏んだ罠

Bing Webmaster ToolsのAPIには、独自の落とし穴がある。いずれも、エラーではなく0を返す形で現れる。

期間を渡さないと0になる

検索数を推定する機能は、開始日と終了日の指定が必須である。渡さないとエラーにならず、0が返る。

国名の大文字小文字で0になる

国を指定する引数は小文字でなければならない。大文字で渡すと0が返る。言語の指定も形式が決まっている。

完全一致である

検索語は完全一致で評価される。編集部が測った例では、スペースの有無で結果が変わった。 同じ意味の語でも、スペースを入れた形では0になる。

広い一致と完全一致は別の値

APIは、完全一致の推定表示回数と、その語を含む検索全体の推定表示回数の2つを返す。題材を選ぶときは後者、記事のタイトルに入れる語を選ぶときは前者を見る。

編集部の例では、ある語の完全一致が0なのに、その語を含む検索は78,150あった。完全一致だけを見て「需要がない」と判断すると誤る。

所有権の確認後48時間はデータが出ない

サイトを登録して所有権を確認しても、すぐには実績が出ない。 最大48時間かかる。

この間に取得すると、すべて0が返る。0を見て「流入がない」と読むと誤る。

0を「需要なし」と読む前に

ここまでの罠に共通するのは、測定の失敗が0として現れることである。

実際に踏んだ

編集部は82語の検索需要をまとめて測るスクリプトを書いた。最初の実行で、82語すべてが0を返した。

原因は、APIの応答の解釈を誤っていたことである。応答の構造を1段深く読もうとしていたため、値が取れていなかった。

対策：対照を必ず一緒に測る

この経験から、既知で需要の大きい語を対照として必ず一緒に測る仕組みにした。

対照の語が0を返したら、測定そのものが失敗したと判断して処理を止める。 他の語の結果は表示しない。

この仕組みを入れた後、実際に一度助かっている。対照も0だったので、誤った結論を出さずに済んだ。

一般化すると

0は、無いことと、届いていないことの両方を意味する。 この2つを区別する仕掛けを、測定の側に持たせる。

対照を置く、件数の下限を決めておく、前回との差を見る。どれでもよいが、「0が出たときに測定を疑う」経路を作っておく。

分布を見ないと判断を誤る

正しい数字が取れた後にも罠がある。平均で語ると実態を外す。

編集部の実測

726記事について、表示回数の多い順に並べて累積を取った。

さらに、209本（29%）は表示が1回もなく、クリックが1回以上あったのは86本（11.8%）だった。

平均は「1記事あたり26回」

18,982表示を726記事で割ると26.1である。この数字から「100記事増やせば2,600回増える」と考えると外れる。

追加される記事の大半は、中央値に近い側に入る。 実際、表示が1〜2回だった記事は234本、3〜9回が176本で、合計410本（56%）が1桁台である。

報告するときは分母と分布を添える

「表示18,982」だけを報告すると、健全に見える。「うち39.2%は1本」を添えると、意味が変わる。

編集部は、件数を報告する際に分母と基準率を必ず書くようにした。これは本記事の5倍の誤りと同じ根の問題である。

表示と選択を分けて見る

流入が増えない原因は2つに分かれる。表示されていないのか、表示されているのに選ばれていないのか。

対策が違うので、分けて見る。

編集部のデータ

記事全体で18,982表示に対して338クリック、クリック率1.8%である。

内訳を見ると割れている。表示1位の記事は3,234表示で64クリック（2.0%）。3位の記事は1,210表示で86クリック（7.1%）。表示は3分の1なのに、クリックは3割多い。

判断の目安

順位が20位より下なら、まず表示されるようにする。 内容と構造の問題である。

順位が10位以内でクリック率が2%を下回るなら、文面の問題である。 記事を書き直すより、タイトルと説明文を直すほうが速く効く。

編集部でも、順位は中央値で9位なのにクリック率が0.7%という一群を見つけ、本文ではなく説明文だけを書き直す対応を取ったことがある。

検索からの流入が落ちたときの調べ方は、トラフィック減少のデバッグに体系的な手順がまとまっている。

順位の平均は扱いに注意が要る

Search Consoleが返す平均順位は、表示された回数で重み付けされた平均である。

何が起きるか

ある語で1位に表示されたが1回だけ、別の語で50位に表示されたが100回、という場合、平均は50位に近づく。

「平均順位が下がった」は、順位が下がったとは限らない。 下位で表示される語が増えただけかもしれない。

見るべきもの

語ごとに見る。 全体の平均順位は、傾向を大きく掴む以上の用途には向かない。

編集部では、重要な語を十数個選び、語とページの組み合わせで順位を日次記録している。

組み合わせで取る意味

同じ語に対して、自社の複数のページが表示されることがある。どのページが表示されているかが変わると、対策の対象も変わる。

語だけで記録すると、この入れ替わりが見えない。

日次で記録する仕組み

管理画面は過去16か月分しか保持しない。それ以前のデータは取得できない。

編集部の構成

APIから日次で取得し、リポジトリ内のファイルに追記している。GoogleとBingの両方について同じ形で記録する。

取得に使っているのはSearch Console APIと、Bing側の同等のAPIである。API側には利用上限があるため、取得の設計はそれに合わせる。

取得したデータは版管理する

ファイルとして保存し、変更履歴を残す。いつ取得した数字かが後から分かる。

本記事で5倍の誤りに気づけたのは、以前の数字が記録として残っていたためである。

アクセス解析と突き合わせる

検索エンジン側のツールと、アクセス解析は別の数字を返す。クリック数とセッション数は一致しない。

一致しないこと自体は正常である。 重要なのは、片方だけを見て全体を判断しないことである。編集部の失敗はここにあった。

なお、アクセス解析側ではデータのしきい値による欠落も起こり得る。どちらのツールにも、見えなくなる条件がある。

生成AIの回答に引用されているかは別の経路である

検索エンジンの管理ツールは、検索結果での表示を測る。生成AIが回答の根拠として自社のページを引用したかは、そこに現れない。

編集部は、この経路も測ろうとして、そこでも罠を踏んだ。

何を測ったか

検索機能を持つ生成AIに業務に関する質問を投げ、回答に付いた出典に自社のページが含まれるかを数えた。

対照として、自社が確実に上位表示されている題材の質問も投げた。

結果

対照の質問では4件中4件で自社のページが引用された。 一方、業務に関する質問では8件中0件だった。

引用されていたのは、同じ分野の事業者が自社で運営しているブログである。規模の小さい事業者のものも含まれていた。引用されるための壁は、サイトの規模ではない。

踏んだ罠：出典が中継用の住所だった

測定の実装で問題が起きた。

利用した仕組みが返す出典は、そのままでは引用元の名前ではなく、中継用の短縮された住所だった。見かけ上は出典が付いているが、その住所を辿らない限り、どの媒体を引用したのかは分からない。

最初の集計は、この住所をそのまま数えていた。結果として、すべての引用が同じ場所を指しているように見え、引用元の分布がまったく取れていなかった。

住所を解決する処理を足して初めて、実際の媒体名が出た。

この形も「0」で現れる

本記事で繰り返し出てくる形である。集計は正常に動いているように見えていた。 件数は出るし、エラーも出ない。間違った量を、正しく数えていた。

検索順位と引用は相関しない場合がある

編集部の観測では、検索で上位にあるページが引用されるとは限らない。逆に、検索での順位が高くないページが引用されることもある。

2つは別の経路なので、別に測る。 片方の数字でもう片方を推し量ると外れる。

生成AIが根拠のない情報を出す仕組みと、出典の確かめ方はハルシネーション対策の実務で扱っている。

サイトマップと登録状況も数えておく

表示回数より手前に、そもそも登録されているかという段階がある。

件数を監視する

編集部が運用している別のサービスでは、サイトマップに含まれるURLの件数を15分ごとに数えている。通常は800件前後で、300件を下回ったら異常として通知する。

件数が減るのは、生成の失敗かデータの欠落を意味する。サイトマップが壊れても、サイト自体は正常に見える。

登録されていないページを数える

管理ツールには、登録の状況を確認する機能がある。公開している本数と、登録されている本数を突き合わせる。

大きく乖離している場合、原因は次のどれかである。内部リンクから辿れない、重複と判定されている、品質が低いと判定されている、クローラが到達していない。

削除したページが残っていないか確認する

編集部では、削除したはずの記事が配信され続けていたことがある。削除済み198本のうち35本が、HTTP 200で全文を返していた。

過去に消したURLを控えておき、定期的に叩く。 200が返ったら削除が効いていない。

この事故の詳細と、他に見つかった無音の故障5件はHTTP 200なのに壊れているにある。

サイトマップの扱いは公式の概要に従うが、書き方が正しくても、生成されて配信されていなければ効かない。

測る前に決めておくこと

何を意思決定するために測るのか

「流入を増やす」では粗すぎる。記事を増やすか、既存を直すか、別の経路に投資するか。 どれを決めるために測るのかで、見る数字が変わる。

どの次元で取るか

全体の規模なのか、ページ別なのか、語別なのか。報告のときに次元を書く。

流入元の内訳を先に見る

検索エンジン別の内訳を確認してから、どのツールを見るかを決める。 編集部はこれを怠った。

正常値を記録する

異常を判定するには、正常な値を知っている必要がある。サイトマップの件数、1日あたりの表示回数、主要ページの順位。

0が出たときの手順を決める

0を見たら、測定の失敗を先に疑う手順を決めておく。対照を置く、期間を変える、別の取り方で取り直す。

ツールの守備範囲を先に書き出す

本記事の失敗をひとことで言えば、ツールが見ている範囲を、全体だと思っていたことである。

これは特定のツールの欠陥ではない。どのツールにも守備範囲があり、範囲の外は静かに存在しないことになる。

それぞれが見ていないもの

編集部が使っている道具について、見ていないものを書き出した。

実際に、この表の右列で事故が起きている

外部リンクは内部リンクの検査の対象外だった。 編集部のサイトでは、全記事の下部に出る外部リンクが404を返していた。内部リンクの検査は90,000本以上を「問題なし」と言い続けていたが、そもそも外部リンクを見ていなかった。

計測がブロックされていた期間は、アクセス解析に現れない。 訪問がなかったのか、計測が動いていなかったのかを、解析の画面からは区別できない。

やること

使っている道具を並べ、それぞれが見ていないものを1行で書く。 15分で終わる。

書き出すと、どの道具も見ていない領域が浮かぶ。編集部の場合、それがBingからの流入だった。全体の44.6%である。

緑の検査を信じる前に、その検査の守備範囲を確かめる。 範囲の外にある欠陥は、何年でも残る。

社内に数字を出すときの書き方

本記事の5倍の誤りは、取得の失敗ではなく、報告の失敗でもあった。数字だけを渡すと、受け取った側は確かめようがない。

編集部が以後守っている書き方を挙げる。

1. 分母を必ず書く

「表示18,982」ではなく「726記事で表示18,982」と書く。分母のない数は、たいてい別の量を測っている。

2. 取得の条件を数字と一緒に運ぶ

期間、次元、対象のドメイン、除外したもの。条件を外した数を、条件なしの数として書かない。

編集部の誤りは、まさに「検索語単位で取った数」を「サイト全体の数」として書いたことだった。

3. 比較対象を並べる

「この記事群は表示131」だけでは読めない。サイト全体の平均、同時期の他の記事、前月の同じ記事のいずれかと並べる。

比較先のない割合は、良いとも悪いとも判定できない。

4. 再現の手順を添える

どのツールで、どの画面から、どの設定で取ったか。受け取った側が同じ数字を出せる状態にする。

編集部では、取得に使ったスクリプトをリポジトリに置き、報告にはその実行方法を書いている。

5. 数字が変わったら、まず測り方を疑う

前回と大きく違う数字が出たとき、現実が変わったのか、測り方が変わったのかを先に切り分ける。

ツールの仕様変更、集計の対象期間のずれ、取得する次元の変更。測り方の変化は、現実の変化と同じ顔で現れる。

6. 0と欠測を区別して書く

「0件」と「取得できなかった」は別である。取得できなかったものを0として集計すると、実態より良い数字にも悪い数字にもなる。

編集部が使っている取得スクリプトは、取得に失敗した語を0ではなく「取得失敗」として区別し、集計から外している。

まとめ

検索流入の測定で踏んだ罠の記録である。

同じ期間・同じサイトで、表示回数が6,251とも31,899とも出た。 検索語単位のデータには、検索数が少ない語が含まれない。全体の規模を知りたいならページ単位で取る。

アンカー付きのURLは別の行で返る。 畳まずに数えると同じページを重複して数える。

この誤りで、95本の記事群を「クリック0」と評価しかけた。 正しくはクリック20である。

最大の流入元がBing（44.6%）で、Googleは15.0%だった。 Search Consoleに映るのはGoogleだけである。3分の1以下の経路だけを見て施策を決めていた。

Bing側のAPIは、引数の誤りをエラーではなく0で返す。 対照となる語を一緒に測り、対照が0なら測定失敗として止める仕組みを入れた。

平均ではなく分布を見る。 上位1本で表示の39.2%、上位50本（6.9%）で84.6%。209本（29%）は表示ゼロだった。

明日から試せる3つ

1つ目は、同じ期間の合計を、ページ単位と検索語単位の両方で取ることである。差が大きいなら、これまで報告していた数字がどちらだったかを確認する。

2つ目は、アクセス解析で流入元の内訳を見ることである。検索エンジン別の比率を知らないまま、片方のツールだけを見ていないかを確かめる。

3つ目は、順位10位以内でクリック率が2%未満のページを抜き出すことである。ここは本文ではなく文面を直すだけで効く。

編集部では、AI導入の支援に加えて、こうした計測の仕組みづくりも行っている。数字は出ているが判断に使えない、という段階の相談については、サービス案内を参照してほしい。

参考にした一次資料

• Search Console — 本記事のデータの取得元
• 検索パフォーマンスレポートの説明 — クエリ単位で欠落が起きる理由
• Search Console の使い方 — 公式の解説
• Search Console API — 日次記録に使用
• API の利用上限 — 取得の設計に必要
• データの保持期間について — 過去分が取得できなくなる条件
• トラフィック減少のデバッグ — 減ったときの調べ方
• サイトマップの概要 — 件数を監視する対象
• Bing Webmaster Tools — Bing 側の実績
• Bing Webmaster Tools のドキュメント — API の仕様
• Bing Webmaster Tools へのアクセス — 所有権確認の手順
• Google アナリティクス Data API — 流入元の内訳を取得
• アナリティクスのデータしきい値 — 解析側で欠落が起きる条件

よくある質問

Search Consoleでクエリ別とページ別の合計が一致しないのはなぜですか。

クエリ別のデータには、検索数が少なく個人を特定できる可能性のある検索語が含まれないためです。編集部のサイトで同じ期間を測ったところ、クエリ単位の合計が6,251表示だったのに対し、ページ単位では31,899表示でした。約5倍の差があります。全体の規模を知りたい場合はページ単位か、次元を指定しない合計を見てください。

Search Consoleの数字だけで施策を決めてよいですか。

流入元がGoogleに偏っている場合を除き、危険です。編集部のサイトでは、アクセス解析で見ると最大の流入元はBingで全体の44.6%、Googleは15.0%でした。Search Consoleに映るのはGoogleだけなので、3分の1以下の経路だけを見て施策を決めていたことになります。

アンカー付きのURLは別ページとして数えられますか。

別の行として返ってきます。編集部のデータでは、同じ記事の見出しへのリンクが複数の行に分かれており、畳まずに集計すると同じページを重複して数えることになります。ページ単位で集計する際は、URLからアンカー部分を落としてから合算してください。

Bing側の数字はどう取ればよいですか。

Bing Webmaster ToolsにAPIがあり、サイトの登録・実績の取得・URLの送信ができます。ただし所有権を確認した直後は最大48時間データが出ません。また検索数を推定する機能は引数の指定に厳しく、期間を渡さない、国名の大文字小文字が違うといった場合に、エラーではなく0を返します。

推定検索数が0と出たらその語に需要はないということですか。

測定が正しく行われていれば需要がないと読めますが、叩き方を誤っても0が返ります。編集部では、応答の解釈を間違えて82語すべてが0に見えた例があります。既知で需要の大きい語を対照として一緒に測り、その値が0なら測定自体の失敗として扱う仕組みにしました。

記事を増やしたのに流入が増えません。どこを見ればよいですか。

平均ではなく分布を見てください。編集部が726記事の全件を測ったところ、上位1本で表示の39.2%、上位50本（全体の6.9%）で84.6%を占め、209本（29%）は表示が1回もありませんでした。集中している場合、本数を増やす投資は効いていません。