Search Console で表示回数があるのに CTR が低いページを見直すとき、タイトルや description だけを個別に直すと、ホームページと問い合わせページの役割がぶつかることがあります。ホームページは self-serve の判断起点、問い合わせページは人が対応すべき相談の窓口です。この2つを同じ「CVページ」として扱うと、検索結果で約束する内容も、クリック後に見せる導線も曖昧になります。
この記事では、既存の SaaSホームページのCTR改善 や 問い合わせページのCTR改善 より一段上の診断軸として、ホーム、help、API、contact をページ種別で分ける実務手順を整理します。特にホームページと問い合わせページについて、タイトル、description、導入文、見出し、内部リンク、CTA をどの順で改善仕様に落とすかを扱います。
まず結論: 低CTRはページ単体ではなく役割の衝突から直す
- Search Console では、URL をホーム、help、API、contact に分けてから CTR を見る
- ホームページは「何のサービスか」と「無料登録後に何を始めるか」を返す
- 問い合わせページは「人が受ける相談」と「自己解決できる導線」を分ける
- help は作業の答え、API は実装順、contact は相談範囲を先に見せる
- 改善仕様は title、description、導入文、最初の見出し、内部リンク、CTA の順で書く
- 変更後は CTR だけでなく、登録、help 回遊、問い合わせ種別まで見る
Google Search Console のパフォーマンスレポートでは、ページ、クエリ、表示回数、CTR などを見ながら検索結果での反応を確認できます。公式ヘルプでも、クエリやページ別に検索結果でのクリック状況を確認し、SEO の改善に使えることが説明されています（Search Console Performance report）。ただし、SaaS サイトではページ種別ごとに役割が違うため、同じ修正を横展開する前に役割を分ける必要があります。
なぜホームと問い合わせは同時に崩れやすいのか
ホームページと問い合わせページは、どちらも商談や登録に近いページです。そのため、検索結果で似た言葉を使いやすくなります。
| 起きやすい混同 | ホームページで起きること | 問い合わせページで起きること |
|---|---|---|
| 導入相談を強く出しすぎる | self-serve で試したい読者が重く感じる | 問い合わせ対象が広がり、相談の質がぶれる |
| 無料登録をどこでも強調する | 登録後の最初の作業が見えない | 人に聞くべき相談まで register に流れる |
| help の役割を吸収する | ホームが説明過多になる | フォーム前の不安をすべて contact で受ける |
| API や技術相談を混ぜる | 非開発者にとってノイズになる | セキュリティ、実装、導入相談が同じ窓口に見える |
CTR を上げたいだけなら、検索結果で強い言葉を足すこともできます。しかし、クリック後の役割がずれると、登録率、問い合わせの質、help 回遊のどこかで無理が出ます。先に「このページが受けるべき検索者」と「別ページに送るべき検索者」を決めるほうが、改善後の判断がしやすいです。
手順1: ページ種別ごとに役割表を作る
まず、Search Console のページ別データを見ながら、対象 URL を役割ごとに分けます。表示回数と CTR だけで並べるのではなく、各ページが何を受けるべきかを先に書きます。
| ページ種別 | 主な役割 | 検索結果で先に言うこと | ページ内で受ける行動 | 逃がす先 |
|---|---|---|---|---|
| ホーム | 製品カテゴリと用途の判断 | 誰向けの何の SaaS か | /register、主要ユースケース確認 |
help、blog、contact |
| help | 作業中の疑問解消 | 何の手順や設定が分かるか | 関連 help、初回設定、登録 | blog、register |
| API | 開発者の実装確認 | 認証、Jobs、Reports、Notifications | 実装順の確認、API キー準備 | help、contact |
| contact | 人が対応すべき相談 | 導入、請求、契約、セキュリティ相談 | フォーム送信、必要情報確認 | register、help |
この表で大事なのは「逃がす先」まで書くことです。ホームに来た人を全部登録へ送るのではなく、設定前に不安がある人は ダッシュボードの機能と基本設定 や Seed URL の使い方と活用例 に送ります。問い合わせページでも、使い方の確認だけなら 効果的なリサーチ指示の書き方 のほうが期待に合います。
手順2: ホームと問い合わせの優先順位を分ける
高表示・低 CTR のページが複数ある場合、単に表示回数が大きい順で直すと、ホームページばかりに作業が寄りやすくなります。ホームと問い合わせは役割が違うため、優先順位も別の条件で決めます。
| 判断項目 | ホームを優先する条件 | 問い合わせを優先する条件 |
|---|---|---|
| クエリの広さ | ブランド、カテゴリ、課題名が混ざっている | 導入相談、請求、セキュリティが見えている |
| 次の行動 | /register への遷移が弱い |
フォーム到達や相談種別の質が弱い |
| ページ冒頭 | 何の SaaS か伝わりにくい | 何を相談できるか伝わりにくい |
| 内部リンク | help や blog への分岐が少ない | 自己解決できる人の逃げ道が少ない |
| 改善の戻り | 登録や初回ジョブに効きやすい | 商談前の不安解消に効きやすい |
ホームは「クリック後に無料登録まで進めるか」を見ます。問い合わせは「人が対応すべき相談に絞れているか」を見ます。同じ CTR 改善でも、見るべき成果が違うため、改善仕様も分けて書く必要があります。
手順3: ホームページの改善仕様を書く
ホームページの改善仕様は、検索結果の約束からファーストビュー、無料登録導線までを一続きで書きます。既存の SaaSホームページのCTR改善手順 ではホーム単体を深掘りしていますが、ここでは他ページとの役割分担を前提に、仕様に入れる項目を整理します。
| 項目 | 仕様に書くこと | 例 |
|---|---|---|
| title | 誰向けの何のサービスか | AI競合調査・市場調査を定点観測するSaaS |
| description | 主要用途、出力、登録後の最初の作業 | 競合サイト、価格、リリース、業界ニュースを定期収集し、レポートと通知にまとめます。無料登録後すぐに初回ジョブを作成できます。 |
| 導入文 | 検索結果で約束した用途を1画面目で返す | 競合調査、市場調査、公開情報の定点観測を継続するためのサービスであることを明示する |
| 見出し | 判断材料ごとに分ける | できること、監視対象、レポート、通知、API連携、無料登録後の流れ |
| 内部リンク | ホームで説明しきらない疑問を送る | 競合調査を自動化する5つの方法、ダッシュボードの機能と基本設定 |
| CTA | 主導線を /register に置く |
無料登録して最初の定期リサーチジョブを作成する |
ホームページで避けたいのは、問い合わせページの役割まで抱え込むことです。導入相談が必要な人には /contact を見せますが、self-serve で試せる読者には登録後の最初の作業を見せたほうが行動しやすくなります。
手順4: 問い合わせページの改善仕様を書く
問い合わせページでは、検索結果で「連絡できます」とだけ言っても弱いです。検索者が知りたいのは、自分の相談がこの窓口で扱われるか、問い合わせ前に何を確認できるかです。
| 項目 | 仕様に書くこと | 例 |
|---|---|---|
| title | 対応できる相談範囲 | お問い合わせ・導入相談・セキュリティ相談 |
| description | 相談種別、返信目安、事前情報 | 導入相談、見積もり、請求書払い、DPA/NDA、セキュリティ質問票、一般サポートの窓口です。返信目安と事前にあるとよい情報も確認できます。 |
| 導入文 | 人が対応すべき相談と、自己解決できる確認を分ける | 導入、購買、契約、セキュリティは問い合わせ、使い方確認は help と register へ分岐する |
| 見出し | 相談種別ごとに分ける | 導入相談、請求・購買、セキュリティ、契約、登録前の確認 |
| 内部リンク | 問い合わせ不要な読者を逃がす | 効果的なリサーチ指示の書き方、Seed URL の使い方と活用例 |
| CTA | フォームと無料登録を役割で分ける | 相談が必要な場合はフォーム、まず触る場合は /register |
問い合わせページの詳細は 問い合わせページのCTRをSearch Consoleで改善する手順 で扱っています。今回の診断では、問い合わせページを「すべての不安を受ける場所」にしないことを先に決めます。登録前の使い方確認までフォームで受けると、問い合わせの質が下がりやすいからです。
手順5: helpとAPIは役割の境界線として使う
ホームと問い合わせを直すとき、help と API は脇役ではありません。役割の境界線を作るページです。
| ページ | ホームから送る理由 | 問い合わせから送る理由 |
|---|---|---|
| ダッシュボードの機能と基本設定 | 登録後の最初の画面を見せる | 使い方確認だけの問い合わせを減らす |
| 効果的なリサーチ指示の書き方 | 初回ジョブの不安を減らす | 相談前に依頼内容を整理してもらう |
| Seed URL の使い方と活用例 | 監視対象の決め方を補う | 情報源設定の質問を自己解決に寄せる |
| APIリファレンス | 開発者向けの実装情報へ送る | 技術相談の前に実装範囲を確認してもらう |
help ページの登録導線は helpページを登録導線に変える内部リンクとCTA設計 で深掘りできます。API ページは APIリファレンスCTRを実装順で改善する のように、実装順を前提に見直します。ここでは、ホームと問い合わせが説明過多にならないように、役割の受け皿として使います。
手順6: 変更後はCTRと次の行動を一緒に見る
改善後の確認では、Search Console の CTR だけを見ると判断を誤りやすいです。ページ種別ごとに、クリック後の行動を合わせて見ます。
| ページ種別 | CTR以外に見ること | 判断の例 |
|---|---|---|
| ホーム | /register 遷移、help 回遊、初回ジョブ作成 |
CTR が上がっても登録後の行動が弱ければ、ファーストビューか CTA がずれている |
| help | 関連 help、register、blog への回遊 | 読まれているのに次へ進まないなら、内部リンクの文脈を見直す |
| API | API キー、関連エンドポイント、contact への遷移 | 実装相談が多いなら、リファレンス内の導線や説明順を見る |
| contact | フォーム到達、相談種別、無料登録への分岐 | 一般問い合わせだけ増えたなら、description が広すぎる可能性がある |
更新後は 7〜14 日単位で見ると、短期の揺れに引っ張られにくいです。表示回数が少ないページでは、CTR の変化だけで勝ち負けを決めず、クエリの内容と次の行動をセットで確認します。
失敗しやすいポイント
1. ホームと問い合わせで同じCTA文言を使う
ホームの CTA は、無料登録後の最初の作業まで見せるほうが合います。問い合わせの CTA は、相談種別と必要情報を示すほうが合います。同じ文言を置くと、ページの役割がぼやけます。
2. 高表示のURLだけを優先する
表示回数が大きいページから直すのは自然ですが、問い合わせページのように件数が少なくても商談に近いページがあります。ホームと contact は、表示回数だけでなく、次の行動の質で優先順位を決めます。
3. helpとAPIを内部リンク先として後回しにする
ホームと問い合わせだけで不安を解消しようとすると、ページが長くなり、検索結果の約束も散らかります。help と API を受け皿にして、役割ごとの導線を作るほうが維持しやすいです。
4. CTR改善をタイトル変更だけで終える
title と description を直しても、導入文や最初の見出しが古いままだと、クリック後の期待がずれます。改善仕様には、検索結果と本文冒頭をセットで入れます。
こんなときに Stratum Flow を使いやすい
- 自社ページの CTR 改善と並行して、競合サイトの title、description、CTA の変化を定点観測したい
- 競合のホームページ、価格ページ、リリースページ、help ページの更新を週次で見たい
- 更新内容をレポート化し、マーケティング、営業、プロダクトで同じ判断材料を見たい
- Slack や Teams に通知して、ページ変更を見逃しにくい運用を作りたい
Search Console は自社ページの検索結果を振り返る道具です。一方で、競合のページ役割や CTA の変化を追うには、監視対象を固定して継続的に見る必要があります。Stratum Flow では、Seed URL の使い方と活用例 を起点に監視対象を決め、定期リサーチとして回せます。
アイキャッチ画像プロンプト
Use case: productivity-visual
Asset type: 16:9 blog eyecatch image
Primary request: Create a clean editorial business illustration about diagnosing low CTR by page role for a SaaS website.
Scene/backdrop: A modern analytics workspace with a Search Console-like dashboard, four page-role lanes, and a decision workflow.
Subject: The homepage and contact page lanes are visually emphasized, with help and API lanes shown as supporting routes. Use abstract UI panels, arrows, small charts, and role labels as symbolic blocks, but avoid readable text.
Style: Polished flat 3D editorial illustration, neutral light background, restrained accent colors, crisp shapes, professional SaaS marketing tone.
Constraints: No logos, no real brand names, no screenshots of actual products, no tiny readable UI text, no watermark.
まとめ
高表示・低 CTR のページを直すときは、ページ単体で title を調整する前に、ホーム、help、API、contact の役割を分けるほうが判断しやすいです。特にホームページと問い合わせページは、登録と相談の距離が近いため、検索結果の約束、導入文、見出し、内部リンク、CTA を別々の仕様として扱う必要があります。
ホームは self-serve の判断起点、問い合わせは人が対応すべき相談の窓口。この境界を先に決めてから Search Console のデータを見ると、CTR 改善が登録や相談の質までつながりやすくなります。
次のアクション
まずはホーム、help、API、contact の4種別で、title、description、導入文、最初の見出し、内部リンク、CTA を1枚の表にしてください。競合ページの変更も並行して追うなら、Stratum Flow で監視対象を固定して定期リサーチを始められます。
