Google Search Status DashboardをJSONで毎朝読む方法｜コアアップデート中は記事の大きな書き換えを止める【2026年】

Google Search Status Dashboardは、公開のJSONを毎朝1回読むだけで、ランキング更新の実施中を見分けられました。僕の会社では、コアアップデートかスパムアップデートの実施中だけ運用フラグを立て、既存記事の大きな書き換えを止めています。下ろすのは人か21日の規則です。

この仕組みは2026年10月15日に作りました。米国時間9月24日に始まった「September 2026 spam update」は、10月8日に完了済みでした。完了から1週間の10月15日までは、順位で判断しない扱いでした。

この記事では、incidents.jsonのどの項目で「実施中」を決めているか、フラグを立てるだけで下ろさない理由、立っている間の運用ルールを順に書きます。「アップデートの最中って、結局サイトを触っていいの？」と迷っている方向けです。

Google Search Status DashboardのJSONを毎朝読み、コアアップデート中は書き換えを止める仕組み

僕の会社の仕組みは、サイト運営の毎朝の点検の中で、Googleが公開しているincidents.jsonを1回読むだけのものです。外部のライブラリは使わず、Macのpython3の標準ライブラリだけで動きます。

読んだ結果で変えるのは、社内の運用フラグ1つだけです。フラグの意味は「コアアップデート実施中」で、立っている間は既存記事の大きな書き換えや、タイトルの新しい試しを止めます。

1回の点検でやることを、段階ごとに並べました。触るものが段階で違うので、そこも書いています。

決めごとの中心は、3の「立てるだけ」です。下ろす判断を機械にさせない理由は、4つ目の章で書きます。

incidents.jsonとproducts.jsonで見ている項目：Rankingのidと9件の履歴

Google Search Status Dashboardには、画面とは別に機械で読める形の情報があります。トップページの案内には、JSONの履歴と製品の一覧、それぞれのスキーマ、Atomのフィードが並んでいます。

products.jsonは製品の一覧です。2026年11月9日に確かめた時点では、Crawling・Indexing・Ranking・Servingの4つでした。

ランキング更新が載るのはRankingで、idは rGHU1u87FJnkP6W2GwMi です。スキーマには、製品のidについて「This field is stable.」と書かれています。

題名の表記は変わることがあっても、idで見分ければ判定がずれにくくなります。そのため僕の会社では、Rankingかどうかをまずidで見ています。

incidents.jsonは、インシデントを並べた配列です。11月9日に読んだ時点では9件が入っていて、1件ごとに15個の項目がありました。

そのうち判定と報告に使うのは、主に6つの項目です。どれもスキーマに説明がある、公開の項目名です。

僕なら、最初に読むのはendとaffected_productsの2つにします。この2つだけで「Rankingの更新が、いま終わっているか」が決まるからです。

時刻はUTCで入っているので、日本時間とは9時間ずれます。9月のスパムアップデートの完了は、JSONでは10月8日08:00、日本時間では10月8日17:00でした。

Rankingの8件を日本時間に直すと、期間は1日足らずから約22日

9件のうち8件がRanking、1件がServingの障害でした。Rankingの8件を日本時間に直し、期間を並べたのが下の表です。

期間は、incidents.jsonのbeginとendの差から僕が計算しました。コアアップデートは約12〜18日、スパムアップデートは1日足らずから約14日です。

Discoverの更新は約22日といちばん長いのですが、題にcore updateもspam updateもありません。僕の会社の決めでは、これはフラグの対象外で、報告に出すだけです。

「実施中」はendの有無で決める：AVAILABLEだけでは終わったと見ない

僕の会社の判定では、endが無い・空・未来の時刻のどれかなら「実施中」とみなします。対象はRankingの製品で、題にcore updateかspam updateを含むもの（大文字小文字は問わない）だけです。

most_recent_update.statusがAVAILABLEでも、endが無ければ実施中として扱います。状態の表示と終わりの時刻が食い違ったら、止める側に倒す決めです。

affected_productsが無い古い形のデータに備えて、service_keyとservice_nameでも製品を見ています。どちらも、11月9日に読んだincidents.jsonに実在する項目です。

トップページにはAtomのフィードもありますが、僕の会社では使っていません。進行中かどうかは、JSONのendで見る方が確実だと判断したからです。

終了の時刻は、完了の知らせより前の時刻で入ることがある

9月のスパムアップデートの個別ページでは、終了の時刻は米国太平洋時間の10月8日1:00でした。一方、完了を知らせる更新が投稿されたのは同じ日の1:37です。

endには、完了を知らせた投稿の時刻ではなく、終わった時刻が入っていると読めます。知らせの文面より、endの値で判定する方がぶれません。

Ranking以外の障害は、報告に出すだけでフラグに触らない

Crawling・Indexing・Servingの障害が進行中でも、フラグには触りません。報告に「その他 進行中」として出すだけです。

2026年2月25日のServingの障害は、JSONの開始と終了の差が15分でした。こうした障害はランキング更新ではないので、記事の運用ルールの対象にはしていません。

完了から14日以内の更新は「最近の完了」として報告に出します。そこに、完了日から7日後の日付を「この日まで順位で判断しない」として添えています。

運用フラグは減速の方向にだけ立て、下ろすのは人か21日

フラグを立てる条件は、実施中のランキング更新が1件以上あり、フラグがまだ下りていることだけです。立てるときは、検知した日を開始日として一緒に記録します。

下ろす処理は、この仕組みにはありません。下ろすのは、毎朝の情報の仕分けの処理が完了の新着を見たとき、開始日から21日たったとき、人が手で下ろしたときの3つだけです。

