WEBサイトSearch Consoleに重大エラー、インプレッションが約1年間も過大表示 ── 自社の数字を確かめ直す方法を確認する（2026年8月時点）
Search Consoleに重大エラー、インプレッションが約1年間も過大表示 ── 自社の数字を確かめ直す方法を確認する（2026年8月時点）
目次
01 何が起きたか — インプレッションは約1年間、正しく記録されていなかった
2026年4月3日、Googleが公式に認めた
2026年4月3日、GoogleはSearch Consoleの「データ異常」ヘルプページを更新し、ある不具合を公式に認めました(Search Console のデータ異常(Google Search Console ヘルプ))。原文は次のとおりです。
"A logging error is preventing Search Console from accurately reporting impressions from May 13, 2025 onward."
(訳: ロギング(記録)エラーにより、2025年5月13日以降、Search Consoleがインプレッションを正確に報告できない状態が続いていました。)
この文言だけを読むと「最近気づかれた不具合」に見えますが、開始日は2025年5月13日です。発覚した2026年4月3日までの期間は約1年間(公式報道では約50週間)にのぼります(Google is fixing a Search Console bug that inflated impression counts(訳: Googleが、インプレッション数を過大に報告していたSearch Consoleのバグを修正へ)(Search Engine Land・2026年4月3日))。
Google報道官のコメント
同じ記事には、Google報道官による直接のコメントも記録されています。
"We identified a reporting error in Search Console that temporarily led to an over-reporting of impressions from May 13, 2025 onward."
(訳: 2025年5月13日以降、インプレッションを一時的に過大報告していたSearch Consoleのレポートエラーを特定しました。)
ここで使われている単語は「logging error(ロギングエラー)」です。画面の見せ方が誤っていた「表示バグ」ではなく、インプレッションという出来事そのものを記録する段階で、実際より多く数えてしまっていたという意味になります。この違いは03章で改めて整理します。
| 時期 | できごと |
|---|---|
| 2025年5月13日 | ロギングエラーが発生。この日からインプレッションの記録が正確でなくなる(社内でも未検知) |
| 2026年4月3日 | Googleが公式にデータ異常ページを更新し、不具合を認める |
| 2026年4月20-21日 | 修正の展開途中で、パフォーマンスレポートの表示回数・クリック数が一時的に急落(Google fixes Search Console's year-long data logging issue(訳: Googleが、Search Consoleの1年越しのデータ記録問題を修正)(Search Engine Land)) |
| 2026年4月27日 | ロギングの修正が完了。以後のインプレッションは正確に記録される |
| 2026年8月(現在) | 数値そのものは安定。だが2025年5月〜2026年4月のデータを根拠にした過去の判断は、そのまま残っている |
修正は「これから」だけを直す。過去には遡らない
ここが最も見落とされやすい点です。Googleの発表は「修正した」で終わりますが、修正されるのは今後のロギングだけです。2025年5月13日から2026年4月27日までの期間について、正しい数値へ再構築される予定はありません。この点はGoogleのJohn Mueller氏も確認したと報じられています(Google fixes Search Console's year-long data logging issue(訳: Googleが、Search Consoleの1年越しのデータ記録問題を修正)(Search Engine Land))。
注意
「修正されました」という一文だけを見て、過去のレポートも正しい数値に置き換わっていると考えるのは早計です。2025年5月13日〜2026年4月27日のインプレッション・CTR・平均掲載順位は、今もその期間だけ歪んだ数値のまま画面に残り続けます。
02 なぜ・背景 — 測定ツール自体が、静かに壊れていることがある
「335日間、内部でも気づかれなかった」という重さ
Search Consoleは、WEBディレクターにとって最も基本的な計測ツールのひとつです。その画面が示す数字を疑わずに、日々の判断やクライアントへの報告を組み立てている人は少なくありません。今回の不具合が重いのは、被害の大きさよりも「約1年もの間、提供元のGoogle自身が異常に気づかなかった」という事実そのものです。日常的に信頼して開いているダッシュボードも、裏側では記録の仕組みそのものにバグを抱えうるソフトウェアである、という当たり前の事実を、この一件は改めて突きつけています。
影響を受けた指標と、受けていない指標
公式ヘルプが明記している影響範囲は限定的です。歪んだのはインプレッション数・CTR(クリック率)・平均掲載順位の3指標で、これらはインプレッションという分母を介して連動しています。一方でクリック数は影響を受けていません。分子であるクリックの計測系統は、今回のロギングエラーとは別の経路で記録されていたと考えられます。
原因そのものは、公表されていない
正直に書いておきます。Googleは「なぜインプレッションだけが対象になったのか」という技術的な原因を公表していません。分かっているのは影響範囲(インプレッション・CTR・平均掲載順位)と、影響を受けなかった指標(クリック数)の対比だけです。原因が分からないものを、分かったふりで書かないことが、この記事の前提です。
実務のヒント
ダッシュボードの数字を疑う出発点は「原因を推測すること」ではありません。「この数字は、どの経路で記録されたものか」を自分に問い直し、複数の経路を突き合わせられる体制を持っておくことです。04章で、その具体的な方法を型に分けて整理します。
03 この記事で出てくる用語
インプレッションとは
用語
インプレッション: Search Consoleのパフォーマンスレポートにおいて、自サイトのURLが検索結果に表示された回数を指す指標です(パフォーマンスレポート(検索結果):概要と基本設定(Google Search Console ヘルプ))。クリックされたかどうかは含まれず、あくまで画面上に表示された事実だけを数えています。今回の不具合は、この「表示された回数」を数える記録の段階で発生していました。
ロギングエラーと、表示バグの違い
用語
ロギングエラー(記録エラー): 出来事そのものを記録する処理の段階で発生する不具合です。今回のケースでは、インプレッションという出来事が起きた時点で、実際より多くカウントされる形で記録されていました。これは、正しく記録された数値を画面に表示する段階で崩れる「表示バグ」とは別の層の問題です。表示バグなら再読み込みで直ることもありますが、記録段階の誤りは、記録された時点のデータそのものが歪んでいるため、後から見た目を直しても解消しません。
Search Console のデータ異常ページとは
用語
データ異常(Data anomalies)ページ: Googleが、Search Consoleの各レポートで発生した既知の不具合・仕様変更を一覧化している公式ヘルプページです(Search Console のデータ異常(Google Search Console ヘルプ))。今回のインプレッション過大表示に加えて、リッチリザルトの提供終了など、パフォーマンスレポート以外の項目についても更新されています。自社の数値が「いつもと違う」と感じたとき、まず確認すべき一次情報です。
Bulk Data Export(一括データエクスポート)とは
用語
Bulk Data Export: Search Consoleのデータを、Google Cloud の BigQuery へ日次で自動的に書き出す機能です(Bulk data export: a new and powerful way to access your Search Console data(訳: Bulk data export: Search Consoleのデータにアクセスする新しく強力な方法)(Google Search Central Blog))。通常のUI画面が保持する期間(最大16か月)を超えて、長期のデータを自社側に蓄積しておける点が特徴です。04章・06章で、この機能を検算の手段として使う際の注意点を扱います。
04 型別 — 自社データを検算する方法の、適用範囲・限界・手順
🅰 適用範囲 — どんな体制なら、どの方法が使えるか
検算の手段は、組織の体制によって現実的に使えるものが変わります。GA4を既に導入しているサイトなら、オーガニック検索セッション数との突き合わせは今日からできます。Google Cloud のアカウントを持つ体制であれば、Bulk Data Export(BigQuery)で日次の生に近いデータを蓄積し、UI側の暫定値と突き合わせることが可能になります。一方、個人運営の小規模サイトで開発リソースを割けない場合は、GA4とBing Webmaster Toolsという、登録するだけで使える無料の外部指標を並べて見ることが、現実的な出発点になります。
逆に言えば、「Search Consoleの画面だけを唯一の指標にしている」という体制ほど、今回のような不具合に対して脆弱です。1つの経路しか持たない検算は、検算になりません。最低でも、Search Console以外の経路をもう1つ持つことが、この型の出発点です。
🅱 その方法が測っていないこと — どの検算にも死角がある
どの検算方法にも、それぞれの死角があります。GA4のオーガニック検索セッション数は、クリック後にサイトへ到達した実績しか反映しないため、インプレッション(表示されただけ)の検証には使えません。Bing Webmaster Toolsは、そもそも計測対象がBing検索に限られ、Google検索の異常を直接は検出できません。そしてBulk Data Export(BigQuery)についても、公式のデータ異常ページはUIとAPI・エクスポートを区別せずに「Search Console」と一括して記載しており、今回の不具合がエクスポート側のデータにも及んでいたのかどうかは、この一次情報だけでは判定できません。
「分からないことは分からないと書く」という原則に従うなら、Bulk Data Exportの利用者は、公式コミュニティで自分のケースを個別に確認する必要がある、というのが誠実な結論です。分からないことを、分かったことのように扱わないことも、検算という作業の一部です。
🅲 手順 — 今日から検算体制を1段階進める3ステップ
手順は難しいものではありません。第一に、自社が今持っている検算経路の数を数えます。Search Console以外に何を見ているか、今この瞬間に1つも思い浮かばなければ、経路は0です。第二に、GA4のオーガニック検索セッション数、あるいはBing Webmaster Toolsのどちらか、まだ導入していない方を1つ追加します。どちらも無料で、登録だけで数日以内にデータが溜まり始めます。第三に、月次のレポート作成時に、Search Consoleの数字だけでなく、追加した経路の数字も並べて1行に記録する習慣を始めます。
Bulk Data ExportやSearch Console APIの導入は、この3ステップの先にある発展形です。まずは無料で今日から始められる並列確認を持つことが、次に同じ規模の不具合が起きたときに、自分の手で気づけるかどうかを分けます。
注意
今回の不具合は335日近く、Google自身も気づかないまま進行していました。「大手の公式ツールだから間違えない」という前提そのものを、検算体制の設計から外しておく必要があります。
05 自分のサイトで確認するチェックリスト
3つの観点 — 期間の特定・自社への影響・今後の体制
ここまでの内容を、今日から手を動かせる作業に翻訳しました。観点は、自社のデータのどこが影響を受けたかを特定する確認、その数値を根拠にした過去の判断を洗い出す確認、そして次に同じことが起きても気づける体制を作る確認の3つに分かれます。チェックの状態はブラウザ内にのみ保存され、サーバーには送信されません。
- Search Consoleのパフォーマンスレポートを開き、期間を2025年5月13日から2026年4月27日に設定してインプレッションの推移を表示する
- 同じ期間でクリック数のグラフも表示し、インプレッションと同じ形で動いていないことを目視で確認する
- 期間の比較機能を使い、平均掲載順位とCTRがこの期間の前後でどう変わっているかを書き出す
- GA4を開き、同じ期間のオーガニック検索セッション数を書き出し、Search Consoleのクリック数と並べて記録する
- 自社がBulk Data Export(BigQuery)を使っているかを確認し、使っているなら該当期間のレコード数を1回クエリで数える
- クライアント向けや社内向けのレポートを検索し、この期間のインプレッション・CTR・平均掲載順位を根拠にした記述が無いか1件探す
- 見つかった場合、その記述をクリック数ベースで読み直し、結論が変わるかどうかを確認する
- Search Consoleの「データ異常」ページを開き、自社サイトに関係する他の異常が無いか3分で確認する
- URL検査ツールで代表ページを3件検査し、インデックス状況に異常が無いことを確認する
- まだBing Webmaster ToolsかGA4のどちらかを導入していない場合、どちらか1つを今日登録する
- Search Consoleの「ユーザーと権限」を開き、この種の公式通知を見落とさないよう、通知先メールアドレスが現在使っているものか確認する
- 月次で数値を記録するスプレッドシートを用意し、今月分のインプレッション・クリック数・GA4セッション数を1行書き込む
- 1か月後に同じスプレッドシートを開き直し、複数の経路で数値が同じ方向に動いているかを記録する
13項目の内訳と、かかる時間の目安
最初の3項目は不具合期間の自社データの実地確認、4番目から7番目は過去の判断への影響の洗い出し、8番目から11番目は今後の体制づくりの第一歩、12番目と13番目は継続的な記録の仕組み化に対応しています。すべてに目を通す時間の目安は1サイトあたり20分程度です。特に6番目と7番目は省略されがちですが、この記事のいちばんの目的はここにあります。数字を見返すだけでなく、その数字を根拠にした過去の判断を洗い出すところまでが、今回の不具合が実務に投げかけている宿題です。
Search Consoleの見方そのものに迷った場合は、🔧 Search Console お助けツールで、既存のパフォーマンスレポートの数値をもう少し詳しく確認することもできます。
06 自社データを検算する方法の比較
7つの経路を、確認できることと影響の有無で並べる
04章で触れた検算の型を、実際に使える経路ごとに一覧にしました。それぞれの経路が「何を確認できるか」と「今回の不具合の影響を受けたか」を横に並べて見ることで、自社にどの経路が足りていないかが分かります。
| 方法 | 確認できること | 今回の不具合の影響 |
|---|---|---|
| Search Console パフォーマンスレポート(UI) | インプレッション・クリック数・CTR・平均掲載順位 | この不具合の当事者(インプレッション・CTR・順位が影響を受けた) |
| GA4 (オーガニック検索セッション) | セッション数・エンゲージメント率 | 影響なし(Search Consoleとは別のログ基盤) |
| Bing Webmaster Tools | Bing経由のインプレッション・クリック数 | 影響なし(別会社の基盤) |
| Search Console API(Search Analytics) | UIと同じ指標をプログラムで取得 | 公式には未区別。UIと同じ基盤の可能性が高い |
| Bulk Data Export (BigQuery) | 日次の、UIより生に近いインプレッション・クリックデータ | 公式ページはUI・APIを区別して記載していない(要個別確認) |
| サーバーの アクセスログ | Googlebotに実際にクロールされた回数(インプレッションとは別概念) | 影響なし(自社サーバーのログ) |
| 当サイトの (🔧 Search Console お助けツール・無料) | Search Console全体の数値をもう少し詳しく確認 | ツール自体はデータの記録層には関与しない。SC本体の数値取得を代替するものではない |
「増えた・減った」だけを見ると、遠回りになる
この一覧を見て分かるのは、7つの経路のうち、今回の不具合を独立して裏取りできる経路が半分以上を占めるという点です。特にGA4とBing Webmaster Toolsは、既に無料で使える体制を持っているサイトが多いにもかかわらず、Search Consoleの数字だけを見て一喜一憂しているケースが少なくありません。「Search Consoleの数字が増えた・減った」という単一の情報源だけで意思決定をしないことが、この表から得られる実務上の結論です。
サイト全体の状態を一度にまとめて確認したい場合は、🔧 WEBサイト総合分析ツールで、検索まわりの数値と合わせて健全性を見ておくと、今回のような外部要因による変動と、自社サイト側の問題による変動を切り分けやすくなります。
07 当サイトの実測
この期間の自社データを開き直す確認は、まだしていない
正直に書きます。当サイト自身のSearch Consoleデータについて、2025年5月13日〜2026年4月27日の期間を対象に、インプレッション・CTR・平均掲載順位の推移を開き直して確認する作業は、この記事の執筆時点ではまだ行っていません。ログインを要する画面の個別確認であり、本記事の一次情報の裏取りとは別の作業になるためです。分からないことは分からないと書きます。
ただし、04章・05章のチェックリストに沿った確認は、当サイト自身にとっても宿題として残っています。次回この記事を見直す際には、実際に自社のデータでこのチェックリストを回し、結果をここに追記する予定です。数字を扱う記事を書きながら、その数字の検算を自分自身が済ませていないという状態を、そのまま放置しないための備忘として、この段落を残しておきます。
08 このテーマの、これまで
Search Consoleの数字が「11ヶ月、壊れていた」と書いた回
実は、Search Consoleの計測が長期間不安定だったという話題そのものは、当サイトが以前にも扱っています(archives/54)。この回では、Search Consoleのバグ・FAQリッチリザルトの廃止・5月の順位変動という、複数の計測不安要素をまとめて扱いました。本記事はその続報にあたり、当時「11ヶ月」として扱われた不具合の、その後の展開(4月20-21日の再急減、4月27日の修正完了)と、検算という視点にしぼって書き直したものです。
GSC・GA4・Bingを「3ツール立体計測」と呼んだ回
AIに表示された回数を追う文脈で、Search Console・GA4・Bingの3つのツールを組み合わせて計測する考え方を扱った回もあります(archives/76)。06章の比較表で挙げた経路の多くは、この回で示した「1つのツールに頼らない」という発想と同じ根を持ちます。AI検索の計測に限らず、通常のインプレッション計測でも、同じ立体計測の考え方が有効だということを、今回の不具合が裏付けた形です。
「同じ条件で測っていなかった」ことに気づいた回
3つのサイトのアクセスログを比較しようとして、実は条件をそろえずに数字を並べていたと気づいた回もあります(archives/117)。今回の不具合も、Search Consoleという単一のツールの数字を、まるで絶対値のように扱っていたという意味で、条件をそろえずに数字を信じていた点は同じです。数字を並べる前に、その数字がどの経路・どの条件で記録されたものかを確認するという教訓は、この2つの回に共通しています。
「0件は安心ではない」と書いた回
サイトを調べる際の判定ロジックが、両方向に倒れうるという内容を扱った回もあります(archives/130)。今回のケースは逆方向で、「N件(インプレッションが表示されている)」という数字が、実は危険信号だったという事例です。件数の増減という表面だけを見て安全・危険を判断しないという姿勢は、両方の回で共通しています。
生成AIパフォーマンスレポートが「半分」しか見えていなかった回
Search Consoleの新しいレポートが、表示回数しか測れず、実際の流入を測れていないという限界を扱った回もあります(archives/125)。あわせて、Search Consoleの生成AIパフォーマンスレポート自体を扱った記事(Search ConsoleのAIパフォーマンスレポート、結局どこまで見えるようになったのか)でも、公式レポートの限界を確認しています。今回の記事とあわせて読むと、Search Consoleという1つのツールが、常に「見えている範囲」と「見えていない範囲」の両方を持っていることが分かります。
現在の貴方のIPアドレス
このサイトで書いている人
