
LPにアクセスはありますが、問い合わせが増えません。コピーやボタンなど、どこから直せばよいでしょうか?

まず計測を確かめ、CTAやフォームのどこで止まるかを分けます。追加CV数と根拠を比べて、検証する修正を選びましょう。
LP改善は、計測の確認、離脱箇所の特定、修正の優先順位、効果の検証の順で進めます。最初からデザインを作り直すより、GA4などで「どの段階で申し込みが止まるか」を調べ、原因に近い箇所を直すのが出発点です。
広告からのアクセスはあるのに、問い合わせや購入が増えない。制作会社に相談したいものの、どこを変えるべきか説明できない。そんな担当者に向けて、LPの分析方法と具体的な改善策、施策の優先順位を決める計算例、変更後の評価までを整理します。
- LP改善は、計測・離脱箇所・修正の優先順位・効果検証の順で進める
- CVRは分母と成果の定義を固定し、流入元と端末を分けて比較する
- ヒートマップで見えた行動と、離脱した理由の仮説を区別する
- 追加CV数の計算、根拠、工数、変更の影響から先に直す箇所を選ぶ
- 問い合わせの質と商談化も追い、採用・再検証・元に戻す判断を残す

株式会社オークスでは実際のWebコンサルタントである、柏倉元太(@genta_oaks)が記事を監修。
月間数十万PVのメディアを複数運営しながら、現在はSEOからSNS、YouTubeまで様々な分野のマーケティング企業を運営。
LP改善は計測と離脱箇所の確認から始める
LP改善とは、ランディングページの説明・構成・操作を見直し、問い合わせや購入につながる割合を高める取り組みです。LPO(Landing Page Optimization)とも呼ばれます。ページに来た人が申し込むまでの過程を扱うため、流入を増やす施策と合わせて考えます。
LP改善の目的は問い合わせや購入までの迷いを減らすこと
LPは、商品やサービスを説明し、資料請求・相談・購入などの行動を促すページです。本記事では、この申込用ページを対象にします。アクセス解析でいうランディングページは「訪問の入口になったページ」を指すため、ブログ記事やトップページも含まれます。分析するときは、改善したいLPのURLに対象を絞りましょう。
改善対象は見た目だけではありません。広告で料金を知りたくなった人に、機能説明ばかり見せていないか。申し込む前に必要な情報が見つかるか。フォームで入力に詰まらないか。訪問時の期待から申込完了までのつながりを確認することが、修正箇所を選ぶ基準になります。
例えば法人向けサービスなら、担当者は自分で理解するだけでなく、上司や関係部署に説明する材料も必要です。対応範囲、導入の流れ、比較できる事例が足りなければ、ボタンを目立たせても検討は進みません。判断できない点を明確にすることが、追加する情報を選ぶ基準です。
計測漏れや流入の変化をLPの問題と混同しない
問い合わせが届いているのに解析画面の成果がゼロなら、コピーより先に完了イベントを点検します。逆に、送信ボタンを押しただけで成果として記録すると、入力エラーでも件数が増えることがあります。実際の送信成功、社内の受信、計測イベントを一連の動作として照合してください。
前月よりCVRが下がっても、LPだけが原因とは限りません。新しい広告で初めて知った人が増えた、スマホからの流入が増えた、申込条件を変えた、といった変化でも全体の割合は変わります。同じLP・流入元・端末・成果の定義で比較し、それでも悪化している段階を調べる順序です。
広告の配信や訴求を含む原因の切り分けは、Facebook広告の改善記事でも扱っています。LPに着く前から数値が悪化している場合は、こちらも確認しましょう。

GA4とヒートマップでLPの課題を調べる

