WordPressサイト移行完全ガイド｜安全・確実に引っ越しする手順とポイント | WPセンターブログ

企業Web担当者の皆さん、自社のWordPressサイトを別サーバーや新ドメインへ移行する際、
「どこから手を付ければいいのか」「移行中にサイトが止まってしまわないか」「SSLや検索順位は大丈夫か」…
多くの不安や疑問が頭をよぎることでしょう。しかし、準備や手順を誤ると、表示崩れやリンク切れ、SEO低下など、致命的なリスクも発生します。

本記事では、初心者から中級者まで安心して実施できるよう、前提準備からプラグイン／手動移行、ドメイン移管、よくあるトラブル対応、移行後の最適化までを完全網羅。さらに、WP‑CLIやCI/CD連携による自動化手法も紹介し、時代の一歩先を行く移行フローを提案します。
この記事一つで、あらゆる移行シナリオに対応できる知見を身につけ、自信をもってサイト移行に臨みましょう。

移行前に必ず押さえるチェックリストと準備
プラグインを使った簡単移行方法
手動で確実に移行するステップバイステップガイド
ドメイン変更・移管時のポイントと落とし穴
よくあるトラブルと対処法
移行後にやるべき確認項目と最適化
未来展望：自動化ツールとCI/CD連携で進化する移行フロー
まとめ

移行前に必ず押さえるチェックリストと準備

WordPress 移行手順の第一歩は、「準備不足によるトラブル」を未然に防ぐことです。結論として、移行前のバックアップ取得、ステージング環境の構築、そしてDNS TTL短縮の３つを確実に実施すれば、万が一の失敗時にも迅速に復旧でき、サイト停止リスクを大幅に低減できます。

バックアップ取得の要点

移行前には必ず完全バックアップを取得しましょう。理由は、ファイルやデータベースの一部が欠けると、移行後にサイト崩壊や表示エラーが発生し、復旧にも余分な工数がかかるためです。

具体例として、FTPクライアントでwp-content全フォルダをダウンロードし、phpMyAdminからSQLダンプをエクスポートする方法があります。しかし、このまま移行すると、プラグインによるシリアライズデータの不整合が起きることも。そこで、WP-CLIのwp db exportコマンドを使うと、文字エンコーディングの問題も自動で解決でき、より安全です。

まとめると、二重のバックアップ（ローカルとクラウド）を必須とし、「ファイル」「データベース」「証明書」「.htaccessなど設定ファイル」すべてを網羅的に保存してください。

ステージング環境の構築

結論は、本番環境への影響を最小化するために必ずステージング環境を使うことです。理由は、移行手順のテストやプラグイン検証を本番サイトに適用するリスクを回避できるからです。

たとえば、サブドメイン（staging.example.com）やローカルのDocker環境にWordPressを複製し、同一のPHPバージョン・MySQLバージョンで動作確認します。ここでSerial Replaceやパーミッション設定、SSL証明書の挙動を事前にチェックし、本番移行時の「真っ白な画面（WSOD）」や「権限エラー」を防止します。

まとめとして、移行用ステージング運用手順書を作成し、作業者全員が同じ手順で動作確認できる体制を整えましょう。

DNS TTL短縮のタイミング

DNS切り替えの前に、TTL（Time to Live）を最短（300秒など）に設定することがコツです。結論として、これにより切り替え反映を高速化し、移行期間中のアクセスのばらつきを最小化できます。

理由は、TTLが長いままだと、旧サーバーと新サーバーが混在表示され、ユーザーによっては古いコンテンツが表示され続けるためです。具体例として、移行前72時間前からDNS管理パネルでTTLを300秒に変更し、24時間後に移行作業を実行します。移行完了後、一晩経ったらTTLを元の3600秒や86400秒に戻す運用がベストプラクティスです。

まとめると、DNS TTL短縮→移行→TTL復旧のフローを定型化し、誰でも同じ手順を踏めるようドキュメント化しておきましょう。

プラグインを使った簡単移行方法

WordPress 移行手順の中でも、結論プラグインを活用すれば、初心者でも比較的簡単かつ短時間で移行できる一方で、データ量が大きい場合やマルチサイト環境では処理が重くなり、途中でタイムアウトやメモリ不足を起こすリスクがあるため、注意点を押さえた上で使うことが重要です。

