LPにアクセスはあるのに申し込みがない原因と改善チェックリスト

LPから申し込みまでの流れを確認するイメージ

こんにちは。バナナデスクです。

LPにはアクセスがあるのに、申し込みのお知らせが来ない。そんな日が続くと、見出しの言葉や商品の説明を、何度も直したくなりますよね。

ここで一つ、確認したいことがあります。「お知らせが来ない」と「申し込みがない」は、同じでしょうか。受付記録は残っているのに通知だけが届かない場合もあれば、申し込もうとした人がフォームのエラーで止まっている場合もあります。

文章を磨く前にここを分けておくと、直すべき場所を見失いにくくなります。私なら、受付記録と、自分のスマートフォンで申込先まで進めるかを先に確かめます。

この記事では、その確認から始めて、流入元とのずれ、商品説明、入力フォームへと点検を進めます。チェックリストを使って、自分のLPで最初に直す場所を絞っていきましょう。

最初に「申し込みがない」の意味をそろえる

LPにアクセスがあるのに申し込みがないときは、受付記録、フォームの動作、計測、流入元と説明の一致を順に確認します。通知が来ないことと、実際の受付がゼロであることを分けると、見出しやボタンを直す前に原因を絞れます。

管理画面に受付がないのか、通知メールが来ないのか、アクセス解析の数字がゼロなのか。この3つは同じではありません。まず同じ期間の受付記録・通知・計測を並べ、次のように切り分けます。

確認結果に応じて、最初に直す場所を選ぶ
確認できた状態 次の確認 最初の作業
受付記録はあるが、通知が来ない 送信先、迷惑メール、送信失敗の履歴 通知の問題を直す。受付件数をゼロとして扱わない
受付記録はあるが、解析はゼロ テスト受付時に完了の計測が動くか 計測条件を確認する。ページの文章だけを変えない
受付記録がなく、操作するとエラーで止まる どの端末・入力・手順で再現するか 再現したフォームの不具合を直す
受付記録はなく、テストでは完了できる 訪問者の流入元と、LPの対象・条件 次の手順で期待のずれや説明不足を調べる

管理画面の期間や表示条件が違えば、記録の比較もずれます。テスト日時と受付内容を控え、同じ1件をそれぞれの場所で探すと、どこまで届いているかを確かめやすくなります。

手順1:自分で申し込みの最後まで操作する

まず、普段の管理用ログインとは別の状態でLPを開きます。テストとして扱える方法を用意し、不要な注文や本番決済を発生させない範囲で、申し込みから受付までを確認してください。

  1. スマートフォンで、最初の画面から申込先へ進む。
  2. 必須項目が分かり、必要な情報を入力できるか見る。
  3. 入力漏れや形式違いを作り、エラーの場所と直し方が分かるか確認する。
  4. 修正後、入力した内容を必要以上に失わず進めるか見る。
  5. 完了画面、受付記録、通知のそれぞれを確認する。

テスト日時、端末、ブラウザ、止まった場所をメモします。「動かなかった」だけではなく、「必須の電話番号に形式指定がなく、送信後にエラーになった」まで書ければ、修正対象を絞れます。

ここでエラーを再現できたなら、広告や文章の比較より先に直します。修正後は同じ端末・入力で再テストし、受付記録が残るところまで確かめてください。

照合例:送信を4回押しても、受付は1件という場合

「送信ボタンを押した回数」を申込件数とすると、どんな食い違いが起きるでしょうか。次は、同じ人が入力をやり直した状況を表す架空の操作ログです。実際の顧客データや改善実績ではありません。

説明用の操作ログ:同じ受付番号を追う
時刻と操作 システム側の結果 新しい受付件数
10:00 送信を押す 必須項目の入力エラー。受け付けず 0件
10:02 直して送信 通信先で処理に失敗。この例では受付なし 0件
10:04 再送信 受付番号A001を保存。完了画面へ 1件
10:05 完了画面を再読み込み A001の完了画面をもう一度表示 0件
10:06 同じ申込を再送信 重複を判定し、既存のA001を返す 0件

