ホームページ公開日の切り替え手順｜担当・時刻・戻し方を決める

ホームページの公開日は、新しい画面を表示できた瞬間で終わりではありません。公開方法によっては、CMSの公開設定だけで済むこともあれば、サーバーやDNS、URL、メール、フォーム、外部サービスまで同時に切り替えることもあります。作業内容が違うのに「○時に公開する」だけで進めると、誰が確認するのか、どこまで正常なら公開完了なのか、問題が出たときに戻せるのかが曖昧になります。

公開前に用意したいのは、作業を並べただけのチェックリストではなく、切替対象・担当・時刻・合格条件・失敗時の処置を一枚で追える進行表です。各作業に完了条件を付け、公開を続ける判断と旧環境へ戻す判断を先に決めておけば、当日の連絡待ちや責任の押し付け合いを減らせます。

最初に作るのは「公開作業一覧」ではなく切替判定表

公開作業一覧には、「データを移す」「DNSを変更する」「フォームを確認する」といった動詞が並びがちです。しかし、当日に本当に必要なのは、作業が終わったかどうかではなく、次の工程へ進んでよいかを判断できる情報です。

一枚の切替判定表には、少なくとも次の項目を持たせます。

項目	記録する内容
切替対象	CMSの公開設定、サーバー、DNSレコード、URL、メール、フォーム、決済、外部連携など
現在値と変更後	変更する設定名、旧環境、新環境、対象URL。パスワードそのものは書かない
操作担当	実際に管理画面やサーバーを操作する人
確認担当	別の端末や回線も使い、結果を判定する人
実施時刻	開始予定だけでなく、確認期限と戻す判断の締切も記録する
合格条件	どのURL・機能・通知まで正常なら次へ進めるか
失敗時の処置	再実行、部分停止、旧設定へ復帰など、状態別の対応
記録先	変更前後の値、スクリーンショット、確認結果を残す場所

「担当者：制作会社」「確認：社内」のような組織名だけでは、当日に連絡先を探すことになります。表には個人名または役割名、連絡方法、代理担当まで書きます。外部のサーバー会社やドメイン管理会社へ問い合わせる可能性があるなら、受付時間と契約者確認に必要な情報も前日までに確かめておきます。

この表は、すべてのホームページで同じ内容になるわけではありません。まず公開方式を分類し、自社の切替で何が変わるのかを絞ることが先です。

前日までに切替対象と停止影響を分ける

「ホームページを公開する」と聞くと、DNSの変更を想像するかもしれません。しかし、新規サイトを同じサーバー内で公開する場合や、既存CMSの非公開状態を解除する場合は、DNSに触れないことがあります。反対に、サーバー移行を伴うリニューアルでは、見た目の公開だけでなく、Web表示、メール、SSL、外部連携の設定が同じドメインに集まっている場合があります。

最初に、公開方式を次のように分けます。

公開方式	主な変更	特に確認すること
同じサーバー・同じURLで公開	CMSの公開状態、トップページ、キャッシュ	テスト環境向けの閲覧制限やnoindexが残っていないか
同じURLでサーバーを変更	Web用DNSレコード、SSL、サイトデータ	新旧環境の並行稼働、フォーム送信、旧環境へのアクセス有無
URLやドメインも変更	新サイト公開、旧URLからの転送、内部リンク	旧URLと新URLの対応、リダイレクト、canonical、サイトマップ
Web以外も同時に変更	メール、予約、決済、会員、APIなど	送受信先、認証、外部サービスの接続元・接続先、データ差分

とくに注意したいのが、DNSの「Web用レコードを一部変更する作業」と「ネームサーバー自体を変更する作業」の違いです。Web表示だけを新しいサーバーへ向けるつもりでも、ネームサーバーを丸ごと切り替えると、メール用のMXレコードや送信認証用のTXTレコード、外部サービス用の設定まで新しいDNS側に再現する必要が生じます。管理画面の案内だけを見て、使途不明のレコードを削除したり、すべてを新しい値へ置き換えたりしないようにします。

