本文へスキップ
  1. TOP
  2. Web制作
  3. 実務知識
  4. サービスや特設サイトを終了するとき、何を閉じればよいか

04 / GROW

育てるフェーズの実務知識

サービスや特設サイトを終了するとき、何を閉じればよいか

ページ、ファイル、フォーム、外部連携、保管データまで一組で確認する

サイトの入口を継続、転送、保管へ分けて終了する経路模型

PRACTICAL KNOWLEDGE 実務知識

WRITTEN BY

FHW制作チーム

反省会と日々の制作記録をもとに、担当スタッフが実際に迷い、確認し、判断した過程を整理しています。

サイトは、トップページを消しただけでは終わらない

サービスやイベントが終了したとき、トップページを非公開にしても、サイトは完全には閉じていません。検索結果から詳細ページへ直接入れる、古いPDFが開ける、フォームへ送信できる、他サイトのバナーが残る、といった入口があるためです。

私たちが終了対応を考えるとき、最初に見るのはトップページではありません。利用者がまだ入れる場所、送信できるフォーム、検索結果に残る資料を一つずつたどります。そこで初めて、継続する情報、案内へ置き換える情報、停止する機能、削除または保管するデータを分けられます。

最初に、公開中の入口を一覧にする

管理画面のページ一覧だけでは、すべての入口を把握できません。URLの存在だけでなく、その先で利用者が何をできるかを確認します。

  • トップページ、一覧、詳細ページ
  • 検索エンジンから直接到達するURL
  • 関連サイトのリンクやバナー
  • 広告、SNS、メール、QRコードのリンク先
  • PDF、画像、動画など単独で開けるファイル
  • フォーム、予約、会員ログイン、資料請求
  • 外部サービス、API、計測タグ、通知先

終了後に残す情報を決める

終了日、問い合わせ先、既存利用者への案内、後継サービス、過去実績として残す情報など、公開を続ける理由がある内容もあります。

終了案内ページには、何がいつ終了し、現在利用できない機能は何か、問い合わせ先はどこかを示します。古い申込みボタンや「受付中」の表現を残したまま、冒頭だけ終了案内へ変える方法は避けます。

フォームと自動処理は、表示より先に止め方を決める

フォームを画面から隠しても、送信先URLが生きていれば直接送信される可能性があります。受付終了日時、送信処理を止める時刻、自動返信と担当者通知の扱い、保存済みデータの保管・削除を決めます。

予約、決済、会員、API連携も同様です。外部サービス側だけを止めると、サイト上では操作できるのに完了しない状態が生まれます。画面表示、受付処理、通知、外部連携を一つの停止手順として扱います。

PDFや画像など、ページ外の公開物を確認する

案内資料、申込書、料金表、利用マニュアルは、ページを閉じてもURLを知っている人から閲覧できることがあります。削除、終了案内への転送、記録としての継続を資料ごとに決めます。

同じファイルが複数ページから参照されている場合は利用箇所を先に確認します。配布済みのQRコードや印刷物は差し替えられないため、アクセス先で終了案内を返す方が適切な場合もあります。

URLは、削除・転送・継続を分ける

すべての旧URLをトップページへ転送すると、利用者は探していた情報を失い、終了したことも分かりません。後継ページがあるURLはそのページへ、終了説明が必要なURLは案内ページへ、代替情報がないURLは適切な終了状態へ分けます。

検索流入や外部リンクが多いページは、一定期間案内を残す判断もあります。転送後は目的のページへ到達でき、循環していないことを確認します。

終了日時から逆算し、前後で確認を分ける

終了前は対象URL、機能、資料、通知先、データの保管方針、戻し方を確認します。指定時刻には表示切替と受付停止を実行します。終了後は一般利用者としてアクセスし、検索結果や外部リンクから古い行動へ進めないことを確認します。

