Search Consoleを見て直すページを決める月次手順

Search Consoleの月次確認では、検索条件をそろえて二つの期間を比べます。変化が集中する1URLを選んだら、今月は変更を見送るか、修正の仮説を一つだけ次の作業へ渡すかを決めます。

ただし、Search Consoleの数値だけでは変化の原因を特定できません。数値が下がったページをすぐに直さず、比較できるデータか、1ページの編集で扱える変化かを先に確かめます。

本記事では、確認対象を1URLと1クエリ群へ絞り、変更を見送るかどうかを判断します。変更する場合は1変更箇所と主指標・補助指標を決めます。これらはGoogleの公式分類や利用要件ではなく、AdRegionの実務上の判断手順です。

比較する期間と検索条件をそろえる

条件が違う二つの期間を比べても、ページ自体の変化と利用者構成の違いを分けられません。レビュー日とデータ取得日を記録してから、何と何を比べるのかを決めます。

期間は、同じ長さと曜日構成を基本にします。月単位で管理しているなら暦月同士を比べても構いません。季節性が強い事業では前年同時期を選ぶ方が判断しやすいこともあります。大切なのは、期間を選んだ理由を後から説明できることです。

検索タイプ、国、デバイスは両期間でそろえます。検索結果の形式が結論へ影響しそうなページでは、「検索での見え方」も同じ条件にします。

Search Consoleでは期間やページ、クエリでデータを絞れます。デバイス、国、「検索での見え方」も絞り込みに使えます。一度に比較できるのは二つの期間、二つの検索タイプ、または一つのディメンションに含まれる二つの値です。数値を読む前に適用中の条件を確かめ、詳しい比較方法はGoogleの高度なフィルタリングと比較で確認します。

最新のデータは完全なデータがそろったとは限りません。パフォーマンス レポートのデータについてでは、最新のデータが暫定値となり、収集中に変わる場合があると説明されています。本記事の月次手順では暫定データを含めず、グラフの点線表示がなくなってから同じ条件で取り直します。これはGoogleの利用要件ではなく、比較条件をそろえるための実務上の扱いです。

サイト全体に変化が広がる場合は原因の切り分けを優先する

1URLを探す前に、変化が一部のページに限られるのか、サイト全体に広がっているのかを確認します。多くのページやクエリ群が同じ時期に動いているなら、個別ページの内容だけが原因とは考えにくいためです。

最初にサイト全体のグラフを見て、変化が始まった時期を確かめます。次にページ単位へ分け、同じ傾向が広く出ていないかを見ます。複数のデバイスや国でも同時に変わっている場合は、1ページを選ぶ前にサイト側や検索需要側の説明を検討します。

Googleの検索トラフィック減少のデバッグ手順では、技術的な問題が変化の候補として挙げられています。セキュリティやスパムの問題、季節性による需要変化も別に切り分けます。ページのインデックス登録やクロール統計に異常がある場合は、本文編集へ進みません。手動による対策やセキュリティ問題が疑われるときも、該当レポートの確認を優先します。

サイト障害やURL変更、大きな公開作業の直後は、その影響を先に切り分けます。Search Console側のデータ異常も確認対象です。こうしたサイト全体の問題が残る間は、1ページを改稿しても結果を解釈できません。インデックス登録が論点なら、先にサイトマップとインデックス登録の確認手順へ進みます。

四つの指標から次に確認する場所を絞る

Search Consoleの4指標は、検索結果で起きたことを別の角度から示します。指標の関係を見ると次に確認する場所は絞れますが、原因までは特定できません。

クリック数は、Google検索の検索結果からサイトへのリンクがクリックされた回数です。表示回数は、サイトへのリンクがGoogle検索で閲覧された、または閲覧された可能性がある回数です。通常は現在の検索結果ページにリンクがあれば、その位置までスクロールされなくても数えられます。ただし、カルーセルや展開領域などでは、スクロールや展開でリンクが見える状態になってから数えられる場合があります。

CTRはクリック数を表示回数で割った値で、平均掲載順位はグラフと表で数え方が異なります。プロパティ単位のグラフでは、そのプロパティが表示されるたびに最上位の検索結果の掲載順位を記録し、その値を平均します。表では、行に表示されたURLまたはグループの平均掲載順位になります。数え方は検索結果の形式によっても変わるため、GoogleのSearch Consoleの指標定義を基準にします。