停止影響も「サイトが見られない」だけではありません。CMSへ記事を追加できない、問い合わせは届くが自動返信だけ止まる、予約は受け付けるが管理画面に反映されない、旧サーバー側に注文が残る、といった部分的な不具合があります。切替対象ごとに、利用者への影響、社内業務への影響、止められる時間、止められないデータを分けてください。

公開日の前日に初めて管理権限を確認すると、契約者しか変更できない、二段階認証の端末が手元にない、担当者の退職後に管理メールが使えない、といった理由で作業自体を始められないことがあります。ドメイン、DNS、サーバー、CMS、CDN、フォーム、メール、計測、外部サービスについて、誰がログインできるかを実際に確かめ、閲覧権限だけではなく変更権限があるかまで確認します。

バックアップは「保存した」ではなく「戻せる地点」で決める

バックアップは、ファイルが存在するだけではロールバックに使えません。いつの状態なのか、何が含まれているのか、誰がどの手順で戻すのかをセットで決めます。WordPressの一般的な構成では、テーマ・プラグイン・アップロード画像などのファイルと、投稿・設定・ユーザー情報などを持つデータベースが別に保存されています。片方だけでは、公開前の状態を完全に再現できないことがあります。

切替用のバックアップには、次の情報を付けます。

• 取得開始・完了時刻と、対象環境
• ファイルとデータベースの取得範囲
• 保存先と、当日に参照できる権限
• 復元を実行する担当者と、おおよその作業順
• 復元後に再確認するURL・機能
• バックアップ取得後に発生した更新の扱い

最後の「取得後に発生した更新」が重要です。公開直前まで記事更新、問い合わせ、注文、予約、会員登録が続くサイトでは、早い時刻に取得したバックアップへ戻すと、その後に増えたデータを失う可能性があります。そこで、最終バックアップの前に変更凍結の時刻を決めます。変更凍結とは、公開用データの基準を一つにするため、CMS更新や商品登録などを一時的に止めることです。

ただし、利用者から届く問い合わせや注文まで完全に止められるとは限りません。止められないデータがある場合は、切替中の書き込み先を一つにする、旧環境と新環境の差分を後から照合する、受付を一時停止して案内を表示するなど、構成に合う方法を決めます。技術的に同期できるか分からない状態で「あとで統合する」とだけ書くのは危険です。どの項目を、誰が、何を正として照合するかまで具体化します。

バックアップを取得した時刻は、公開を戻せる最後の地点でもあります。切替後に新環境へ問い合わせや注文が入り始めたら、単純に古いデータベースへ戻すだけでは済みません。どこから先はデータ調整が必要になるかを、切替判定表に「戻せる期限」または「差分確認が必要になる条件」として記録します。

担当と時刻は作業順ではなく判断の待ち時間まで含める

公開当日は、操作する人だけを決めても進みません。小規模な体制でも、次の四つの役割を分けて考えます。

• 公開判断者：開始、続行、保留、ロールバックを決める
• 操作担当者：CMS、サーバー、DNSなどを変更する
• 確認担当者：表示、送信、通知、外部連携を別の視点で確認する
• 連絡担当者：社内、制作会社、サーバー会社、利用者向けの連絡をまとめる

一人が複数の役割を兼ねても構いません。ただし、操作した本人だけが同じブラウザで確認すると、ログイン状態やキャッシュの影響を見落としやすくなります。少なくとも重要な合否判定は、別端末または別回線を使う確認担当者を置くと判断しやすくなります。

公開時刻は「アクセスが少なそうだから深夜」と自動的に決めるものではありません。問題が出たときに、ドメイン・サーバー・メール・外部サービスの担当者へ連絡できるか、社内の決裁者が待機できるか、確認と復旧に十分な時間を取れるかで決めます。業務への影響が小さくても、支援先がすべて営業時間外では、少しの設定ミスが翌朝まで残ることがあります。

