LPOとは？広告を増やす前に見直すLPの改善順序

LPOとは、訪問者が最初に開くページを見直し、申し込みや購入などの成果につながりやすくする取り組みです。

例えば、広告はクリックされているのに、問い合わせが増えない場合です。

広告費を増やす前に、LPで説明が足りないのか、ボタンが見つからないのか、フォームで操作が止まるのかを調べます。

最初に直す場所は、見た目の好みではなく、成果を妨げている根拠から決めます。

この記事では、計測の確認、広告とのつながり、操作の点検、施策の優先順位、変更後の検証までを順に説明します。

最後のシートを使えば、「なぜその修正を先に行うのか」を制作担当者やクライアントに共有できます。

製品の操作説明は2026年10月4日に確認した公式資料に基づき、数値例と優先順位の付け方は当記事が提案する架空の例です。

LPOで改善する範囲を決める

LPOでは、広告を押した人が、ページの説明を理解し、必要な操作を終えられるまでを確認します。

ただし、成果が少ない原因がすべてLPにあるとは限りません。

集客とページ内の課題を分ける

最初に、広告の配信先、LPへ来た後の行動、申し込み後の対応を分けて並べます。

例えば、法人向けサービスのLPに、個人利用を探す人が多く来ている場面を考えてください。

ページを読みやすくするだけでは、対象の違いを解消できない可能性があります。

反対に、対象に合う人が来ていても、料金や申し込み条件が分からなければ、判断を先送りされるかもしれません。

以下のように、確かめる内容と担当者を分けると、LPの制作担当者だけに調査が集中するのを防げます。

範囲	最初に確かめること	相談する相手の例
広告からLPまで	どんな人へ、何を約束しているか	広告運用担当
LPからフォームまで	判断に必要な説明と入口があるか	制作・マーケティング担当
フォームの完了まで	入力、エラー修正、送信ができるか	開発・フォーム管理担当
申し込み後	対応できる問い合わせか、連絡できるか	営業・顧客対応担当

Googleもランディングページの利便性について、広告をクリックした人の期待と、ページの関連性や操作のしやすさを挙げています。[1]

調べる範囲が決まったら、今回はどこまで直すのかを一行で残します。

成果の定義をそろえる

LPOを始める前に、何をコンバージョンとして数えるかを決めます。

コンバージョンは、事業にとって成果とする行動のことです。

問い合わせボタンのクリック、フォームの送信完了、商談の成立は、別々の出来事です。

「CVが増えた」という言葉だけでは、どの段階が改善したのか分かりません。

問い合わせを増やしたいなら、送信完了を主な成果にし、ボタンのクリックは途中の行動として追う方法が考えられます。

さらに、率を比べる場合は分母をそろえます。

訪問したセッションを分母にするのか、訪問者を分母にするのかを、計測担当者と決めてください。

例えば「対象LPから始まったセッションのうち、問い合わせを完了したセッションの割合」と書けば、比較したい範囲が明確になります。

業務システムの受信件数とアクセス解析のイベント数も、同じものとして扱わず、別の欄で確認します。

LPの現状を指標で確認する

改善前には、対象LPのURL、期間、流入元、端末、成果の定義を記録します。

この条件が残っていれば、修正後に同じ問いで振り返れます。

流入別の成果を確認する

全体平均を見るだけでは、特定の広告やスマートフォンだけにある課題を見落とすことがあります。

GA4を使っている場合は、「レポート」から「ランディング ページ」を開き、対象のURLを絞ります。[2]

レポートがメニューにない場合は、編集権限のある担当者に追加を依頼してください。[2]

次に、セカンダリディメンションへ「セッションの参照元 / メディア」を追加すると、入口のページと流入元を合わせて確認できます。[2]

調査では、広告の名前だけでなく、同じ期間にどんな配信変更があったかも残しましょう。

以下は、全体と内訳を分けるための架空の例です。

対象	セッション	問い合わせを完了したセッション	完了した割合
広告経由・スマホ	800	8	1%
広告経由・PC	200	10	5%
合計	1,000	18	1.8%

この表から言えるのは、同じ条件で集計した場合に、端末ごとの結果が違うということです。

スマホのデザインが原因だとまでは断定できません。

広告の内容や利用者の違いも確認しながら、まずスマホで完了まで操作できるかを調べる材料にします。

計測の不備を先に調べる

成果イベントの設定に誤りがあると、修正の効果も正しく判断できません。

例えば、送信に失敗しているのに、ボタンを押すたびに「問い合わせ完了」が記録される場合です。

この状態でボタンのクリックが増えても、実際の問い合わせが増えたとは言えません。

テストでは、成功だけでなく、未入力によるエラー、二重クリック、完了画面の再読み込みも確認します。