分析では、成果を数えるルールを固定してから、LP内の行動を段階に分けます。GA4は流入やイベントの数値、ヒートマップはページ内のクリックやスクロールの分布を見るために使い分けると、確認する内容が整理できます。
成果の定義とCVRの分母をそろえる
CVR(コンバージョン率)は、対象とした訪問のうち、成果が起きた割合です。本記事の計算例では、LPを入口にしたセッションを分母とし、その中で申込完了が起きたセッションを分子にします。1回のセッションで同じ操作が繰り返されても、各段階を通ったセッションは1として数える設計です。
| 指標 | 本記事での計算 | 確かめること |
|---|---|---|
| 全体CVR | 完了セッション ÷ LP流入セッション | 訪問から成果につながる割合 |
| CTA到達率 | CTA到達セッション ÷ LP流入セッション | 申込への案内が見られる割合 |
| フォーム開始率 | 開始セッション ÷ CTA到達セッション | 案内から入力に進む割合 |
| フォーム完了率 | 完了セッション ÷ 開始セッション | 入力を始めて完了する割合 |
CTAは、資料請求や相談などの行動を促すボタンや案内のことです。上の表の「到達」は、画面にCTAが表示された状態を指します。到達、クリック、入力開始は別の行動なので、同じイベント名にまとめないようにしましょう。表の計算結果を百分率で表すときは、さらに100を掛けます。
ページビュー、ユーザー数、セッション数、イベント回数を混ぜるとCVRの意味が変わります。例えば申込イベントが50回でも、同じセッションで再発火していれば「50セッションが申し込んだ」とはいえません。成果の定義を資料請求から相談申込に変えた場合も、変更前後をそのまま比べるのは避けます。
GoogleのGA4ランディングページレポートの説明では、セッションの最初のページを入口として扱います。対象URLを絞り、セッションの参照元・メディアなどで分けるのが基本です。キーイベントの回数と、成果のあったセッションの割合は区別して確認してください。
流入元・端末別にCTAとフォームの通過率を追う
まずは流入元と端末で分け、流入セッション、CTA到達、クリック、フォーム開始、完了を並べます。広告別の数値は、URLに付けた識別情報と解析側の集計を照合しましょう。全体平均が良くても、スマホの特定広告から来た人だけ入力に進めない、といった問題を発見できます。
これらの行動が、GA4を設置しただけですべて取得できるとは限りません。CTAの表示・クリックや、フォームの開始・送信成功は、ページの構造に合わせたイベント設計が必要です。Googleのキーイベントに関する公式資料では、リアルタイムやDebugViewで記録を確認する方法が示されています。
入力欄の表示を「開始」とするのか、最初の入力を「開始」とするのかも、計測前に固定する項目です。CTAを押さずにページ内フォームへ直接入力できる場合は、その経路を別に集計します。同じ入口から同じ順路を通るセッションを比較することで、どこで止まったのかを読み違えにくくなります。
ヒートマップの行動と離脱の理由を分ける
Microsoft Clarityなどのヒートマップは、クリックやスクロールを集約して、行動の分布を見られる道具です。Clarityの公式資料を踏まえ、同じページ・端末・期間のデータを見て、CTAの手前まで届いているか、ボタンでない場所が押されていないかを調べます。
ただし、赤い部分が購入理由を証明するわけではありません。料金の説明付近で止まる人がいても、「料金が高い」「読みづらい」「比較に必要な条件がない」など複数の理由が考えられます。観測した行動は事実、離脱の理由は仮説として分け、問い合わせで聞かれる内容や実際の操作確認を合わせて判断します。
LP改善の優先順位を追加CV数と根拠から決める