以下は、午後に切り替える場合の進行表の一例です。時刻そのものを標準とせず、作業の間に確認と判断の余白を置く考え方を参考にしてください。

時刻例	作業	主担当	完了条件	未完了時の処置
13:30	CMS更新を凍結し、関係者へ開始連絡	連絡担当	更新者全員が停止を確認	開始を保留する
13:45	ファイル・DBの最終保存	操作担当	保存先と取得時刻を確認	取得できるまで切替しない
14:00	新環境の差分と閲覧制限を最終確認	操作・確認担当	主要ページと公開設定が一致	修正後に再確認する
14:20	CMS公開またはDNS・接続先を変更	操作担当	変更後の値を記録	変更前の値へ戻せる状態を維持
14:35	主要URL、HTTPS、フォームを確認	確認担当	即時判定項目をすべて通過	影響範囲を特定し、続行可否を相談
15:00	メール・予約・決済・外部連携を確認	各機能担当	テスト結果と通知先が一致	該当機能を止めるか切り戻す
15:30	公開続行またはロールバックを決定	公開判断者	記録済みの合格条件を満たす	決めた戻し手順を開始
16:00	完了連絡と残課題の引継ぎ	連絡担当	次回確認時刻と担当を共有	未確認事項を公開完了扱いにしない

この表では、作業開始時刻だけでなく「判断時刻」を置いています。軽微な表示ずれを直し続けるうちに、旧環境へ安全に戻せる時間を過ぎないためです。問題が残った場合に、何時まで調査し、誰が続行可否を決めるかを先に書きます。

DNS・CMS・キャッシュは構成別に作業順を変える

公開の順番は、すべてのサイトで「バックアップ、DNS、キャッシュ削除」になるわけではありません。変更箇所が少ない順に考えると、不要な操作を減らせます。

同じサーバーでCMSの公開状態を変える場合

テスト中に使っていたベーシック認証、IP制限、メンテナンス表示、noindex、robots.txtの制限を一覧にし、本番で外すものを決めます。トップページの表示設定やサイトURLを変更する場合は、管理画面へ戻れなくなる可能性も含めて手順を確認します。公開後は、ログイン済みブラウザだけでなく、シークレットウィンドウや未ログイン端末でも見ます。

この構成ではDNSを変更しなくても、CMS、サーバー、CDN、ブラウザの複数箇所に古いキャッシュが残ることがあります。どこにキャッシュ機能があるかを事前に洗い出し、変更した層だけを順に消します。すべてを同時に消すと、原因を追いにくくなったり、一時的に負荷が増えたりするため、実行した操作を記録します。

同じURLのままサーバーを変える場合

新サーバー側は、DNSを向ける前にできる限り確認します。一時URLやhosts設定など、利用している環境で許可された方法を使い、ページ、画像、PDF、フォーム、管理画面、SSL、外部通信を確認します。本番切替では、変更対象となるDNSレコードと変更前の値を記録し、関係のないメールや外部サービスのレコードを巻き込まないようにします。

DNSの応答は、設定を変更した瞬間に全利用者が一斉に新環境へ切り替わるとは限りません。DNSレコードはTTLという有効期間に基づいてキャッシュされるため、利用する回線やキャッシュの状態によって、旧環境と新環境へのアクセスがしばらく混在します。「世界中への反映が完了した」という一つの表示を待つのではなく、新旧両方のアクセス記録と複数回線での表示を確認します。

TTLを事前に短くできる場合でも、公開直前に変更すれば必ず間に合うとは限りません。現在のTTL、変更できる時期、DNS事業者の仕様を確認し、必要な期間だけ調整します。切替後は運用上適切な値へ戻す作業も予定表に入れます。

URLやドメインを変える場合

URL変更を伴うリニューアルでは、公開日の接続先変更だけでは不十分です。旧URLと新URLの対応表、リダイレクト、内部リンク、canonical、サイトマップ、Search Consoleの管理範囲を別の作業として準備します。すべての旧ページを新トップページへ送るのではなく、内容が対応するページへつなぐか、廃止するページは適切な状態を返すかを決めます。