All-in-One WP Migration の利点と注意点

All‑in‑One WP Migrationは、移行元でエクスポート、移行先でインポートするだけのシンプルなフローが魅力です。理由は、シリアライズデータの置換処理やマルチバイト文字の扱いを自動で行ってくれるからで、細かな技術知識が不要になります。

具体例として、プラグインを有効化し、「エクスポート」→「ファイル」によるバックアップを取得。生成された.wpressファイルをダウンロードし、新サーバーでAll‑in‑One WP Migrationをインストール後、「インポート」→該当ファイルをアップロードすると、自動的にファイル、データベース、プラグイン、テーマまで丸ごと移行されます。

しかし注意点として、無償版では512MBまでしかインポートできないため、データ量がそれ以上の場合は有償の「Unlimited Extension」を購入する必要があります。また、PHPメモリ上限を超えるケースがあり、その際はphp.iniでmemory_limitを512M以上に設定する、あるいは一時的にプラグインのchunk size（分割アップロードサイズ）を小さく調整するなど工夫が必要です。

Duplicator の使い方とポイント

Duplicatorは「パッケージ作成→パッケージ展開」の流れで、All‑in‑One WP Migrationよりもスクリプトベースの柔軟なカスタマイズが可能です。結論として、大規模サイトやマルチサイトに向いており、複数のエクスポートオプション（Zip, 複数アーカイブ）を使い分けられる特徴があります。

手順は以下の通りです。

移行元でDuplicatorを有効化し、「パッケージを作成」→「スキャン」→エラーがなければ「ビルド」を実行。
生成されたinstaller.phpとアーカイブ（.zip）をダウンロード。
新サーバーのドキュメントルートにinstaller.phpとアーカイブを配置し、ブラウザでhttps://example.com/installer.phpを開く。
ウィザードに従い、データベース接続情報を入力すると、自動で展開と置換が行われる。

具体例では、Search Pathsに旧URL、新URLを手動で追加できるため、ステージング環境や深いディレクトリ構成でも柔軟な置換が可能です。

まとめると、Duplicatorはファイル分割やマルチサイト移行、任意の置換ルールを設定したい場合に優位ですが、インストーラー公開によるセキュリティリスクを伴うため、展開完了後は必ずinstaller.phpを削除し、適切なファイル権限（600など）に戻してください。

注意点まとめ

データ容量とメモリ制限：プラグインの無償版制限やPHPメモリ不足による処理中断リスクに備え、あらかじめサーバー設定を確認。
シリアライズデータの整合性：自動置換機能は便利だが、マルチバイト文字や長いシリアライズキーでは誤置換の可能性があるため、本番前にステージングで必ず動作確認。
セキュリティ対策：プラグインによって一時公開されるインストーラーや一時フォルダは速やかに削除し、不要プラグインは無効化・削除することで不正アクセスを防止。
タイミング管理：アクセスの少ない深夜帯や週末に実行し、TTL短縮やメンテナンスモード発動による影響を最小化。

プラグイン移行は「手軽さ」と「一部自動化」が大きなメリットですが、必ずステージングで動作検証し、バックアップを確保した上で利用してください。これにより、予期せぬトラブルを最小限に抑えながら、スムーズにWordPressサイトを移行できます。

手動で確実に移行するステップバイステップガイド

プラグインに依存せず、結論として「手動移行」は全てのデータと設定を自分の目で確認しつつ移行できるため、大規模サイト／マルチサイト／データベースが複雑な場合に最適です。理由は、各ファイルやエントリを細かく制御でき、シリアライズデータ置換やパーミッション調整などを必要に応じて手作業で行えるからです。

1. ファイル一式のエクスポートとインポート

結論：wp-content以下の「テーマ」「プラグイン」「アップロード済みメディア」を含む全ファイルを丸ごと取得し、新サーバーへ同一パスで配置。

理由：WordPress本体は新サーバーで最新版を別途インストールし、wp-contentを差し替えるだけでデザインとメディアはそのまま移行できるため、整合性を保ちやすい。

具体例：

FTP/SFTPクライアント（FileZillaなど）で旧サーバーに接続し、public_htmlやwww配下のwp-contentフォルダをローカル保存。
新サーバーに同じくFTPで接続し、最新版WordPressをアップロード＆展開後、既存のwp-contentを上書きアップロード。
**パーミッション**はディレクトリ755、ファイル644で統一。また、一部ホスティングではowner/groupの所有者設定も要確認。