通過率の低い箇所を見つけても、そこが最優先とは限りません。修正できる幅、次の段階に進む割合、必要な工数を合わせて考えます。以下は実績ではなく、判断方法を示すための仮定の計算例です。
1,000セッションの計算例で改善の影響を比較する
LP流入1,000セッションのうち、CTA到達500、フォーム開始200、完了50だったと仮定します。同じ入口・順路のセッションで、各段階は重複せず数えています。このときCTA到達率50%、到達後の開始率40%、開始後の完了率25%、全体CVRは5%です。
| 段階 | 仮定のセッション数 | 前段からの通過率 |
|---|---|---|
| LP流入 | 1,000 | 基準 |
| CTA到達 | 500 | 50% |
| フォーム開始 | 200 | 40% |
| 完了 | 50 | 25% |
フォーム完了率を25%から35%に変えられると仮定し、開始数200が変わらなければ、完了は200 × 35% = 70セッションになります。基準の50から追加20CVです。一方、CTA到達率を50%から60%に変え、後段の通過率が一定なら、600 × 40% × 25% = 60で追加10CVになります。
| 仮定の改善案 | 変更後の完了数 | 基準50からの増加 |
|---|---|---|
| フォーム完了率25%→35% | 200 × 35% = 70 | 追加20CV |
| CTA到達率50%→60% | 600 × 40% × 25% = 60 | 追加10CV |
この条件では、同じ10ポイントの改善でも、完了数への影響は異なります。ただし「フォームを直せば35%になる」ことは確認していません。入力エラーの再現や離脱の集中など、改善幅を見込む材料が必要です。追加CV数は比較の仮定であり、成果の予測値や保証ではありません。
実際には、CTAの文言を変えるとフォームを始める人の質も変わることがあります。後段を一定とする計算は、最初の比較を簡単にするためのものです。変更後は各段階を取り直し、想定よりどこが変わったかを確認します。割合だけでなく、元のセッション数と完了数も残しておきましょう。
根拠の強さ・工数・実装の影響も確認する
優先するのは、成果への影響が見込め、原因に近い根拠があり、検証できる変更です。例えばスマホの送信ボタンが押せない不具合を再現できたなら、色の比較より先に直します。全員が申し込めない状態でA/Bテストを続けても、改善案の良し悪しは判断できません。
| 根拠・状態 | 扱い方 | 次にすること |
|---|---|---|
| 送信できない不具合を再現 | 優先して復旧 | 修正後に正常送信と計測を確認 |
| 特定端末の開始後離脱が増加 | フォーム改善の仮説 | 入力操作とエラーの出方を調査 |
| CTA付近での誤クリックが集中 | 案内の見せ方の仮説 | リンクと装飾の違いを明確にする |
| 好みで色を変えたい | 根拠が不足 | 課題と比較する指標を先に決める |
さらに、制作と実装にかかる時間、他ページへの影響、元に戻せるかを並べます。コピーの変更とフォームの仕組みの変更では確認範囲が異なるため、工程ごとに作業を見積もるのが基本です。成果への影響・根拠・工数・変更の影響範囲を一枚の施策表にまとめると、担当者間で順位を説明しやすくなります。
BtoBでは商談化率までそろえて判断する
資料請求が増えても、対象外の企業ばかりなら営業の成果は伸びません。申込のハードルを下げるときは、サービスの対象、相談できる範囲、申し込んだ後の流れを伝えたまま、不要な入力を減らします。条件を隠して件数だけ増やす場合は、営業側の確認負担にも注意が必要です。
仮に、変更前は問い合わせ50件から商談20件、変更後は70件から商談14件だったとします。問い合わせは40%増えていますが、商談化率は40%から20%となり、商談数は30%の減少です。この仮定の例は、LPのCVRと事業の成果を一緒に評価する必要を示すものです。
比較時は、営業が商談を確定するまでの期間もそろえます。変更前の問い合わせは1か月追跡したのに、変更後は昨日届いた分まで含めると、商談化率は低く見えます。対象企業かどうかを判定する条件と追跡日数を固定し、問い合わせの発生日ごとに成果を照合してください。
LP改善で見直す5つの箇所と具体策

