準備するもの
まず「誰に見せるか」を確定する。社内の編集長・ライター・クライアント担当者など役割ごとにアクセス権の粒度が変わる。社内だけなら会社ドメイン認証、外部のクライアントも含むなら個別のメール認証が適切だ。この段階で閲覧者リストを作っておくと、後のメール通知先設定がスムーズになる。
デモページのHTMLを共有サービスにアップロードする前に、本番環境へのリンクや社内APIエンドポイントが埋め込まれていないか確認する。デモ専用のモックデータを使っているつもりでも、開発時のconfig.jsなどに本番URLが残っていることがある。ブラウザの開発者ツールでNetworkタブを開き、ページ読み込み時の外部リクエスト先を一通り確認しておくとよい。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
実際の手順
GitHubやローカルで管理している記事デモのHTMLを、ギガサイト便などのプレビューURLサービスにZIPでアップロードする。アップロード後、認証設定画面でパスワードまたはメール認証を選択し、有効期限を指定する。期限はフィードバック回収に必要な期間＋3日のバッファを目安に設定すると、返信が遅れても対応できる。
URLを関係者に送る際は、アクセス方法・認証情報・確認してほしい観点・フィードバック期限を1通のメールにまとめる。観点を「構成のわかりやすさ」「情報の正確性」「CTA文言の魅力度」など具体的に指定すると、受け取った側が何を確認すればよいか迷わなくなり、フィードバックの質が上がる。
失敗しやすい点
限定公開のつもりが「検索除外（noindex）設定を忘れていた」というケースがある。プレビューURLサービスの多くはデフォルトでnoindex設定をしているが、自前でHTMLをホスティングする場合は`<meta name="robots" content="noindex, nofollow">`をheadに入れることを忘れないこと。
「修正後も同じURLで確認できるか確認する」という点も見落としやすい。デモを修正してアップロードし直すたびにURLが変わるサービスを使っていると、関係者に何度もURLを再送する手間が生じ、古いバージョンを見ている人が出てくる。URLが不変のまま内容だけ差し替えられるサービスを選ぶか、差し替えのたびに全員へ通知するフローを整備することが必要だ。
テンプレ文面
記事デモの限定共有メール例：「件名：【確認依頼】〇〇記事デモ（期限：〇月〇日）。下記URLより記事デモをご確認ください。アクセスにはパスワード：XXXX が必要です。ご確認いただきたい点は①構成の流れ②リード文の引き込み力③CTAボタンの文言の3点です。〇月〇日までにこのメールへご返信ください。」
修正差し替え後の通知例：「先ほどお送りしたURLのデモを更新しました。主な変更点はリード文の書き直しとCTA文言の変更です。URLは同じですので、再度ご確認の際はページをリロード（F5）してください。キャッシュが残る場合はシークレットウィンドウでのアクセスをお試しください。」
よくある質問
記事デモを複数バージョン同時に比較してもらいたい場合、どうすればよいですか？
バージョンごとに別々のURLを発行し、メールに「AパターンURL」「BパターンURL」と明記して送るのが最もシンプルです。混同を防ぐため、各デモのtitleタグにバージョン名（例：案A・案B）を入れておくことを推奨します。
限定公開URLをSNSでシェアされてしまった場合はどうすればよいですか？
パスワードまたはメール認証を設定していれば、URLを知っている人全員がアクセスできるわけではないため被害は限定的です。それでも拡散が確認された場合は即座に公開を停止し、新しいURLと認証情報を正規の閲覧者だけに再送してください。
記事デモに埋め込んだGoogle AnalyticsタグはレビューURL経由のアクセスも計測しますか？
はい、計測されます。レビュー用の閲覧データが本番の分析データに混入しないよう、デモ用HTMLではGoogle Analyticsタグを削除するか、フィルタリング用のカスタムディメンションを設定してレビュートラフィックを除外することを推奨します。