この作業は、同じURLのままサーバーだけを変える移行とは確認対象が異なります。公開当日の判定表には、代表的な旧URLから期待する新URLへ移動できるかを入れ、詳細なURL対応や検索評価の確認は専用の移行表で管理すると混乱を減らせます。

合格判定は主要ページ、送信、外部連携を一組で確認する

トップページが表示されたことだけで「公開成功」とすると、問い合わせや管理業務の不具合が後から見つかります。確認URLは、ページ一覧を上からすべて見るのではなく、構造と機能を代表するものを選びます。

公開直後の合否に使う確認項目は、次のようにまとめられます。

確認領域	確認例	合格の考え方
表示・移動	トップ、主要サービス、会社情報、記事、404、スマホメニュー	重要情報へ到達でき、致命的な崩れやリンク切れがない
URL・通信	HTTPS、www有無、旧URL、主要リダイレクト	想定したURLへ一貫して到達し、証明書エラーがない
公開制御	noindex、robots.txt、ベーシック認証、メンテナンス表示	本番で外すべき制限が残らず、残す制限は維持されている
フォーム	入力、エラー、完了、管理者通知、自動返信、返信先	送信者と社内の双方で、想定した内容を確認できる
業務機能	予約、購入、会員登録、検索、PDF、API	安全なテスト方法で主要な一連の処理が完了する
管理・更新	CMSログイン、記事更新、画像追加、権限	運用担当者が本番環境を更新できる
計測・検索	GA4受信、Search Console所有権、サイトマップ	公開後に継続確認できる管理状態が保たれている

フォームは「完了画面が出た」だけでは足りません。管理者通知が正しい宛先へ届くか、自動返信の差出人や返信先が正しいか、迷惑メールに入っていないか、送信内容が管理画面にも保存される仕様なら保存されているかを確認します。テスト送信には、公開確認用だと分かる件名や氏名を使い、実際の問い合わせと混ざらないようにします。

メールサーバーを変更しない場合でも、フォームの送信元ドメイン、SMTP設定、DNS認証、サーバー側の送信制限が変わることがあります。Web表示とメール送信を別の確認項目にし、受信担当者まで含めて結果を残します。

確認は、社内Wi-Fiだけでなく携帯回線など別の経路でも行います。DNSやCDNの切替では、確認者の環境によって旧サイトが見えることがあるためです。ただし、一台だけ旧環境が見えたことを即座に失敗と決めるのではなく、取得先、応答、旧新サーバーのログ、TTLの状況を合わせて判断します。

公開直後に見る項目と、翌営業日以降に見る項目も分けます。サイトが利用できるか、問い合わせが届くか、重大な誤表示がないかは即時判定です。一方、検索エンジンのクロールやアクセス計測の傾向、遅れて実行される定期処理は継続確認になります。公開後のGA4とSearch Consoleの確認は、既存記事のホームページ公開後にGA4とSearch Consoleで最初に確認することへ分け、当日の切替表を計測手順で膨らませないようにします。

続行・保留・ロールバックを三段階で定義する

ロールバックは「問題があれば元に戻す」という一文では実行できません。何を問題とみなすか、修正を続けるか、機能だけ止めるか、全体を戻すかを前もって分類します。

判定	状態の例	基本対応
続行	軽微な余白ずれ、公開後でも直せる表記、代替手段がある機能	課題、担当、修正期限を記録して公開を継続
保留・部分停止	一部フォームだけ不達、特定機能だけ不安定、原因を短時間で特定できる	該当導線を一時停止し、公開判断者が再判定
ロールバック	複数回線で主要ページへ到達不能、HTTPSエラー、主要フォーム・予約・購入が使えない、非公開情報の露出	決めた旧設定または旧環境へ戻し、利用者と関係者へ連絡