分析で絞った箇所に合わせて、次の5項目を見直します。すべてを一度に変える必要はありません。どの課題に対する修正なのかを、変更前のデータや問い合わせ内容と結び付けて選びましょう。
ファーストビューは流入時の期待に答える
ファーストビューは、ページを開いた直後に見える範囲です。まず、誰に向けた何のサービスなのか、どの課題を解決するのかを短く伝えます。「高品質な支援」のような抽象語だけでは、読み手が自分に合うか判断できません。対象業務や対応範囲がわかる言葉に置き換えます。
例えば、広告で「導入費用がわかる」と案内したなら、LPでも費用と見積もり条件が探しやすい構成にします。写真や装飾の印象だけを広告に合わせるのではなく、流入元で伝えた約束がLPでも確認できることが重要です。スマホではタイトルや画像が大きすぎて、必要な説明が画面外へ押し出されていないかも点検します。
前後比較のために、変更前のスマホ画面を残しましょう。キャッチコピーの変更では、誰にどんな価値を伝えるかが検証軸です。文字・画像・条件を同時に全面変更すると、改善したとしても何が効いたのかを切り分けにくくなります。
コンテンツと実績は比較・不安解消に使う
説明の順序は、サービスを知らない人が理解し、比較し、相談を決める過程に合わせます。機能を並べる前に何ができるかを伝え、対応範囲・利用場面・費用・導入の流れを補う構成が基本です。すでに料金を比較している人が来るLPなら、費用の説明を早めに見せる案も検討できます。
不足している情報は、営業が繰り返し答える質問から選ぶと具体化できます。「自社規模でも使えるか」「既存の仕組みを引き継げるか」「何を準備すれば相談できるか」などです。文章を減らすことだけを目的にせず、申し込み前の判断に必要な説明は残してください。
実績や利用者の声は、課題・支援内容・結果・条件がわかる形で掲載します。業種や規模の違う事例を、どの企業にも同じ結果が出る証拠として扱わないようにしましょう。自社で確認できる根拠だけを使い、数字に計測期間や対象がある場合は併記します。
CTAは押した後の行動と条件を伝える
CTAの文言は、押した後の行動がわかる具体的な表現が基本です。相談につながるなら「見積もりを相談する」、資料が手に入るなら「サービス資料を請求する」のように、実際の遷移先と一致させます。クリックを増やすために、資料請求のボタンで商談予約へ誘導すると期待とのずれが生まれます。
料金や事例の説明を読み、納得した位置に次の行動を用意するのも一案です。ただし、追従ボタンが本文やフォームを隠す状態は先に修正します。スマホでスクロールしながら、文字が読みやすいか、他のリンクと区別できるか、意図した位置に移動するかを確かめましょう。
ボタンの周辺には、相談で何を話せるか、申込後にどのような連絡が来るかを説明すると、行動を決めやすくなります。「営業電話なし」「入力30秒」などは、実際の対応や計測で確認できる場合に限って掲載してください。約束の実態が伴うことが前提です。
フォームは必要な入力とエラーを見直す
入力項目は、申し込みを受け付けるために必要なものと、後から確認できるものに分けます。BtoBでも、詳細な要件をすべて初回で聞く必要があるとは限りません。一方、提供対象を判別するための会社情報まで消すと、商談の質を確認しにくくなることがあります。営業の運用と合わせて決めましょう。
- 必須と任意がわかり、入力例が適切に表示されているか
- スマホのキーボードで入力しやすく、選択肢が画面から切れないか
- エラー箇所と直し方がわかり、入力した内容が失われないか
- 送信後に完了がわかり、社内で受信でき、成功イベントが記録されるか
入力エラーは、正しい入力まで拒否していないかを確認します。メールアドレス、会社名、電話番号など、実際に受け付ける形式に合わせたテストが必要です。フォームの完了率が低い場合は、項目数を減らす前に、特定の項目で操作が止まる不具合を調べてください。
スマホの操作と表示速度は実機で確かめる
制作時のPC表示だけで確認を終えず、実際のスマホでLPの表示から送信完了まで操作します。文字の折り返し、ボタンの押しやすさ、追従要素、入力時の画面移動を通して見ると、画像だけの確認では見落とす問題を拾えます。速度の検証とフォームの動作確認は、それぞれ独立した確認工程です。
GoogleのCore Web Vitalsの公式説明では、良好の目安をLCP 2.5秒以下、INP 200ミリ秒以下、CLS 0.1以下としています。LCPは主なコンテンツの表示、INPは操作への応答、CLSは表示中のずれを見る指標です。実際の読み込みの75パーセンタイル(全体の75%がこの値以下になる点)を、モバイルとPCで分けて評価します。
対策は、診断で大きな負荷や表示のずれが見つかった要素から選びます。表示に対して過大な画像を軽くする、不要な処理を見直す、画像の表示領域を確保するなどです。GoogleのLCP最適化の説明でも、LCP画像の遅延読み込みを避けるよう案内されています。最初に見せる画像まで一律に遅延読み込みへ変えず、変更後に表示を確かめましょう。速度の数値が良好でも、CVRが上がる保証にはなりません。
LP改善の効果を検証して次の修正を決める

