Search Consoleの直近データが少ないのは、減少ではない（2〜3日の遅延と週次の部分窓）

Search Consoleのデータを週ごとに集計すると、こういうグラフになることがあります。

6/29週  91
7/06週  89
7/13週  76
7/20週  66
7/27週  89
8/03週  12   ← 急落？

これはたいてい、減少ではありません。

原因1: Search Consoleのデータは2〜3日遅れる

Search Consoleの検索パフォーマンスのデータは、リアルタイムではありません。最新の数日ぶんは、まだ入っていない状態です。

実際に確認した例です。2026年8月6日にAPIから取得したところ、データが存在する最終日は8月3日でした。3日ぶんが未着ということになります。

つまり8月6日時点では、「8月4日・5日・6日は表示ゼロ」ではなく、**「まだ分からない」**が正しい状態です。

原因2: 最後の週が「部分窓」になる

ここに週次集計を重ねると、問題が起きます。

上の例の「8/03週」は、本来 8/03〜8/09の7日間です。でも8月6日時点でデータがあるのは8/03の1日ぶんだけ。

つまりこの 12 は、7日ぶんの合計ではなく1日ぶんの数字でした。

日次で並べると一目瞭然です。

7/27  6
7/28  12
7/29  18
7/30  12
7/31  20
8/01  11
8/02  10
8/03  12   ← ここでデータが終わっている

毎日6〜20で安定していました。 減っていません。週次の見かけ上の急落は、窓が途中で切れているだけでした。

切り分け方

1. データの最終日を確認する

週次を見る前に、そのデータがいつまで入っているかを確かめます。日次の次元で取得して、最後の日付を見るのが確実です。

# ページ×日付で取得して、存在する最終日を見る
rows = query(access_token, site, {
    "startDate": "2026-07-27",
    "endDate":   "2026-08-15",   # 未来まで指定してよい
    "dimensions": ["date"],
})
print(max(r["keys"][0] for r in rows["rows"]))

終了日を未来に指定しても、存在するぶんまでしか返りません。返ってきた最終日が、実質のデータ末端です。

2. 末尾の1〜2週は判断に使わない

グラフを見るときは、最後の点を無視するのが安全です。「直近が落ちている」に見えたら、まず窓を疑います。

3. 比較は「同じ長さの期間合計」で行う

施策の前後を比べるなら、週次グラフではなく期間合計を使います。

• ❌ 「先週は89、今週は12だから落ちた」
• ⭕ 「7/24〜8/03の11日間」と「8/05〜8/15の11日間」を比べる

窓の長さを揃えれば、部分窓の問題は起きません。

なぜ間違えやすいか

このグラフは「急に落ちた」ように見えます。そして急落は、原因を探したくなる形をしています。

私は実際に、この 12 を見て「減少が始まったのか」と読みかけました。日次に落として初めて、1日ぶんしか入っていないと分かりました。

存在しない異常を追いかけると、対策まで打ってしまいます。 落ちて見えるものを見たら、まずデータの端を確認するのが安全です。

まとめ

• Search Consoleのデータは2〜3日遅れる（実測で3日）
• 週次にすると、最後の週は必ず部分窓になる
• 判断する前にデータの存在する最終日を確認する
• 前後比較は同じ長さの期間合計で行う。週次グラフの末尾は使わない

---

このサイトでは、施策の効果を測るときの手順と、そこで踏んだ失敗を記録しています。「測る前に決めておく」をどう運用しているかは、連載「委任の記録」に書いています。