このログでは送信操作が4回、完了画面の表示は少なくとも2回ありますが、新しい受付番号は1件です。ボタンクリックや完了画面の表示をそのまま成果へすると、受付記録と合いません。完了画面の再読み込みや重複送信で、成果が増えないかも点検します。

実装では、フォームの受付成功を確認し、利用できる場合は受付番号などで照合・重複除外する方法を検討します。氏名やメールアドレスを解析ツールへ送る設計にする必要はありません。フォームが提供する成功イベントや連携機能を使い、必要な状態だけを計測します。

また、通信エラーが表示されても、サーバー側では受け付け済みのことがあります。上の10:02は「受付なし」と分かった仮例です。現場では画面の表示だけで決めず、同じ時刻の受付記録を調べてから再送の扱いを判断してください。

通知・受付・解析を、同じ1件で確認する記録欄

テストを始める前にコピーするメモ

テスト日時・タイムゾーン:
端末・ブラウザ・流入元:
試した入力と操作:
期待する結果:
画面に出た結果:
受付番号と記録の有無:
通知の到着・送信失敗:
解析に記録された状態と回数:
ずれた箇所・次に確認する場所:

運営側だけで完了する確認にせず、スマートフォンの入力、エラー修正、完了までを通します。本番で課金や契約が発生するフォームは、用意されたテスト環境・テスト手順を使ってください。

手順2:流入元の約束と、LPの答えをつなぐ

LPの文章だけを読む前に、直前に見た広告・記事・メールも開いてください。人はその案内に期待してページへ来ます。入り口で「初心者向けの作り方」と伝えたのに、到着先では前提説明のない高額な代行サービスだけが並んでいないでしょうか。

期待のずれを見つける仮の例
入り口の期待 LPの状態 確認・修正の方向
自分で初めて作りたい 全面代行だけを説明 対象が違うことを明確にし、入り口も見直す
料金を比較したい 料金や見積条件が分からない 金額・条件・変動要因を示す
一部だけ相談したい 相談と契約の区別が曖昧 次の操作で何が起きるか説明する

この段階で問いたいのは、説得が強いかより、「来た人が必要とする答えがあるか」です。対象外の人に無理に申し込んでもらうより、誰に向く提供内容かを明確にしたほうが、その後のやり取りも整えやすくなります。

記事から登録へ案内する場合は、配布まで同じ約束を通す

LPの目的が有料サービスの申し込みではなく、資料請求やメルマガ登録の場合も、入口の期待と受け取るものを照合します。記事を読む、登録案内を見る、入力する、受付が完了する、最初の資料を受け取る、は別の出来事です。登録ボタンのクリックだけで「特典が届いた」と数えないようにしましょう。

たとえば、サービス紹介文の書き方を説明した記事から案内するなら、「記入例付きの下書きシート」が次の作業に合うかもしれません。これは説明のための仮例です。記事内で紹介文の作り方を十分に説明し、シートは自分の条件を当てはめる補助として位置づけます。

登録から配布までの約束を照合する仮例
場面 見える説明と確認すること
記事の案内 紹介文の下書きを整理するシートであることを伝える
短い登録LP 対象者、完成するもの、PDFなどの形式、受取方法、継続して届くメールの内容を明示する
登録受付 入力内容と同意を確認し、受付記録が残るかを試す
最初の配布 案内と同じ名前のシートが見つかり、スマホでも開けるかを試す

配布ができていても登録が少ないなら、記事を読んだ後に必要な作業と、特典が助ける作業がつながっているかを見直します。反対に、登録はあるのに資料が開けないなら、案内文を強くする前に配布の不備を直します。広告宣伝メールの同意や表示などは、消費者庁の案内も確認してください。

手順3:対象・提供物・条件を、見える言葉にする

「あなたのビジネスを次のステージへ」と書かれていても、何を受け取れるのかは分かりません。最初の画面と詳しい説明を合わせて、少なくとも次を判断できるようにします。

  • どんな状態の人を対象にしているか。
  • 相談、添削、制作代行など、何を提供するか。
  • 納品物や対応する範囲はどこまでか。
  • 料金・期間・回数・事前準備などの条件は何か。
  • 対象外の作業や、別料金になる部分はあるか。
  • ボタンを押すと、相談・申込・決済のどこへ進むか。