変更後に数値が上がっただけでは、LP改善が原因とは断定できません。比較する条件と指標を先に決め、採用するか、追加検証するか、元に戻すかを判断します。検証を始める前に、次の流れを担当者間で共有しましょう。
申込成功とイベントを照合し、流入元・端末別に止まっている段階を調べます。数値の問題とページの問題を分けるのが出発点です。
観測した行動、考えられる理由、変更する箇所をつなげます。追加CV数の仮定と工数を比べ、原因に近い修正を選びましょう。
対象URL、成果の定義、流入、端末をそろえ、A/Bテストか前後比較で評価します。正常動作を確認してから、成果の差を見る工程です。
申込完了、問い合わせの質、商談化を照合します。採用・再検証・元に戻す理由と、次の確認日を残してください。
一つの仮説と評価指標を変更前に決める
仮説は、観測した問題と修正内容を一つにつないだ説明です。例えば「スマホで料金説明の後にCTAが見えず、入力開始まで進めないため、その位置に相談ボタンを追加する」と記録します。改善の目的が具体的なら、検証に使う指標も明確です。
最終評価は申込完了や有効な問い合わせ、途中の確認にはCTAクリック率やフォーム開始率を使います。クリック率だけが上がり、完了率が落ちた場合は、ボタンが期待に合う人を集めたかを見直します。途中指標の改善だけで採用を決めないことは、事業の成果とのずれを防ぐための基本です。
変更前の画面、対象URL、変更日、対象の流入、イベント定義を残し、担当者と確認日を決めておきます。フォームの不具合、問い合わせ対応の負担、受注の質など、悪化させたくない指標も添えます。元のデータと復旧手順は、問題が出たときに判断を実行するための準備です。
A/Bテストと前後比較の条件をそろえる
A/Bテストでは、同じ時期に元のページと改善案へ訪問を割り当て、成果を比較します。仮説は一つに絞り、変更しない条件をそろえるのが基本です。配信の割り当て、重複した訪問の扱い、イベントの発火が正常かを確認してから、結果の差を評価します。
必要な件数や期間は、元のCVR、検出したい差、訪問量で変わります。「2週間」「100件」のような固定条件だけで十分とはいえません。検証ツールの統計的な判断方法と終了条件を先に確認し、都合のよい日だけを抜き出して勝ち案を選ぶことは避けましょう。
A/Bテストが難しい場合は、変更前後を比較し、広告の配信、流入元の構成、端末、季節、申込条件の差を記録します。同じLPでも、訪問者の違いは結果を左右する要素です。前後比較では他の変化を完全に除けないため、「改善後に上がった」という観測と「変更が原因」という解釈を分けて報告します。
採用・再検証・元に戻す判断を記録する
| 判断 | 主な条件 | 残す記録 |
|---|---|---|
| 採用 | 比較条件が妥当で、成果と問い合わせの質が改善 | 変更内容、比較条件、数値、採用理由 |
| 再検証 | 件数不足や条件差で、差を判断できない | 不足している材料、検証上限、次の確認日 |
| 元に戻す | 不具合がある、または定めた損失上限に達する | 復旧内容、影響、次に調べる原因 |
差が出なかったときは、すぐ失敗と決める必要はありません。狙った箇所が見られたか、イベントが正常か、検証する差に対して件数が足りたかを確かめます。ただし、件数が足りないまま期限や費用を増やし続けず、検証を続ける上限を先に置いておきましょう。
採用した案も、問い合わせの質や営業の負担を継続して確認します。BtoBは商談化まで時間がかかるため、申込時点と一定期間追跡した後の二段階での評価が必要です。変更内容・根拠・比較条件・次の判断が残れば、担当者が変わっても同じ検証を繰り返さずに進められます。
LP改善を外注するときに確認する範囲
外注する場合は、「LPを良くしてほしい」という依頼だけでなく、どこで止まっているか、何を成果にするか、どこまで対応してもらうかをそろえます。分析資料の納品から修正・検証まで、依頼範囲が社内の役割と費用を決める前提です。
分析・修正・検証の担当と成果物をそろえる
| 工程 | 確認する成果物 | 担当の分け方 |
|---|---|---|
| 現状分析 | 指標の定義、離脱段階、優先課題 | 計測設定と営業データの提供者を決める |
| 改善案の設計 | 根拠、変更案、期待する変化 | 訴求・条件・素材を社内で確認する |
| 制作・実装 | 修正画面、動作確認、戻す方法 | デザイン、実装、反映の担当を決める |
| 効果検証 | 比較条件、結果、採用判断 | 分析担当と事業側の判断者を決める |
制作会社へ渡す情報は、対象URL、現状の流入と成果、改善したい段階、計測の状態、過去の変更履歴です。スクリーンショットに箇所を示し、「なぜ変えたいか」も説明します。既存ページを直せるかを判断するには、元のデザインデータと更新権限の管理者の情報も必要です。
オークスのCRO/LPOコンサルティングでは、アクセス解析・ヒートマップ・ファネル分析から課題を整理し、改善仮説、A/Bテスト、継続的な検証を支援しています。相談の出発点は、現在の計測状況と止まっている段階の共有です。
改修費用と作り直す費用を同じ条件で比べる
既存LPの文言修正、フォームの改修、構成の作り直しでは工数が異なります。見積もりは、分析の有無、修正箇所、原稿と素材の作成、実装、動作確認、効果検証、修正回数を同じ条件で比較します。制作だけの金額と、継続分析を含む月額費用をそのまま比べないようにしましょう。
文章やCTAの位置だけで課題に対応できるなら、部分改修が選択肢です。一方、対象顧客や提供内容が変わり、ページ全体の説明が合わなくなった場合は、構成から見直す必要があります。作り直す理由を、デザインの好みではなく課題と変更範囲で説明することが、見積もりの妥当性を判断する基準です。
制作費の相場や依頼先ごとの違いは、LP制作費用の記事で詳しく整理しています。改善記事では、金額だけでなく、課題を特定して修正・検証まで進む範囲に注目してください。

