%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
LP改善は、訪問者が次の行動へ進めない理由を見つけ、変更後に確かめる取り組みです。 まず、広告やメールで伝えた内容からフォーム送信後の対応までをたどります。ページのどこを直すかは、その途中で確認できた行動から決めます。
LP改善は、訪問者が次の行動へ進めない理由を見つけ、変更後に確かめる取り組みです。 まず、広告やメールで伝えた内容からフォーム送信後の対応までをたどります。ページのどこを直すかは、その途中で確認できた行動から決めます。
たとえば、CTAが押されない場合でも、訪問者がCTAを見る前に離れているのか、見たうえで押していないのかで調べる箇所は変わります。前者なら冒頭から本文への流れ、後者なら行動前の説明と遷移先を確認します。クリックされているのに送信されない場合は、フォームの操作と案内を調べます。
この記事では、調査の順序、施策を選ぶ分かれ目、変更前に残す記録、結果を見直す条件を解説します。各施策の優先順位は一律に決めず、自社の訪問者の行動と実際の提供内容に照らして判断してください。
本記事は「CVR（コンバージョン率）改善の基本と実践施策15選｜BtoB企業向け完全ガイド」シリーズの一部です。
この記事でわかること
広告やメールからLPへ訪れる人の行動を調べ、改善の着手順を決めたいBtoBマーケティング担当者に向けて、流入前の訴求からフォーム送信後までの確認方法をまとめました。各節では、見るべき記録、原因を絞るための比較、次の施策へ進む条件を示します。
- LP改善の優先順位 — 表示や操作の支障を確認したうえで、行動が止まる接点と評価できる変更範囲から着手順を決めます。
- ファーストビューとコピーの改善方法 — 流入前の期待と冒頭の説明を照らし、見出しと本文のどちらを直すべきか判断します。
- CTAとフォームの設計方法 — クリック後の期待と実際の案内を比べ、必要な入力情報を送信後の仕事から決めます。
- 社会的証明と情報構造の整え方 — 訪問者の疑問に合う情報を選び、事実と掲載許可を確認して配置します。
- A/BテストとHubSpotを使った運用方法 — 比較条件と採用判断を残し、フォーム送信後の対応まで確認します。
LP改善はページ制作ではなく顧客接点の設計
LPの役割は、訪問者が自分の課題との関係を理解し、判断に必要な情報を得て、問い合わせや資料請求などの行動へ進めるようにすることです。ページ内の要素だけを見ると、流入前に抱いた期待や送信後の対応との食い違いを見落とします。
LP単体ではなく前後の流れを見る
広告が「導入までの流れ」を訴求しているのに、LPの冒頭が機能一覧から始まれば、訪問者は探していた情報にすぐたどり着けません。また、フォーム送信があっても担当者と対応条件が決まっていなければ、その後の進捗を追えません。
流入元ごとに訴求とLP冒頭を照らし、本文の閲覧、CTAのクリック、フォーム送信、送信後の対応を順に確認します。前の段階までは進んでいるのに次で止まるなら、段階の間にある説明や操作を調べます。
| 接点 | 確認する内容 | 改善の方向 |
|---|---|---|
| 流入前 | 広告やメールの訴求とLPの内容が一致しているか | 表現と対象をそろえる |
| ファーストビュー | 誰のどの課題を扱うページか伝わるか | ヘッドラインを明確にする |
| 本文 | 判断に必要な情報が順番に並んでいるか | 情報構造を整理する |
| CTA | クリック後に何が起きるか理解できるか | 行動内容を具体化する |
| フォーム | 入力の負担や不安が大きくないか | 項目と案内を見直す |
| 送信後 | 担当者や次の対応が決まっているか | 対応ルールを仕組みにする |
調査では「確認できた行動」「原因の仮説」「次に確かめること」を分けます。たとえば「CTAのクリックが確認できない」は行動の記録です。CTAが見られていないなら配置やそこまでの説明を、見られているなら文言と周辺説明を調べます。接点ごとの記録がなければ、変更前に計測対象と記録方法を決めます。
スプレッドシートだけでは改善履歴が分散しやすい
改善案、実施日、結果、フォームから得た顧客情報を別々のスプレッドシートで管理すると、変更と反応の対応を追いにくくなります。担当者ごとに記録方法が異なると、採用や差し戻しの理由も引き継ぎにくくなります。
スプレッドシートを使う場合は、対象LP、流入条件、変更箇所、変更理由、評価に使った記録、採用判断を同じ単位で残します。フォーム送信後は、担当者がどこで対応状況を確認するかも決めます。変更履歴と顧客対応をつなげて説明できなくなった時点で、記録方法を見直します。
改善対象は課題から選ぶ
「フォーム送信が少ない」という結果だけでは、フォームが原因とはいえません。CTAが押されていなければ、先にCTAまでの説明を調べます。CTAは押されるのに送信されないなら、フォーム上の迷いや負担を調べます。
| 観察した状態 | 考えられる課題 | 最初に確認する箇所 |
|---|---|---|
| ページを開いても本文へ進まない | 訴求が流入時の期待と合っていない | ヘッドラインとサブコピー |
| 本文は読まれているがCTAが押されない | 行動後の価値や内容が伝わっていない | CTA文言と周辺説明 |
| CTAは押されるが送信されない | 入力負担や不安が残っている | フォーム項目とエラー表示 |
| 送信はあるが商談へつながらない | 対象者や送信後の対応設計が合っていない | 訴求対象と営業連携 |
この表は原因の確定ではなく、調査の入口です。たとえば本文を読んだ後にCTAが押されない場合、まずCTAが見える位置まで読まれたかを確認します。見られていなければ配置と説明の順序、見られていれば行動前の疑問を調べます。問い合わせ内容が仮説と合わない場合は、変更箇所を決める前に原因を探し直します。
改善施策の優先順位を決める
施策の着手順は、一般的な効果の順位では決められません。まず表示や操作に支障がないかを確認します。次に、自社で行動が止まる接点と、その原因を調べます。複数の案が残ったら、原因との関係、変更に必要な作業、変更後に追える行動を表に並べて比べます。ただし、原因を確認できない案は、着手前に確認方法を決める必要があります。
施策を一度に実施すると、結果が変わっても要因を分けにくくなります。調査で確認した停滞箇所に関係する案を挙げ、変更前の状態と比較方法を決めてから着手します。
次の表は、各施策に進む前の確認項目です。ファーストビューを直す場合は、流入元の訴求、冒頭の見出し、本文で伝える内容を並べて確認します。内容が食い違う箇所を見つけたら、どこを修正するか表の項目に沿って決めます。ただし、本文で説明していない約束を見出しに加えても、訪問者が判断できる情報は増えません。
| 施策カテゴリ | 着手を考える状態 | 実装前に確かめること | 優先順位の決め方 |
|---|---|---|---|
| ファーストビュー改善 | 冒頭で対象や内容が伝わらない | 流入元の訴求と見出しの関係 | 本文へ進む前に止まるなら検討 |
| CTA最適化 | CTAが見られても押されない | 周辺説明と遷移先の内容 | 行動内容が伝わらないなら検討 |
| フォーム最適化（EFO） | CTA後に送信が止まる | 必要項目と入力時の迷い | フォーム上の課題を確認して検討 |
| 社会的証明の追加 | 判断に必要な根拠が不足する | 内容の裏付けと掲載許可 | 訪問者の疑問に答える素材があれば検討 |
| コピーライティング改善 | 課題と提供内容の関係が伝わらない | 見出しと本文の一貫性 | 読まれても理解が進まないなら検討 |
| ページ速度改善 | 表示前に閲覧が妨げられる | 発生箇所と原因 | 読む前に支障があるなら先に対応 |
| モバイル最適化 | 小さな画面で読めない・操作できない | 端末上の表示と入力の流れ | 操作に支障があるなら先に対応 |
効果と実装負荷で整理する
施策を選ぶ前に、「どの行動を変えたいか」を書きます。冒頭で止まるなら流入元と見出し、CTAを見て止まるなら行動前の説明、フォーム表示後に止まるなら入力画面を確認します。
同じ接点に複数の案がある場合は、担当者が原因を説明でき、変更後の行動を確認できる案から着手します。表示やモバイル操作に支障がある場合は、訪問者が内容を読んで操作できる状態を先に整えます。
現状を記録してから変更する
対象LP、流入元、広告やメールの訴求、CTAの文言と遷移先、フォーム項目、送信後の対応を変更前に記録します。「冒頭から本文へ進むか」「CTAからフォームへ進むか」など、仮説に対応する行動も決めます。
変更後に広告の配信対象や計測方法も変わった場合は、流入条件と計測条件を先に分けて確認します。変更前後で同じ行動を比べられないなら、LPの変更だけによる効果とは判断しません。比較できる記録が残る条件を選び直してから、採用を判断します。
小さく始めて段階的に広げる
「クリック後に何が得られるかわからない」という仮説なら、まずCTA文言と周辺説明を見直します。フォーム項目やページ構成まで同時に変える必要があるかは、その後の行動を見て決めます。
変更後もクリックされなければ、説明が見られているか、訪問者の疑問に答えているかを調べます。クリックが確認できたら、フォーム送信と送信後の対応へ確認を進めます。前の接点だけが改善しても次で止まるなら、その接点を次の調査対象にします。
「CVR2倍」という目標を数字に置き換える
タイトルの「CVRを2倍にする」は成果の保証ではなく、改善の目標の置き方を指しています。CVR（コンバージョン率）は「フォーム送信数 ÷ ページを訪れたセッション数」で求めます。次の表は計算の例で、数値は説明用の仮定です。
| 項目 | 改善前（仮定） | 「2倍」の目標（仮定） |
|---|---|---|
| LPのセッション数（月） | 1,000 | 1,000（流入条件は変えない） |
| フォーム送信数 | 20件 | 40件 |
| CVR | 2.0%（20 ÷ 1,000） | 4.0%（40 ÷ 1,000） |
| 確認する分解 | CTAクリック率 × クリック後の送信率 | どちらの率を上げる施策かを先に決める |
CVRは「CTAクリック率」と「クリック後の送信率」に分けて考えられます。たとえばクリック率が20%、クリック後の送信率が10%なら、CVRは2%です。2倍にするには、どちらかの率を上げる必要があります。分子だけを見て施策を選ぶのではなく、止まっている段階の率を比べてから決めます。LPの流入が少ない場合は、少ない送信数の増減を成果と見なさず、期間を延ばして比較します。実際の支援のあり方は支援事例のページで確認できます。
ファーストビューとコピーを改善する
ファーストビューでは、訪問者が自分に関係するページかを判断できるようにします。ヘッドラインで対象と主題を示し、サブコピーで状況や解決方法を補い、CTAで次の行動を伝えます。
ヘッドラインで対象と価値を伝える
成果の数値や利用条件を見出しに入れる前に、その根拠と実際の案内を確認します。確認できない場合は、対象者、扱う課題、ページで説明する内容を具体化します。
| NG例 | OK例 |
|---|---|
| マーケティングオートメーションツール | 見込み客への対応状況を確認する方法 |
| 業界最高水準のCRMソリューション | 商談情報の引き継ぎを見直す方法 |
| 無料でお試しいただけます | 利用前に確認できる内容をご案内 |
流入元の広告やメールで約束した内容を書き出し、その答えがLP冒頭と本文で見つかるかを確認します。製品名だけが大きく表示され、対象者や扱う課題が読み取れないなら、誰の何を助けるページかを言葉にします。
見出し案を作ったら、実際に説明できる内容だけを残します。
ヘッドライン案は、流入元の訴求と合うか、対象者がわかるか、本文が見出しの内容に答えているかの順に確認します。見出しと本文が食い違うなら、表現を強める前にページで提供する情報をそろえます。
成果や限定条件を使う場合は、対象、根拠、適用条件を掲載前に確認します。確認できない場合は、対象者と利用場面を明確にし、その人が判断に必要とする説明を本文へ置きます。
| 改善前の傾向 | 改善後の方向 |
|---|---|
| 製品名だけを大きく見せる | 対象となる課題と得られる価値を示す |
| 抽象的な品質を訴える | 利用場面や解決する業務を示す |
| 複数の価値を並べる | 主要な価値をひとつに絞る |
| 広告と異なる言葉を使う | 流入前後で表現をそろえる |
変更後は、冒頭から本文へ進む行動に加え、本文が見出しの約束に答えているかを確認します。冒頭から読まれるようになってもCTAへ進まないなら、見出しだけをさらに変える前に、本文で不足する判断材料を探します。
サブコピーで判断材料を補う
サブコピーはヘッドラインの繰り返しではなく、訪問者が自分の状況に当てはめるための説明に使います。顧客情報の集計に困っている担当者へ向けるなら、どの作業で情報が分かれ、何を判断しにくくなるのかを示します。
書いた後は、ヘッドラインだけで主題が伝わるか、サブコピーが利用場面や進め方を補っているかを別々に確認します。両方が同じ内容なら、サブコピーには本文で扱う具体的な疑問を加えます。
本文の入口を整える
ファーストビューの直後には、訪問者が抱える課題と、その解決の考え方をつなげます。機能を紹介する場合も、必要になる場面を先に示し、どの課題に対する説明なのかをわかるようにします。
冒頭を越えて読まれているのにCTAへ進まないなら、行動前の疑問に答えていない箇所を探します。冒頭で読むのをやめているなら、本文を増やす前に、流入時の期待と最初の説明を照らします。
CTAを次の行動が伝わる表現へ変える
CTAでは、クリック後に何が起きるかを伝えます。後述の表に挙げる文言は優劣や効果を保証するものではありません。実際に提供する内容と条件を確認し、自社の案内に使える表現を選びます。
文言だけでなく、周辺説明と遷移先も一緒に確認します。たとえば「相談できる内容を確認する」と示すなら、遷移先で相談範囲がわかる必要があります。クリックが増えても送信につながらない場合は、文言が生んだ期待と遷移先の内容を比べます。
| カテゴリ | 抽象的な文言 | 具体化する方向 | 公開前に確認すること |
|---|---|---|---|
| 資料請求 | 資料請求 | 資料の主題を示して受け取りへ案内する | 受け取れる資料の内容 |
| 問い合わせ | お問い合わせ | 相談できるテーマを示す | 対応できる相談内容 |
| デモ | デモを見る | 確認できる画面や操作を示す | 実際に案内する内容 |
| トライアル | トライアル | 利用開始までの流れを示す | 適用される利用条件 |
自社のCTAを決める際は、まず遷移先で受け取れる資料、相談できる内容、確認できる画面を担当者と照合します。案内できる内容を文言にしたら、クリックからフォーム送信までを続けて確認します。
ボタン文言を具体化する
遷移先で訪問者が実際にできることを確認します。資料の主題、相談できるテーマ、確認できる画面が明確なら、その内容をボタンと周辺説明に反映します。案内する内容が定まっていない場合は、先に提供内容を決めます。
| 抽象的な文言 | 見直す方向 |
|---|---|
| 送信 | 入力内容を送信することを示す |
| 詳細はこちら | 閲覧できる情報を示す |
| 資料請求 | 受け取れる資料の内容を示す |
| お問い合わせ | 相談できるテーマを示す |
| デモを見る | 確認できる画面や内容を示す |
文言を変更したら、クリックに加えて、その先のフォーム表示や送信も確認します。クリック後に送信へ進みにくくなった場合は、ボタンが示した内容と遷移先の案内が合っているかを調べます。
配置は判断の流れに合わせる
CTAの文言・色・配置をさらに細かく設計したい場合は「CTA設計の教科書」も参考になります。
CTAは、訪問者が行動を判断できる地点に置きます。冒頭で内容が伝わるなら上部に置き、説明や事例を読んでから判断する場合は、その情報の後にも行動できるようにします。
CTAが見られていないなら配置を調べます。見られているのに押されないなら、配置を増やす前に、直前の説明とクリック後の内容を確認します。配置を変えた後は、CTAが見つけられるかと、クリック後に進めるかを分けて見ます。
マイクロコピーで不安を減らす
CTAの近くには、クリック後の流れや、入力後に誰からどのような連絡があるかなど、行動前に知りたいことを示します。案内内容は実際に対応する担当者と確認します。
送信後の運用が定まっていない場合は、先に対応ルールを決めます。文言を変更した後も、案内どおりの対応ができているかを確かめます。
フォームの入力負担と運用負担を減らす
フォームでは、入力しやすさと、送信後に必要な情報が得られることの両方を考えます。項目を減らす前に、誰が何の判断に使うのかを確認します。
項目を目的から見直す
フォーム送信の手前で止まる動きは、「マイクロコンバージョンの設計方法」で整理した中間行動を置くと原因を絞りやすくなります。
入力が止まる理由は、項目数だけでは判断できません。項目の意味、入力方法、エラーの案内、情報の利用目的、表示状態を実際の画面で確かめます。
各項目について、送信直後に使う人と利用目的を確認します。使われていない項目は削除を検討し、後の会話で確認できる項目は必須入力にする必要があるか考えます。営業対応に必要な項目は、担当者と取得方法を決めます。
| 離脱につながり得る状態 | 確認する箇所 | 対策 |
|---|---|---|
| 入力項目が多すぎる | 各項目を送信直後に使うか | 項目を必要な範囲に絞る |
| 入力が面倒 | 入力方法や選択肢で迷うか | 入力方法を見直す |
| エラーの意味がわからない | 修正する項目と方法が伝わるか | エラーの内容と直し方を示す |
| 情報の扱いがわからず不安 | 利用目的を確認できるか | 利用目的と案内を明確にする |
| ページが重い | フォームを表示・操作できるか | 表示を妨げる原因を調べる |
入力開始後に離脱が見られたら、まずどの操作の後に止まるかを確認します。エラー表示の後なら、入力した人が修正箇所と方法を理解できるかを実際の画面で調べます。特定の項目で止まるなら、その項目の意味、必須にする理由、入力方法を担当者と照合します。原因を特定できない場合は理由を決めつけず、変更後も同じ箇所で止まるか確認します。
| 確認事項 | 残す判断 | 見直す判断 |
|---|---|---|
| 送信直後の対応に使うか | 担当者が具体的に利用する | 閲覧されていない |
| 別の情報から確認できるか | フォームでの取得が必要 | 後から確認できる |
| 入力方法が明確か | 選択肢や例が理解しやすい | 意味が曖昧で迷いやすい |
| 取得理由を説明できるか | 利用目的が明確 | 慣例だけで残っている |
項目を変更した後は、送信完了と担当者の対応を合わせて確認します。送信はしやすくなっても、担当者が必要な情報を得られず確認作業が増えたなら、項目を戻すか、別の取得方法を検討します。
エラーと入力方法をわかりやすくする
入力エラーが起きたときは、どの項目をどう直せばよいか、その場でわかる表示にします。必須項目や入力形式も、入力前に確認できるか確かめます。
選択式に変更する場合は、実際の顧客が自分に合う選択肢を選べるかを確認します。当てはまらない問い合わせが届くなら、選択肢や項目の設計を見直します。変更後は、選択結果が担当者の対応に使えるかも確認します。
フォームを一覧で管理する
フォームが増えると、目的が同じでも項目や送信後の処理が異なる場合があります。フォーム名、利用ページ、担当者、取得項目、送信後の対応を一覧にし、それぞれの用途を確認します。
以下の画面は、HubSpotのフォーム管理画面で、フォーム名、ページビュー、フォーム送信、表示場所などを一覧で確認できる状態を示しています。
一覧で送信を確認したら、そのフォームがどのLPで使われ、誰の対応につながるかをたどります。利用場所や担当者がわからないフォームは、集計の解釈や改善判断に使う前に用途を確認します。
社会的証明と情報構造を整える
導入実績や顧客の声は、訪問者が抱く疑問に答えるために使います。掲載する素材については、内容の裏付け、利用場面との関係、掲載許可を確認します。素材の種類だけからCVRへの効果は判断しません。
BtoBのLPでは、内容を理解した後に「自社でも利用できるか」「提供元を信頼できるか」といった疑問が残る場合があります。たとえば利用条件が気になる訪問者には、ロゴを増やすより、対応範囲や導入の流れを示すほうが疑問に直接答えられる場合があります。
次の構成表は、各節の役割を整理するためのものです。節の数を設計基準にせず、訪問者が判断するうえで不足している情報を確かめます。
| セクション | 内容 | 目的 |
|---|---|---|
| ファーストビュー | ヘッドラインとCTA | 対象と次の行動を伝える |
| 課題提起 | 対象者が抱える課題と、問い合わせで見られる具体的な疑問 | 自分の状況との関係を確認し、読むべき情報を見つける |
| 解決策 | サービスの概要 | 対応できることを示す |
| 特長・機能 | 課題に関係する機能 | 必要な範囲を理解してもらう |
| 導入事例 | 掲載できる事例（利用場面がわかるもの） | 内容の裏付けと、自社との共通点の判断材料を示す |
| 導入の流れ | 実際の手順と担当範囲 | 次に起きることを示す |
| FAQ | 行動前によくある質問 | 残る疑問に答え、迷いを減らす |
| CTA | 最終アクション | 次の行動へ案内する |
素材を選ぶ前に、訪問者の疑問を書き出します。「自社で利用できるか」が疑問なら利用場面のわかる事例、「情報を送ってよいか」が疑問なら利用目的の説明というように、必要な情報を対応させます。
| 種類 | 内容 | 掲載前に確認すること |
|---|---|---|
| 導入社数 | 確認できる導入実績 | 集計対象と掲載できる範囲 |
| 企業ロゴ | 利用企業を示すロゴ | 利用実態と掲載許可 |
| お客様の声 | 利用場面を伝える推薦文 | 発言内容と掲載許可 |
| 受賞・認定 | 第三者機関からの評価 | 評価の内容と表示条件 |
| メディア掲載 | 掲載媒体を示す情報 | 掲載事実と表示条件 |
利用場面を示せる事例がなければ、サービスの内容、対応範囲、導入までの流れを説明します。素材を掲載する場合は、訪問者のどの疑問に答えるかを決めてから位置を選びます。
社会的証明は迷いが生まれる場所へ置く
社会的証明は、素材をまとめて並べるだけでなく、訪問者が疑問を持つ場所へ置くことを検討します。機能の説明後に利用場面がわかる事例を置く、CTAの前に導入の流れを示すなど、直前の説明とつなげます。
| 配置場所 | 訪問者の疑問 | 適した情報 |
|---|---|---|
| ファーストビュー付近 | 信頼できる提供元か | 掲載許可を得た企業ロゴや認定 |
| 特徴の説明後 | 実際に利用できるのか | 内容が確認できる導入事例 |
| CTAの手前 | 自社にも関係するのか | 課題や利用場面がわかる顧客の声 |
| フォーム付近 | 情報を送って問題ないか | 利用目的やプライバシーポリシー |
適した素材がない場合は、サービス内容、対応範囲、導入までの流れを具体的に説明します。掲載後は、その情報が直前の説明とつながり、訪問者の疑問に答えているかを確認します。
情報を判断順に並べる
まず、自分に関係する内容かを判断できる情報を置きます。その後に解決方法、根拠、進め方、行動前の疑問へ答える構成を検討します。
| 順番 | セクション | 役割 |
|---|---|---|
| 冒頭 | ファーストビュー | 対象と価値を伝える |
| 前半 | 課題提起 | 自分の状況との関係を確認してもらう |
| 中盤 | 解決策と特徴 | 解決方法を具体的に説明する |
| 中盤以降 | 社会的証明 | 判断の根拠を示す |
| 後半 | 導入の流れとFAQ | 行動前の疑問を減らす |
| 終盤 | CTAとフォーム | 次の行動へ案内する |
閲覧記録や問い合わせから、特定の疑問が早い段階で繰り返し現れるなら、その答えを前へ移します。構成を変えた後は、移した情報が読まれ、その先の行動へ進めているかを確かめます。
情報を増やしすぎない
情報を追加する前に、どの疑問に答える内容かを決めます。主要な判断に必要ならLPへ置き、詳しい条件や補足が中心なら別ページや資料で説明する方法もあります。
短くすること自体を目的にせず、必要な情報を見つけられるかで判断します。同じ質問が問い合わせで続くなら、その答えがLP上で見つけにくくないかを見直します。
表示速度とモバイル体験を見直す
表示や操作に問題があると、コピーやCTAを評価する前に訪問者が離れている可能性があります。ページが表示されるまでの状態と、表示後に読んで操作できるかを分けて確認します。
次のツールは表示状況を調べる際の確認先です。測定結果を見たら、実際の画面で起きている問題と照らし、訪問者の操作に関係する箇所から調べます。
| ツール | 特徴 | URL |
|---|---|---|
| PageSpeed Insights | Googleの公式ツール、スコアと改善提案 | pagespeed.web.dev |
| GTmetrix | 詳細なウォーターフォール分析 | gtmetrix.com |
| WebPageTest | 複数拠点からの測定 | webpagetest.org |
画像とコードを整理する
表示に時間がかかる箇所が見つかったら、画像、スクリプト、外部から読み込む要素のどれが関係するかを調べます。画像は表示領域に合うサイズや形式を確認し、コードの整理は計測やフォームへの影響も踏まえて担当者と進めます。
測定にはPageSpeed Insights、GTmetrix、WebPageTestなどを利用できます。スコアだけで変更を決めず、実際の表示で困る箇所と測定結果を照らします。変更後は表示に加え、CTAの遷移とフォーム送信も確認します。
モバイルでは操作の流れを確認する
モバイルでは、見出しの改行、CTAの押しやすさ、フォームの入力順、画像内の文字を実際の画面で確認します。PCで読める内容も、小さな画面では順番や間隔によって理解しにくくなる場合があります。
以下の表はPCとモバイルを見比べる項目です。表示方法を一律に決めず、内容の読みやすさと操作のしやすさを画面ごとに確かめます。
| 要素 | PC版 | モバイル版 |
|---|---|---|
| ヘッドライン | 全体を読み取れる改行 | 小さな画面でも意味が伝わる改行 |
| CTAボタン | 説明を読んだ後に見つけられる配置 | 押しやすさと本文の読みやすさを両立する配置 |
| フォーム | 入力順がわかるレイアウト | 項目を順に確認しやすいレイアウト |
| 画像 | 内容を読める表示 | 文字の可読性と表示の負担を確認 |
| ナビゲーション | 必要な情報へ移動できる表示 | メニューを見つけて操作できる表示 |
技術対応の限界を見極める
表示速度やレイアウトの問題を見つけたら、発生するページ、端末、操作、表示状態を記録します。担当者が再現できる状態にしてから修正範囲を決めます。
フォームや計測に関係する変更では、表示が改善しても送信や記録が正常に続いているかを確認します。技術上の問題が残る間は、コピーの変更結果も慎重に解釈します。
A/Bテストを改善の仕組みにする
A/Bテストでは、観察した課題から仮説を立て、変更対象と評価する行動を先に決めます。結果に加えて、なぜ変更を選び、どの条件で比較したかを残します。
仮説を課題と結び付ける
次の表は、テスト対象を選ぶための整理です。対象ごとの改善幅はあらかじめ決められません。行動が止まる接点に関係するか、比較条件をそろえられるかで選びます。
「CTAを変える」だけでは、何を確かめたいのかが曖昧です。「クリック後に得られる内容が伝わっていないため、資料の内容をCTA周辺に示す」というように、観察した状態、原因の仮説、変更、確認する行動をつなげます。
| テスト対象 | 確かめる行動 | 比較前に確認すること |
|---|---|---|
| ヘッドラインの文言 | 冒頭から本文へ進むか | 流入元の訴求がそろっているか |
| CTAの文言・色 | CTAが見つかり、クリックされるか | 文言の理解と視認性を分けて考えられるか |
| フォームの項目数 | 入力から送信へ進めるか | 送信後に必要な情報を残せるか |
| ファーストビュー画像 | 冒頭の内容を理解できるか | 画像と見出しの役割を区別できるか |
| ページ構成の順序 | 必要な情報を読んで次へ進めるか | 変更した範囲を記録できるか |
対象が決まったら、次の項目を変更前に記録します。原因の仮説と評価方法を書けない場合は、閲覧行動や問い合わせ内容を調べ、確かめたいことを明確にします。
| 仮説の要素 | 記録する内容 |
|---|---|
| 観察した課題 | どの段階で行動が止まっているか |
| 原因の仮説 | なぜ止まっていると考えたか |
| 変更対象 | ヘッドライン、CTA、フォームなど |
| 期待する変化 | どの行動が変わると考えるか |
| 評価方法 | 何を比較して判断するか |
一度に変える範囲を限定する
特定の要素について仮説があるなら、変更範囲を限定します。CTA文言を評価したいときにフォーム項目や広告の訴求も同時に変えると、結果の理由を分けにくくなります。
説明の順番そのものが課題なら、構成変更として扱います。その場合も、どの流入元と行動を比較するかを先に決めます。途中で流入条件が変わったら、その期間を同じ条件の結果としてまとめず、比較方法を見直します。
結果と判断理由を残す
テスト名、対象ページ、仮説、変更内容、流入条件、評価した行動、結果、採用判断を同じ形式で記録します。想定した行動に変化が見られない場合も、次に調べる箇所を書き残します。
CTAのクリックが変わらないときは、まずCTAが表示されたかを確認します。表示されていなければ、文言を変える前に配置や直前の説明を見直します。表示された場合は、変更前後で閲覧位置や流入条件をそろえ、クリックの記録を比較します。ただし、比較できる記録が不足している段階では成否を判断せず、条件をそろえて確認できてから次の変更を決めます。
HubSpotでLP改善を顧客管理へつなげる
HubSpotでLPやフォームを管理している場合は、ページ上の反応に加え、フォーム送信後の情報が誰の対応につながるかを設計します。企業様によって最適な形は異なります。 管理する情報と担当者の仕事を確かめ、必要な範囲から整えます。
LPの作成や検証については「HubSpotランディングページ（LP）作成ガイド｜テンプレート選定・A/Bテスト・CV最適化」で、テンプレートの選び方から公開後の見直しまで確認できます。
フォーム送信後の流れを定義する
フォーム送信を受け取ったら、誰が内容を確認し、どの条件で営業対応へ進めるかを決めます。担当者が次に何をするか判断できる記録も用意し、送信があったことだけでLPの評価を終えないようにします。
| 段階 | 管理する内容 | 確認すること |
|---|---|---|
| コンタクト | フォームから得た顧客情報 | どのLPから接点が生まれたか |
| 取引 | 商談として管理する情報 | どの条件で営業対応へ進めるか |
| 顧客 | 受注後の関係 | 過去の接点を確認できるか |
| その後の管理 | 継続的な対応情報 | 関係者が同じ情報を参照できるか |
送信は増えても商談につながらない場合は、LPで伝えている対象者と、営業へ渡す条件を確認します。送信後の対応が追えない場合は、まず担当者と記録方法を整えます。そこで対応状況を確認できてから、LPの訴求を見直す必要があるか判断します。
一元管理と自動化と可視化を分けて考える
一元管理では、LP、フォーム、コンタクト、取引の関係をたどれるようにします。自動化では、担当者への通知や引き渡しなど、繰り返す対応を対象にします。可視化では、ページ上の反応とその後の進捗を確認できるようにします。
最初に主要なLPとフォームの用途を整理し、送信後の対応ルールを決めます。手作業での引き渡しに漏れが生じるなら自動化を検討し、判断に必要な情報が見つからないなら記録や表示方法を見直します。
HubSpotの画面でLP改善の指標を確認する
改善の効果を確かめるには、ページ、CTA、フォームのそれぞれで同じ期間の数字を並べます。HubSpotの公式ナレッジで確認できる画面と指標を、見たい行動ごとに整理すると次のとおりです。
| 見たい行動 | HubSpotの画面（公式ナレッジで確認した場所） | 見る指標 |
|---|---|---|
| CTAが見られているか・押されているか | マーケティング ＞ CTA ＞ 「分析」タブ、または個別CTAの「パフォーマンス」タブ | ビュー数、クリック数、クリック率、送信数 |
| クリック後にフォーム送信まで進むか | CTAの「関連付けられたフォーム送信」（Attributed form submissions） | 関連付けられた送信数と送信率 |
| どのフォームとページで送信されているか | マーケティング ＞ フォーム ＞ 「分析」タブ | フォーム送信数の合計、ページ別の送信、ライフサイクルステージ別の送信 |
| 2つのLPの版を比べる | コンテンツ ＞ ランディングページ ＞ 対象ページのパフォーマンス ＞ テスト結果 | 版ごとの反応と、勝者の選択 |
出典: CTAのパフォーマンスを分析する（HubSpot公式ナレッジ）、フォーム送信レポートを分析する（同）。メニュー名は画面の更新で変わることがあるため、実際の画面で確認してください。
見方のポイント: クリック率が低いのにクリック後の送信率が高いなら、CTAまでの説明に課題があります。逆にクリック率は高く送信率が低いなら、遷移先とフォームを調べます。この切り分けが、前の節の「止まる接点の特定」に対応します。
LPのA/BテストをHubSpotで実施する手順
HubSpotのランディングページでは、同じURLで2つの版を出し分けて比較できます。公式ナレッジに沿った手順は次のとおりです。
- 「コンテンツ」から「ランディングページ」を開き、テスト対象のページ名をクリックします。
- 編集画面の左サイドバーにあるテストのアイコンから「A/Bテスト」を選びます。ファイルメニューの「新規」＞「A/Bテストを実行」からも開始できます。
- それぞれの版に名前を付け、「バリエーションを作成」をクリックします。
- 編集画面で変更する版を作ります。公式ナレッジは、原因を特定しやすくするために1回に1つの要素だけを変えることを推奨しています。
- 「公開」＞「今すぐ公開」で、2つの版を同じURLで公開します。
- 対象ページの「パフォーマンス」の「テスト結果」タブで比較し、判断できる量の閲覧が集まってから、版にカーソルを合わせて「勝者として選択」を押します。
公式ナレッジによると、訪問者の半数ずつに各版が表示され、同じセッション中は同じ版が表示されます。勝者を選ぶと、その版だけが公開され、もう一方は下書きに戻ります。利用にはContent Hub ProfessionalまたはEnterpriseと、マーケティングの編集・公開権限が必要です（出典: ページのA/Bテストを実行する（HubSpot公式ナレッジ））。必要なサンプル数や期間は公式ナレッジに記載がないため、自社の流入量から先に評価期間を決めておきます。
フォーム送信後の設定例（フォームのオプションとワークフロー）
フォーム送信後の対応は、フォーム自体の設定と、ワークフローの2段階で決めます。フォームでは「オプション」タブで、送信後に表示する内容（サンキューメッセージ、HubSpotページ、外部URL）、送信通知メールの宛先（コンタクト担当者への通知も選択可）、ライフサイクルステージの設定を選べます。ライフサイクルステージは後戻りしない点に注意してください（出典: フォームを作成する（HubSpot公式ナレッジ））。
通知だけで足りない場合は、「オートメーション」＞「ワークフロー」から、フォーム送信を条件にしたワークフローを作ります（出典: ワークフローを作成する（HubSpot公式ナレッジ））。設計例は次のとおりです。ここで挙げる名称は、読者が自社の名称に置き換えるための例です。
| 設計項目 | 設計例 | 決める理由 |
|---|---|---|
| ワークフロー名 | LP資料請求_初回対応 | どのLPの対応かを名前から判別するため |
| 登録条件 | 特定のフォームの送信（資料請求フォーム） | LPごとに対応を分けて、送信後の動きを比較するため |
| アクション1 | 営業担当への内部通知 | 担当者が送信に気づけず、初回対応が遅れる状況を防ぐため |
| アクション2 | 担当者にタスクを作成（件名例「資料請求への初回連絡」） | 誰がいつ対応するかを記録として残すため |
| 確認方法 | フォームの「分析」タブの送信数と、タスクの完了状況を同じ期間で見る | 送信と対応の間で止まっていないかを確かめるため |
ワークフローの登録条件・再登録・命名を設計書にまとめる方法は「HubSpotワークフロー設計書の書き方」で解説しています。
HubSpotでLP改善を進めるときの失敗と回避策
| 起きやすい失敗 | なぜ問題になるか | 回避策 |
|---|---|---|
| LPの版を変えた日と、広告の配信条件を変えた日が重なる | 送信数が変わっても、どちらの影響か分けられない | 変更日を記録し、LPの変更は広告の変更と別の期間に行う |
| A/Bテストで複数の要素を同時に変える | 結果が出ても、どの変更が効いたか説明できない | 1回に変える要素を1つに絞る。複数を変える場合は構成変更として別に記録する |
| フォームのライフサイクルステージを安易に設定する | ステージは後戻りしないため、誤った設定を後から戻せない | 設定前に営業と、どのステージに進める条件かを合意しておく |
| 通知先を個人だけにする | 担当者の不在時に初回対応が止まる | チームを通知先に含め、タスクで担当を明確にする |
StartLinkの進め方：LP改善をCRMの運用まで届ける
StartLinkはHubSpotゴールドパートナーとして、150社以上のHubSpot支援に携わってきました。LP単体の改修に閉じず、フォーム送信後の営業対応とデータの管理まで一続きで設計します。公開しているHubSpot導入・構築支援（サービスページ）では、次の順序で進めます。
- 現状把握と戦略設計: 営業・マーケティングの業務をヒアリングし、LPからフォーム送信後までの課題を整理します。
- 環境構築と設定: フォーム、プロパティ、パイプライン、ワークフローを設計して構築します。標準機能で足りない連携は、自社開発のSyncシリーズなどで補います。
- データ移行とテスト: 既存の顧客情報を移し、フォーム送信から通知・タスク作成までの動作を確認します。
- トレーニングと定着支援: 運用担当者への研修と定例レビューで、改善サイクルを回せる状態にします。
最初から全LPを対象にせず、問い合わせにつながる主要なLP1本から始め、結果を確認しながら対象を広げます。AIを使った業務設計（HubSpot×AI支援）も、フォーム内容の振り分けなど、人が判断する箇所を決めたうえで組み込みます。支援の対象や事例は支援事例のページで確認できます。
自社でA/Bテストを行うかの判断表
| 自社の状況 | 判断 | 次の一手 |
|---|---|---|
| 対象LPの流入が少なく、2つの版に十分な閲覧が集まらない | A/Bテストは見送る | 流入元を整え、変更前後の記録で比較する |
| 流入元の広告やメールを頻繁に変えている | 条件が揃うまで待つ | 流入条件を固定できる期間を決めてから実施する |
| 変えたい要素が1つに絞れている | A/Bテストを実施する | 評価する行動と期間を先に書き出す |
| プランや権限の都合でA/Bテストを使えない | 変更前後の比較で進める | 変更日と計測条件を記録して比べる |
HubSpotを入れるだけでは改善は進まない
ツール上で反応を確認できても、どの顧客へ何を伝え、どの行動を成果とするかは自社で決める必要があります。変更前に仮説と判断基準を定め、変更後はフォーム送信とその後の対応を確認します。
フォームやレポートを増やす際は、名称、担当者、利用目的を記録します。用途を説明できないものが増えた場合は、新しい設定を追加する前に既存の管理方法を整理します。
よくある質問
LP改善はどこから着手すればよいですか？
まず表示や操作に支障がないかを確認し、流入からフォーム送信後までを分けて、どこで次の行動が止まるかを調べます。記録がなければ、流入元、CTAの閲覧とクリック、フォーム送信など、判断に必要な行動を把握します。止まる接点がわかったら、その直前の説明や操作に仮説を立て、変更後に同じ行動を確認できる範囲から着手します。
CTAの色と文言はどちらを先に見直すべきですか？
クリック後に何が起きるかわからないなら、文言と周辺説明を先に確認します。内容は伝わっているのにボタンを見つけにくいなら、色を含む視認性を調べます。CTAを見た人の行動と遷移先での行動を分けて確認し、どちらに課題があるかで変更対象を決めます。
フォーム項目は少ないほどよいですか？
項目ごとに、誰がいつ何の判断に使うかを確認して決めます。使われていない項目や後から確認できる項目は見直します。送信後の対応に必要な情報まで削ると確認作業が増えるため、営業担当者と取得方法を決め、変更後の送信と対応状況を合わせて確認します。
社会的証明として何を掲載すればよいですか？
訪問者の疑問に関係し、事実と掲載許可を確認できる導入事例、顧客の声、企業ロゴ、認定などを検討します。素材がない場合は成果を推測で示さず、サービス内容や導入の流れを具体的に説明します。掲載後は、その情報が疑問に答える位置にあり、直前の説明とつながっているかを見直します。
A/Bテストが向かないケースはありますか？
比較できる記録が不足している場合や流入条件が変わっている場合は、結果だけから変更の効果を判断しにくくなります。まず閲覧行動や問い合わせ内容を調べ、仮説と評価条件を整理します。複数の要素を変える必要がある場合は構成変更として記録し、個別要素の効果と混同しないようにします。
まとめ
LP改善では、流入からフォーム送信後までの行動をたどり、止まる接点に合う施策を選びます。ファーストビュー、サブコピー、CTA、フォーム、社会的証明、情報構造、表示速度、モバイル体験、A/Bテストは、自社で確認した課題に応じて使い分けます。
まず訪問者が読んで操作できる状態を確かめます。次に、行動が止まる箇所の直前にある説明や操作を調べます。変更前後の流入条件と計測方法を確認し、ページ上の反応だけでなく送信後の対応まで見て採用を判断します。
- 流入元からフォーム送信後までをたどり、行動が止まる接点を特定します。
- その接点の原因について仮説を立て、変更前の状態、比較条件、評価する行動を記録します。
- 変更後の行動と対応状況を確認し、仮説に合う結果なら採用を検討します。合わなければ次に調べる箇所を残します。
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
LPで行動が止まる接点を確認できたら、次の記事で中間の行動、CTA、サイト全体の導線を詳しく調べられます。フォーム送信前の動きを把握したい場合はマイクロコンバージョン、クリック後の行動を見直したい場合はCTA、複数ページをまたぐ流れを調べたい場合はサイト改善の記事へ進んでください。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
