Search Console で表示回数が多いのに CTR が低いページを見ると、まず title や description を直したくなります。ただ、SaaS サイトではホーム、help、API、contact がそれぞれ別の仕事を持っています。CTR を同じ KPI として並べるだけでは、どのページを登録、自己解決、実装、問い合わせのどれにつなげるべきかが見えません。
この記事では、既存の ページ役割でCTRを診断する記事 や、ホーム・API・contact の個別改善記事とは別に、ページ役割KPI の設計に絞ります。Search Console の CTR、クリック後の次アクション、事業上の転換 KPI を分け、週次で見直せる表に落とす手順です。
まず結論: CTRは入口KPI、次アクションと転換は別に設計する
- Search Console の CTR は、検索結果でクリックされたかを見る入口 KPI として扱う
- ホーム、help、API、contact は、同じ CTR でも期待する次アクションが違う
- KPI 表には、CTR、次アクション、転換 KPI、判断条件、担当者を分けて書く
- 低 CTR ページの優先順位は、表示回数だけでなく役割と転換距離で決める
- 改善後は 7-14 日単位で、クエリ内容、CTR、次アクション、転換の順に読む
- 競合の title、description、CTA 変化も見ると、自社の KPI 仮説を直しやすい
Google Search Console の公式ヘルプでは、CTR はクリック数を表示回数で割った指標として説明されています（Search Console のクリック、表示、掲載順位の説明）。この数字は検索結果での反応を見るには便利ですが、登録、問い合わせ、API 利用の質までは直接示しません。ページ役割KPIでは、Search Console KPI とサイト内 KPI を分けて読むことが前提です。
なぜCTRだけでは改善判断がぶれるのか
CTR は「検索結果でクリックされたか」を見る指標です。SaaS のページ改善では、その先に別の判断が必要になります。
| ページ | CTRだけで見たときの誤読 | 追加で見るべきこと |
|---|---|---|
| ホーム | クリックが増えたので改善済みと見る | /register 遷移、無料登録、初回ジョブ作成 |
| help | 操作記事のCTRが高いので良いページと見る | 関連 help 回遊、register CTA、初回設定への移動 |
| API | 開発者流入が増えたので目的達成と見る | API キー作成、認証セクション閲覧、技術相談の質 |
| contact | 問い合わせページのクリック増を成果と見る | フォーム完了、相談種別、不要な問い合わせの増減 |
たとえば contact の CTR が上がっても、一般的な使い方質問だけが増えるなら改善とは言いにくいです。逆に API リファレンスは CTR が少し低くても、認証、Jobs、Reports を確認した開発者が API キー作成へ進むなら、次アクションの質は高いと判断できます。
手順1: URLを4つの役割に分ける
最初に Search Console のページ別データを見ながら、対象 URL を役割で分けます。ここでは表示回数が多い順に並べるだけではなく、「そのページが受けるべき検索者」と「ページ内で起こしたい行動」を書きます。
| 役割 | 受ける検索者 | ページの仕事 | 送ってよい先 |
|---|---|---|---|
| ホーム | ブランド、カテゴリ、課題名で探す人 | 何の SaaS かを判断し、無料登録へ進める | help、blog、contact |
| help | 作業手順や設定を確認したい人 | 目の前の疑問を解き、次の作業へ送る | 関連 help、blog、register |
| API | 認証、エンドポイント、連携を確認する開発者 | 実装順を示し、API 利用の準備へ送る | API キー、webhook help、contact |
| contact | 導入、請求、セキュリティ、契約を相談したい人 | 人が対応すべき相談を受ける | register、help、関連資料 |
この分類は、既存の 高順位・低CTRページをページ種別で直す手順 と合わせて使えます。違いは、ここでは改善文言より先に KPI を決める点です。先に KPI を決めると、title を強くしたあとに「何を見れば成功か」が曖昧になりにくいです。
関連する help ページは、ダッシュボードの機能と基本設定、Seed URL の使い方と活用例、API リファレンス のように、役割ごとの受け皿として置きます。
手順2: 役割別にCTR・次アクション・転換KPIを分ける
次に、ページごとの KPI 表を作ります。1 行に CTR、次アクション、転換 KPI を混ぜず、別の列にします。
| 役割 | CTR KPI | 次アクション KPI | 転換 KPI |
|---|---|---|---|
| ホーム | ブランド以外のカテゴリ・課題クエリのCTR | /register クリック、help / blog への文脈リンククリック |
無料登録、初回ジョブ作成 |
| help | 手順系クエリのCTR、ページ別CTR | 関連 help クリック、register CTA、blog への移動 | help 経由登録、登録後の初回設定完了 |
| API | API、認証、エンドポイント系クエリのCTR | API キー画面、認証セクション、Webhook help への移動 | API キー作成、技術相談の適格率 |
| contact | 導入相談、請求、セキュリティ系クエリのCTR | フォーム開始、相談種別選択、register 分岐 | フォーム完了、商談化、不要問い合わせの減少 |
ここでのポイントは、CTR 改善 KPI を「転換 KPI の代理」にしないことです。CTR が上がっても登録や相談の質が落ちることはあります。反対に、CTR が横ばいでも次アクションのクリック率が上がれば、ページ内の役割は改善している可能性があります。
手順3: KPIごとにイベント名と判断条件を書く
KPI 表は、数字の名前だけでは運用できません。実際に見るイベント名、判断条件、担当者まで書くと、週次レビューで迷いにくくなります。
| 役割 | 見るイベント例 | 判断条件の例 | 主担当 |
|---|---|---|---|
| ホーム | register_cta_click, homepage_help_link_click |
CTR 上昇後に register クリックが落ちていないか | マーケティング |
| help | help_related_link_click, help_register_click |
読了後に関連 help か register へ進んでいるか | コンテンツ / CS |
| API | api_key_page_view, api_docs_contact_click |
API ページ閲覧後に技術相談が増えすぎていないか | DevRel / プロダクト |
| contact | contact_form_start, contact_form_submit, contact_register_click |
フォーム完了率と相談種別が想定範囲にあるか | Sales / CS |
イベント名は実装環境に合わせて変えて構いません。大事なのは、Search Console の CTR と同じ画面で無理に解決しようとしないことです。Search Console ではページとクエリを見る。サイト内分析では次アクションと転換を見る。この分担にすると、改善案の議論が短くなります。
手順4: 高表示・低CTRページの優先順位を決める
表示回数が多いページから直すのは自然ですが、それだけでは contact や API のような転換に近いページを見落とします。次の順番で優先順位を決めると扱いやすいです。
- Search Console で表示回数が多く、平均掲載順位が比較的高い URL を抽出する
- URL をホーム、help、API、contact に分ける
- 各 URL のクエリを、役割に合うものと合わないものに分ける
- CTR が低い理由を、検索結果の約束、ページ冒頭、内部リンク、CTA に分ける
- そのページの次アクション KPI と転換 KPI が計測できるか確認する
優先度は、次のように読みます。
| 状態 | 優先度 | 先に見ること |
|---|---|---|
| 表示回数が多く、役割に合うクエリでCTRが低い | 高 | title、description、導入文 |
| CTRは低いが、次アクションが強い | 中 | 検索結果の約束を少し具体化する |
| CTRは上がったが、転換が弱い | 高 | CTA、ファーストビュー、内部リンク |
| 役割に合わないクエリで表示されている | 中 | ページ分割、内部リンク、見出し整理 |
| 表示回数が少なく、転換にも遠い | 低 | まとめて次回レビューへ回す |
ホームは表示回数が大きいため目立ちます。一方で contact は件数が少なくても、導入相談やセキュリティレビューに近いページです。ページ役割KPIでは、表示回数と転換距離を両方見ます。
手順5: 週次レビュー用の1枚表にする
最後に、週次レビューで使う表に落とします。毎週すべてのページを細かく見る必要はありません。変更した URL と、表示回数が増え始めた URL に絞ります。
| URL / 役割 | Search Consoleで見ること | 次アクション | 転換 | 今週の判断 |
|---|---|---|---|---|
/ja / ホーム |
ブランド以外クエリの表示回数、CTR | /register クリック、help 回遊 |
無料登録、初回ジョブ | CTR が低ければ description に用途と初回行動を足す |
/ja/help/seed-url / help |
Seed URL、情報源設定系クエリ | 関連 help、register CTA | 初回ジョブ設定 | CTA を「監視対象を決めて試す」に寄せる |
/ja/help/api-reference / API |
API、認証、Jobs 系クエリ | API キー画面、Webhook help | API キー作成、技術相談 | 認証と Jobs を title / 導入文で先に出す |
/contact / contact |
導入、請求、セキュリティ系クエリ | フォーム開始、register 分岐 | 適格問い合わせ | 相談種別と自己解決導線を分ける |
この表を作ると、改善作業が「CTR を上げる」だけで終わりにくくなります。たとえば help ページなら、CTR よりも関連 help への移動や register CTA の文脈が大事な週もあります。API ページなら、技術相談が増えすぎたときに、リファレンス内の説明順や問い合わせ前のリンクを見直します。
失敗しやすいポイント
1. CTRを全部のページの共通ゴールにする
CTR は入口の反応です。ホームの登録、help の自己解決、API の実装準備、contact の適格問い合わせは別の KPI として見ます。
2. 次アクションを計測せずにtitleだけ直す
title と description を直しても、次アクションが見えなければ改善の判断ができません。クリック後に何を見るかを先に決めてから文言を変えます。
3. contactを登録導線と同じ扱いにする
contact は人が対応すべき相談の窓口です。無料登録で解決できる読者は /register へ、使い方確認だけの読者は help へ送るほうが、問い合わせの質を保ちやすいです。
4. 競合ページの変化を見ない
自社の CTR が落ちた理由は、自社ページだけでは説明できないことがあります。競合が title、description、CTA、docs 導線を変えた場合、自社の検索結果の約束も見直す必要が出ます。
こんなときに Stratum Flow を使いやすい
ページ役割KPIを作ったあとに見たいのは、自社ページだけではありません。競合のホーム、help、API docs、contact、価格ページが、どの役割をどう見せているかを継続して追うと、CTR 改善の仮説を直しやすくなります。
- 競合の title、description、CTA 変更を週次で見たい
- help や API docs の導線変更を、マーケティングとプロダクトで共有したい
- 競合監視の結果をレポート化し、Search Console の改善会議に持ち込みたい
- Slack や Teams に、見逃したくないページ変更だけを通知したい
Stratum Flow では Seed URL の使い方と活用例 を起点に監視対象を固定し、競合ページの変更を定期リサーチとして回せます。自社の Search Console KPI と、競合ページの変化を別々に見てから合わせると、次の改善案を決めやすくなります。
まとめ
高表示・低 CTR ページを改善するときは、CTR を最終成果にしないほうが判断しやすいです。ホーム、help、API、contact ごとに、CTR、次アクション、転換 KPI を分けると、どのページをどう直すべきかが見えます。
最初に作るべきものは、きれいなダッシュボードではなく 1 枚の役割別 KPI 表です。URL、クエリ、CTR、次アクション、転換、担当者を並べるだけで、Search Console の数字が改善仕様に落ちやすくなります。
次のアクション
まずはホーム、help、API、contact の4行だけで KPI 表を作ってください。競合のページ役割や CTA の変化も並行して追うなら、Stratum Flow で監視対象を固定して始められます。
