LPを直しても成果が動かない——10項目を全部触る前に、詰まりを1つ特定する

広告のクリックは増えているのに、問い合わせや購入が動かない。そこで見出し、画像、ボタン、フォームを一度に変えたものの、結局どの修正が効いたのか分からない——。LP改善で先に避けたいのは、この「全部直す」状態です。

図解

LP改善の優先順位

関連用語 CRO｜コンバージョン率最適化 訪問者が目的の行動へ進みやすいよう、ページを継続的に改善すること。

1. 1 計測 どこで離脱しているか確認
2. 2 訴求 誰の何を解決するか明確化
3. 3 信頼 判断材料と不安への回答を追加
4. 4 CTA 行動の内容と位置を整える

見た目の微調整より前に、伝達と行動の詰まりを直す。

LP改善は、見た目の採点ではなく、申込みまでのどこで判断が止まったかを特定する作業です。この記事では10項目を、流入・訴求・信頼・CTA・フォームの順に確認し、最初の一手を一つに絞ります。

最初に見るのはLPではなく、広告と計測のつながりです

LPだけを見ていると、流入の問題をページの問題と取り違えます。たとえば広告では「無料相談」と書いているのに、LPのファーストビューが会社紹介から始まれば、訪問者は期待した情報を見つけられません。検索広告から来た人と、既存顧客向けメールから来た人でも、知識量と検討度は異なります。

まず広告文、検索語句、配信先、LPの見出しを横に並べます。「誰が」「何を期待して」来たのかと、着地直後の約束が一致しているかを確認してください。ここがずれている場合、ボタンの色を変えても根本原因は残ります。

次に、申込み完了だけでなく途中の行動を測れる状態かを確かめます。最低限、LP到達、主要CTAのクリック、フォーム表示、送信完了を区別します。GA4のランディングページレポートは、セッションで最初に到達したページと利用状況を確認できます。探索のファネルデータ探索では、設定した順序に沿って利用者がどこまで進んだかを見られます。

ただし、イベント名が似ていても発火条件が違えば比較できません。ボタンクリックを成果としているのか、送信完了を成果としているのかを、タグ設定と管理画面の両方で確認します。

10項目は「流入→訴求→信頼→CTA→フォーム」の順に確認します

この表は採点表ではありません。上流で大きなずれが見つかったら、いったんそこで止めます。対象外の訪問が多いのにフォームだけ短くすると、申込み率が動いても商談につながらない可能性があるためです。

ファーストビューでは「3秒」より、伝わる内容を言葉で検査します

「3秒で伝わるか」という表現は便利ですが、全員が同じ秒数で判断するわけではありません。検査では、画面を見た人が次の3点を言い直せるかを確認します。

• 自分向けのページか
• 何を提供しているか
• 続きを読む、相談するなど、次に何をすればよいか

社内の担当者は商品を知りすぎているため、初見の人に見てもらいます。説明を加えず、見出し、補足文、主要な画像、CTAだけで上の3点を答えてもらいます。答えが割れた場合は、装飾ではなく主語と便益を直します。

表示性能も別に確認します。Core Web Vitalsは読み込み、操作への反応、表示の安定性を評価する指標です。単一の「表示3秒」だけで合否を決めず、PageSpeed InsightsやSearch Consoleの実ユーザーデータを見て、モバイルとデスクトップを分けて判断します。

信頼材料は多さではなく、申込み前の疑問と対応させます

会社ロゴ、受賞、利用者の声を並べるだけでは、訪問者の疑問に答えられないことがあります。BtoBなら「自社と同じ規模で使えるか」「導入時に誰が作業するか」「契約後に何が含まれるか」が判断材料になります。商品なら、価格、仕様、配送、返品条件などが先です。

実績数値は、何を1件と数えたか、いつまでの数字かを説明できるものだけ使います。許諾のない企業ロゴや顧客コメントは掲載しません。根拠を増やすために曖昧な「満足度」や架空の声を足すくらいなら、対象条件や対応範囲を具体的に書く方が安全で役に立ちます。

CTAとフォームは、クリック数ではなく完了までを一続きで見ます

CTAの改善では、色や大きさより先に文言を見ます。「詳しくはこちら」では、資料が開くのか、フォームへ進むのか分かりません。「料金表を確認する」「相談内容を入力する」のように、押した直後の行動を示します。