クリック数が減ったという事実だけでは、何を直すべきかは分かりません。表示機会が減ったのか、同じ表示機会から選ばれにくくなったのかで、次に確認する対象が変わります。表示回数が減っていても、需要が失われたとは断定できません。掲載順位や対象となったクエリの構成が変わった可能性も残ります。

CTRの低下からタイトルを候補にすることはできます。ただし、デバイス構成や検索結果の見え方が変わっただけかもしれません。平均掲載順位は複数の表示をまとめた値なので、低下してもアルゴリズム変更が原因とは断定できません。4指標は診断結果ではなく、次に分けて見る条件を決めるために使います。

数値が悪いページより変化が集中するページを選ぶ

今月確認する候補は、CTRが最も低いページや平均掲載順位が最も悪いページとは限りません。普段から同じ水準にあるページより、比較期間の間で変化し、サイト全体の差に影響しているページを先に見ます。

条件を固定したままページ単位で比較し、クリック数や表示回数の変化量がどのURLへ集まっているかを確認します。そのうえで、ページが事業サイトで担う役割を確かめます。変化が大きくても、ページの役割と狙う検索行動が合っていなければ、編集の優先度は決められません。

変化率だけで候補を選ぶと、普段の表示が少ないページが上位に出ることがあります。一律の最低表示回数や変化率は設けず、普段のデータ量に照らして今回の差を判断できるかを見ます。判断できる量がなければ期間を延ばします。それでも傾向が定まらない場合は、今月の変更を見送ります。

ここで決めるのは、調べる1URLです。まだ直すページと確定したわけではありません。選んだ理由とページの役割を残してから、そのURLの内側へ進みます。

一つのURLを選んでから変化が集中するクエリ群を探す

選んだURLにページフィルタをかけ、どのクエリ群で変化したのかを確認します。単独の検索語句を追うのではなく、同じ検索意図とページの役割で説明できる語句を一つの群として扱います。

そのクエリ群について二期間を比べ、デバイスや国で変化が偏っていないかを見ます。検索での見え方が関係するページなら、その条件でも分けます。特定の条件にだけ変化が集中すれば、ページ全体の平均値より狭い仮説を立てられます。複数のクエリ群が別々の動きをしているなら、URL全体の数値を一つの原因で説明しない方がよいです。

クエリ表は需要の全件一覧ではありません。Googleのディメンションとデータのグループ化によると、プライバシー保護のため匿名化されるクエリがあります。内部的な制限により、表へ出ない行もあります。

クエリフィルタをかけていない場合、匿名化されたクエリはグラフの合計に含まれます。そのため、グラフの合計とクエリ表に見える行の合計は一致しないことがあります。見えているクエリから群を作ることはできますが、表にない語句を需要なしと断定してはいけません。

変化が一つのクエリ群や条件へ集まらないなら、修正の仮説はまだ広すぎます。期間を延ばすか、次の月次確認まで観測を続けます。

GA4では検索後の行動を別の証拠として確認する

Search Consoleで対象を絞った後は、GA4でそのランディングページへ到着した後の行動を見ます。両者は同じ出来事を別画面で数えているわけではありません。

Search ConsoleはGoogle検索結果からサイトへ到達するまでを主に観測します。GA4は到着後のページ閲覧や行動を観測します。GoogleもSearch ConsoleとGoogleアナリティクスのデータの使い分けで、クリック数とセッション数は算出方法が異なり、完全には一致しないと説明しています。

そのため、Search Consoleのクリック数とGA4のセッション数を同じ値として扱いません。問い合わせ数も別の値です。

GA4では使用したデータ元を記録し、対象ランディングページと集客条件を固定します。問い合わせを見るなら、イベント名だけでなく、何をもって問い合わせと数えるのかも確認します。イベント定義や計測状態が不明なままでは、問い合わせが減ったという判断自体が成り立ちません。

GA4の役割は、選んだページが検索後の行動にどう関わっているかを別の証拠として示すことです。Search Consoleとの差を埋めるために数値を合わせるのではなく、それぞれの観測事実を分けて記録します。

変更を見送る理由によって再確認の条件は変わる

見送りの理由が違えば、再確認できる状態も変わります。何がそろえば判断を再開できるかを残しておくと、翌月に同じ迷いを繰り返さずに済みます。

