イベント専用マイクロサイトと既存サイト内のページ、どちらを選ぶ？

二つの形式を運用の違いで定義する

ここでいう既存サイト内のページは、団体が現在使う公開・編集システムで管理するイベントURLです。マイクロサイトは、イベント向けに別途運用するサイトで、独自ドメインまたはサブドメインを使う場合があります。既存の編集システム内でデザインだけを大きく変えても、運用上は同じサイトのページです。提案を比べる前に、実際のURLと管理範囲を書き出してください。

日時、会場、プログラム概要、明確な申込リンクだけのワークショップなら、1ページで足りることがあります。複数日の会議なら、プログラム、登壇者、交通案内、協賛情報を分ける必要があるかもしれません。どちらの形式も情報を自動で正しく保ちません。承認と更新を担える内容だけを計画します。

参加者の導線と必要な情報から考える

案内メールや検索結果から公開情報へ進み、実際の申込・購入先まで歩いてみます。途中のホスト名と各段階の担当チームを記録します。決済が外部サービスなら、案内サイトの修正が決済画面に反映されるとは限りません。リンク先、料金や入場条件を承認済みのイベント記録と照合してください。

独自のイベント名義、広いプログラム内の複数の入口、多言語表示、毎年使う案内拠点は必要でしょうか。そのうえで、既存サイトでも分かりやすく提供できるか確認します。別サイトにすれば検索表示、計測、売上が必ず改善するという前提は置かず、解決したい参加者の課題を具体的に示します。

継続作業ごとに担当者を置く

編集できる担当・保守比較表をダウンロード（Markdown、英語）

英語の担当・保守比較表をダウンロードしてください。URLとドメイン、ホスティングと証明書、編集権限、確定情報の参照元、申込リンク、分析へのアクセス、問い合わせ、終了後の保存を比較します。各作業に主担当と代行者、日時・会場・チケット情報の根拠を記します。空欄は、制作費が安くても未割当の運用負担です。

初期制作と継続作業を分けて数えます。マイクロサイトには別のアカウントや公開手順、更新期限、業者からの引き継ぎが生じる場合があります。既存サイトには中央のWeb担当の承認待ちやレイアウト制約があるかもしれません。どちらも製品・体制ごとに確認します。制作を外注するなら、終了時に編集可能な内容とアクセスを誰が受け取るかを決めます。

決定前に更新作業を試す

両案で同じ作業を試します。下書きを公開し、セッション時刻を訂正し、正式なチケットリンクを差し替え、古いお知らせを削除します。編集者、承認者、所要時間、公開後の確認者を記録してください。スマートフォンでページと申込先を開き、キーボードでもナビゲーションと操作を確認します。完成済みのデモより、実際の担当者が訂正できるかが判断材料です。

主担当が不在のとき、代行者は正しい情報源を見つけ、システムに入り、修正できますか。外部のチケットサービスが使えない場合は、検証済みの正式な代替経路か、現状を正確に伝えるサポート案内を用意します。Webアドレスを増やしても、チケットサービス自体が複製されるわけではありません。

終了後にURLをどう扱うか決める

公開前に、終了後のURLの役割を決めます。その回の情報が役立つなら残し、必要に応じて現在の開催回やシリーズ案内へ導きます。内容を新しいURLへ移すなら、旧URLと対応する新ページを対応付け、リダイレクトとリンク更新を計画します。Google Search CentralはURL変更を伴うサイト移転の手順を説明しています。旧ページをすべて無関係なトップへ送らないでください。[1]

マイクロサイトでは、継続するドメイン、ホスティング、更新の担当者を決めます。既存サイト内のページでは、開催済み表示、期限切れの購入案内の撤去、ナビゲーション更新の担当者を決めます。終了後の作業も最初の選択に含めます。

選択と条件を記録する

判断を根拠付きの一文で書きます。例:「毎月の講座は既存サイトの編集者が直せ、購入リンクの担当も確認済みなので既存ページを使う」。または「年次会議は確定したプログラムを複数の区分に分ける必要があり、別システムを運用する担当がいるのでマイクロサイトにする」。これは例であり、一般的な正解ではありません。

予定URL、責任者と代行者、正式な申込先、公開時の確認、年次または終了時の再確認日、業者への未解決事項を記録します。イベントの規模や担当者が変わったら選択を見直します。新しいドメインを登録する前に、比較表で継続作業を見えるようにします。