2. データベースダンプとリストア

結論：mysqldumpまたはphpMyAdminのSQLエクスポート機能で旧データベースをダンプし、新データベースへインポート。

理由：データベース内の投稿／ページ／設定情報はWordPressの全体構成を決めるため、完全に再現させるには生SQLダンプが最も確実。

具体例：


# 旧サーバーで
mysqldump -u ユーザー -p パスワード データベース名 > wp_backup.sql

# 新サーバーで
mysql -u 新ユーザー -p 新データベース名 < wp_backup.sql

もしphpMyAdminを利用するなら、エクスポート画面で「SQL」「DROP TABLE文を追加」「詳細オプションで互換性など」をチェックしてダンプを取得し、新環境でのインポート時も同オプションで実行します。

3. WP‑CLI によるシリアライズデータの置換

結論：旧URL→新URLの置換は、WP‑CLIのsearch-replaceが安全かつ高速で、シリアライズ化されたオプション値も正しく更新。

理由：単純なSQLのUPDATE文ではシリアライズ長が変わり不整合を起こすが、WP‑CLIはその長さを再計算しデータを正確に書き換える。

具体例：


# 新サーバー環境で、WordPressルートに移動後
wp search-replace 'https://old.example.com' 'https://new.example.com' --all-tables

オプション--dry-runで置換プレビューが可能なので、まず--dry-runで問題なければ本処理を実行します。

4. wp-config.php と.htaccess の確認

結論：wp-config.php内のデータベース接続情報と認証キーを新環境に合わせて更新し、.htaccessのリダイレクト設定やパーマリンク構造を再確認。

理由：接続情報やセキュリティキーが旧環境のままだと、サイトが動作せずログインできない。.htaccessのモジュール設定も異なる場合があるため再設定が必要。

具体例：


define('DB_NAME', 'new_database');
define('DB_USER', 'new_user');
define('DB_PASSWORD', 'new_password');
define('DB_HOST', 'localhost');
// 認証キーは旧環境のものをそのままコピペでOK

パーマリンク設定後、WordPress管理画面＞設定＞パーマリンクで「変更を保存」をクリックし、.htaccessを自動更新させます。

ドメイン変更・移管時のポイントと落とし穴

サーバー移行と並行してドメインを変更または移管する場合の結論は、WHOISロック解除→Authコード取得→DNS切り替え→SSL再発行の順序を厳守し、各ステップで認証遅延や証明書失効リスクを回避することです。ここを誤ると、サイト全体の表示不能や検索順位の大幅な変動を招く恐れがあります。

WHOISロック解除とAuthコード取得

理由：ドメインレジストラ間の移管には、ドメインの「ロック」を解除し、Auth（認証）コードを取得する必要があるためです。

具体例：

現在のレジストラ管理画面でドメインのロックをOFFに設定。
「移管用Authコード送信」機能を使い、登録メールアドレスに届いたコードを控える。

このAuthコードを新レジストラの移管申請画面で入力すると、通常72時間以内に移管処理が完了します。注意点として、認証メールの受信設定（ドメイン指定受信）が未設定だとコードが届かず、移管が遅延するため、事前にメール設定を確認してください。

DNSレコード切り替えとTTL管理

結論：移管完了前にDNSレコードを新サーバーのIPに設定し、TTL短縮を行った上で、移管完了後にMXやTXTレコードなどを旧レジストラから新レジストラへ正確に移行します。

理由：DNSレコード不整合により、メール送受信障害やサービス停止が発生しやすいためです。

具体例：

移管申請前72時間以内に旧レジストラでTTLを300秒に変更。
新ホスティング会社のIPアドレスをAレコードまたはAAAAレコードに設定し、wwwや@レコードを新IPに向ける。
MXレコードは旧レジストラの設定をエクスポートし、新レジストラで同値をインポート。

まとめると、DNSゾーンファイルの完全なバックアップを取得し、移管後の再設定ミスを防ぐ運用手順書を準備しておくことが重要です。

SSL証明書の再発行とHTTPS切り替え

結論：新サーバーまたは新ドメインでSSL証明書を再発行し、HTTP→HTTPSへのリダイレクト設定を忘れず行う。