ロールバック条件には、発生した不具合だけでなく、調査時間の上限も入れます。たとえば「主要フォームが送信できず、判断時刻までに原因と復旧見込みを確認できない場合」のように書きます。原因不明のまま修正を重ねると、変更点が増えて戻しにくくなるためです。

戻し手順では、次を具体化します。

• DNSや接続先の変更前の値
• 旧環境を再公開する操作と担当者
• ファイル・データベースの復元順
• キャッシュを更新する箇所
• 戻した後に確認するURL・フォーム・メール
• 新環境で受けた問い合わせ、注文、予約などの回収方法
• ロールバック完了を判断し、連絡する人

特に、切替後のデータ差分を無視しないことが重要です。新環境で問い合わせや注文を受けた後に、公開前バックアップのデータベースへそのまま戻すと、新しい受付データが消えるおそれがあります。全体を戻す前に新環境の書き込みを止め、差分を書き出すのか、旧環境へ手作業で反映するのか、別途連絡して業務側で救済するのかを決めます。

DNSの切り戻しにもキャッシュの影響があるため、値を戻した瞬間に全員が旧環境へ戻るとは限りません。新旧どちらへ接続しても重大な問題が起きない状態をできるだけ保ち、旧環境を早く削除しないことが、戻しやすさにつながります。

公開完了の連絡は残課題と旧環境の扱いまで書く

公開完了の連絡は、「公開しました。ご確認ください」だけでは、どこまで確認済みかが分かりません。切替判定表を更新し、次の内容を一つの連絡にまとめます。

• 公開判断をした日時
• 実際に変更した対象と、変更しなかった対象
• 確認したURL、フォーム、メール、外部機能
• 未解決だが公開継続とした課題、影響、担当、期限
• 次に確認する時刻と担当者
• 旧環境を保持する期限または終了条件
• 最終バックアップと変更記録の保存先

社外向けの公開告知は、切替操作の直後ではなく、即時の合格条件を満たした後に行います。告知後にロールバックすると、利用者が新旧の案内を行き来しやすいためです。広告、SNS、メールマガジン、名刺や印刷物のURLを変更する場合も、公開判定後に実行する作業として分けます。

旧サーバーは、公開完了と同時に解約しない方が安全です。同じURLでサーバーを移した場合は、旧環境へのアクセスがなくなったこと、新環境で利用者と検索エンジンのアクセスを受けられていることを記録で確認します。保持期間はサイト規模、契約、保存データ、費用、セキュリティ条件によって変わるため、一律の日数ではなく終了条件で決めます。旧環境を残す間は、更新を続ける本番と誤認しないよう、管理者向けの識別方法やアクセス制限も検討します。

翌営業日には、当日すぐには分からなかった処理を確認します。定期メール、バッチ処理、バックアップ、予約通知、決済結果、アクセスログ、エラーログなどです。残課題を別のメモへ移すのではなく、切替判定表の続きとして担当と期限を残せば、公開当日の緊張が解けた後も対応が途切れません。

まとめ｜公開日は「続ける・戻す」を判断できる状態で迎える

ホームページ公開日の切り替え手順は、作業項目を多く並べるほど安全になるわけではありません。自社の公開方式を見分け、変更する対象だけを特定し、担当、時刻、合格条件、失敗時の処置を同じ表に置くことが出発点です。

前日までに管理権限と停止影響を確認し、ファイルとデータベースを戻せる形で保存します。当日は変更凍結、最終保存、切替、主要機能の確認、続行判断、完了連絡を時系列で進めます。DNSを使う場合は旧新環境が混在する前提で確認し、URL変更やメール・外部連携がある場合は別の作業として扱います。

最後に、ロールバック条件とデータ差分の扱いを決めておけば、「公開できるか」だけでなく「問題が出ても事業を止めずに戻せるか」を判断できます。公開日は、一度きりの操作日ではなく、新しい環境へ責任を引き継ぐ日として計画してください。