架空の商品例。LPの修正案というサービスについて、対象は公開済みLPがある人、提供物は1ページを確認した修正案と具体的に示す。
説明用の架空例です。実際のLPでは、提供する内容に合わせて料金・期間・対応範囲も示します。

説明用の架空サービスで、書き換えてみます。「集客を改善します」だけでは、相談なのか制作代行なのかが分かりません。

サービス説明の書き換え例

変更前:あなたのビジネスの集客を改善します。

変更後:公開済みのLPがあり、どこから直すか迷っている方向けの点検です。1ページを対象に、想定読者・提供内容・フォームの3点を確認し、修正の優先順位と理由を文章でお返しします。デザイン制作やサイトへの実装は含みません。

対象・受け取れるもの・対象外まで書くと、検討する人が自分に合う支援か比べられます。料金や納期なども実際の提供条件に合わせて補ってください。架空の例を、そのまま自社の約束として使わないようにします。

最初の画面へ全条件を押し込む必要はありません。そこで概要をつかめて、詳しい条件へ迷わず進めるかを見ます。商品説明を画像だけに閉じ込めず、本文でも読めるようにすると確認しやすくなります。

第三者に見てもらうときは、感想より質問で確かめる

「このLP、どうですか」と聞くだけでは、好みの感想になりがちです。内容を知らない人に見てもらえるなら、次の5問を使ってみてください。これは統計的な検証ではなく、説明の抜けを探す確認です。

  1. 誰のためのサービスだと理解したか。
  2. 何を受け取れると思ったか。
  3. 料金や利用条件を、どこで確認できたか。
  4. 申し込む前に、まだ知りたいことは何か。
  5. このボタンを押したら、次に何が起きると思ったか。

回答が想定と違ったら、こちらが口頭で説明して納得してもらう前に、どの文を見てそう理解したかを聞きます。LPだけを見た人にも同じ情報が届くよう、該当箇所を直します。

手順4:相談・申込・決済の違いを、ボタンの前で伝える

LPの説明が整っていても、最後の操作が曖昧だと迷いが残ります。例えば「詳しくはこちら」というボタンの先で、いきなり長い申込フォームが出る場合を考えてみてください。読者は説明を読むつもりだったのか、相談するつもりだったのか、購入を決めていたのか。その状態で必要な案内は違います。

仮に次が事前相談なら、「事前相談の内容を送る」など、実際の操作に合う表現を候補にできます。次が購入の申込なら、そのことが伝わる言葉を使います。送信した時点で何が始まり、その後どんな連絡があるかも、事実に沿って説明してください。

ボタン周辺の点検例
読者の疑問 確認する説明
何を送るのか 相談内容か、正式な申込情報か
送信後はどうなるのか 連絡方法や、実際に対応できる時期の案内
まだ比較したい 料金・提供範囲・条件へ戻って確認できるか
入力する理由は何か 今必要な情報と、任意項目の区別

「不安を取り除く」という抽象的な改善も、こうして一つの疑問へ分けられます。例えば、連絡方法が分からないことへの迷いなら、実際の連絡方法を示します。理由が分からない電話番号欄なら、必要性を見直し、必要な場合は用途を説明します。

ただし、問い合わせを増やすために「相談だけ」と書きながら、実際には契約を前提に進めるような食い違いは作りません。ページ上の約束と、その後の対応が一致しているかまで確認します。LPの外で起きることも、読者にとっては同じ申し込み体験です。

手順5:フォームで迷う場所を減らす

申し込みの意思があっても、入力項目の意味が分からなかったり、エラーを直せなかったりすれば止まります。フォームでは、入力をお願いする理由と、必要な操作を分かるようにします。

