サーバー移行で壊れるのは、ファイルではなく環境の差
この記事の目次 読みたい項目へ移動
サーバーの引っ越しは、作業そのものより「移した後に何を確かめるか」で結果が変わります。壊れ方に型があるので、先に知っておくと慌てずに済みます。
移行・サーバー・複製に関する相談は、600+件のうち22件でした。
件数としては中位ですが、壊れ方が毎回よく似ているのが特徴です。
裏を返せば、移す前に確認する項目を決めておけば、多くは防げます。
この記事では、実際に起きた型を並べて、移行の前後に何を見るかを整理します。
引っ越しの理由も、相談の中では似通っていました。
料金の見直し、表示が重い、サポートの対応、そしてサーバー会社側のサービス終了。
どれも前向きな判断ですが、移すこと自体が目的になると確認が抜けます。
- 移行で壊れるのは「ファイル」ではなく、たいてい環境の差であること
- 移行後に起きる代表的な症状と、その原因
- データベースの中に残る、古い URL の扱い方
- 移す前に控えておくべき、移行元の情報
- 移行を任せるか自分でやるかの、判断の目安
壊れているのはファイルではなく、環境の差
移行の相談でいちばん多い誤解が、「ファイルが壊れた」というものです。
実際には、ファイルは正しくコピーできていることがほとんどでした。
壊れて見えるのは、移行元と移行先で前提が違うからです。
同じファイルでも、置かれる環境が変われば動きが変わります。
この6つを移行前に突き合わせておけば、起きる問題の大半は予測できます。
逆に、突き合わせずに移してしまうと、症状から逆算することになります。
全体の構造はWordPressはどう動いている？全体図を参照してください。
もうひとつ、見落とされやすいのがファイルの置き場所です。
サーバーによって、公開されるフォルダの名前や階層が違います。
同じ場所に置いたつもりでも、実際には1階層ずれていることがあります。
この状態だと、トップページすら開きません。
逆に言えば、「まったく開かない」ときは置き場所を最初に疑います。
移行後によく出る、4つの症状
22件で実際に起きていた症状を、型として並べます。
| 移行後の症状 | 疑うところ | 最初に試すこと |
|---|---|---|
| トップ以外が 404 | パーマリンクの仕組み | 設定を開いて、そのまま保存し直す |
| 画像だけ出ない | データベースに残った古い URL | 画像のアドレスを直接開いて確認 |
| 管理画面が崩れる | サイトアドレスの設定2か所 | 設定値が新しいドメインか確認 |
| 文字化け | データベースの文字コード | 作業を止めて、移行元の有無を確認 |
| プラグインだけ動かない | PHP の版、またはライセンス | エラーログと設定画面を見る |
| メールが届かない | 送信経路の変更 | フォームから自分宛てにテスト送信 |
この表の右列は、どれも管理画面かブラウザだけでできる確認です。
順番に試すだけで、どこに原因があるかはかなり絞れます。
トップページだけ開いて、他が 404
最も多い型です。
トップは表示されるので一見うまくいったように見えますが、他のページが開きません。
原因は、パーマリンクの設定を実現している仕組みが移行先で効いていないことです。
サーバーによって設定ファイルの書き方が違うため、そのまま持っていくと無効になります。
- まず管理画面のパーマリンク設定を開いて、そのまま保存し直す
- それで直らなければ、サーバー側の設定ファイルを確認する
- 管理画面にも入れない場合は、設定ファイルを一時的に外して切り分ける
切り分けの手順はURL設定とDB接続の確認にまとめています。
画像だけ表示されない
記事の文章は出るのに、画像だけ出ない。
これはデータベースの中に、移行元の URL が残っている典型的な症状です。
本文に書かれた画像のアドレスが、古いドメインのままになっています。
古い側がまだ生きていれば表示されてしまうため、気づくのが遅れることもあります。
管理画面に入れない・入っても表示が崩れる
ログイン画面は出るのに、入ったあとで崩れる場合があります。
管理画面のアドレスが古いままで、読み込む部品の場所がずれている状態です。
設定の2か所（サイトアドレスと WordPress アドレス）を確認します。
ログインできない場合の切り分けはログインできない原因の整理にあります。
文字化け
日本語が記号の羅列になる症状です。
データベースを書き出して取り込むときに、文字コードの指定がずれると起こります。
この症状だけは、後から直すのが難しいので注意が必要です。
化けた状態で上書きしてしまうと、元の文字列が失われます。
気づいた時点で作業を止め、移行元のデータが残っているかを確認してください。
文字化けのご相談で最初に伺うのは「移行元はまだ生きていますか」です。生きていれば、やり直せば済みます。
プラグインだけが動かない
表示は問題ないのに、特定のプラグインの機能だけ止まることがあります。
多いのは、PHP の版が上がって古い書き方が通らなくなった場合です。
この場合、エラーログにそのプラグインのファイル名が記録されています。
読み方はエラーログ解析でトラブルを即解決にまとめました。
もうひとつ多いのが、ライセンスがドメインに紐づいている場合です。
有料のテーマやプラグインでは、移行先のドメインで登録し直す必要があります。
- エラーログにファイル名が出ていれば、PHP の版の問題
- 設定画面に「ライセンスが無効」と出ていれば、登録のし直し
- どちらでもなければ、そのプラグインの設定値が失われている可能性
データベースの中の URL を、どう扱うか
移行のつまずきの多くが、この一点に集まります。
WordPress は、記事の本文や設定の中に URL をそのまま保存しています。
だから、ドメインが変わると中身も書き換える必要があるわけです。
ところが、単純な置換をしてはいけない箇所があります。
| 保存されている場所 | 置換してよいか | 注意点 |
|---|---|---|
| 記事本文の画像・リンク | よい | http と https の両方を確認する |
| サイトアドレスの設定 | よい | 管理画面か設定ファイルから変更 |
| プラグインの設定値 | 注意 | まとめて保存されている場合は壊れることがある |
| テーマのカスタマイズ内容 | 注意 | 同上。専用の道具を使う |
下の2つは、複数の設定がひとまとまりで保存されていることがあります。
この形式は文字数の情報を含んでいるため、中の文字列だけを置き換えると整合が崩れます。
崩れると、その設定がまるごと読み込まれなくなります。
- 単純な文字列置換ではなく、この形式を理解する道具を使う
- 置換の前に、必ずデータベースの控えを取る
- 置換後は、プラグインの設定画面が開くかどうかを確認する
仕組みと対処はDB事故と移転 ― シリアライズデータと整合性の防衛で詳しく扱っています。
なお、置換の対象は http と https の両方を見る必要があります。
移行のタイミングで SSL を導入する場合、古い側は http で保存されているためです。
片方だけ置換すると、混在した状態が残ります。
ブラウザが「保護されていない通信」と警告を出すのは、この状態です。
移す前に、控えておきたいこと
移行そのものより、移す前の記録が結果を左右します。
移行先で不具合が出たとき、比較する相手があるかどうかで解決までの時間が変わるためです。
4つ目の「画面を撮っておく」は、地味ですがいちばん役に立ちます。
移行後に「ここ、前からこうだったかな」と迷う場面が必ず出るためです。
現状の確認はWP-CLI での現状調査を使うと一度に取れます。
プラグインの状態だけならプラグイン・テーマの状態を安全に確認する方法が早いです。
移行後に確認する順番
移し終わったあと、どこから見るか。
表示を見る前に、まず土台が合っているかを確かめます。
- 1. サイトアドレスの設定2か所が、新しいドメインになっているか
- 2. トップ以外のページが開くか（パーマリンク）
- 3. 画像が表示されるか（データベースに残った URL）
- 4. 管理画面が崩れずに開くか
- 5. フォームから実際に送信して、メールが届くか
- 6. https で開くか、警告が出ないか
5番目のフォームは、忘れられがちな項目です。
サーバーが変わるとメールの送信経路も変わるため、届かなくなることがあります。
画面上は送信完了と出るので、テストしないと気づけません。
6番目の SSL は、切り替えのタイミングによっては後追いになります。
証明書が用意できるまで、一時的に警告が出る期間があると考えておいてください。
この6項目は、移行の当日に通しで行ってください。
翌日に回すと、気づいたときには検索結果やアクセスに影響が出ています。
所要時間は、慣れていれば30分ほどです。
見落とされやすい、3つの落とし穴
上の6項目を確認しても、あとから出てくるものがあります。
検索エンジンに向けた設定
移行のときにテスト用として「検索避け」を有効にすることがあります。
これを戻し忘れると、公開後も検索結果に出てこなくなります。
管理画面の表示設定にある項目なので、公開の前に必ず確認してください。
数か月気づかれないこともある、影響の大きい見落としです。
定期実行の処理
バックアップや予約投稿など、時間で動く処理があります。
移行後にこれが動かなくなっても、画面上は何も変わりません。
気づくのは、バックアップが必要になったときです。
- バックアップのプラグインが、移行後も動いているか
- 予約投稿が、予定どおり公開されているか
- 定期的なお知らせメールが、止まっていないか
古いドメインからの転送
ドメインも変える場合、古い側から新しい側への転送を設定します。
これを忘れると、これまでの検索結果やリンクが行き止まりになります。
転送は、ページ単位で対応づけるのが理想です。
まとめてトップページに送る設定は、簡単ですが評価を引き継ぎにくくなります。
移行そのものは半日で終わっても、確認を含めると1週間は見ておきたいところです。止まるのは一瞬でも、気づかない不具合は長く残ります。
自分でやるか、任せるか
移行は、手順そのものは公開されていて、やろうと思えばできます。
判断の分かれ目は、止められる時間があるかどうかです。
- 止まっても困らない時間帯がある
- 移行元をしばらく残しておける
- プラグインが少なく、構成が単純
- 同じサーバー会社の中での移動
- 止められる時間がほとんどない
- 会員機能・決済・予約が動いている
- ドメインの切り替えも同時に行う
- 移行元をすぐ解約する予定がある
右側に共通するのは、やり直しがきかないという点です。
特に4つ目、移行元を先に解約してしまうと、比較する相手が無くなります。
不具合が出たときに戻せる状態を、いつまで保てるか。
ここを先に決めておくと、進め方が自然に決まります。
- 移行元は、最低でも1か月は残す
- 切り替えの直後に、上の6項目を通しで確認する
- 会員・決済が動いている場合は、テスト用の環境で先に試す
よくある質問
まとめ
移行で壊れるのは、ファイルではなく環境の差です。
- URL ― データベースの中に古いものが残る。置換には注意が要る
- PHP ― 版が上がると、古い書き方が動かなくなる
- 設定ファイル ― サーバーごとに形式が違う。404 の原因になる
- メール ― 経路が変わる。送信テストをしないと気づけない
そして、移行元をすぐ消さないこと。
比較できる相手が残っていれば、たいていの不具合は追えます。
残っていなければ、症状から逆算するしかなくなります。
移す前の記録と、移したあとの確認。
この2つがあるかどうかで、かかる時間が何倍も変わります。
急がないことも、立派な対策です。
症状の呼び方そのものは言葉と原因のずれ、移行後に出るエラー番号は500・503・404 の切り分けにまとめています。
本記事の件数は、ココナラの取引データにもとづく 2026 年 9 月時点の数値です。件名のキーワードで機械的に分類したもので、1 件は 1 つのテーマにだけ計上しています。対応の範囲・料金・受付時間は、各サービスページの記載によります。
