Google の順位モニターは、たいてい同じ設定で組まれます。しきい値を決め、順位がそれ以上動いたらアラートを出し、それで終わり。多くのツールの既定しきい値は3順位あたりで、3という数字が意味のある変動に聞こえるからです。
自社データでは、そうではありません。90日間で30インプレッション以上あった106クエリを見ると、クエリの順位標準偏差の中央値は7.45でした。典型的なクエリにとって、3順位の変化はシグナルではありません。その数字の日常的な振る舞いです。
モニターが壊れているのではなく、調整されていないのです。これが、既定値ではなく自社の履歴から調整したときの姿です。
モニターが前提にしていること、そして崩れる前提
どのアラートルールの背後にも4つの前提があり、成り立つのは1つだけです。
順位はしきい値が機能する程度に安定している。 崩れます。ばらつきはクエリごとに桁で違います。以下で実測しました。
同じ大きさの動きは、どの順位でも同じ意味を持つ。 崩れます。3位と6位の距離は、41位と44位の距離と、クリック数でも意味でも等価ではありません。
すべてのクエリが同じしきい値に値する。 崩れます。指名検索クエリと競争の激しいヘッドタームは、統計的に共通点がありません。
チェック頻度を上げれば情報が良くなる。 ある点を超えると崩れます。毎日チェックすると週次の7倍の読みが得られ、ほとんどのクエリセットでは同じシグナルの周りに7倍のノイズが得られます。
本記事の残りは、この4つをそれぞれ計測に置き換えます。
自社のクエリが実際にどう動くか
方法：自社の Search Console プロパティ、2026年9月12日を終点とする90日間、ディメンションは query と date、8,020行を、期間中30インプレッション以上あった106クエリに絞りました。クエリごとに日次平均順位の標準偏差と、自身の中央値から3順位以内にとどまった日の割合を計算しました。
指標 | 値 |
|---|---|
サンプルのクエリ数 | 106 |
日次順位の標準偏差の中央値 | 7.45 順位 |
標準偏差が2順位未満のクエリ | 106件中12件（11%） |
標準偏差が10以上のクエリ | 106件中40件（38%） |
そのクエリ自身の中央値から3順位以内だった日の中央値割合 | 59% |
同じサンプルから4つのクエリを取ると、同じサイトでもクエリごとにこれだけ挙動が違います。
クエリ | 中央値の順位 | 標準偏差 | 中央値から3以内の日 |
|---|---|---|---|
amazon echo keywords | 14.1 | 1.29 | 100% |
on page seo audit | 92.2 | 4.99 | 63% |
perplexity seo checker | 31.9 | 12.87 | 22% |
geo | 70.4 | 9.83 | 30% |
実務的な読み方：固定の3順位ルールが意味を持つほど安定しているクエリは、およそ10件に1件です。10件に4件は、10順位未満のしきい値では絶えず発火するほど動きます。
ほとんどのクエリは、既定のアラートしきい値が想定するよりはるかに大きく動きます。
調整ルール1：サイト単位ではなくクエリ単位でバンドを作る
サイト全体のしきい値は、互いに似ていない挙動の平均です。修正は、各クエリのバンドをそのクエリ自身の履歴から計算することです。Search Console の取得1回と数行の算術で済みます。
クエリごとに、全体の数字ではなくそのクエリ自身の分布を使います。
- Normal： そのクエリ自身の中央値から標準偏差1つ以内。
- Watch： 標準偏差1つから2つの間、またはクエリが自身の中間80%バンドを外れたとき。
- Investigate： 標準偏差2つを超え、かつ連続する2回目の実行で確認されたとき。
上のサンプルでは、これでアラート量が劇的に変わります。標準偏差1.29のクエリは、watchバンドに届くのに約3順位の動きが要ります。標準偏差12.87のクエリは約13順位必要で、何か実質的なことが起きるまでアラートはほとんど出ません。
これはアラートバンド設計ガイドが定期監視に使っているのと同じ論理を、アカウント単位ではなくクエリ単位に適用したものです。この記事を読んで1つだけ変えるなら、しきい値を定数からクエリ別の値に変えてください。
調整ルール2：表示回数の下限を設ける
順位は平均であり、3インプレッションの平均は測定ではありません。期間中およそ30インプレッションを下回ると、土台のサンプルが小さいせいで数字が勝手に動きます。
そこから2つの帰結が続き、どちらも実装は簡単です。
低インプレッションのクエリではアラートを出さない。 監視はしますが、順位はシグナルではなく文脈として扱います。例外は急にボリュームを得たクエリで、それはインプレッションの出来事であり、それ自体で知る価値があります。
すべての順位にインプレッションを添える。 インプレッションが安定したままの5順位下落と、インプレッションが60%失われて起きる5順位下落は意味が違います。後者はインデックスや適格性の問題に近く、前者は競合に近い。順位だけを報告するモニターはその区別を捨てており、それがこのトリアージ順序が捕まえるために存在する失敗モードです。
調整ルール3：アラート前にデバイスと地域を分ける
合成された順位は、デバイス別・地域別の結果の重み付き平均です。構成比が変われば、ページに何も起きていなくても平均が動きます。同じクエリでモバイルとデスクトップの差を最大11順位まで実測しているので、これは丸め誤差ではありません。検出しようとしているノイズと同じ桁です。
実装は地味で安価です。デバイス別に順位を取得し、両方を保存し、動きが起きたデバイスでアラートを出します。合成された数字を1つだけ追うなら、構成比の変化が推測ではなく見えるように、デバイス構成比を出力に書き出してください。クエリの形についてはデバイス分割の手順で扱っています。
5つの列が、アラートを出発点のある調査に変えます。
順位だけでなく監視すべきもの
順位は1つの列にすぎません。動きが人の注意に値するかは、他の4つが決めます。
インプレッション。 需要側です。ここが動くと、すべての順位の数字の意味が変わります。
SERP機能の状態。 そのクエリに AI Overview、動画ブロック、ローカルパックがあるかどうか。機能の変化は、ページに何も変わらなくても順位を動かします。
クリックカーブ上の位置。 一覧のどこにいるかだけでなく、機能に対してどこにいるか。AI Overview の下の1位は1位ではありません。機能の状態をきちんと追うなら、保存すべきフィールドはAI Overview トラッカーの構築で扱っています。
変更ログの記録。 自社のデプロイ、テンプレート変更、コンテンツ編集を同じタイムライン上に。私たちが調査した実際の下落のほとんどには、背後にコミットがありました。
この5つをクエリごと・日ごとに保存すれば、アラートは、警告に見える数字と、週を記憶から再構成しなければならない人ではなく、出発点のある調査になります。
コミット前に確認する頻度の計算
監視コストはキーワード数×チェック回数で増えるので、頻度は意欲ではなくクエリ数から決めます。
- 30の重要クエリを毎日チェックすると月900リクエスト。ほぼどのプランでも払えて、ほとんどのチームがここから始めるべきです。
- 200クエリを毎日チェックすると月6,000リクエストで、動きの激しいセットではアラートの大部分をノイズから生み出します。
- 同じ200クエリを週次にすると月およそ1,400リクエストで、実際の変化は1週間より長く持続するため、実質的な動きのほとんどを捉えます。
両方が必要な場合は、好みではなく賭け金で分けます。収益に直結する短いリストは毎日、それ以外は週次。自分で取得を組むなら、2ソースのトラッカーがリクエストの型と比較ルールを扱っています。
どんなモニターでも信頼する前のチェックリスト
5つの問い。どれか1つでも落とすモニターは、節約するより多くの注意を奪います。
- 生の結果を保存しているか、計算済みの順位だけか？ 後からページに何が載っていたかを問えないなら、アラートを説明できません。
- 地域とデバイスはクエリごとに固定され、記録されているか？ そうでなければ履歴が条件を混ぜ合わせます。
- しきい値はクエリ別か、アカウント全体の単一の数字か？ 単一の数字は既定値であり、調整ではありません。
- 障害と下落を区別しているか？ Google は障害履歴つきのステータスダッシュボードを公開しており、最初に確認するほうがどんな調査より安く済みます。
- 何が変わったかを教えるか、何かが変わったことだけを教えるか？ 後者のアラートはやることリストで、前者は判断です。
Auspia の見解：順位モニターは調整の良し悪しでしかありません。既定の3順位しきい値が間違っているのは、ツールが怠惰だからではなく、個々のクエリに当てはめた母集団平均だからです。自社のクエリを測り、それぞれの分布からバンドを設定すれば、残るアラートは実際に行動するものになります。
FAQ
Google 順位モニターが無視すべき正常な順位変動とは？ 万能の数字はなく、そこが要点です。私たちのサンプルでは、中央値のクエリが90日間で7.45順位動いた一方、10件に1件は2順位以内に収まりました。正しいしきい値は各クエリ自身の履歴から導かれるもので、通常は標準偏差1つです。
順位モニターはどのくらいの頻度で順位を確認すべき？ 通常のセットは週次、収益に直結する短いリストは毎日。大きなセットへの毎日チェックはコストを倍加させ、実質的な順位の動きは1日より長く持続するため、ほとんどノイズを拾います。
モニターが Search Console にない日次変動を示すのはなぜ？ 別の測定だからです。モニターは、ある時点・ある地域の実際の検索結果ページを1回スナップショットします。Search Console は日付範囲とデバイス構成にわたってインプレッションを平均します。どちらも間違っておらず、直接比べると、片方にしか存在しない下落を追いかけることになります。
順位があるキーワードをすべて監視すべき？ いいえ。測定できるだけのインプレッションがあるクエリを監視します。私たちのデータでは数千のうち106でした。インプレッション下限を下回るものは、個別アラートではなく、たとえば何クエリがそもそもランクしているかを数えるなど、グループとして追うほうが適しています。
モニターの調整に有料ツールは必要？ 不要です。query と date のディメンションがある Search Console のエクスポート1回で、クエリ別の中央値と標準偏差を計算でき、調整に必要なのはそれだけです。有料ツールが加えるのは利便性とベンダー横断データであり、統計ではありません。
著者：Miles Carter、Auspia で8,000クエリのランキングデータ分析を担当。ランキング測定、アラート調整、そしてデータの変化と検索結果の変化をどう見分けるかを書いています。
