NetlifyやGitHub Pagesで公開したWebサイトを、別のサーバーへ移すとき。新しいURLでページが表示されたら、移行完了だと思っていませんか？
読者
YuLab
実際には、表示できることと、安心して旧サイトを止められることは別です。ログイン、フォーム、保存データ、アクセス解析、自動デプロイなど、ページ表示だけでは確認できない項目があります。
私自身、穴埋めノート、幼児向けWebアプリ、ポートフォリオなど複数の制作物を、NetlifyやGitHub PagesからConoHa WINGの独自ドメイン配下へ段階的に整理しました。そのとき役立った「移行完了を判断するチェックリスト」を、個人開発向けに紹介します。
この記事の結論
旧公開先は一括で削除せず、新URL・各機能・データ・計測・公開フロー・旧URLの役割を確認してから、サイトごとに停止判断するのが安全です。
サーバー移行で起こりやすい見落とし
静的なHTML/CSSサイトなら移行は簡単に見えます。しかし、Webアプリになると状況は変わります。とくに、ブラウザ内へ保存するデータや、特定のURLを前提にした設定が見落とされがちです。
注意：URLが変わるとブラウザの保存領域も変わる
localStorage は原則としてオリジン（スキーム・ホスト・ポートの組み合わせ）ごとに分かれます。Netlify上に保存されたデータが、新しい独自ドメインのアプリへ自動的に引き継がれるわけではありません。必要なデータがある場合は、移行方法を事前に用意しましょう。
また、GitHub Pagesを開発中の確認先として使っている場合、正式公開先を移した後も役割が残っていることがあります。「古いから不要」と判断しないことが大切です。
移行前に確認したい6つの項目
公開中のサイトとURLを書き出す
サイト名、旧URL、新URL、公開に使うリポジトリ、更新方法を一度整理します。何をどこから公開しているか不明なままだと、不要と思って止めたサイトが実は別の作業に使われていた、という事態が起こります。
新しいURLで表示と基本操作を確認する
トップページだけでなく、ページ遷移、画像、音声、スマホ表示も確認します。アプリの場合は、問題登録・回答・復習など主要操作を最初から最後まで試します。
ログイン・フォーム・保存データを確認する
認証があるならログイン・ログアウト・再ログイン、フォームがあるなら送信から受信まで、データ保存があるなら保存後の再読込までを確かめます。旧ドメインに依存した設定が残っていないかも確認します。
GA4などのアクセス計測を確認する
計測タグがあることだけでなく、新URLから実際にイベントが届くかを確認します。使用している場合はMicrosoft Clarityなどの計測サービス、内部リンクやSNSプロフィールのリンク先も点検します。
次回の更新方法を確認する
現在のページが表示されても、次回の変更が反映できなければ運用は続けられません。私の制作物では、GitHubのmainブランチへ変更を反映し、GitHub Actionsを経由してConoHa WINGへ公開する経路を整えました。
自動化を使う場合は、デプロイ処理の成功表示だけでなく、公開先へ変更が実際に届いたかを確かめます。FTP/FTPSの認証情報をコードや記事に書かず、シークレットとして保管することも重要です。
旧サイトを今も使っていないか確認する
旧URLがSNSや記事で使われていないか、開発中の試作品確認に利用していないか、ほかのサービスから参照されていないかを見ます。確認が済むまでは旧環境を保留して構いません。
旧公開先は「削除・維持・保留」の3つに分けた
今回の移行では、すべてを同時に消す方法は取りませんでした。
実際に行った整理の考え方
削除候補：新URLで主要機能・保存・計測・更新経路を確認でき、旧環境の役割がなくなったもの。
維持：まだ試作版の実機確認などに使っている旧公開先。
保留：旧URLを使う外部リンクや、機能への影響が確認しきれていないもの。
私の場合、移行確認後に不要となった一部のNetlifyサイトは整理しました。一方、幼児向けアプリ群のGitHub Pagesは、当時、新作アプリの実機確認にも使っていたため、すぐには停止しませんでした。
重要なのは「使っているサービスをできる限り減らすこと」ではなく、残す理由と止める条件が説明できることです。
公開先を移したあとに使える最終チェックリスト
旧サイトを停止する前の確認
- 新URLでPCとスマホの表示が正常
- 主要機能・フォーム・ログインなどが動く
- 必要なデータの保存と引き継ぎを確認した
- GA4など計測サービスの受信を確認した
- GitHubなどから次回更新できる
- SNS・記事・ポートフォリオのリンク先を整理した
- 旧URLに試作・検証など残す理由がない
- 問題が出た場合に戻せる手段を確認した
すべてが不要なサイトもあります。例えばログイン機能のない単純なページなら、認証確認の項目は対象外です。サイトの機能に合わせて項目を調整してください。
実際に移行して分かったこと
AIでWebアプリを作ると、試作と修正の回数が増えます。そのぶん、公開先が分散すると「どれが最新版か」「どこを更新すればいいか」を確認する負担も増えます。
私にとってConoHaへの集約には、単に公開URLを揃えるだけでなく、公開と更新の手順を一定にする意味がありました。ただし、すべての人にサーバー移行が必要というわけではありません。利用規模や費用、必要な機能によって適した方法は変わります。
【PR】WordPress用サーバーの比較候補
私は現在ConoHa WINGを使っていますが、これからWordPressを始める場合は、XServer系も比較候補に入ります。料金だけでなく、サポートや運用のしやすさも含めて、自分に合う方を選ぶのがおすすめです。
まとめ：表示確認と移行完了は分けて考える
移行を完了と判断する基準
- 新しい公開先でサイトと主要機能が動く
- データ・計測・更新方法が継続できる
- 旧公開先に残すべき役割がない
移行作業のゴールは、旧サイトを消すことではありません。利用者が問題なく使えて、次回から迷わず更新できる状態を作ることです。新URLを表示できた段階で作業を終わらせず、停止条件まで確認しておくと、その後の手戻りを減らしやすくなります。
なお、移行を検討した背景にあった無料枠の制限については、Netlify無料枠のクレジットを使い切った実例で別途詳しく書いています。
移行後に公開している制作物は、幼児向けWebアプリ一覧から確認できます。
コメント