W3Cのフォーム解説は、入力欄に分かりやすいラベルを付けることや、エラーの内容と修正方法を伝えることを説明しています。入力項目のラベル、エラー・完了の通知の案内が参考になります。

  • 入力を始めた後も、項目名が確認できる。
  • 必須と任意の違いが分かる。
  • 指定の形式があるなら、入力前に説明されている。
  • エラーになった項目と直し方が分かる。
  • 送信後、受け付けられたかが分かる。

項目は少なければ必ずよい、という判断もしません。見積もりに必要な情報を削りすぎれば、その後の確認が増えるかもしれません。今この段階で必要か、後で聞けるか、なぜ聞くかを一つずつ確かめます。

仮の数値例:大きな離脱だけで原因を決めない

操作と説明を点検したうえで、データを見ます。次は同じ期間・同じユーザー集団を、順番に追えたと仮定した説明用の数値です。実績や業界平均ではありません。

仮例。LP訪問100人、フォーム表示40人、入力開始10人、受付完了2人。各段階を分けて計測する。
説明用の仮例です。人数の減り方だけで原因は確定できません。計測の定義と受付の動作を先に確認します。
同じ100人を順に追った仮例
段階 人数 前段階からの割合
LP訪問 100人 起点
フォーム表示 40人 40%
入力開始 10人 25%
申込完了 2人 20%

全体の完了率は2÷100で2%です。人数としてはLPからフォーム表示までで60人減っています。一方、割合だけを見ると、入力開始から完了まででも大きく減っています。どちらを先に調べるかは、数字だけで決まりません。

この割合を自分の表で使うときは、分母がユーザー数なのか、訪問回数なのかを明記してください。同じ人が何度もLPを開いたページビューと、重複を除いた受付人数を組み合わせると、上の例とは別の指標になります。イベント名だけで判断せず、何を一回として数えているかも記録します。

また、テスト送信が含まれているか、同じ受付が二重に記録されていないかも確認します。割合を細かく計算する前に、元の記録と集計条件が合っていることを確かめると、その後の比較を誤りにくくなります。

フォームでエラーが再現するなら、そこを先に直します。正常に動いていて、流入元と対象がずれているなら、入り口を見直します。観測した数字と、実際の画面で確かめたことを合わせて優先順位を決めます。

GA4のファネルデータ探索は、定義したステップごとの行動を確認できます。途中から入る人を含めるか、どの順序で完了した人を数えるかで集計は変わります。単純なイベント発生回数を並べて、同じ人の離脱だと解釈しないようにしてください。Google公式:ファネルデータ探索

「完了」は送信ボタンのクリックだけで数えない

ボタンを押しても、入力エラーや通信失敗で受け付けられていない場合があります。先ほどの表を自分の計測へ置き換えるなら、各段階が何を表すかを先に決めます。

計測する状態を決める見本
段階 この分析で捉えたい状態 テストで確かめること
LP表示 対象LPが表示された 別ページやテストアクセスが混ざっていないか
フォーム表示 対象フォームが実際に表示された フォームへ進むボタンを押しただけで数えていないか
入力開始 対象フォームへ最初の入力をした 開いただけで入力開始になっていないか
申込完了 システムが受け付け、受付記録が残った エラー時や二重クリック時に、誤った完了が増えないか

これはイベント名の指定ではなく、計測したい状態の定義です。設置方法はフォームや計測ツールで異なります。測れない段階を推測で埋めず、確認できた範囲を記録し、同じ条件で比較してください。

アクセスが少ないときの改善と、記録の残し方

数人の行動だけでA案とB案の優劣を決めようとすると、たまたまの違いを拾う可能性があります。その段階では、受付の不具合、説明の不足、入力の迷いなど、現物を確認して直せることを優先します。

一つの改善を残す記録例
観測 スマートフォンで、入力エラーの場所が分かりにくい
根拠 テスト日時・端末・操作と、表示された文言
修正 対象項目の近くに、理由と入力例を表示
直後の確認 同じ操作でエラーを直し、完了まで進めるか
後から見ること 同じ集計条件で、入力開始から完了までの変化

修正後は同じ操作で動作を確かめ、その後で一定の期間の行動を見直します。前後で流入元が変わったなら、その変化も記録してください。良くなった数字をすべてコピーの効果にせず、次に使える判断を残します。

