サイトリニューアルとサーバー移転を同時に進めるときの注意点

リニューアルは見た目や情報設計を変え、サーバー移転は配信基盤を変える作業です。同じ公開日に重ねると効率的に見えますが、不具合の原因と戻す対象が増えます。二つの変更を別々に説明できる計画を作り、同時公開が本当に必要かを先に判断します。

二つの変更軸を分けて責任範囲を決める

リニューアル側ではテンプレートとコンテンツの変更を一覧にします。URLと機能の変更も同じ一覧へ加えます。

移転側ではOS・PHP・Webサーバーの環境差を整理します。DNSとメールも対象です。不具合ごとにどちらの担当が一次判断するかを決め、同じ項目を双方の未対応にしません。

公開責任者は制作完了と移転完了を別々に判定します。新しい画面が表示されたという一つの確認だけでは、基盤と内容のどちらも合格したことになりません。検査結果を二つに分けることで、問題時にリニューアルだけ戻す判断も可能になります。

安全性を優先できるなら、旧サイトを新サーバーで確認してからリニューアルするなど変更を段階化します。先に新サイトを旧環境で完成させる方法もあります。どちらが適するかは、旧環境で新しい要件を動かせるかと契約期限から判断します。

同日公開が必要な場合も、検証工程まで同時にする必要はありません。移転だけを試す複製と、新デザインを試す環境を分け、合流する条件を決めます。公開日から逆算して結合試験の時間を確保できないなら、変更範囲か日程を見直します。

移行前に主要URLと応答コードを記録します。タイトル・検索流入・フォーム動作も基準値にします。新旧の差が意図した変更かを判断する材料になります。

DNSレコードと証明書も保存します。メール送信経路を含め、見た目に現れない設定を比較できるようにします。

URLが変わるページは旧URLと新URLを一対一で対応させます。トップページへ一括転送せず、同じ目的のページへ恒久的なリダイレクトを設定します。削除するページも代替先の有無を判断し、内部リンクとサイトマップを新URLへ更新します。

制作期間中に旧サイトへ記事・注文・問い合わせが増えると、最初の複製だけではデータが欠けます。どのデータが更新されるかを分類し、公開直前に同期する対象を決めます。編集停止が必要なら、開始時刻と影響する担当者を事前に案内します。

WordPressではファイルとデータベースの時点を合わせます。新環境で作った設定を旧データベースで上書きしないよう、移すテーブルや手順を確認します。最終バックアップを取得した後も、戻す際にどのデータを失う可能性があるかを記録します。

公開前にDNSを変えず新環境を確認し、主要ページ・管理画面・フォーム・メール・証明書を試します。開発中のnoindexやアクセス制限を公開時に外す項目も検査票へ入れます。公開担当者は制作と移転の両方の合格記録を見て切り替えます。

切り戻しは「大きな問題が出たら」では判断が遅れます。決済不能や全ページエラーなど条件と決定者を先に定めます。旧環境の保持期間とDNSを戻す手順も決めます。公開後に増えたデータの扱いを決めておくと、慌てて新旧を混在させずに済みます。

切り替え後は新サイトのエラー、サーバー負荷、フォーム到達を確認します。DNSの参照先が利用環境により異なる時間帯は、新旧双方のログを見ます。旧環境へのアクセスが続いてもすぐ削除せず、移行漏れか通常の反映過程かを判断します。

URL変更がある場合は、Google Search Consoleでクロール・インデックス・サイトマップを確認します。Googleは移行中に新旧サイトへのクロールを増やす場合があるため、アクセス増だけで攻撃と断定しません。リダイレクトと旧環境を十分な期間維持し、基準値との差を追います。