比較条件が一致しない場合や暫定データが含まれる場合は、その月の判断を止めます。再開条件は、同じ条件で暫定表示のないデータを取り直せることです。データ量が足りない場合は比較期間を延ばし、変化が一時的な揺れと区別できるまで待ちます。全サイト共通の最低表示回数は置きません。

直近の変更について観測期間が終わっていない場合は、別の変更を重ねません。再開日は、先に決めた観測期間が終わり、暫定表示のないデータを取得できる日以降にします。期間の長さは一律にせず、変更内容と普段のデータ量に合わせて記録します。

サイト障害、手動による対策、セキュリティ問題が残る場合は変更を見送ります。クロールやインデックス登録の問題は、ページ編集より先に扱います。季節性や外部需要の変化を除けない場合は、比較期間の選び方を見直します。再開するのは、先行する問題が解消し、その後の安定した期間を同じ条件で比較できるようになってからです。

観測事実を説明できる仮説が複数残り、一つの変更箇所へ絞れない場合も急いで直しません。クエリ群やデバイスなどの条件を追加して、どこに変化が集中するかを再確認します。それでも分けられなければ、再確認日だけを決めて変更を見送ります。

変更する場合は修正の仮説を一つに絞る

変更へ進めるのは、1URLと1クエリ群について、一つの変更箇所まで説明できるときだけです。複数箇所を同時に変えると、再確認したときにどの修正が妥当だったのか判断できません。

この修正の見立てを、シートでは「編集仮説」として残します。対象URL、対象クエリ群、一つの変更箇所を明示します。

さらに、変化を観測する主指標を一つ選びます。別の重要な状態を損なっていないかを見るため、悪化させたくない補助指標も一つ決めます。指標が動いても原因の証明にはならないため、別の説明候補は残したままにします。

実施担当と期限を決め、変更後の観測期間と再確認日も先に決めます。観測期間の途中では、同じ箇所へ追加変更を重ねません。観測条件まで決めておけば、修正後も同じ前提で判断できます。月次確認の結果は、この状態で次の作業へ渡します。

月次確認シートに残す比較条件と判断の根拠

確認結果は、画面のスクリーンショットだけでなく、比較条件と判断を同じシートへ残します。空欄を推測で埋めず、確認できない項目が結論を左右するなら判定を変更見送りにします。

判定欄には「変更見送り」か「編集仮説を次工程へ渡す」のどちらか一つを記録します。編集仮説は、何を直してどの変化を確かめるかを一文で示したものです。「次工程」には、判定後に行う確認や修正作業を書きます。

Search Console月次確認シート

レビュー日:
担当:
Search Consoleプロパティ:
データ取得日:

比較期間A:
比較期間B:
比較期間を選んだ理由:
暫定データが含まれていないことの確認:

検索タイプ:
国:
デバイス:
検索での見え方:
その他の固定条件:

候補URLとページの役割:
選んだ1URL:
このURLを選んだ理由:

クリック数（期間A / 期間B / 変化）:
表示回数（期間A / 期間B / 変化）:
CTR（期間A / 期間B / 変化）:
平均掲載順位（期間A / 期間B / 変化）:

選んだ1クエリ群:
クエリ群のまとめ方:
変化が集中した条件:
表に出ないクエリを含む制約の扱い:

GA4側のデータ元:
GA4の対象ランディングページ:
GA4の集客条件:
確認するイベント名:
イベント定義:
計測状態:

直近のページ変更:
サイト障害・技術変更:
季節性・需要変化:

観測事実:
別の説明候補:

判定（変更見送り / 編集仮説を次工程へ渡す）:
見送り理由:
再開条件:

一つの編集仮説:
対象URL:
対象クエリ群:
一つの変更箇所:
主指標:
悪化させたくない補助指標:
実施担当:
担当期限:
観測期間:
再確認日:
再確認時の判断条件:
次工程:

判定後に進む作業は問題の種類で分かれる

月次確認の後は、見つかった問題に応じて次の作業を分けます。異なる問題を同じ改稿へ混ぜないためです。本文と検索意図のずれを直すなら既存記事を更新する確認手順へ進みます。タイトルまたはmeta descriptionだけを検討するならタイトルとmeta descriptionの見直し手順が次の作業です。

クロールやインデックス登録が先に解決すべき問題なら、ページ編集の仮説は作らずサイトマップとインデックス登録の確認手順へ戻ります。変更を見送った場合は、シートに書いた再確認日まで観測を続けます。次の月次確認は、前回固定した条件と再開条件を確かめるところから始められます。