僕の会社では2026年10月15日に、減速の方向だけなら機械に任せてよいと決めました。書き換えを再開させる向きの判断は、人と既存の規則に残しています。

21日は、さきほどの表のコアアップデート・スパムアップデートの最長（2025年12月のコアアップデートの約18日）より長い日数です。完了の知らせを取りこぼしても、立ちっぱなしにならない歯止めになります。

取得や読み込みに失敗した回は、フラグに触らず、失敗したことだけを記録します。失敗の回を「実施中なし」とも「実施中」とも扱わない、という決めです。

立てる・立てない・すでに立っていた、のどれでも正常に終わった扱いにしています。失敗のときだけ、別の終了コードで終わります。

コアアップデート中の運用ルール：大きな書き換えをしない、完了から1週間は順位で判断しない

フラグが立っている間、僕の会社では4つのことを普段と変えます。どれも、既存記事への手入れを急がないための決めです。

誤解されやすいのは、新しい記事の本数です。アップデート中でも減らしはしません。止めるのは既存記事への大きな手入れで、新しく足す側は普段どおりです。

完了した後も、すぐには順位を見に行かず、最低1週間待ちます。そのあと、開始前の1週間と完了後の1週間をSearch Consoleで比べ、落ちた記事は本文の中身で直す順番です。

社内のガードレールでは、コアアップデートのときは応急処置をせず、コンテンツの削除は最終手段としています。回復には数か月かかることもある、という前提で動いています。

9月のスパムアップデートと、新設の日の扱い

2026年9月のスパムアップデートの時期には、僕の会社のサイトで表示の急落が重なりました。原因の切り分けの経緯はSEOハネムーン終了か事故かを切り分けた記録に書いたので、ここでは仕組みの話に絞ります。

その更新が完了したのは10月8日で、仕組みを作った10月15日は、ちょうど完了から1週間の最後の日でした。新設の日の時点では実施中の更新が無く、フラグは立てていません。

開始前と完了後の1週間を比べる数字は、日別にそろっていないと比べられません。毎朝の数字のそろえ方は、Search Console APIを毎朝Pythonで取る方法に書きました。

2026年11月9日の確認結果：9件を読み、実施中のランキング更新は0件

2026年11月9日11:12の確認では、incidents.jsonの取得に成功し、9件を読みました。実施中のランキング更新は0件、その他の進行中の障害も0件で、フラグは下りたまま変えていません。

完了から14日以内の更新も0件でした。いちばん新しいSeptember 2026 spam updateの完了（日本時間10月8日）から、32日たっているためです。

公式のJSONを見る限り、仕組みを作った10月15日以降に始まったランキング更新はまだありません。つまり、この仕組みがフラグを自分で立てた回は、11月9日の時点で0回の計算です。

本番で立てる場面をまだ見ていないので、確かめる手段を2つ用意しています。手元のファイルを渡して判定だけさせる方法と、何も書き換えずに判定の結果だけを見る方法です。

次にコアアップデートが来た朝、フラグが立つかどうかが、この仕組みの最初の本番になります。立った日と下りた日は、確認結果のファイルと週次の報告で追えます。

Pythonの標準ライブラリで公開JSONを読む最小の例

社内で動かしているものとは別に、この記事のために書いた最小の例です。Ranking のidと題で絞り、endで実施中かを見ます。

import json
import urllib.request
from datetime import datetime, timezone

URL = "https://status.search.google.com/incidents.json"
RANKING_ID = "rGHU1u87FJnkP6W2GwMi"

with urllib.request.urlopen(URL, timeout=30) as res:
    incidents = json.load(res)

now = datetime.now(timezone.utc)
for inc in incidents:
    ids = [p.get("id") for p in inc.get("affected_products", [])]
    title = inc.get("external_desc", "")
    end = inc.get("end")
    ongoing = not end or datetime.fromisoformat(end) > now
    is_update = "core update" in title.lower() or "spam update" in title.lower()
    if RANKING_ID in ids and is_update and ongoing:
        print("実施中:", title, inc.get("begin"))

11月9日の時点では、この例を動かしても何も表示されないはずです。実施中のランキング更新が0件だからです。

endの値は 2026-10-08T08:00:00+00:00 の形で入っています。Python 3.9の datetime.fromisoformat は、この形をそのまま読めます。

僕なら、毎日回す前に3つ足します。取得に失敗したらフラグに触らないこと、結果をファイルに残すこと、下ろす処理を書かないことです。

毎朝の実行の仕組みを自分で用意するなら、Macのlaunchdで定期実行する方法があります。設定の仕方と落とし穴はMacのlaunchdで定期実行する方法に書きました。

ダッシュボードに載らない問題もある

公式ヘルプでは、個別のサイトに限られる問題や、影響が少数にとどまる問題は載らない場合があるとしています。JSONに何も無い日でも、自分のサイトの不具合が無いとは言えません。

同じヘルプには、ランキング更新について「多くの場合、対応は不要」という趣旨の説明もあります。僕の会社のフラグも、何かを直すためではなく、手を止めるためのものです。

まとめ

• Google Search Status Dashboardのincidents.jsonは公開されていて、ログインも鍵も要らず、Pythonの標準ライブラリだけで毎朝読めます
• 実施中かどうかは、Rankingのid（rGHU1u87FJnkP6W2GwMi）と題のcore update・spam update、それにendの有無で決めています
• 2026年10月15日の新設から、運用フラグは「減速の方向」にだけ立て、下ろすのは人か開始から21日の規則に任せています
• フラグが立っている間は既存記事の大きな書き換えとタイトルの試しを止め、完了から1週間は順位で判断しません
• 僕なら最初に、endとaffected_productsの2項目だけを読む小さな確認から始めます