LP改善に関するよくある質問
- 複数のLPがある場合は、どれから改善すればよいですか?
-
まず成果の種類と対象の流入が近いLPを同じ単位で比べます。CVRの低さだけで並べず、流入量、止まっている段階、再現できる不具合、改善できそうな幅、工数を合わせて選びましょう。訪問量が極端に少ないLPは、変更しても成果への影響を判別しにくい場合があります。申し込めない不具合は先に復旧し、その後に検証できるページから進める順序です。
- 資料請求と相談申込を同じ成果として数えてよいですか?
-
目的が違うため、個別の件数とCVRを残すのが基本です。両方をまとめた値だけでは、資料請求だけ増えて相談申込が減る変化を見落とします。どちらを主な評価指標にするか決め、もう一方も悪化していないか確認してください。同じセッションで両方の行動が起きる場合は、全体の完了セッションとしては重複を除き、成果の種類別にはそれぞれ記録します。
LP改善は根拠のある修正と検証を積み重ねる
LP改善は、計測と流入の変化を確認し、離脱した段階から修正を選ぶ取り組みです。ファーストビューやCTAを先に変えると決めず、入力の不具合や不足情報を含めて調べます。追加CV数の計算は優先順位を考える材料とし、実際の成果は同じ条件で検証しましょう。
- 解析の数値と実際の申込成功を照合し、計測の問題から解消する
- 同じ入口・順路のセッションで、CTA到達・入力開始・完了を追う
- 修正順位は低い通過率だけで決めず、改善幅・根拠・工数も比較する
- 変更後は同条件で検証し、申込件数に加えて商談化まで評価する
- 外注時は分析・制作・実装・検証の担当と成果物をそろえる
分析から制作・実装・検証までの担当が決まっていない場合は、対象LPと現在の数値を整理したうえでご相談ください。どの課題を、どの範囲で確認するかから検討できます。