理由：ドメイン変更／移管後は旧証明書が無効となり、ブラウザに「保護されていない通信」と表示されるためです。

具体例：

Let’s Encryptの場合、Certbotで再発行コマンド（certbot certonly --webroot -w /var/www/html -d example.com -d www.example.com）を実行。
商用証明書なら新レジストラまたはホスティング会社のSSL発行サービスで、ドメイン認証（DV）を再取得。
再発行後、サーバー設定ファイル（ApacheのVirtualHostやNginxのserver {}）で証明書パスを更新し、80番ポートから443へ301リダイレクトを設定。

まとめると、SSL切れによる信用低下やSEO影響を避けるために、移管直後に再発行→設定反映を必ず実施してください。

よくあるトラブルと対処法

WordPress 移行手順において特に起こりやすい結論は、事前準備不足と置換・パーミッションミスが大きな要因であり、これらを踏まえたトラブルシューティングを用意しておけば、移行作業中のダウンタイムや後処理工数を大幅に削減できます。

パーマリンクが404になる

原因・理由：新環境で.htaccessが正しく生成されなかった、またはパーマリンク設定が旧環境と異なる場合に発生。

具体例：移行直後、投稿ページにアクセスすると「404 Not Found」が表示されるケース。

対処手順：

管理画面＞設定＞パーマリンクにアクセス。
何も変更せずに「変更を保存」をクリックし、.htaccessを再生成。
サーバーのファイルパーミッションを確認し、.htaccessが644になっているかチェック。
キャッシュプラグイン（WP Rocket等）を一時的に無効化し、キャッシュクリアを実施。

これで大半の「パーマリンク404」は解消します。

メディアファイルが読み込まれない

原因・理由：wp-content/uploadsフォルダの転送漏れ、またはパス置換が正しく行われず旧URLのまま参照しているため。

具体例：記事内の画像タグ<img src="https://old.example.com/wp-content/uploads/..." />のままになっている状態。

対処手順：

FTPでuploadsフォルダの中身を再度チェックし、全ファイルが存在するか確認。

WP‑CLIでURL置換を再実行：


wp search-replace 'https://old.example.com/wp-content/uploads' 'https://new.example.com/wp-content/uploads' --all-tables

ブラウザのネットワークタブで失敗しているリクエストを確認し、レスポンスコード（404等）に応じて個別対応。
CDNを利用している場合は、CDNキャッシュクリアを忘れず実行。

シリアライズ置換ミスによる文字化けやエラー

原因・理由：SQLの直接更新や不適切な置換プラグイン使用で、シリアライズ長が一致せずUnserializeエラーが発生。

具体例：プラグイン設定画面で「エラーが発生しました」となり、ダッシュボードに入れない場合。

対処手順：

WP‑CLI --dry-runで改めて検索置換をシミュレーションし、変更数と対象テーブルを確認。

問題のテーブル（例：wp_options）のみを対象に、再度：


wp search-replace 'https://old.example.com' 'https://new.example.com' wp_options --all-columns

エラーが解消しない場合は、phpMyAdminで手動バックアップ（対象テーブルのみ）を取得後、シリアライズデータ手動修正を試みる。
移行前にステージングで同一操作を行い、問題がないか検証しておくことが重要です。

PHPバージョン・拡張モジュールの不一致

原因・理由：旧環境と新環境のPHPバージョン違いや必要な拡張モジュール（GD、mbstring、curl等）が不足していると、動作や表示上の不具合が起こる。

具体例：画像のサムネイル生成に失敗したり、テーマ・プラグインがエラーを吐くケース。

対処手順：

phpinfo()で新環境のPHPバージョンと拡張モジュール一覧を確認。
旧環境と同じバージョン／モジュールをインストール、またはcomposer.jsonやドキュメントで推奨環境を確認し、必要なモジュールを有効化。
画像処理エラーが残る場合は、Regenerate Thumbnailsプラグインで再生成。

以上のトラブル事例と対処フローを抑えておけば、移行中・移行後の障害発生時にも迅速に復旧対応が可能です。次章では、移行完了後に行うべき確認と最適化について解説します。

移行後にやるべき確認項目と最適化

