SEOダッシュボードには、検索結果での動き、訪問後の成果、記事の変更履歴とSEO上の問題をまとめましょう。数値を並べるだけでなく、クリック数や流入が下がったURLと次に行う作業まで絞れる画面にしておくのがおすすめです。
Search Console、GA4、記事管理表を行き来していると、数値の変化に気づいても、どの記事を直すべきか決めるまでに時間がかかります。
データを一か所に集めるだけでは、改善するURLや次の施策は決まりません。
すぐに可視化したい場合はLooker Studio、少人数で自動集計したい場合はGoogle Apps Script（GAS）がおすすめです。独自画面や社内データも扱いたい場合はAPIを使い、CodexやClaude Codeに設計・実装・テストを補助してもらえます。
この記事では、SEOダッシュボードに載せる指標、4つの画面構成、確認する頻度、Looker Studio・GAS・APIを使った作り方を解説しています。「数字は見ているものの、改善するURLや次の施策を決められない」と悩んでいる方は、ぜひ参考にしてみてください。
SEOダッシュボードには、①検索結果での動き、②訪問後の成果、③記事の変更履歴とSEO上の問題を載せましょう。
この3種類を同じURLと期間で見比べると、落ち込みを見つけた後に原因を調べやすくなります。見ても次の対応が決まらないグラフは、無理に追加する必要はありません。
Search Consoleから取り込む基本指標は、表示回数、クリック数、CTR、平均掲載順位の4つです。
表示回数が減っていれば検索結果に出る機会が減り、表示回数が保たれたままCTRが落ちていれば、検索結果で選ばれる割合が下がっています。4指標を同じ期間で比べることで、どの段階に変化があったのかを切り分けられます。
順位だけでは、検索需要が減ったのか、検索結果で選ばれにくくなったのかを区別できません。表示回数とCTRも必ず一緒に見ましょう。
GA4では、オーガニック検索のセッション数、エンゲージメント率、キーイベント数を見ます。キーイベントには、問い合わせや購入など、事業上の成果として追っている行動を設定しましょう。
ランディングページ別に集計すると、検索から訪れた人がページ内で行動したか、問い合わせや購入につながったかをURL単位で比べられます。
Search Consoleのクリック数とGA4のセッション数は、計測する指標と仕組みが異なります。そのため、同じ期間を指定しても数値は一致しません。Google Search Centralの公式ドキュメントでも、両者のデータは完全には一致しないと説明されています。
二つの数値を合わせようとせず、同じ期間で増減の傾向を比べましょう。
URLごとに公開日、更新日、変更内容を残しましょう。検索指標と更新履歴を同じ期間で見れば、記事を変える前後で数値がどう動いたかを追えます。
SEO上の問題が見つかった場合は、変更履歴とは別の列に記録しておくのがおすすめです。検索データとGA4だけでは分からない改善理由を、後から確かめられます。
たとえば、タイトルを変えた後にCTRが下がっていれば、変更内容を見直す候補になります。一方、更新していない複数のURLが同じ時期に下がった場合は、個別記事より検索需要やサイト全体の問題から調べましょう。
表示回数、クリック数、CTR、平均掲載順位などの意味や効果測定ツールの選び方は、SEO効果測定ツールの記事で詳しく解説しています。
SEOダッシュボードは、「全体」「検索」「URL別」「改善候補」の4画面に分けましょう。
一つの画面にグラフや表を詰め込むと、異常を見つける数字と原因を調べる情報が混ざります。4画面に分ければ、サイト全体の落ち込みを起点に、クエリ、URL、次の作業へ順番に進めます。
最初の画面には、サイト全体のクリック数、表示回数、オーガニック検索セッション、キーイベント数を載せましょう。それぞれに前期間比を付けると、詳しく調べるべき落ち込みを見つけられます。
クエリやURLを並べた長い表は、この画面には不要です。目立った落ち込みがなければ、その日の確認はここで終えて構いません。原因を調べるときだけ、検索画面へ進みます。
サイト全体のクリック数や表示回数が落ちたら、Search Consoleのクエリ別データを開きましょう。クリック数や表示回数が減ったクエリ、CTRが低いクエリ、順位が動いたクエリが原因を探る手掛かりになります。
クエリ、URL、デバイス、国、期間で絞れるようにしておくのがおすすめです。モバイルだけで落ちているのか、特定のURLに集中しているのかを切り分けやすくなります。
URL別の画面では、Search ConsoleとGA4の指標を同じURL・期間で比べましょう。公開日、更新日、変更内容も添えると、記事を変えた時期と数値が動いた時期を照らし合わせられます。
Search ConsoleとGA4の数値は、足し合わせたり同じ指標として扱ったりしないでください。検索結果での動きと訪問後の成果を分けたまま、同じURL・期間で傾向を比べます。
最後の画面には、改善するURL、候補にした理由、次に行う作業を並べましょう。理由には「表示回数は多いがCTRが低い」「順位とクリック数が下がった」「SEO上の問題が見つかった」など、実際に見つけた状態を書きます。
リライト、追加調査、内部リンクの追加など、次の作業まで決めておくと担当者へそのまま渡せます。候補に加えた時点の数値も残しておけば、後から優先した理由を確かめられます。
SEOダッシュボードで行う作業は、日次・週次・月次に分けましょう。毎日は大きな異常だけ、毎週は改善するURL、毎月は実施した施策の結果を見ます。
検索順位やアクセス数は日々動きます。毎日すべてを分析すると、小さな揺れまで記事を直す理由にしてしまうため、詳しい分析は週次と月次にまとめるのがおすすめです。
毎日は、サイト全体の急落とデータ欠損だけを見ましょう。どちらかが起きていたら、その日のうちに計測障害かサイト全体の問題かを切り分けてください。個別記事を直すかどうかは、週次で判断します。
一つのキーワードが一日下がっただけでタイトルや本文を変えると、その変更の効果を切り分けられません。記事を変えるのは、複数日の傾向を見て、検索需要、他ページ、デバイスの影響を調べた後です。
週次では、前期間よりクリック数や表示回数が落ちたクエリを探しましょう。対応するURLが分かったら、GA4の指標と更新履歴を同じURL・期間で比べます。
改善するURLを選んだら、追加調査、リライト、内部リンクの追加のうち、どの作業へ進むかも決めておくのがおすすめです。
月次では、その月に変更したURLと、施策前後の数値を振り返りましょう。伸びなかった施策も記録に残せば、同じ仮説を何度も試さずに済みます。
SEOダッシュボードは継続的な確認と改善に使い、月次レポートには関係者へ共有する結果を抜き出します。実施した施策、結果、翌月に行うことの3点があれば、月次の共有に必要な流れを作れます。
順位、インデックス、内部リンク、流入のうち、どこまで自動で集めるか迷った場合は、SEO自動計測ツールの選び方も参考にしてみてください。
検索指標を毎週手作業で集計していると、記事を直す時間が減ります。inSiteでは、Search Consoleのクリック・表示回数・CTR・順位を前期間と比べられます。
数値が動いたら、最初に「どの指標が」「いつ」「どのURLで」変わったのかを確かめましょう。原因を決めつけず、検索結果での動き、訪問後の成果、記事の変更日から候補を絞ります。
見つけた変化、考えられる原因、次に見る場所を対応させておくと、調査の途中で迷いにくくなります。
| 見つけた変化 | まず疑うこと | 次に見る場所 |
|---|---|---|
| 表示回数と順位が低下 | 検索需要や掲載状況が変化 | クエリ、ページ、デバイス、他ページの動き |
| 表示回数はあるがCTRが低い | 検索結果で選ばれていない | 検索意図、タイトル、説明、SERPの構成 |
| クリック数は保たれているがキーイベント数が少ない | 流入後の内容や導線に課題 | ランディングページ、読後行動、CTA |
| 記事の更新後に数値が動いた | 施策が影響した可能性 | 変更内容、実施日、観測期間、他要因 |
表示回数と順位が同時に下がったら、対象URLが検索結果に表示されたクエリの内訳を開きましょう。表示回数が減ったクエリと順位が下がったクエリを分けると、どの指標から調べるべきかが分かります。
複数のクエリで同じ傾向が出ている場合は、季節性、検索結果の変化、別URLとの競合を順番に調べるのがおすすめです。
複数ページが同じ時期に下がっているなら、個別ページの書き換えを急ぐ段階ではありません。原因を調べる順番は、SEO順位変動の原因と対策で詳しく解説しています。
表示回数と順位が保たれているのにCTRが低い場合は、検索結果で選ばれにくくなっている可能性があります。まず、検索クエリが求める答えとページの内容が合っているかを確かめましょう。
内容が合っていれば、タイトルと説明文だけでページの答えが伝わるかを読み直します。
タイトルや説明文は、ページで実際に答えている内容とそろえるのが原則です。変更日と変更内容を残し、変更前後を同じ長さの期間で比べましょう。
検索クリック数が保たれているのにキーイベント数が少ない場合は、訪問後の内容と導線を見直しましょう。答えが冒頭にない、必要な情報へのリンクが見つからない、読後の行動が分からないといった問題が候補になります。
全面改稿を始める前に、どの段階で離脱しているか、設定したキーイベントがページの役割に合っているかを確かめてください。直す場所が決まった後の進め方は、SEOリライトの正しいやり方で解説しています。
記事を更新した後に数値が動いても、その変更が原因とは限りません。更新日と変更箇所を記録し、同じ時期に検索需要や他のURLも動いていないかを調べましょう。結果を見る日も施策ごとに決めておくのがおすすめです。
すぐに可視化したい場合はLooker Studio、少人数で自動集計したい場合はGAS、独自画面や社内データも扱いたい場合はAPIがおすすめです。
選ぶ前に、利用人数、更新頻度、必要なカスタマイズ、保守に使える時間を整理しましょう。作った後に誰が接続や集計を直すのかまで決めておくと、構築方法を選びやすくなります。
コードを書かずにSearch ConsoleとGA4を可視化したい場合は、Looker Studioがおすすめです。Googleの公式ガイドに沿って二つのデータソースを接続し、前節で決めた画面ごとにグラフや表を配置できます。
グラフを比べるときは、期間、対象URLの範囲、デバイス条件をそろえましょう。Search Consoleだけをモバイルに絞り、GA4を全端末のままにすると、同じ条件で増減を比べられません。
ページ分類や担当者などの社内データを結合する場合は、URLや日付の表記に加えて、URL単位・日付単位といった集計の細かさもそろえてください。Google Search Centralの例では、Search ConsoleへURL情報やクエリクラスタを加える方法が紹介されています。
Looker Studioに接続するSEOデータに迷う場合は、SEOツールの選び方を参照できます。
少人数で運用する場合は、Google Sheetsをデータの保存先と閲覧場所にして、GASで更新する方法がおすすめです。Apps ScriptはSheetsの読み書きやグラフ作成に対応しています。時間主導トリガーを設定すれば、定期的に自動更新できます。
Google Sheetsも、前節の4画面に合わせてシートを分けましょう。推移はグラフ、URLやクエリの絞り込みはフィルタで扱えます。
最初はSearch Consoleのクリック数、表示回数、CTR、順位だけを取り込むのがおすすめです。項目を絞っておくと、集計がずれたときに原因となる処理を探しやすくなります。
claspを使うと、Apps Scriptをローカルで編集し、変更をGitへ残せます。Apps Scriptへの反映コマンドはclasp pushです。ローカルに保存したコードの作成や修正は、CodexやClaude Codeにも依頼できます。
claspを使う前に、Node.js 22以上を用意し、Google Apps Script APIを有効にしてください。準備ができたら、claspへログインしてプロジェクトを作成しましょう。
npm install -g @google/clasp
clasp login
clasp create-script --title "SEO Dashboard" --type sheets
clasp push
claspのREADMEには、Googleの正式サポート製品ではないと明記されています。
認証情報はGitへ追加しないでください。実装前に、Apps Scriptと接続先APIの実行回数や処理時間の上限も確かめましょう。
社内DB、記事管理、施策履歴まで扱いたい場合は、APIで取得したデータを自社のデータベースへ保存し、Webアプリで表示する方法が向いています。Search Console APIからは検索パフォーマンスを取得できます。Google Analytics Data APIは、GA4のデータを独自ダッシュボードや定期レポートへ取り込むAPIです。
APIでは、取得に失敗した日と実際にアクセスが0件だった日を区別してください。失敗した日のデータを0件として保存すると、サイトの異常だと誤解するおそれがあります。
取得結果とエラーを別々に保存し、画面には最終更新日時も表示しましょう。処理全体は、取得、保存、集計、表示の4段階に分けるとテストしやすくなります。
実装を始める前に、OAuthやサービスアカウントの権限、APIの上限、ログの保存先を決めておくのがおすすめです。
CodexやClaude Codeには、GASやWebアプリのコード作成、APIクライアントの実装、テストを依頼できます。MCPサーバーを接続すれば、開発中に外部ツールやデータを参照・操作する作業も任せられます。
開発環境でMCPへ接続しても、SEOダッシュボード本体がMCP経由で動くわけではありません。CodexとClaude Codeのどちらを使って実装しても、本番環境にはデータ取得用のAPIと認証、表示画面、指標の定義が別途必要です。
依頼するときは、取得する指標、比較期間、更新頻度、エラー時の扱い、閲覧権限を仕様として渡しましょう。Search ConsoleやGA4をMCPで扱う設定は、GSC MCPの設定方法とGA4 MCPの設定方法で解説しています。
会社固有のデータまで載せたい場合は自作、接続や集計の保守を減らしたい場合はSEO管理ツールがおすすめです。
自由に作れる範囲だけでなく、更新や障害対応に使える時間も含めて選びましょう。以下のinSite欄には、実際に確認できた機能だけを掲載しています。
| 比較項目 | 自作 | inSite |
|---|---|---|
| 画面設計 | 自社の指標に合わせて自由に作れる | 検索指標、記事情報、改善候補を製品内で扱える |
| データ接続 | 接続・認証・フィルタ・結合を自分で設定する | Search Consoleと連携し、記事情報を取得する |
| 保守 | コードを保守し、接続切れを直し、重複集計を防ぐ | 変更された記事情報が自動で更新される |
| 改善候補 | 条件を設計して自分で抽出する | SEO上の問題を継続的に検出する |
会社固有のKPIや社内データまで一つの画面で扱いたい場合は、自作がおすすめです。自社の計算式や権限に合わせて、表示内容を細かく変えられます。
ただし、CodexやClaude Codeに実装を任せても、運用中の保守は残ります。フィルタやデータ結合の変更、権限管理に加え、接続が切れたときの復旧も必要です。
データの取得元、計算式、認証方法を文書に残しておきましょう。担当者が変わった後も、どこを直せばよいか分かります。
検索指標に加えて、記事の変更やSEO上の問題まで追いたい場合は、SEO管理ツールがおすすめです。
inSiteは、記事のタイトル、見出し、公開日、文字数、リンク情報を取得し、変更があった記事情報を自動で更新します。SEO上の問題も継続的に検出するため、数値と記事の状態から改善候補を探せます。
SEO施策や記事の変更履歴まで含めた管理の考え方は、SEO管理ツールの記事で詳しく解説しています。
GSCやGA4との接続が切れるたびに復旧している場合や、記事情報とSEO上の問題を別々の表で照らし合わせている場合は、専用ツールも比較してみましょう。
まずは、自社で追う指標と、数値が動いたときに行う作業を決めましょう。毎日の異常検知、毎週の改善候補選び、毎月の施策評価まで決めておくと、数字を見るだけで終わりません。
構築方法は、導入の速さ、利用人数、独自要件、保守に使える時間から選ぶのがおすすめです。運用を始めた後も、使わないグラフを外しながら、自社の改善手順に合わせて整えていきましょう。
