ツールなしのサイト引っ越しに向き合う
WordPressのサイト引っ越しというと、専用プラグインを使うのが一般的な選択肢として語られることが多い。ただ、実際に手作業で移行を経験してみると、ツールに頼らないことで見えてくる構造的な理解があると感じることがある。
ここでは「WordPress サイト引っ越し ツールなし」という方法を選んだときの整理メモとして、移行の考え方や注意点を順番に書き留めておく。
なぜ専用ツールに頼らないのか
移行ツールやプラグインは便利だが、すべての環境で期待通りに動くわけではない。サーバーの仕様やPHPのバージョン、データベースの設定によっては、ツール自体がエラーを出すケースもある。
手作業による移行は、一見すると手間がかかるように思えるが、何が起きているかを自分で把握できるという点で透明性が高い。ツールが内部で何をしているかを知らずに使うよりも、各ステップを自分で確認しながら進めるほうが、問題が起きたときの対処がしやすいという見方もできる。
移行の全体像をどう捉えるか
WordPressのサイト引っ越しを大きく分解すると、「ファイルの移動」「データベースの移行」「設定の書き換え」という三つの作業に整理できる。この三つがそれぞれ独立しているようで、実は密接に連動しているところが、移行作業の難しさでもある。
全体像を先に把握しておくことで、どのステップで何が起きているかを追いやすくなる。
サーバー移転とドメインの関係整理
サーバーを移転するとき、ドメインのDNS設定を変更するタイミングが重要になる。DNSの変更は世界中のサーバーに伝播するまでに時間がかかるため、移行作業中は新旧両方のサーバーが一時的に混在した状態になる。
この伝播期間（プロパゲーション）は最大48〜72時間かかる場合があり、その間はユーザーによってアクセス先が異なることがある。そのため、データベースの移行やファイルのコピーはDNS変更の前に済ませておくのが基本的な考え方になる。
hostsファイルを使って手元のPCだけ新サーバーを参照するよう設定する方法もあり、これを使うと移行後の表示確認をDNS変更前に行うことができる。
ファイルとデータベース移行の考え方
WordPressのファイル一式は、FTPまたはSSHを使って旧サーバーからダウンロードし、新サーバーへアップロードする。wp-contentフォルダの中にはテーマ・プラグイン・メディアファイルが含まれており、ここが実質的なサイトの資産になる。
データベースはphpMyAdminやmysqldumpコマンドを使ってエクスポートし、新サーバーのデータベースにインポートする。この際、文字コードの設定（UTF-8）が一致していないと文字化けが発生するため、確認が必要になる。
最低限押さえておきたい確認ポイント
移行作業に入る前に、以下の項目を確認しておくと後のトラブルを減らせる。
- 旧サーバーのPHPバージョンと新サーバーのPHPバージョンの差異
- データベース名・ユーザー名・パスワードの新旧の違い
- wp-config.phpに記載されているDB接続情報の書き換え箇所
- パーミッション設定（特にwp-contentフォルダとその配下）
- SSL証明書の有無と、httpsへのリダイレクト設定
これらは移行後に「サイトが表示されない」「管理画面に入れない」といった問題の主な原因になりやすい項目でもある。事前に一覧化しておくことで、問題が起きたときの切り分けが格段に楽になる。
URLとパスを書き換える意味
WordPressはデータベースの中にサイトのURLを直接保存している。旧サーバーのURLと新サーバーのURLが異なる場合、データベース内に残った旧URLがそのまま残り、リンク切れや画像の表示崩れが発生する。
この書き換えはphpMyAdminから手動で行う方法と、WP-CLIのコマンドを使う方法がある。シリアライズされたデータが含まれている場合は単純な文字列置換では対応できないため、Search Replace DBのようなツールを使うか、WP-CLIのsearch-replaceコマンドを使うのが一般的な対処になる。
検索結果と内部リンクへの影響
URLが変わる場合、Googleなどの検索エンジンに登録されている旧URLへのアクセスが発生し続ける。これに対応するためには、旧サーバーから新URLへの301リダイレクトを設定するか、Search Consoleでサイト移転の通知を行うことが推奨される。
内部リンクについても、記事本文や固定ページの中に旧URLがハードコードされている場合は、データベースの一括置換で対応する必要がある。ただし、テーマやプラグインのファイル内にURLが書き込まれているケースもあり、ファイル側の確認も合わせて行うほうが安全といえる。
Googleのクローラーが新URLを認識するまでには一定の時間がかかるため、移行後すぐに検索順位が変動することは珍しくない。これは移行の失敗ではなく、インデックスの更新プロセスとして理解しておくと、焦らずに対処できる。
移行後に起こりがちな不具合
移行直後に発生しやすい問題として、「真っ白な画面（WSoD）」「500エラー」「画像が表示されない」「管理画面にログインできない」といったものが挙げられる。これらはそれぞれ原因が異なるため、一つひとつ切り分けて対処する必要がある。
エラーログを確認する習慣をつけておくと、原因の特定が早くなる。
原因の切り分けと優先順位付け
不具合が起きたときの確認順序を整理すると、以下のような優先順位が考えやすい。
- wp-config.phpのDB接続情報が正しいか
- データベースのインポートが完全に完了しているか
- パーミッションが適切に設定されているか
- .htaccessファイルが正しく配置されているか
- プラグインの競合が発生していないか
この順番で確認を進めると、多くの場合は原因を絞り込める。プラグインの競合については、wp-contentのpluginsフォルダをリネームして一時的に全プラグインを無効化し、問題が解消するかどうかで判断する方法が有効になる。
バックアップとロールバックの設計
移行作業を始める前に、旧サーバーの状態を完全にバックアップしておくことは前提条件になる。ファイル一式とデータベースのダンプを手元に保存しておけば、何か問題が起きても元の状態に戻せる。
バックアップは「移行前」「移行中の各ステップ後」「移行完了後」という複数のタイミングで取得しておくのが理想的な設計といえる。
失敗を前提にした進め方という視点
移行作業は「うまくいく前提」で進めるよりも、「どこかで問題が起きる前提」で設計するほうが、結果的にスムーズに完了することが多い。これはリスク管理の基本的な考え方でもある。
具体的には、本番のDNS切り替えを最後のステップに置き、それまでの作業はすべて新サーバー上でのテスト環境として進めるという流れが有効になる。新サーバーでの表示確認・ログイン確認・主要ページの動作確認がすべて完了してから、初めてDNSを切り替えるという順序が安全といえる。
失敗したとしても、旧サーバーがそのまま動いている状態であれば、ユーザーへの影響を最小限に抑えながらやり直せる。この「逃げ道を確保しながら進む」という発想は、手作業移行の大きな利点の一つでもある。
ビジネス視点で見るサイト引っ越し
サイト引っ越しはエンジニア的な作業に見えるが、ビジネスの観点から見ると、サービスの継続性・SEOへの影響・ダウンタイムの最小化という三つの要素が重要になる。特に収益に直結するサイトであれば、移行のタイミングや方法の選択はビジネス判断でもある。
ツールなしで移行を行う場合、作業時間と習熟コストが発生するが、その代わりに「何が起きているかを完全に把握できる」という透明性を得られる。
リスクと学習コストのバランス
手作業による移行は、初めて行う場合には相応の時間がかかる。ただ、一度経験しておくと次回以降の移行作業の精度と速度が大幅に上がるという側面もある。
リスクとコストのバランスを考えるうえで、以下の観点が参考になる。
- サイトの規模（ページ数・メディアファイルの量）が大きいほど手作業のコストは増える
- 収益への影響が大きいサイトほど、ダウンタイムを最小化する設計が重要になる
- 移行作業の経験値は、将来的なサーバー選定やトラブル対応にも活きてくる
- ツールを使う場合でも、手作業の知識があると問題発生時の対処が速くなる
どちらの方法が正解かという二択ではなく、状況に応じた判断が求められるという見方が現実的といえる。
最後に
WordPress サイト引っ越し ツールなしという方法は、手間がかかる分だけ、サイトの構造に対する理解が深まるという特性がある。移行を通じて、WordPressがどのようにファイルとデータベースを組み合わせて動いているかを体感できるのは、長期的に見て有益な経験になりうる。
完璧な移行手順というものはなく、環境によって必要な対処は変わってくる。ここで整理した内容が、同じような状況に向き合う人にとっての参考になれば十分だと思っている。
【参照・引用元】
該当なし
