DNSを切り替えてトップページが表示されても、サーバー移転は完了していません。旧サーバーのキャッシュを見ている可能性があり、フォームや定期処理だけが失敗していることもあります。完了チェックでは、画面の見た目ではなく利用者の行動と運用担当の復旧まで確認します。
最初に新サーバーへ到達した証拠を取る
確認する端末と回線を決め、DNSが返す値と実際の応答を記録します。新環境だけに置いた確認用ヘッダーやログがあれば、到達先を判別しやすくなります。IPアドレスだけではCDNやロードバランサーを経由する構成を判断できない場合があります。事業者の確認方法とアクセスログを組み合わせます。
一つの端末で新環境が見えても、すべての利用者が切り替わったとは限りません。変更前のTTLが残る間は旧環境へ到達する経路があります。社内回線・モバイル回線・外部監視など複数の視点で確認します。時刻と結果を残し、旧環境へ新しい更新が入っていないかも並行して見ます。
公開ページは代表ではなく導線で確認する
トップページから会社情報・サービス・問い合わせまで、読者が実際にたどる順に開きます。画像・CSS・JavaScriptが読み込まれるだけでなく、メニューと内部リンクが正しいURLへ進むかを確認します。wwwの有無やHTTPからHTTPSへの統一も、想定する正規URLへ一回で到達するかを見ます。
ページ種類の違いも考えます。WordPressでは投稿・固定ページ・検索結果でテンプレートが異なり、一部だけ崩れる場合があります。スマートフォンでの表示と主要ブラウザも対象です。リンク切れやMixed Contentを見つけた場合は、旧URLの残存・ファイル不足・キャッシュのどれかを切り分けてから修正します。
業務機能は開始から通知まで通して試す
問い合わせフォームは入力画面を見るだけでなく、送信完了・データ保存・管理者通知・自動返信まで確認します。予約や応募も同じです。決済を含む場合は用意されたテスト方法を使い、実取引を不用意に発生させません。利用者側と担当者側の結果が一致して初めて合格にします。
WordPress管理画面ではログイン・記事保存・画像追加を試します。cronや外部APIなど画面に表れない処理は、実行結果とログを確認します。移転直後はキャッシュを消した状態と通常状態の両方を見ます。公開ページだけが正常でも、翌日の定期処理で失敗する構成なら完了とは言えません。
メールとDNSは変更しない項目も照合する
Webだけを移した場合も、MX・SPF・DKIM・DMARCが切り替え前と同じか確認します。ネームサーバー変更でDNSを移したときは、変更しないはずのレコードが欠けやすくなります。外部アカウントから受信を試し、自社から外部へ返信します。フォーム通知も通常の個人メールとは別の送信経路として確認します。
メールも移した場合は、新旧受信箱を確認して取りこぼしを回収します。送信できた表示だけでなく、相手側で受信され迷惑メール扱いになっていないかを見ます。DNSSECを使っている場合は委任と署名の整合も対象です。DNSの変更票と現在値を照合し、意図しない差分を残しません。
速度とログは移転前の基準と比べる
測定にはPageSpeed Insightsを使います。移転前と同じURL・端末区分で複数回測り、実測データとラボデータを分けて読みます。点数だけで合否を決めず、応答開始や主要表示の変化を確認します。WordPress管理画面などPageSpeed Insightsで測らない機能は、操作時間とサーバーログから見ます。
アクセスログでは新環境へ利用者が来ていることを確認し、エラーログでは移転後に増えた失敗を探します。HTTP 200でも業務処理の成功までは証明できません。監視の通知先と監視URLも新しい構成へ合わせます。速度低下やエラーがあれば、旧環境との条件差を記録し、解約前に原因を判断します。
完了条件と戻す条件を同時に判定する
問題を見つけたときは、影響範囲と修正時間から新環境で直すか旧環境へ戻すかを決めます。戻すDNS値・最終バックアップ・更新停止の手順が使えることを確認します。軽微な表示差を理由に全体を戻す必要はありませんが、問い合わせや決済の停止を保留のまま公開し続けないことが大切です。
すべての合格記録と残課題を責任者が確認してから、旧サーバーの終了日を決めます。最終データを取得し、旧環境へのアクセスと更新がなくなったことを確かめます。hostsなど検証用の端末設定も戻し、台帳と復元手順を更新します。この判断記録が、移転完了を表示確認だけにしないためのチェックリストになります。