アクセスが少ない段階で、最初に直すもの

LPの修正に着手する順番の目安
見つかった問題 先に行うこと 修正後の確認
送信できない/受付が失われる 再現する不具合を直す 同じ入力で受付記録が残る
料金・対象・申込後の説明が事実と違う 実際の提供条件と一致させる LPだけで次の操作を判断できる
受付はあるが、計測だけが合わない イベントと集計の定義を直す テスト1件を記録同士で照合できる
動作も説明も整い、候補が複数ある 一つの仮説を決め、比較条件を記録する 件数・期間・流入条件を見て判断する

「アクセスが100件あれば必ず結論が出る」といった共通の基準は置きません。元の申込率や検出したい差で必要な件数は変わります。今すぐ再現できる不備の修正と、比較データを待つ改善は、別の仕事として扱いましょう。

A/Bテストを始める前に、差と期間を見積もる

比較をするなら、まず「何を一件と数えるか」「どれくらいの差なら判断を変えるか」を決めます。申込率が3%から3.6%へ変わる例では、差は0.6ポイント、元の3%に対しては20%の増加です。相対20%と20ポイントを混同すると、必要な件数の見積もりが変わります。これは説明用の数値で、当ブログの実績ではありません。

Optimizelyの公式解説は、元のコンバージョン率と、検出したい最小の差が必要なサンプル数に関わることを説明しています。さらに、各案の必要人数を合計し、実験へ割り当てられる人数で割ると、おおよその期間を考えられます。Optimizely:MDEと実験の優先順位。統計手法や設定によって計算は異なるため、同社の計算結果をすべてのツールへ流用はしません。

A/Bテストの期間を考える仮の計算。必要人数を算出した例ではありません
項目 この例の仮定
比較する案 A・Bの二案へ均等に割り当てる
計画上の必要人数 各案6,000人と仮置き。利用する検定設計で別途算出が必要
合計 6,000×2=12,000人
一日で新しく実験へ入る対象者 100人と仮定。ページビューや再訪回数は含めない
人数が集まるまでの単純計算 12,000÷100=120日。流入が一定の場合

「各案6,000人」は3%と3.6%から計算した必要人数ではなく、期間の式を説明する仮置きです。実際には、元の率、検出したい差、統計手法、誤判定を扱う設定などをそろえ、利用する仕組みで設計します。また、人数を満たせば必ず差が見つかるわけではありません。

この期間が現実的でなければ、実験のためだけに長く放置せず、操作で再現する不具合や、読者が誤解した説明を先に直せます。比較を続ける場合は、対象・指標・割当・期間と判定方法を事前に残し、都合のよい日だけ切り取って勝ち負けを決めないようにします。

単に修正前の月と修正後の月を比べる方法は、同じ時期に無作為に割り当てたA/Bテストとは異なります。季節、流入元、価格なども変わるため、前後の差を見出しの変更だけの効果と断定しません。

よくある疑問

まず広告を増やしたほうがよいですか?

受付と計測が動き、対象の人に何を届けるページか確認してから判断することを勧めます。広告を増やせば原因が分かるとは限りません。進めない箇所があるなら、先に直せます。

実績が少ないと、何を根拠にすればよいですか?

提供範囲、納品物の見本、進め方、確認できる資格や経験など、実際に示せる材料を使います。お客様の声を作ったり、他社の成果を自分の実績のように見せたりしません。何を約束し、何を約束しないかも、検討する人に必要な情報です。

今日は、受付記録と1回の操作から始める

まず受付記録を開き、次にスマートフォンで一度、申込先から受付完了まで確かめてみてください。通知の問題、操作の問題、説明の問題を分けるところから始められます。

見つかった不備のうち一つを直し、同じ操作で再確認します。色や文言を何度も替える前に、「何を確かめ、なぜ直したか」が残る改善にしましょう。

更新日:2026年9月30日。本文で仮例・例文と記した内容は説明用であり、当ブログや顧客の実績ではありません。

関連する記事

コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

CAPTCHA