SiteGroundでサイトを作成・移行する前に確認したいこと

SiteGroundを使う前に、今回はゼロからサイトを作るのか、それともすでに利用者がいるWordPressを移すのかを決めます。新規サイトは主にコンテンツと管理方法の整理が必要ですが、移行では既存データ、更新時点、切り替えのリスクも扱います。どちらもプラットフォームのツールから始められますが、同じ完了メッセージだけですべての確認が済んだとは考えられません。

本記事はSiteGroundの新規サイト、WordPress Migrator、Stagingに関する公開文書に基づく説明で、アカウントにログインした実機検証ではありません。継続的に注文、会員登録、フォームを受け付けるサイトでは、移行中もデータが変わり続ける点に特に注意してください。最終同期と切り替えの担当者を先に決めることで、新しいデータの取りこぼしを防ぎやすくなります。

購入前に必要なツールとリソースを確認する

サイト数、ファイルとデータベースの容量、必要なプラグイン、メールボックス、バックアップ、テストの要件を列挙し、現行プランと照合します。Staging、必要な時点でのバックアップ作成、共同作業の権限などは、プランによって利用条件が異なる場合があります。最新の製品説明とアカウントの内容を確認し、紹介ページの全機能がすべてのプランに含まれるとは考えないでください。

費用を比べるときは、初回支払、更新、追加サービス、必要な人手を分けて記録します。公式の移行支援が必要なら、対象範囲、提出する情報、料金を先に確認し、メール、外部サービス、独自プログラムまで含むかも尋ねます。移行の目的は元の業務を続けられることであり、見た目が似た新しいトップページを手に入れることだけではありません。

新規サイトは設定ウィザードで作成する

現在の初回設定では、Client AreaのWebsitesからFinish Site Setupを選び、ドメインとWordPressを確認します。別のサイトを追加する場合はNew WebsiteからWordPressを選び、画面に従って設置先、ドメイン、管理者情報を設定します。ドメインを購入する選択肢と、すでに持っているドメインを使う選択肢は別です。次へ進むためだけに別の名前を買わず、どちらが必要か先に確認しましょう。

作成後はWordPressの管理画面に入り、トップページ、主要コンテンツ、連絡先を整えてから、ナビゲーションと外観を調整します。家庭教師のサイトなら、まず科目、授業方法、問い合わせフォームを用意し、実際の情報がない生徒の成績や口コミを追加しないようにします。インストール手順が提供するのはコンテンツの出発点であり、公開情報と画像の利用権は自分で確認する必要があります。

移行前に移行元と移行先を準備する

既存サイトでは、復元可能なファイルとデータベースのバックアップを先に取得し、現在のURL、プラグイン、定期処理、メール、重要な連携を記録します。移行元に適切な移行プラグインを導入でき、移行先のサーバーにも十分なリソースがあることを確認してください。制限のあるプラットフォーム、マルチサイトネットワーク、特殊な構成が移行元なら、ツールの互換性と制約を調べ、必要に応じて公式支援を利用します。

SiteGroundの公式手順では、移行先のSite ToolsでWordPress、Migratorを開き、移行先ドメインとパスを選んでMigration Tokenを発行します。それを移行元サイトのSiteGround Migratorプラグインに入力します。移行先に残すべきコンテンツがないことを先に確認し、トークンは機密情報として扱い、対応する移行作業だけに使ってください。

移行が完了したら、公式のプレビューやテスト方法でコピーを確認し、旧サイトは当面残します。コピーの成功は、メール、ドメイン登録、すべての外部サービスまで移ったことを自動で証明するものではありません。従来の送信メール、定期処理、キャッシュ設定が新環境でどう動くかも確認し、記事数が一致しただけで検証を終えないようにします。

1. 移行元をバックアップし、プラグイン、データ、メール、現在も新しいコンテンツを生成する機能を一覧にする。
2. Site ToolsのWordPress → Migratorで、移行先に対応するトークンを発行する。
3. 移行元WordPressに公式Migratorプラグインを導入し、移行先を確認して移行を送信し、結果を保存する。
4. 新サイトをプレビューしてデータと機能を抽出確認した後、最終同期、DNS切り替え、旧サービスの保存期間を決める。

Stagingは変更を試す場所で、常時同期された本番サイトではない

利用条件を満たすアカウントでは、Site ToolsのWordPress、Stagingからテスト用コピーを作成できます。公式文書ではサイトのファイルとデータベースをコピーすると説明されているため、テスト環境にも本番データが含まれる可能性があります。アクセスを制限し、外部連携を見直してください。「新レイアウトのテスト」など用途が分かる名前を付け、見分けのつかない「新サイト」をいくつも作らないようにします。

SiteGroundの文書によると、StagingのコピーではWordPress標準のcron機能が無効になり、自動処理の重複を減らします。ただし、すべての第三者サービスへの外部呼び出しが止まるという意味ではありません。決済、メールマガジン、Webhook、外部の定期実行を確認し、必要ならテストモードやテスト用認証情報を使用します。URLにstagingが含まれるという理由だけで、コピー上で実際の課金を行わないでください。

テスト済みの変更を本番へ反映する前に、デプロイでどのファイルやデータベースのテーブルが更新されるか理解します。テスト中に本番で新しい注文を受けていた場合、古いデータベースをそのまま上書きすると失われる恐れがあります。データ構造を理解する人が適切な反映範囲と同期方法を確認し、操作前に新しいバックアップを取得してください。ワンクリックのデプロイでも、データのリスクがないわけではありません。

本番切り替えではデータと機能を確認する

切り替え前にデータ更新の締め切り時点を決め、必要に応じて新しいデータを生む処理を一時停止してから最終同期を行います。自分のドメインとDNSサービスに合わせて設定し、元の値と復旧方法を残すとともに、メール用レコードを誤って変更していないか確認します。本番ドメインが新サイトへつながったら、HTTPS、ルートドメイン、www、重要な深い階層へのリンクを再確認します。

未ログインのブラウザーとスマートフォンで、記事、画像、検索、フォーム、ログインなど主要な訪問者の操作を試します。移行したサイトでは、古い記事だけでなく直近に追加したデータも照合してください。ショップがある場合は、プラットフォームのテスト手順に従って購入手続き、通知、管理画面のデータを確認します。トップページが開けることだけで、業務の流れ全体が復旧したとは考えないでください。

引き継ぎ条件が明確になるまで旧サイトを残す

新サイトが安定していると確認してから、元の提供元の条件に従って旧サービスの停止を手配します。旧プランにメールボックス、バックアップ、他のサイトが依存していないか先に確認し、必要なデータを保存してください。新サイトを元に戻す場合も、切り替え後に追加されたコンテンツをどう扱うか明確にします。DNSを戻すだけで、すべてのデータが自動で一致するとは限りません。

最後に管理表を作り、Site Tools、WordPress、ドメイン、DNS、バックアップ、更新の担当者と、今回使った移行・検証方法を記録します。次の更新や移行で一から調べ直す手間を減らせます。ツールはコピー時間を短縮できますが、継続的な保守には明確な責任、データ保存、検証可能な完了条件が必要です。

詳しい説明を読む

SiteGroundの移行を、移行元バックアップ、ツールでのコピー、プレビューテスト、本番切り替えの順に進め、各段階の検証資料を保存する図。

サイト保守で行うこと：バックアップ、更新、障害報告の日常的な管理

DNS設定の確認方法：A・CNAMEからメール用レコードまで

• チュートリアル
• アプリ・ソフト
• サイト構築・EC
• WordPress