サイトリニューアルに合わせてサーバーを変えることはできます。ただし、デザイン、URL、サーバー環境が一度に変わると、不具合の原因が分かりにくくなります。特に注意したいのは、旧URLからの転送と、制作中に増えた記事・問い合わせデータの引き継ぎです。
公開日が同じでも、サーバー側の動作と新しいサイトの機能を分けて確認しておくと、切り替え時に問題を見つけやすくなります。
デザインの問題と、サーバーの問題は原因が違う
例えば、特定の画面だけ崩れる場合はテンプレートやCSS、フォーム送信時だけエラーになる場合はPHPやメール設定が関係しているかもしれません。リニューアルと移転を一度に行うと、この両方が調査対象になります。
同じ制作会社が担当するなら、必ず担当者を分ける必要はありません。新しいデザインの表示確認だけでなく、サーバー環境でフォームや更新機能が動くかも含めて確認することが大切です。
順番は切り分けやすさと期限から選ぶ
安全性を優先できるなら、旧サイトを新サーバーで確認してからリニューアルするなど変更を段階化します。先に新サイトを旧環境で完成させる方法もあります。どちらが適するかは、旧環境で新しい要件を動かせるかと契約期限から判断します。
同日公開が必要な場合も、検証工程まで同時にする必要はありません。同じ検証環境でも、移転先で旧サイトが動くことを確認してから新デザインを反映するなど、順に確かめる方法があります。必ず二つの検証環境を用意するという意味ではありません。
URLが変わるページは転送先も用意する
移行前に主要URLと応答コードを記録します。タイトル・検索流入・フォーム動作も基準値にします。新旧の差が意図した変更かを判断する材料になります。
DNSレコードと証明書も保存します。メール送信経路を含め、見た目に現れない設定を比較できるようにします。
URLが変わるページは旧URLと新URLを一対一で対応させます。トップページへ一括転送せず、同じ目的のページへ恒久的なリダイレクトを設定します。削除するページも代替先の有無を判断し、内部リンクとサイトマップを新URLへ更新します。
コンテンツ停止と最終同期を設計する
制作期間中に旧サイトへ記事・注文・問い合わせが増えると、最初の複製だけではデータが欠けます。どのデータが更新されるかを分類し、公開直前に同期する対象を決めます。編集停止が必要なら、開始時刻と影響する担当者を事前に案内します。
WordPressではファイルとデータベースの時点を合わせます。新環境で作った設定を旧データベースで上書きしないよう、移すテーブルや手順を確認します。最終バックアップを取得した後も、戻す際にどのデータを失う可能性があるかを記録します。
公開前の確認と、戻す場合の注意
公開前にDNSを変えず新環境を確認し、主要ページ・管理画面・フォーム・メール・証明書を試します。開発中のnoindexやアクセス制限を公開時に外す項目も検査票へ入れます。noindexは検索結果への掲載を抑える指定なので、公開後にも残っていると検索流入を失う原因になります。検証環境の方は、公開後も引き続き保護します。
決済不能や全ページエラーが出た場合には、公開を続けるか旧環境へ戻すかの判断が必要です。旧環境の保持期間とDNSを戻す手順も決めます。公開後に増えたデータの扱いを決めておくと、慌てて新旧を混在させずに済みます。
公開後は新旧サイトと検索状態を監視する
切り替え後は新サイトのエラー、サーバー負荷、フォーム到達を確認します。DNSの参照先が利用環境により異なる時間帯は、新旧双方のログを見ます。旧環境へのアクセスが続いてもすぐ削除せず、移行漏れか通常の反映過程かを判断します。
URL変更がある場合は、Google Search Consoleでクロール・インデックス・サイトマップを確認します。Googleは移行中に新旧サイトへのクロールを増やす場合があるため、アクセス増だけで攻撃と断定しません。Googleは旧URLからのリダイレクトを少なくとも1年維持するよう案内しています。転送は新サーバーでも提供できるため、旧サーバー契約自体を同じ期間残す必要があるとは限りません。
