ACQUA JOURNAL
LP公開前チェックリスト30項目｜広告・受付・計測と公開判断
LPを公開する前には、広告に書いた約束と、到着するページ、申し込みの受付、成果の数え方を揃える必要があります。画面がきれいに仕上がっていても、広告から別のプランへ到着したり、受付できていない送信を成果として数えたりすると、公開後の判断を誤ります。確認する対象を、LPの一画面から、訪問者と受付担当者の行動へ広げましょう。
この記事は、LPの制作を発注する担当者と、広告・営業・Web運用を担当する人向けのチェックリストです。公開前から運用中までの30項目を、広告、訴求条件、表示と操作、フォーム受付、計測、公開判断、再確認の7つに整理しました。各項目には、確認日、担当、結果、残る課題を添えて使ってください。使わない機能は「対象外」とし、理由を残せば、自社のLPに合う確認表になります。
Google広告、Google Analytics、W3Cなどの一次資料を参照しました。確認日は2026年9月10日です。Google広告の要件は同サービスを使用する場合の条件であり、すべての媒体のルールを代用するものではありません。資料請求や点検サービス、担当者のメモは説明用の架空例です。公式文書にあるエラー例も、特定のお客様の失敗談とは区別しています。
30項目は、公開判断を具体化するための道具です。すべてに印を付ければ売上が上がる、という保証ではありません。訪問者がどこで迷うかを調べる方法はLP公開前のユーザーテスト、企業サイト全体の実装とCMS更新の確認はホームページの公開前チェックで補えます。
1. 広告の設定から、正しいLPへ到着できるか確認する
制作会社から届いたURLと、広告の設定を照合する
確認の出発点は、公開予定のLPと、広告側へ設定するURLの組み合わせです。制作会社から送られた確認用URLを開けても、そのURLが広告のリンク先として使われるとは限りません。広告担当と、対象キャンペーン、広告の文面、最終ページのURL、計測用の設定を共有し、どの組み合わせを試すか決めます。
複数のプランや地域別のLPがある場合は、似たページの取り違えも対象です。例えば、法人向けの広告から個人向けの申込ページへ進めてしまうと、ページ自体が正常でも意図した案内にはなりません。リンクが開くことと、その広告を見た人に合う内容へ到着することを、別の観点として見ます。
実際の広告を自分で何度もクリックして確認する方法に頼らず、広告媒体が用意するテスト方法やプレビューを広告担当に確認します。クリック測定サービスや外部の予約サービスが関わる場合は、その担当者にも確認範囲を共有します。誰がどの設定を管理しているかを先に揃えると、問題があったときの連絡先が明確になります。
項目1〜4：URLと到着先を確認する
- 公開用URLを指定しているか。確認用のURL、古いLP、入力途中のURLが混ざっていないかを、広告設定と公開予定の一覧で照合します。対象広告と確認日時も記入します。
- 計測設定を含めても同じ内容へ到着するか。パラメータやトラッキング設定を含めた経路を試し、到着したページの見出し、プラン、資料を確認します。
- 意図しないエラーや閲覧制限がないか。一般の訪問者が使う条件でページを開きます。広告媒体による取得の確認が必要な場合は、広告・制作担当へ結果を確認します。
- 広告と到着先が対応しているか。表示されるドメイン、案内するサービス、地域、申込方法を照合します。転送がある場合は、その理由と最終的な到着先も記録します。
公式のエラー例を、確認漏れの発見に使う
Google広告のリンク先の要件には、表示URLと最終ページのドメインが異なる例や、最終ページとトラッキング設定で別の内容へ誘導する例が掲載されています。後者は、同じサイトの中であっても、計測経路によって着く内容が変わる問題として読めます。自社の設定でも同じ種類の取り違えがないかを確認しましょう。
また、公式のランディングページのテスト方法には、テストの対象や結果の説明とともに、ポリシー違反を確認する機能ではないこと、すべての計測エラーを検出するものではないことが記されています。「テストでページが見つかった」ことを、広告全体の審査や業務上の準備が終わったという報告に置き換えないようにします。
不一致が見つかった場合は、LPをすぐ作り替える前に、広告設定、転送、計測設定のどこで行き先が変わったかを担当者と確認します。原因を特定して修正した後は、同じ広告と設定の組み合わせで再確認し、実施した範囲を残します。
2. 広告・LP・受付で、約束する内容と条件を揃える
強い表現より、判断に必要な条件を確認する
広告とLPでは、同じサービスを別の長さで説明します。広告では短く伝えていても、LPでは誰が利用でき、何を提供し、何が対象外なのかを確認できる状態が必要です。「無料」「すぐ対応」「定額」などの言葉を使う場合は、利用者がその言葉から期待する内容と、実際の提供条件を照合しましょう。
架空の設備点検サービスで「無料相談」と案内するなら、無料なのが最初の電話相談なのか、現地確認まで含むのかを揃えます。営業担当者は当然と思っている条件でも、初めて訪れる人には分かりません。条件があることを小さな文字だけで知らせるより、申込判断に必要な場所で説明できているかを見ます。
Google広告の不実表示に関するポリシーは、商品やサービスについて誤解を招く情報や、費用・支払い方法を明確に伝えない表示などを扱っています。Google広告を使う場合は、LPの文章と実際の条件を広告担当と照合します。媒体の審査を通ったという事実だけで、自社の案内内容を確定させないことも大切です。
項目5〜9：内容の裏付けと掲載条件を確認する
- 誰の、どんな用事に応えるかが分かるか。広告の対象者とLPの説明を並べます。サービス名だけでなく、利用できる場面や対象外の条件を読めるか確認します。
- 料金と含まれる範囲が一致しているか。基本料金、追加条件、継続費用、支払い方など、利用者の判断に関わる説明を、社内の現行資料と照合します。
- 特典の期間と利用条件が有効か。期限、対象者、対象プラン、提供できる内容を確認します。終了した特典や古い受付条件が、広告や画像に残っていないか見ます。
- 実績やお客様の声の根拠を確認できるか。掲載許可、正式な名称と敬称、担当範囲、数値の期間や条件を照合します。件数を満たすために説明や成果を作りません。
- 申し込んだ後の案内が実際の受付と合うか。連絡方法、対応時間、次に必要な資料、相談から契約までの流れを、受付や営業の担当者に確認してもらいます。
事実を変更する人と、表現を整える人を分ける
制作会社が文章を読みやすく修正しても、サービスの条件まで決められるわけではありません。料金は管理担当、対応範囲は営業や現場、実績は案件担当など、事実の確認先を決めます。複数部署の意見を集める際は、どの条件が決まっていて、どれが回答待ちかを一つのメモへ整理します。
写真や図の中の説明、一覧に出る抜粋、広告画像も照合対象です。本文だけ直しても、アイキャッチに旧価格が残っていれば、利用者に異なる情報が伝わります。同じ説明が表示される場所を一覧にしておくと、特典の終了や条件変更の際にも使えます。
お客様の声は、一律に何件あれば十分と決めるより、その声が利用者の疑問に答えるかを確認します。詳しい取材や掲載内容の整え方はLPのお客様の声の記事へつなぎ、チェックリストでは事実、許可、表示の一致を確認する役割に絞ります。
3. 読む・押す・戻る操作と、表示の待ち時間を確認する
一つの画面ではなく、利用中の状態を見る
PCで開いた最初の画面が整っていても、長い比較表、展開したFAQ、入力中の画面では状態が変わります。ページの上から下へ読み進め、必要な情報を探し、ボタンを押し、必要なら戻るところまで確かめましょう。スマートフォンでは、追従ボタンや入力用キーボードが出た状態も対象です。
試した端末、ブラウザー、画面の向きを記録します。PC上で幅を狭めた表示と、実物のスマートフォンで操作した結果は分けて書きます。実機を確認できていない場合は、その範囲を制作会社へ伝え、契約や利用者の状況に応じて必要な確認を相談します。
不具合の報告では、どの操作で困ったかが伝わる画面とメモを残します。「小さく見える」なら対象の文字や図を示し、「押せない」ならボタンの場所と、周囲に重なっているものを示します。具体的な再現手順はLPのスマホ対応を見直す記事で整理しています。
項目10〜14：表示と操作を確認する
- 文字・画像・表の内容を読めるか。小さい画面や拡大時も、重要な条件を確認できるか見ます。図の説明を画像だけへ閉じ込めず、本文にも必要な情報があるか確かめます。
- ボタンの文言と動作が一致するか。「資料を見る」から入力フォームへ進むなど、期待と違う動作がないか確認します。近接するリンクの押し間違いにも注意します。
- 開閉・戻る・キーボード移動ができるか。FAQ、メニュー、拡大画像などを開いた後、閉じて元の行動へ戻れるかを試します。選択中の場所が分かるかも確認します。
- 重要なリンク先に到達できるか。申込先、資料、会社情報、個人情報の取り扱いなどを開き、行き先の内容まで読みます。判断に必要なリンクを、離脱防止だけを理由に消しません。
- 読み込みや反応の遅さが利用を妨げないか。測定結果の条件と、実際に待った場所を記録します。動画や大きな画像を含む場合は、その前後で読書や入力を続けられるか見ます。
速度の点数を、公開の合否そのものにしない
GoogleのPageSpeed Insightsの説明は、一定条件で測るラボデータと、実際の利用から得られるフィールドデータを区別しています。新しいページや利用者の少ないページでは、個別ページの実利用データが十分でない場合もあります。結果がページ単位なのか、サイト全体に近い単位なのかも確認します。
点数が低い原因を把握せずに、画像を削るだけの対応を決める必要はありません。主な画像の表示が遅いのか、操作への反応に時間がかかるのか、表示中に位置が動くのかで相談内容が変わります。スコア、測定条件、利用者が困る操作をセットで制作担当へ渡しましょう。
点数が良くても、料金表の右端へ移動できない、ボタンが重なって押せないといった問題は別に残ります。公開前の判断では、測定上の問題と操作上の問題を分け、必要な改善と公開予定を相談します。ある点数を超えたことだけで、問い合わせの増加や広告成果を保証しないようにします。
4. フォームは、入力ミスの修正から社内受付まで試す
何を送信し、誰が受け取るかを先に決める
フォームの試験は、受付担当が内容を確認できる時間に行います。送信先、利用者向けの自動返信、保存先、営業管理ツールなどとの連携を確認し、どこまで動かすかを決めます。テストと分かる件名や名前、実施時刻を共有し、実際の相談と混ざらないようにしましょう。
試験では、担当者が管理するメールアドレスと、確認に必要な範囲の情報を使います。実在のお客様の問い合わせ内容をコピーする必要はありません。資料請求後に営業メールが自動配信される仕組みがあるなら、その動作を含めるかも事前に確認します。
W3Cのフォームの通知に関する解説は、入力エラーを分かる形で示し、修正方法や処理結果を伝える考え方を説明しています。確認では、エラーを出せたかだけでなく、その説明を読んで入力を直し、次の行動へ進めるかを見ます。
項目15〜18：入力と受付を確認する
- 必要な入力を理解できるか。項目名、必須・任意、入力例、添付の条件を読んで操作します。相談の目的に対して、答えにくい質問や不要な入力がないかも確認します。
- エラーから修正して進めるか。未入力や形式の違いを試し、問題のある欄が分かるか、正しい入力が残るか、修正後に送信へ進めるかを確認します。
- 送信結果と次の行動が分かるか。完了画面に、何を受け付けたか、誰からどの方法で案内するかが表示されるか見ます。受付体制と異なる返信期限を約束していないか照合します。
- 担当者が内容を受け取り、対応できるか。通知、保存内容、添付、自動返信など、仕様にある処理を確認します。画面上の完了、社内での受信、担当者の対応準備を分けて記録します。
未着を見つけたら、送信の繰り返しより切り分ける
完了画面が出ても通知を確認できなければ、送信時刻、試験用の識別情報、試した機能を制作会社へ伝えます。宛先の違い、通知設定、メール処理、保存処理など、どこまで到達したかを調べてもらいます。発注担当者が原因を決めつけて設定を変更すると、元の問題を追いにくくなることがあります。
例えば、通常の相談は届いても、写真を添付した相談だけ受付できないなら、添付なしの試験結果で全体を完了にしません。問題があった条件を記録し、修正後に同じ条件を試します。添付サイズなどの仕様があるなら、その条件を利用者が入力前に理解できるかも見直します。
フォームの質問や説明を改善する場合は問い合わせフォーム改善ガイド、ボタンやエラーの短文を整える場合はLPのマイクロコピー改善ガイドを参照してください。この確認表では、実装された機能と案内が、受付までつながっているかを記録します。
5. 計測する行動と、成果として扱う条件を決める
クリック・送信成功・有効な相談を混ぜない
公開後にLPを改善するには、何を数えているかが分かる計測が必要です。問い合わせボタンのクリック、入力開始、送信成功、営業担当が対応する相談は、それぞれ違う出来事です。どれを主要な成果として使い、どれを途中の行動として見るかを、広告担当と営業担当で揃えます。
例えば、資料ボタンを押した人が、実際に資料を開いたとは限りません。GA4の拡張計測機能の説明では、ファイルのダウンロードに関するイベントは、対象のファイルへ移動するリンクのクリックで記録されると説明されています。この記録を、資料を最後まで読んだ人数に置き換えることはできません。
同じ資料では、フォームの入力開始や送信のイベントも説明されています。利用中のフォームで、いつどのイベントが発生するかを確認し、名前だけで受付成功と判断しないようにします。試験中の画面結果、計測結果、社内の受付記録を照合すると、意図した条件で数えられているかを判断できます。
項目19〜23：計測の条件と結果を確認する
- 計測する行動に定義があるか。どの操作が起きたら記録し、何を成果として扱うかを書きます。「問い合わせ」のような名称だけでなく、送信成功など実際の条件を示します。
- 正しい計測先へデータが届くか。対象のサイトと計測設定を確認し、確認用サイトや別事業のデータへ混ざっていないかを担当者と照合します。
- 成功・エラー・再表示で期待した記録になるか。送信成功時だけでなく、入力エラー、戻る操作、完了画面の再読み込みなどを試し、意図しない重複や欠落がないか見ます。
- 広告や案内の入口を識別できるか。必要なキャンペーン名や流入の区分を揃えます。入口の記録と最終的な成果の帰属は同じ確認ではないため、見るレポートも確認します。
- テストの記録を実際の成果と分けられるか。日時と識別情報、除外設定の扱いを記録します。同意や閲覧環境で観測できる範囲が異なる場合も、条件を結果に添えます。
DebugViewの記録を、受付と突き合わせる
Google AnalyticsのDebugViewの公式説明では、デバッグモードを有効にして、操作中に収集されるイベントを確認できます。設定を担当する人に、対象端末を絞って操作とイベントを照合してもらうと、何を試した結果なのかが分かりやすくなります。
例えば「ボタンを押したが必須項目が未入力」「正しく送信して受付を確認」「完了画面を再表示」という試験を分けます。それぞれの画面結果とイベントを並べ、成功していない操作まで成果に入っていないか、同じ受付を意図せず重複して数えていないかを確認します。実際の識別方法は、フォームと計測の仕様に合わせて決めます。
DebugViewにイベントがない場合も、直ちに送信失敗と決めつけません。同意の状態や設定などを確認し、フォーム側の受付記録とは別に切り分けます。また、この画面だけで広告成果の帰属を確定しないようにします。公開後の集計では、対象期間、計測条件、有効な相談の定義を揃えて比較してください。
6. 未確認の項目を残し、修正版を見て公開を判断する
チェック数より、残った問題の影響を見る
確認表は、何項目に印が付いたかだけで公開を決めるものではありません。広告が違うページへ到着する、料金条件が確定していない、問い合わせを受け付けられないといった問題は、少数でも公開判断へ影響します。反対に、使わない機能に関する項目は、対象外とする理由が明確なら未完の作業として抱える必要はありません。
記録の状態は「確認済み」「修正が必要」「回答待ち」「対象外」などに分けます。確認済みには確認日時と担当、修正が必要な項目には場所と操作、回答待ちには判断する人を添えます。「制作会社へ連絡した」という作業記録と、「修正版で解消した」という確認結果も分けてください。
公開判断をする人には、残っている項目とその影響を説明します。広告費を使う開始時刻、LPの公開作業、受付担当が対応できる時間が揃っているかも確認します。制作会社、広告代理店、社内の担当が別々の場合は、誰が開始や延期を連絡するかを一人決めておくと伝達漏れを減らせます。
項目24〜27：公開判断に必要な記録を揃える
- 対象の版と担当が記録されているか。どのLP、どの広告設定、どの確認結果に対する判断かを明確にします。途中で設定や原稿が変わった箇所は、再確認の対象にします。
- 修正後に同じ条件で確認したか。不具合のあった操作と端末、広告の設定を使って試します。共通部を直した場合は、影響する別の箇所も確認します。
- 残る項目の扱いが決まっているか。公開前に直すこと、後で対応すること、回答待ちを整理します。後回しにする場合は、担当・期限・それまでの案内を共有します。
- 公開と広告開始、受付の予定が揃っているか。実施する人、確認する時間、問題発生時の連絡先を記録します。サイト反映後に、公開URLと主要な受付を確認します。
修正依頼は、一件を最後まで追える形にする
架空の修正メモなら、「資料請求LP、スマホで必須項目を空欄のまま送信すると、エラーの説明が追従ボタンに隠れる。該当欄を読める状態にしたい」と書けます。修正版が届いたら同じ手順を試し、「エラー文を読め、修正して送信できた。受付通知も確認」と結果を追記します。
ここで、別の端末だけを試して元の問題を完了にしないようにします。制作会社での修正報告を受け取り、自社で確認する範囲まで終えてから公開判断へ進めます。確認できない条件が残るなら、その条件と、代わりにどの確認を行ったかを記録します。
公開の承認は、対象の版、範囲、残る課題を添えて伝えます。公開後に広告側の設定を変更する必要がある場合は、その作業も別に確認します。LPの公開完了という連絡だけで、広告配信や受付準備まで完了したと思わず、担当ごとの実施結果を揃えましょう。
7. 公開後は、変更や問題に合わせて確認表を更新する
固定の頻度だけでなく、再確認するきっかけを決める
運用中の点検は、一定間隔で振り返る機会と、変更があったときの確認を組み合わせます。料金を変えた、特典が終了した、フォームを更新した、広告のリンク先を切り替えたなど、影響が分かる変更があれば、その変更に関わる項目を再確認します。すべてのLPへ同じ頻度の試験を一律に当てはめる必要はありません。
例えば、広告画像だけを変更した場合でも、本文や受付と違う特典を約束していないかを確認します。フォームの更新なら、入力、エラー、受付、計測をもう一度見ます。LPの文章を変えていなくても、通知先の担当者が変わったなら、受信と対応体制が確認対象になります。
定期点検の頻度は、更新の多さ、受付への影響、広告運用の状況、担当者が確認できる体制から決めます。短期間に変更が多い期間と、安定して運用している期間を同じ扱いにせず、点検結果を見ながら調整します。異常の連絡を受けたときは、次の定期点検日まで待つのではなく、影響する範囲を確認します。
項目28〜30：運用中の再確認を続ける
- 変更の影響がある項目を再確認したか。広告、料金、資料、フォーム、計測、担当変更などを記録し、関連するチェック項目へ確認結果を追記します。
- 数字と受付の様子を同じ期間で見ているか。流入、行動、送信、有効な相談を分けて見ます。広告条件や計測変更があれば、前後比較の背景として残します。
- 残る改善の担当と次の確認が決まっているか。課題、仮説、対応範囲、確認方法を記録します。変更しただけで完了にせず、実際の表示や受付、必要な観測結果まで追います。
確認表を、社内と制作会社の共通メモにする
表計算や共有文書へ移すときは、「項目番号」「対象URL・広告」「確認方法」「確認日・担当」「結果」「修正担当・期限」の列を用意すると使いやすくなります。細かな画面や動画は同じ行から参照できるようにします。番号を残せば、「16番の入力エラーを修正しました」のように、やり取りの対象も揃えられます。
確認表にない問題を見つけた場合は、30項目に収めるために捨てず、自社の追加項目として残してください。外部予約、購入、会員登録などを含むLPには、それぞれの処理に合う試験が必要です。一方、使わない機能の確認を繰り返す必要はなく、対象外の理由を更新すれば判断を引き継げます。
公開後の改善を判断する方法はLP改善の計測・仮説・検証ガイドで説明しています。A/Bテストも、時期だけで実施を決めるのではなく、確かめたい仮説と観測できる条件を揃えてから検討します。競合にある要素をそのまま追加するより、自社の利用者が困っている場所を確認することから始めましょう。
Acquaでは、LP制作と改善の相談を受け付けています。現在のLP、広告から案内している内容、受付や計測で困っていること、希望時期をまとめてお問い合わせください。確認表を使い、必要な作業と自社で判断する条件を整理していきましょう。