テストする操作	確かめること
入力不足で送信する	失敗を完了として数えていないか
正常に送信する	受付の成功と成果イベントが対応するか
ボタンを続けて押す	意図しない重複が起きないか
完了画面を再度開く	新しい申し込みとして数えていないか

GA4のDebugViewでは、デバッグモードを有効にした端末から送られるイベントを確認できます。[3]

Google Tag Assistantのプレビューを使い、GA4の「管理 → データの表示 → DebugView」で、自分のテスト操作とイベントを照合します。[3]

同意やブラウザの条件で表示されない場合もあるため、DebugViewにないことだけで原因を決めつけず、設定担当者と確認してください。[3]

LPの訴求と説明を点検する

LPには、広告で興味を持った人が、申し込むかどうかを決めるための情報が必要です。

情報を増やす前に、何を期待して来た人に、何を説明するページなのかをそろえます。

広告で約束した内容を確認する

配信中の広告を一つ選び、広告文とリンク先の最初の画面を並べて見ます。

広告の見出し、画像内の言葉、説明文、ボタンを確認し、訪問者が期待しそうな内容を書き出してください。

例えば「無料で料金表を確認」と書いているのに、到着先では営業相談の予約だけが目立つ場合です。

料金表を見たい人にとって、次に何をすればよいか分かりにくい導線になります。

対応としては、料金表を見る入口を明確にするか、実際に提供する内容へ広告の表現を合わせます。

ページだけを書き換える前に、広告側の約束が実際のサービスと合っているかも確認します。

Googleの案内でも、広告の行動喚起と、キーワードやリンク先の内容のつながりが重視されています。[4]

スマホでは、見出しの途中で改行されても意味が通じるか、案内が固定ボタンに隠れないかも見ます。

大きな文字があることより、何ができるページかが一度で伝わることを確認してください。

料金や条件の不足を確認する

訪問者が申し込み前に知りたいことを、営業や顧客対応の担当者と整理します。

料金、対象者、利用を始めるまでの流れ、申し込み後の連絡、利用できない条件などが候補です。

例えば「無料」と案内するなら、無料で使える範囲と、料金が発生するタイミングを確認します。

条件を小さな文字へ追いやるのではなく、判断する場所の近くに置きましょう。

以下の表を埋めると、単に説明を増やす作業から、必要な答えを探しやすくする作業へ進められます。

訪問者の疑問の例	自社で確認する事実	置く場所の候補
自分も利用できるか	対象業種、地域、利用条件	サービス説明の近く
いくらかかるか	初期費用、継続費用、追加料金	料金と申し込みの近く
押した後に何が起こるか	資料表示、登録、相談予約のどれか	ボタンの文言と周辺
いつ使い始められるか	必要な準備と対応の流れ	導入手順の近く

回答できない項目は、都合のよい言葉で埋めず、社内の確認先を残します。

LPの操作上の問題を調べる

必要な説明があっても、見つけられない、押せない、送れない状態では成果につながりません。

集計で気になる場所を探し、個別の操作で何が起きているかを確かめます。

ヒートマップで到達を確認する

ヒートマップは、ページ上のクリックやスクロールなどを集計して見るための道具です。

まず、対象URL、期間、端末を選び、調べたい位置を決めます。

Clarityのスクロールマップでは、ページの各位置まで到達した訪問者の割合を確認できます。[5]

料金説明や問い合わせボタンの位置に合わせて、そこまで届いているかを調べてください。

ただし、到達したことと、文章を読んで理解したことは別です。

到達が少ない場合も、長すぎる説明だけが原因とは限りません。

上部の別のボタンから先へ進んだり、必要な答えをすでに得たりしている場合があります。

期間中にレイアウトを変更したなら、変更前後のデータが混ざっていないかも確認しましょう。

SiTestのように、スクロールやクリックなどを異なるマップで確認する製品もあります。[6]

ツールの色をそのまま評価にせず、「どの操作を、どの条件で集計した図か」を説明できる状態にします。

録画でエラーを確認する

セッションリプレイは、ページ上の操作の流れを後から確認するために使います。

ヒートマップで気になったページについて、同じ端末や期間の記録を探します。

例えば、フォームの送信ボタン付近で操作が繰り返されている場合です。

ボタンが反応しないのか、入力エラーが上部に出ていて気づけないのかを、前後の操作から調べます。

Clarityには反応のないクリックなどを確認する機能がありますが、その表示だけで不具合が確定するわけではありません。[7]

自分のブラウザでも同じ操作を試し、端末、画面幅、入力条件を記録します。

観察したことの例	続けて確認すること
同じボタンを繰り返し押す	通信中の表示と、クリック後の応答
エラー後にページを上下する	エラーの場所と、直し方の説明
メニューを開いた後に進めない	閉じる操作と、他の要素との重なり
入力後に前の画面へ戻る	戻った後に入力内容が残るか

録画を確認するときは、対象ページのマスキングと、共有相手の範囲を設定済みであることも確かめます。