CTAクリックが多く、フォーム表示後に落ちているなら、LP本文よりフォーム側が候補です。必須項目、入力例、エラー表示、個人情報の扱い、返信の目安、営業連絡の有無を確認します。ただし、項目を減らせば常に良いわけではありません。初回対応に必要な情報まで削ると、後工程の確認が増えます。

営業担当やカスタマーサクセスにも、初回対応で必要な項目を聞きます。マーケティング部門だけでフォームを短くせず、「利用者の負担」と「適切に対応するための情報」の両方で決めます。

アクセスが少ないときは、数字を待つだけでなく定性確認を使います

訪問数や申込み数が少ないLPでは、率が一件で大きく動きます。この状態で「CVRが上がった」と断定するのは危険です。期間を延ばすだけでなく、問い合わせ内容、営業商談で出た質問、サイト内検索、ヒートマップ、操作観察を組み合わせます。

ヒートマップの熟読率が低いからといって、その位置が悪いとは限りません。上部だけで疑問が解決した人や、別の導線へ進んだ人も含まれます。数字は「原因の証明」ではなく、次に確かめる場所を絞る手掛かりとして使います。

定性確認では、最低5人といった固定数を万能な基準にしません。異なる解釈が出なくなるまで確認し、誰に見せたかを記録します。既存顧客だけでは初見のつまずきを見落とすため、想定顧客に近い未利用者も含めます。

一度に変えるのは、同じ仮説に属する要素だけです

症状から仮説を作るときは、数字を単独で読まないようにします。広告クリック後すぐに離れる人が多いなら、流入との不一致、表示不具合、読み込み、ファーストビューが候補です。本文は読まれているのにCTAへ進まないなら、提供内容、信頼材料、行動の重さが候補になります。CTAは押されるのに送信されないなら、フォームの入力負担、エラー、個人情報への不安を確認します。

ここで「離脱率が高いから悪い」と決めないことが重要です。電話番号を確認して離れた、店舗の場所を見て来店した、必要な情報を読み終えた、といったページ外の行動は、画面上の完了イベントだけでは見えない場合があります。目的の行動を先に定義し、その目的に必要な計測を決めます。

また、端末や流入元で結果が大きく違う場合は、全訪問者を平均した数字で判断しません。モバイルだけでフォームが操作しづらい、特定の広告だけ訴求がずれている、といった問題が平均値に隠れるためです。ただし、細かく分けすぎて一群の件数が極端に少なくなった場合は、傾向ではなく調査候補として扱います。

変更履歴には7つの項目を残します

厳密なA/Bテストを行えない場合でも、変更履歴は残せます。変更日、対象流入、観測した症状、仮説、変更内容、見る指標、判断日を一行にします。

同じ仮説に属する見出しと補足文を同時に直すことはあります。しかし、見出し、料金、フォーム、配信対象まで一度に変えると、学びが残りません。改善の目的は一回だけ数字を動かすことではなく、次の判断に使える知識を残すことです。

数字が動かなかった変更も、失敗として消さずに残します

変更後に差が見えない場合、「案が悪かった」とはまだ言い切れません。対象期間が短い、流入の構成が変わった、イベントが正しく発火していない、変更箇所まで到達した人が少ない、といった別の理由があります。まず変更前後で比較条件が揃っているかを確認します。

そのうえで、仮説、実施内容、観測結果、次の判断を残します。「効果なし」だけでは、数か月後に同じ案を繰り返します。「検索広告からの訪問ではCTA到達に明確な差を確認できず。フォーム到達者への聞き取りを先に行う」のように、どの範囲まで分かったかを書きます。

結果が出なかった記録も、次に触らなくてよい場所を絞る判断材料です。勝ち案だけを残すのではなく、条件と限界をセットで残してください。

まとめ：10項目から、最初の詰まりを一つ選びます

LP改善は、流入、訴求、信頼、CTA、フォームの順に確認します。すべてを同時に整えるのではなく、観測した症状に最も近い一か所を選び、仮説と変更履歴を残してください。

今日行うことは、広告文とファーストビューを横に並べ、主要CTAクリックと送信完了が別々に計測されているか確認することです。この二つが揃えば、次の修正を感覚だけで決めずに済みます。

仕様確認：Google Analytics「ランディング ページ レポート」、Google Analytics「ファネルデータ探索」、web.dev「Core Web Vitals」（2026年8月11日確認）。管理画面名や指標定義は変更される場合があるため、公開前に公式情報を再確認してください。