自動切替を設定していても、キャッシュ、外部サービス、時刻設定、権限など制作側だけでは制御できない条件があるため、終了後確認は必要です。

削除する前に、保管するものを決める

制作データ、公開ファイル、フォームの受付履歴、計測結果、契約上必要な記録など、終了後も保管すべきものがあります。保管期間、保管場所、閲覧権限、削除責任者を決めます。

何でも残すことが安全とは限りません。個人情報や不要なアカウントは、目的と期間を確認して削除します。サイトの終了と、データの保管・削除は別の判断として記録します。

この方法が向いているケース

  • 期間限定のキャンペーンやイベントサイト
  • 終了または統合するサービスサイト
  • 受付期間が決まっているフォームや予約サイト
  • 後継サービスへ案内を切り替えるサイト
  • 長期停止後に再開せず閉鎖するサイト

終了ではなく縮小を選ぶケース

今後再開する可能性があり、必要な情報や利用者対応が残る場合は、完全削除ではなく縮小公開が適します。新規受付を止め、既存利用者向け案内だけを残す、検索対象から外す、管理機能を読み取り専用にするなど、残す役割を明確にします。再開時に古い情報を正としないため、停止時点の状態も記録します。

終了前後チェック

  • 公開中のページ、ファイル、フォーム、外部リンクを一覧にしたか
  • 終了後に残す案内と問い合わせ先を決めたか
  • 受付処理、自動返信、通知、外部連携を止めるか確認したか
  • PDFや画像の単独URLを確認したか
  • URLごとに削除、転送、継続を分けたか
  • 終了前、指定時刻、終了後の担当を決めたか
  • 古い行動へ進めないか確認したか
  • データの保管期間、権限、削除責任者を決めたか

PRACTICAL KNOWLEDGE 同じフェーズの実務知識

私たちが別の制作で得た判断や確認方法を、同じ制作フェーズからご覧いただけます。

中断したWeb制作の資料と進捗を再確認する作業デスク

長期化・中断・担当交代したWeb制作を、安全に再開するには

長期化、中断、担当交代があったWeb制作で、目的、承認、素材、仕様、環境、残作業を再確認し、安全に再開する手順を整理します。

検索結果と登録データの整合性を確認する作業デスク

検索型サイトで、一覧・詳細・件数・公開状態の整合をどう保つか

検索機能を持つサイトで、管理画面への登録から一覧、詳細、検索結果、件数、ページネーション、公開状態までを一続きで確認する方法を整理します。

二つの外部システム間で同期と再処理を行う仕組み

外部サービス連携で、失敗・遅延・重複をどう扱うか

APIや定期同期について、接続先の停止、通信遅延、再送、部分失敗を検知し、安全に復旧する仕組みを整理します。

コンテンツ、機能、環境、緊急対応を分けて扱う保守作業台

公開後のコンテンツ更新と環境更新を、どう分けて保守するか

公開後の更新をコンテンツ、機能、環境、緊急対応に分け、影響確認、検証、バックアップ、切り戻しを安全に進める方法を整理します。

稼働中サイトの旧環境と新環境の切替経路を確認する作業台

稼働中サイトのサーバー移行と改修を、同時事故にしないために

公開中サイトを止めずに移行するとき、環境の再現と機能追加を分け、切替前確認、戻せる地点、切替後の監視までを整理します。

共通フレームへ企画ごとの展示パネルを組み替える制作チーム

LP・特設サイトを、次の制作へ使える基盤としてどう残すか

繰り返し制作するLPや特設サイトで、共通部品、企画固有表現、計測、メタ情報、公開手順を分け、次回も安全に使える基盤として残す方法を整理します。

外部タグの発火経路を透明な分岐模型で確認する制作チーム

計測タグ・外部タグを、設置から削除までどう管理するか

アクセス解析や広告、外部フォームなどのタグについて、読み込み元、管理者、発火条件、同意状態、テスト・本番の区別、削除後の確認までを整理します。