再現できる不具合が見つかったら、デザイン案の比較より先に、修正担当者へ事実を渡します。

LPO施策の優先順位を付ける

優先順位は、影響する範囲、根拠の強さ、実装の負担を別々に書いて決めます。

三つを最初から一つの点数にすると、まだ分からないことまで確かな数字に見えてしまいます。

影響と確からしさを分ける

まず、再現した不具合と、これから確かめる仮説を分けてください。

申し込みできない操作を再現できた場合と、ボタンの色が目立たないと感じた場合では、根拠の種類が違います。

影響がありそうな人数だけでなく、何を見て判断したかを残します。

以下は、優先順位を考えるための架空の例です。

候補	影響範囲	根拠	判断の例
スマホの送信エラーを直す	対象の入力条件で申し込む人	自分の端末でも再現	先に修正を依頼
無料の範囲をボタン付近に示す	無料利用を検討する人	問い合わせで質問が繰り返される	文案を作り、検証
CTAの色を変更する	ボタンに到達する人	現時点では担当者の印象	他の根拠を集めて判断

どのLPでもフォームが最優先、どのLPでも最初の画面が最優先、という固定順にはしません。

そのページで確認できた問題と、まだ仮説の段階にある問題を区別することが、着手順の土台です。

分からない欄は「未確認」とし、次に何を調べるかを書きます。

実装負担を見積もる

次に、変更に必要な作業と、戻せる方法を確認します。

見出しの変更でも、翻訳、広告審査、法務確認、複数ページへの反映が必要なら、単純な文字修正では済みません。

制作担当者へは、直したい場所だけでなく、理由と完了条件を渡してください。

例えば「ボタンを大きくする」だけでは、どこまで直せばよいか曖昧です。

「スマホで固定バナーに隠れていた問い合わせボタンを、通常の操作で押せるようにする」と書けば、確認する操作が決まります。

作業を決める欄	記入内容
変更する箇所	ページ、要素、対象端末
変更する理由	観察記録、再現条件、利用者の質問
実装担当	制作、開発、広告運用など
完了の確認	実際に試す操作と、期待する結果
戻す方法	変更前の版と、戻す担当者
結果を見る日	確認する期間と、判断する指標

必要な確認が終わり、結果を評価できる単位で、最初の施策を選びます。

LPOの改善を検証する

修正後は、ページが正しく動くかと、事業の成果につながったかを分けて確認します。

公開できたことだけを、LPOの成功とは扱いません。

同時に変えた条件を残す

ページを修正した日には、広告の配信先、予算、価格、キャンペーン、フォームの変更も記録します。

例えば、LPを変えた日に広告の配信先も広げたなら、結果の変化をLPだけの効果とは説明できません。

A/Bテストでは、元のページと変更したページを同じ期間に出し分け、決めた成果を比較する方法があります。

Ptengineも、ページの案を出し分けて仮説を検証する機能を提供しています。[8]

ただし、ツールを使えば少ない件数でも必ず判断できるわけではありません。

必要な期間や件数は、普段の成果の割合と、見分けたい差などによって変わります。

事前に主な指標と判断方法を決め、途中で都合のよい数字だけを選ばないようにします。

前後比較で確認する場合は、配信条件や曜日などの違いを記録し、原因を特定できる範囲に限界があることも共有してください。

結果が不明なら、勝敗を付けずに、観察できた事実と次の確認を残します。

CVの質まで確認する

問い合わせが増えても、対応できない依頼や連絡できない申し込みが増えたなら、事業にとって良い変更とは限りません。

LP側の完了数と合わせて、営業や顧客対応で分かる結果も確認します。

例えば、対象に合う問い合わせか、相談へ進んだか、購入後の取消が増えていないかといった情報です。

件数だけを見るために、対象者や料金の条件を曖昧にすると、申し込み後の負担が増える可能性があります。

確認する指標は、事業の目的に合わせて選んでください。

最初の施策を決めるには、次のシートをコピーして埋めるところから始められます。

LPOの課題・優先順位シート	自社で書くこと
対象のLP	URLと主な流入元
増やしたい成果	完了条件、分母、重複の扱い
現状の条件	期間、端末、流入、母数
確認できた問題	観察した操作と、再現の結果
原因の仮説	まだ確かめていない理由
最初に直す箇所	変更内容と、先に選ぶ根拠
担当と公開日	実装・確認・判断の担当
評価するもの	完了数、完了率、問い合わせの質
結果と次の作業	継続、再調査、戻す判断

LPOは、一度の全面改修で終わる仕事ではありません。

計測できる状態を整え、根拠のある問題から直し、同じ条件で結果を確かめる流れを作ります。

録画とヒートマップをまだ使っていない場合は、Microsoft Clarityの機能と導入条件も参考にしてください。

AgentSignalで確認する手順は、録画とヒートマップの使い方にまとめています。