何が共有しづらいのか
Difyが出力するLP案のHTMLはCSSをインラインに持つ構造が多く、外部スタイルシートへの依存が少ない点は有利だが、Google FontsやFont AwesomeをCDNから読み込む記述が含まれることがある。レビュアーが社内プロキシ環境にいる場合、これらのリソースがブロックされてフォントやアイコンが崩れた状態で表示される。
またDifyのプレビュー画面はアカウントログインが必要なため、クライアントや社外パートナーにそのURLを共有することはできない。LP案をファイルでDropboxなどに置いても、相手がダウンロードして開く手順が増え、レビューの心理的ハードルが上がる。URLをクリックするだけで確認できる共有形式が理想だ。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
URL化する前の確認点
LP案のHTMLに含まれる`<a href>`タグのリンク先を確認する。ダミーの`#`や`javascript:void(0)`であれば問題ないが、本番のカートURLや申し込みフォームへのリンクが含まれている場合、レビュアーが誤クリックして実際に申し込みが発生する恐れがある。本番URLはすべてダミーリンクに差し替えてから共有する。
LP特有のリスクとして、A/Bテスト用の分岐ロジックやヒートマップツール（Hotjar等）のスクリプトが混入していることがある。これらはレビュアーの閲覧行動を収集してしまうため、該当スクリプトを削除してからアップロードする。また画像はできればHTMLにBase64で埋め込み、外部画像サーバーへの依存を排除する。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
認証と期限の決め方
LP案のレビューは競合に漏れると問題になるケースがある。特定のクライアント向け提案の場合はパスワード認証を設定し、URLとパスワードを別チャンネルで伝える。コンペ用のLPなら期限も短く（5〜7日程度）設定して、提案終了後はアクセスを自動で閉じるようにする。
複数パターンのLP案をまとめてレビューさせる場合は、パターンごとに別URLを発行するか、1つのHTMLに並べて配置する。別URLにすると「Aを見た後Bと比較する」作業がレビュアー側で楽になる。どちらのURLも同じ認証・同じ期限で統一しておくと管理コストが低い。
- 誰でも見てよい: URL共有のみでもよいが、検索除外は確認する
- 特定の相手だけ: パスワードまたはメール認証を使う
- 会社内だけ: 会社ドメイン認証を検討する
- 短期レビュー: 期限を設定して古いURLを残さない
共有後のフィードバック回収
LP案のレビューでは「ファーストビューでサービスの価値が伝わるか」「CTAボタンのコピーが行動を促しているか」「価格・実績などの信頼要素が不足していないか」の3点を質問として送ると、マーケティング知識がないレビュアーでも具体的に回答しやすい。回答をSlackのスレッドで集めると後から検索しやすい。
LP案は修正サイクルが速いことが多い。フィードバックを受けてDifyで再生成した場合は、新しいHTMLをすぐに同じURLに上書きアップロードして「更新しました」と一言送る運用が効率的だ。バージョン番号をHTMLのタイトルタグに入れておくと、レビュアーが古いキャッシュで見ていないかを確認できる。
- 確認してほしい観点を3つ以内に絞る
- 期限と返信先を明記する
- 修正後も同じURLで見られるか伝える
- 最終版と途中版が混ざらないようタイトルを付ける
よくある質問
DifyでLP案を複数パターン生成した場合、どう共有するのが効率的ですか？
パターンごとに別HTMLとして静的共有サービスにアップし、それぞれURLを発行するのが比較しやすくおすすめです。1つのページに並べると縦スクロールが長くなりレビュアーが疲れます。
LP案に含まれるヒートマップスクリプトはなぜ削除が必要ですか？
レビュアーの閲覧行動（クリック・スクロール位置）が本番の計測データに混入し、実際のユーザー行動の分析が歪む可能性があります。レビュー用HTMLからは計測スクリプトを除去してください。
Difyで再生成したLP案を同じURLで更新できますか？
静的HTML共有サービスの多くは同一URLへの上書きアップロードをサポートしています。新しいHTMLをアップロードすれば、レビュアーはURLを変えずに最新版を確認できます。