移行作業が完了したら、結論として「サイトの正常性」「パフォーマンス」「SEO設定」の３つを必ずチェックし、問題があれば即修正することが重要です。これらを怠ると、ユーザー体験の低下や検索順位の大幅下落を招きかねません。

1. リンク切れ＆リダイレクト確認

理由：移行中にURL構造が変わったり、旧ドメイン／旧ディレクトリへのリンクが残っていると、404エラーが増加しSEO評価が下がります。

具体例と手順：

Broken Link CheckerやScreaming Frog SEO Spiderを使い、サイト全体をクロール。
404エラーのリストを抽出し、該当ページへの301リダイレクトをサーバーまたは.htaccessで設定。
内部リンクに旧URLが残っていないか、WP‑CLIで再度search-replaceを実行して一括更新。
最終確認として、Google Search Consoleの「カバレッジレポート」でエラーをチェック。

2. キャッシュ＆CDNの最適化

理由：旧環境のキャッシュ設定やCDNキャッシュが残っていると、ユーザーに古いコンテンツが配信され続けるため。

具体例と手順：

プラグインキャッシュ（WP Rocket, W3 Total Cache等）：管理画面から全キャッシュをクリアし、必要に応じてキャッシュ有効期限を見直し。
CDN（Cloudflare, AWS CloudFrontなど）：キャッシュパージを実行し、キャッシュ設定（キャッシュレベル、TTL）を移行先に合わせて最適化。
ブラウザキャッシュ：.htaccessやNginx設定で、静的ファイル（CSS, JS, 画像）に適切なCache-Controlヘッダを付与。

3. サイトパフォーマンス計測と改善

理由：移行時に環境が変わることで、サーバー応答時間やページ読み込み速度に影響が出るためです。

具体例と手順：

Google PageSpeed InsightsやGTmetrixでパフォーマンス測定し、FCP（First Contentful Paint）やLCP（Largest Contentful Paint）を確認。
サーバーレイテンシが高い場合は、PHP-FPM設定の調整や、ホスティングプランの見直しを検討。
画像最適化が不十分なら、ShortPixelやImagifyを導入し、次世代フォーマット（WebP）で提供。
CSS/JSの結合・圧縮や遅延読み込み（lazy loading）を適用し、レンダリングブロッキングを削減。

4. SEO設定およびアナリティクス連携

理由：移行後にメタタグやサイトマップ、構造化データが正しく機能しなければ、検索エンジンによるクロールやインデックスが滞り、流入数減少を招きます。

具体例と手順：

Yoast SEOやAll in One SEOで、canonicalタグが新URLを指しているか検証。
XMLサイトマップを再生成し、Google Search ConsoleとBing Webmaster Toolsに登録。
構造化データ（Schema.org）がプラグインやテーマで正しく出力されているか、Rich Results Testでチェック。
Google Analytics 4（GA4）やGoogle Tag Managerのトラッキングコードを移行先に貼り付け、データ収集が継続して行われているかリアルタイムレポートで確認。

未来展望：自動化ツールとCI/CD連携で進化する移行フロー

今後は、「自動化による移行の標準化と高速化」が主流となりつつあります。理由として人的ミス削減・再現性確保・迅速なデプロイを同時に実現できるためです。中級者以上向けに、以下の自動化フローを解説します。

WP‑CLI＋GitHub Actionsでの自動移行ワークフロー

具体例と手順：

GitHubリポジトリにWordPressテーマ・プラグイン・カスタム設定コードを管理。
CI（継続的インテグレーション）で新コミットを検知し、GitHub Actionsのワークフローが発火。
WP‑CLIコンテナを用いて、wp db export→wp db import→wp search-replaceを自動実行。
最後にSSHで新サーバーにデプロイし、Health Check & TroubleshootingプラグインをAPIで確認、結果をSlack通知。

利点：人的オペレーションの省力化・ロールバックの容易化。

インフラコード（Terraform/Ansible）によるサーバープロビジョニング

具体例と手順：

TerraformでAWS EC2／RDSインスタンスをコード化し、ネットワーク・セキュリティグループを一貫して管理。
AnsibleプレイブックでNginx/Apache設定、PHP-FPMインストール、Let’s Encrypt SSL化を自動化。
Blueprintとしてテンプレート化し、新環境立ち上げを数分で完了。

利点：環境差異によるトラブルを根絶し、大規模サイトでもスケーラブルに展開可能。