既存サイトを止めずに、サーバー移行と更新基盤を分けて進める

すでに利用されている製品サイトのため、リニューアル作業中も閲覧を止めず、既存URLとコンテンツを維持することが前提でした。そのうえで、検索流入を増やすための情報ページと、社内で継続更新するニュース領域をWordPressで運用したい要望がありました。既存サイト全体をCMSへ載せ替えるのか、更新が必要な部分だけを追加するのかを判断する必要がありました。

サーバー移行、WordPress導入、ドメイン・DNSの切替を同時に行うと、不具合が起きた際に原因を特定しにくくなります。また、現在の表示を維持するだけでは、更新担当者の作業範囲や、検索向けページを増やすルールが曖昧なまま残ります。公開を止めないことと、今後更新しやすくすることを別の課題として整理する必要がありました。

現行サイトの移行と、新しい更新領域の構築を分けました。まず既存ページが新環境でも同じURLと表示で動く状態をつくり、リンク、フォーム、計測、ファイル参照を確認します。その後、ニュースや検索向けページなど継続更新が必要な範囲へWordPressを導入し、固定された製品ページまで無理に同じ管理方式へ入れない方針としました。

公開切替も、移行先での動作確認、CMS領域の確認、DNS・サーバー切替、公開後確認の順に分けました。問題が起きた場合に戻せる地点と、誰が判断するかを明確にし、移行とコンテンツ追加の原因を切り分けられるようにしています。検索向けページは数を先に決めず、テーマ、元となる情報、更新責任、関連する製品ページへの導線を確認してから追加する構成です。

既存サイトの利用者にとって、移行は新しい操作を覚える機会ではありません。基本のナビゲーションと製品情報への到達方法は維持し、新しく加えるニュースや情報ページだけが浮かないよう、見出し、余白、関連リンクのルールをそろえました。既存部分を全面的に作り直すより、どこが更新領域かを自然に理解できることを優先しています。

検索から情報ページへ直接訪れた利用者が、記事を読んで終わらず、関連製品や問い合わせへ進める導線も設けました。更新担当者が画像や文章量を毎回調整しなくても一定の読みやすさを保てるよう、記事内の構成要素を限定しています。

サーバー移行では、ファイルを置くだけでなく、URL、PHPやデータベースの条件、フォーム送信、外部サービス、解析タグ、リダイレクトを確認対象にします。WordPressは更新する範囲へ限定し、既存の静的ページと共存させることで、移行時の変更範囲を抑えました。DNS切替前後の確認項目を分け、旧環境へ戻す判断もできる手順としています。

この進め方は、現行サイトを止められず、更新が必要な領域だけを段階的にCMS化したい案件に向きます。一方、既存環境の仕様や管理権限、DNSの管理者、フォームの送信先が確認できない場合は、移行日を先に決めるべきではありません。移行元と移行先の責任範囲、切替を判断する人、問題発生時の連絡経路まで確認してから実施します。