WordPressの引っ越し手順｜サーバー移行の準備・確認・失敗を避けるチェックリスト
※本記事にはPRを含む場合があります。
こんにちは。『脱会社員』脱サラを応援し続けるブログ、運営者の『なかびー』です。
WordPressの引っ越しで大切なのは、データを移す操作だけではありません。「何を移すかを整理する」「切り替える前に新しい環境を試す」「旧環境をいつ終了できるか判断する」までを、一つの作業として考えることです。料金が安くなると思って契約しても、メールの移行漏れや有料プラグインの再設定が残れば、予定外の負担が生じます。
この記事では、独自ドメインのURLを基本的に変えず、別のレンタルサーバーへWordPressを移す場面を中心に、準備・移行方法の選択・動作確認・切り替え後の点検を整理します。ドメイン変更や大幅なサイト改修も同時に行う場合は、確認事項が増えるため、その違いも最初に切り分けましょう。特定のサービスへの乗り換えや、検索順位の上昇を約束する内容ではありません。
移行先をまだ決めていない方は、先に費用と移行機能を比べておくと、手順を調べ直す負担を減らせます。レンタルサーバー6社の料金・機能・選び方を比較する。すでに契約先が決まっている方は、そのまま下の準備と確認項目へ進んでください。
WordPressの引っ越しで移すものを整理する
サーバー移行とドメイン移管は別の手続き
レンタルサーバーは、サイトのファイルやデータベースを動かす場所です。独自ドメインは、読者がサイトへアクセスする際の名前に当たります。サーバー会社を変えても、ドメインを管理する会社まで必ず変える必要はありません。まず「サイトの置き場所を変える」のか、「ドメインの管理会社も変える」のかを分けて考えます。
例えば、現在のドメインを同じ管理会社に残し、サイトだけを新しいサーバーへ移すなら、ドメインの登録者変更や別会社への移管とは異なる作業です。反対に、サーバーの契約特典で取得したドメインを利用している場合は、旧契約の終了によって特典や更新条件がどうなるかを確認する必要があります。サイトを移せたことと、ドメインを今後も維持できることは別々に確認してください。
契約一覧には、サーバー、ドメイン、メール、バックアップ、有料テーマ、有料プラグインの契約先をそれぞれ書き出すと整理しやすくなります。請求が一つにまとまっていても、解約対象や更新日は同じとは限りません。管理会社が分からない場合は、過去の契約メールや請求内容から確かめ、推測だけで設定を変更しないようにしましょう。
記事のデータと画像・テーマなどのファイルをそろえる
WordPressの移行では、記事や各種設定が入るデータベースと、画像・テーマ・プラグインなどのファイルを区別します。記事のエクスポートファイルだけを保存すれば、現在のサイト全体が必ず再現されるというわけではありません。どの方法で何を移せるかは、利用する移行機能の対象範囲によって異なります。
確認する対象には、投稿と固定ページだけでなく、メニュー、ウィジェット、フォーム、テーマ設定、追加CSS、リダイレクト、計測用の設定なども含めます。日常的に記事を書いている人でも、最初の制作時に誰かが設定した項目は把握していない場合があります。普段触らない部分ほど、変更前の画面や設定内容を記録しておく意味があります。
画像が数枚表示できたからといって、すべて移せたとは限りません。古い記事、添付ファイル、PDF、カテゴリ別の画像など、保存時期や種類が異なるものを選んで確認します。外部サービスから表示している画像は、サーバー内の画像と扱いが違うため、「もともと外部にあるもの」として一覧に分けておくと切り分けに役立ちます。
メールや外部サービスはサイト移行とは別に確認する
独自ドメインのメールを使っている場合は、サイトが正常に表示されても、メールが届くとは限りません。メールの提供元、アカウント、受信方法、転送先、保存済みメールをどこで管理しているかを確認します。新サーバーにメールも移すのか、現在のメールサービスを継続するのかを先に決めておきましょう。
フォームからの通知、予約サービス、決済サービス、広告配信、アクセス解析なども別の確認対象です。連携先の管理画面でドメインや接続先の登録が必要なもの、有料ライセンスの認証を伴うものもあります。サイトの見た目が再現されたことだけで、外部との連携まで完了したと判断しないことが重要です。
読者向けの公開記事にある広告リンクは、移行と同時に不要な書き換えをしない方が比較しやすくなります。移行前後でURLや計測用の属性を保持できているかを確認し、成果計測のテストは広告主やASPが案内する方法に従います。運営者自身が何度も広告をクリックして確認する方法は避けましょう。
今回は何を変更しないかも決める
移行と同時にテーマ、URL構造、ドメイン、プラグイン構成まで一度に変えると、問題が起きた原因を追いにくくなります。最初に「今回はサーバーだけ」「テーマ変更は移行確認後」と範囲を決めると、確認項目と戻す方法が明確になります。古い環境に問題がある場合は、単純なコピーで解決するとは限らない点にも注意が必要です。
移行対象と対象外を一枚にまとめ、作業する人と確認する人で共有しておきます。個人運営でも、前日の自分と当日の自分が同じ判断をできるよう、文章にしておくと手戻りを減らせます。「サイトが見える」という曖昧な完了条件ではなく、代表記事、フォーム送信、メール受信など、何を確かめるかまで決めてください。
切り替え前にそろえるバックアップと確認リスト
復元できる形でバックアップを確保する
WordPress公式の移行案内は、ファイルとデータベースのバックアップから始めるよう説明しています。バックアップは、作成完了の表示を見るだけでなく、保存先、取得日時、対象範囲、復元手順を確認して初めて実用的な備えになります。旧サーバーを解約すると取り出せなくなる場所だけに残しておかないことも大切です。
保存する際は、ファイル名に日時や対象を入れて、古いものと混同しないようにします。例えば「移行前のサイト一式」と「移行後の確認用データ」を別のフォルダにするだけでも、トラブル時の判断を助けます。バックアップに個人情報や認証情報が含まれる場合は、公開フォルダや誰でも閲覧できる共有場所へ置かないでください。
復元に専用プラグインや有料機能が必要なら、その条件も把握します。データはあるものの、復元に必要な権限や契約がない状態では、想定した方法で戻せない可能性があります。重要なサイトでは、本番を壊して試すのではなく、隔離された検証環境で復元の流れを確かめられるか検討しましょう。
現在の動作環境と契約期限を記録する
WordPress、PHP、データベース、テーマ、主要プラグインのバージョンを記録します。移行先の環境に対応しているかは、公式の対応条件を確認してください。古い環境から新しい環境へ変わることが、必ずしもすべての機能にとって問題のない変更とは限りません。更新が必要な場合も、本番で一気に変更するのではなく、バックアップと動作確認を前提に計画します。
容量は記事数だけでは判断できません。画像、動画、メール、バックアップファイル、ログなどの利用量も確認します。自動移行機能には移行対象や容量の条件が設定されている場合があるため、「契約容量には収まるが移行機能の条件に合わない」という違いにも注意します。条件を満たせないときは、公式サポートへ対象と状況を伝えて相談しましょう。
契約期限は、旧サーバーの更新日、新サーバーの支払日、ドメインの更新日、自動更新の締切を並べます。旧契約の期限ぎりぎりに作業を始めると、再試行や確認の時間が取れません。移行のための重複契約期間は追加費用になる一方、安全に比較確認するための期間でもあります。安さだけで短縮しないようにしてください。
更新が入るサイトではデータの食い違いを防ぐ
記事を読むだけのサイトと、注文・予約・会員登録が続くサイトでは、切り替え時の注意点が異なります。コピーした後に旧環境で新しい情報が追加されれば、その差分は最初のコピーには含まれていません。ブログでも、コメント、問い合わせ、投稿の予約などが動いている場合は確認が必要です。
例えば、金曜夜にコピーして土曜朝に切り替える計画なら、その間の投稿編集やフォーム受信をどのように扱うかを決めます。更新を一時停止する範囲、作業開始の連絡方法、コピー後に追加された情報の確認方法を整理してください。注文を扱うサイトなどは、通常のブログと同じ手順で進めず、利用システムや担当者の案内に沿って計画する必要があります。
作業記録には、「何時に何をコピーしたか」「その後どこで編集したか」を残します。新旧どちらの管理画面を触っているのか分かりにくいときは、作業用のメモやブラウザのウィンドウを分けるなどして混同を防ぎます。ただし、分かりやすくするためだけに本番の記事タイトルやURLを変更する必要はありません。
作業前のチェックリストを判断に使う
確認項目は、契約・データ・権限・連絡の四つに分けると抜けを見つけやすくなります。契約では更新日と解約条件、データではバックアップと追加更新、権限では誰が何を操作できるか、連絡では問題が起きたときの問い合わせ先を確認します。パスワードそのものをチェック表に書く必要はありません。
開始条件を「バックアップの場所と復元手順が分かる」「新環境で必要な機能が使える」「問題時の対応先を確認した」のように決めます。一つでも未確認なら、ただ予定時刻が来たという理由で切り替えない方が安全です。条件を満たすまで新旧の契約を残す、専門の作業を依頼するなど、複数の進め方を用意しておきましょう。
自動移行・手動移行・依頼のどれを選ぶか
まず移行先の自動移行機能が対象サイトに合うか調べる
移行先のレンタルサーバーにWordPress移行機能がある場合は、対象サイトの条件と移せる範囲を確認します。名称が似ていても、各社の機能は同一ではありません。WordPressの種類、利用環境、容量、認証方法などによって使えないケースがあるため、契約前に公式マニュアルを読んで判断します。
ConoHa WINGの公式案内には、移行前の確認事項とテスト移行の説明があります。シンレンタルサーバーやロリポップ！の案内にも、移行対象になるデータと対象外のデータ、利用条件が記載されています。ここで重要なのは、他社の説明をそのまま自分の利用サービスへ当てはめないことです。具体的な操作は、選んだ移行先の最新手順に合わせてください。
自動移行という名称でも、メール、独自に置いたファイル、特殊な設定まで全部移るとは限りません。サイトの移行完了と、契約やメールを含めた引っ越し全体の完了を区別します。操作を始める前に対象外の一覧を確認し、自分のサイトで該当するものを別の作業として書き出しましょう。
手動移行は作業を理解できる場合に選ぶ
手動移行では、ファイルとデータベースの扱い、接続設定、文字列の置換が必要かどうかなど、判断する範囲が広がります。サイトの構成によって必要な手順が異なるため、一つの一般記事だけを見て、本番のデータベースを直接編集するのは避けてください。操作内容を理解できず、戻す手順も分からない場合は、公式サポートや専門家への相談を優先します。
特にURLを変える移行は、同じURLを保つサーバー変更とは別の検討が必要です。データベースのURLが含まれる場所を単純な文字列置換だけで処理すると、形式によって不具合につながる可能性があります。利用するツールの対応形式や公式手順を確認し、実行前にバックアップと検証環境を用意しましょう。
手動で進めること自体が良い、悪いというわけではありません。自分で検証できる範囲、サイトを止められる時間、問題が起きた場合に対応できる人を基準に選びます。日常の更新に使える時間が限られている副業ブログなら、手順の分かりやすさや問い合わせ先も、費用と同じくらい重要な比較項目です。
移行代行を頼むときは納品範囲を言葉にする
代行を利用する場合は、「サイトを移す」だけでは範囲が曖昧です。WordPress本体の移行、メール移行、SSL、フォーム確認、広告やアクセス解析の設定確認、旧環境の終了まで、どこを担当してもらうのかを確認します。作業費に含まれる内容と、別料金になる内容を分けて見積もりを依頼しましょう。
確認事項の例は、「URLを変更しない移行か」「停止時間の想定はあるか」「移行できなかった場合の扱い」「確認後の不具合連絡の期限」「旧環境を誰がいつ終了するか」です。実施日だけでなく、完了の判断方法も決めると、認識違いを減らせます。集客や検索順位まで保証する説明がある場合は、その根拠と契約条件を慎重に確認してください。
アクセス情報の受け渡しも、指定された安全な方法に従います。公開コメントや一般公開の資料へ管理情報を書かないでください。作業完了後に残る権限や一時アカウントの扱いは、依頼時点で確認しておくと整理しやすくなります。費用の安さだけで、管理権限を渡す相手を選ばないことも大切です。
移行先の比較は更新後の費用と運用条件まで見る
移行先の契約では、初回キャンペーンだけでなく、更新後の支払額、契約期間、バックアップの復元条件、サポート窓口、メールの利用条件を確認します。移行費用が無料でも、契約期間が自分の予定に合わなければ、総額では負担が大きくなる場合があります。数年先まで継続するか分からないなら、長期契約の割引を当然の正解にしないようにしましょう。
候補サービスを比較する段階では、当サイトのレンタルサーバー比較記事も参考にできます。移行手順を確認するこの記事と、費用・機能を比べる記事を使い分けると、操作と契約の判断を混同しにくくなります。比較表の料金や特典は変わるため、申込み直前に公式の表示と条件を確かめてください。
DNSを変える前に新環境の動作を確認する
テスト環境で公開ページと管理画面を確かめる
データのコピーが終わったら、すぐにアクセス先を切り替えるのではなく、新環境での動作を確認します。テスト移行、確認用URL、hostsを使う方法などがありますが、利用できる方法はサービスやサイト構成によって異なります。自分のサイトに合う公式手順を選び、確認用のURLを本番のURLと混同しないでください。
確認するページは、トップページだけでなく、記事、固定ページ、カテゴリ、検索結果、画像を多く使うページなどに分けます。ログインしているときだけ正常に見える場合もあるため、読者としての表示も確認します。PCだけでなくスマートフォン相当の幅で、表や画像、メニューがはみ出していないかを見ましょう。
確認の記録は、ページ名、確認した日時、問題の有無、対応内容の四つで十分です。最初からすべてのページを細かく見られない場合も、アクセスが多いページ、収益につながるページ、重要な申込みページを優先して選びます。確認した範囲を明記すれば、「全部確認したつもり」の見落としを防ぎやすくなります。
フォーム・通知・予約投稿まで実際の機能を点検する
問い合わせフォームは、入力欄が表示されるだけでなく、送信できるか、通知が届くか、返信先が正しいかを確認します。テストメッセージを送る場合は、実際の問い合わせと区別できる内容にしてください。予約・決済など外部に影響がある機能は、提供元のテスト手順を利用し、実注文や二重請求が発生しないようにします。
予約投稿や定期処理も忘れやすい確認項目です。時刻の設定、実行の仕組み、外部サービスからの呼び出しなど、現在使っている処理を一覧にして照合します。「記事を開けたから大丈夫」と判断すると、時間が経って初めて動く機能の問題を見落とします。新旧で同じ処理が二重に動く可能性にも注意してください。
アクセス解析や広告設定は、管理画面に設定値が残っているかと、実際のページに必要なコードが出力されるかを分けて確認します。成果計測の問題はリンクの表示だけでは判断できません。ASPや広告主が提供する確認方法に従い、自己クリックや自己申込みで数字を作らないようにしましょう。
SSL・リダイレクト・キャッシュの役割を混同しない
SSL証明書の設定、httpからhttpsへの転送、wwwの有無、キャッシュはそれぞれ別の確認事項です。SSL証明書の発行タイミングや、DNS変更前に確認できる範囲はサービスによって異なります。一つの手順を全サービス共通の順番として扱わず、移行先の公式案内に沿って準備してください。
証明書や安全性の警告が出たときは、読者にも警告を無視するよう求めるのではなく、原因を確認します。画像だけが古いまま、変更が反映されないなどの現象は、キャッシュの影響と、別の環境を見ていることの両方が考えられます。複数の設定を一度に変更するより、どの経路でどの結果になったかを記録して切り分ける方が有効です。
SEO関連では、テスト用の検索除外設定が本番に残っていないかを確認します。公開予定のページにnoindexが付いたままになっていないか、robots.txtによる意図しない制限がないか、canonicalが適切かなどを点検します。URLを変えない移行なら、サイト内リンクのURLまで必要なく変更していないかも確認してください。
不具合を見つけたら切り替え前に立ち止まる
確認中に問題が見つかったときは、予定どおり公開することを優先しすぎないようにします。重要なフォームが動かない、画像が大量に欠ける、管理画面に入れないなど、運営に必要な機能が使えない状態なら、切り替え前に対応できるか確認します。直したつもりの項目は、同じ条件で再度試すことが大切です。
問い合わせには、移行元・移行先のサービス、問題が起きるページ、発生する操作、表示されたエラー、実行した時刻を整理して伝えると説明しやすくなります。個人情報や認証情報は隠し、スクリーンショットも必要な部分だけにします。こうした記録は、サポートへ相談するときにも、自分で再確認するときにも役立ちます。
切り替え当日の進め方と旧環境を残す判断
DNS変更は準備完了後の切り替え操作として扱う
DNSは、ドメイン名に対するアクセス先を調べる仕組みです。サーバーを移す際は、ネームサーバー全体を変更する方法と、利用中のDNS管理を続けて必要なレコードを変える方法などがあります。どちらが適切かは構成により異なり、メールや外部サービスに関係する設定もあるため、必要な値を把握せずに一括で置き換えないようにしてください。
例えば、サイトとメールを別々のサービスで管理しているなら、サイトの接続先を変えるだけのつもりでも、メール用の設定が抜けると受信に影響する可能性があります。設定変更前に現在値を記録し、変更対象を明確にします。技術的な判断が難しい場合は、旧・新サービスのサポートへ、メールを継続する構成も含めて確認しましょう。
Googleのホスティング変更の案内も、新環境の準備とテスト、DNS設定の変更、トラフィックの監視、旧環境の停止を分けて説明しています。サイトのデータをコピーした時点と、実際に読者が新しい環境へ接続する時点は同じとは限りません。作業記録では、この二つの時刻を別々に残すと整理できます。
反映のばらつきを前提に、新旧の状態を見る
DNS設定を変えた直後は、利用しているネットワークやキャッシュの状態によって、見える環境が異なる場合があります。自分の端末だけを見て「全員が新環境へ移った」とは判断しないようにします。アクセスログや公式の確認方法など、実際の接続先を判断できる情報を使って確かめてください。
旧環境へアクセスが残っている間は、投稿編集やフォームの受信がどちら側に入るかにも注意します。新旧両方で更新を続けると、どちらが最新データなのか分からなくなります。切り替え中の編集方針を決め、必要な情報が失われていないかを確認しながら進めます。一定時間待ったことだけを完了の根拠にしない方が安全です。
ネットワークを切り替えて確認する場合も、それだけで全世界の反映が保証されるわけではありません。確認できた範囲を記録し、旧環境へのアクセスや重要な機能の状態を継続して見ます。具体的にどれくらい旧契約を残すかは、サービスの案内、データの更新頻度、利用中の機能を踏まえて判断してください。
戻す場合にも、追加されたデータを考える
切り替え後に不具合が起きた場合、アクセス先を戻せば必ず問題が終わるとは限りません。新環境で注文や問い合わせ、記事編集などが発生していれば、その情報をどう扱うかが残ります。事前の切り戻し計画には、設定を戻す方法だけでなく、その間の追加データの確認方法も含めてください。
影響が小さい表示の問題なのか、問い合わせを失う可能性がある機能の問題なのかによって、優先する対応は変わります。緊急時に迷わないよう、「この問題なら切り替えを止める」「この問題ならサポートへ相談する」という判断基準をあらかじめ決めておきます。自分だけで判断できない構成なら、対応できる人を作業前に確保しましょう。
旧サーバーの解約は確認がそろってから行う
旧サーバーを終了する前には、新環境の表示、フォーム、メール、定期処理、必要なデータの保存、ドメインの維持条件を確認します。旧サーバー内にしかないバックアップやメール、別サイトが残っていないかも点検してください。一つのブログの移行が終わっても、同じ契約内の別サービスまで不要になったとは限りません。
解約操作では、対象契約と終了日を確認し、画面や案内メールを保存します。自動更新停止と即時解約が同じ意味とは限らないため、管理画面の文言をよく読みましょう。移行の成功を確認することと、旧契約の料金を整理することを最後まで別の作業として扱うと、運営上の抜けを減らせます。
移行後の点検と、よくある失敗を防ぐ運用
確認を当日・数日後・更新前に分ける
移行後の点検は、一度で全部終わらせようとするより、確認する内容に応じて分けると管理しやすくなります。当日は主要ページや問い合わせ、メールなどの基本動作を確認し、その後はアクセスやエラー、予約投稿、検索への掲載状況を見ます。契約更新前には、当初の目的が達成できたかと実際の費用を確認します。
これは、何日たてば安全と保証する予定表ではありません。短時間で確認できる表示と、実際に利用されて初めて分かる機能を分けるための考え方です。記事を毎日更新するサイトと、月に一度だけ更新するサイトでは、必要な確認の機会も異なります。自分の運営頻度に合わせて、点検項目を選びましょう。
検索順位やアクセスの変化を移行だけのせいにしない
サーバーを変えただけで、検索順位が必ず上がるわけではありません。移行後にアクセスが増減した場合も、季節、記事更新、検索結果の変化など複数の要因が考えられます。検索流入を比較するときは、対象期間、曜日、公開した記事、変更した設定をそろえて見ます。数時間の数字だけで成功や失敗を決めないことが大切です。
Search Consoleでは、表示回数、クリック数、対象ページの状況を確認します。ページが開けない、意図しない検索除外がある、別URLを正規URLとして示しているなど、具体的な問題がないかを先に点検しましょう。URL自体を変更した場合は、URL変更を伴うサイト移転の公式案内に沿った対応が必要で、今回の同一URLでの移行と同じ扱いにはできません。
費用比較は月額表示ではなく実際の支払いで行う
移行による費用を振り返るときは、新サーバー代だけでなく、旧契約との重複期間、移行作業の費用、ドメイン更新、必要なオプションを含めます。例えば、仮に新契約の年間支払額が12,000円、旧契約の重複分が2,000円、作業費が5,000円なら、初回に考える支出は19,000円です。これは説明用の架空の数字であり、特定サービスの料金ではありません。
翌年も同じ19,000円になるとは限りません。初年度だけの作業費や割引、更新後の通常料金を分ければ、継続した場合の負担を考えやすくなります。安くなった金額だけでなく、問い合わせにかかる時間や、作業の分かりやすさなども、自分にとって続けやすい環境かを判断する材料になります。
よくある疑問は「自分の条件」に戻して考える
「プラグインだけで全部移せるか」という疑問は、移行対象外の設定やメールがあるかを確認して判断します。「旧サーバーをいつ解約するか」は、新旧のアクセスと必要な機能を確認できたかで考えます。「サーバーを変えれば速くなるか」は、画像やテーマ、プラグインなど他の要因も含めて調べます。同じ質問でも、サイト構成によって答えが変わるためです。
「無料の移行機能で十分か」も、料金だけの問題ではありません。対象条件に合い、確認できる範囲を理解し、問題が起きた場合の対処先が分かっているかが判断の中心になります。公式マニュアルを読んでも自分の状態に当てはめられない部分が残るなら、操作を進める前に問い合わせる価値があります。
最後に、完了と判断するための記録を残す
移行の記録には、利用した方法、切り替え日時、確認したページと機能、残っている課題、旧契約を終了した日を残しましょう。担当者が変わったときや、数年後に再度移行するときも参考になります。パスワードや秘密の値を記録用の記事に混ぜず、運営の判断に必要な事実だけをまとめます。
WordPressの引っ越しは、「新しい場所へデータを入れた」で終わる作業ではありません。準備、テスト、切り替え、利用状況の確認、旧環境の整理まで進めて、ようやく運営の土台を引き継げます。焦ってすべてを同日に変えるより、戻せる準備と確認できる条件をそろえ、自分のサイトに合った方法で進めてください。 ブログ運営全体の準備を見直したい場合は、副業ブログの始め方も併せて確認できます。
移行前の準備が整理できたら、次は移行先の費用と対応範囲を確認しましょう。自分に合うレンタルサーバーを6社比較で確認する。月額だけでなく、更新料金・移行機能・サポートまで比べてから判断してください。
移行手順の確認に使った公式資料
以下は操作・仕様の確認用資料です。契約先の比較は上の比較記事で、具体的な操作は利用するサービスの最新マニュアルで確認してください。
ConoHa WING：WordPressかんたん移行 / シンレンタルサーバー：WordPress簡単移行 / ロリポップ！：WordPress簡単引っ越し
