WordPressをローカルから本番サーバーへ移行する手順｜FTP・DB移行を失敗しない方法

ローカル環境から本番移行でつまずくのはなぜか

WordPressのローカル環境から本番サーバーへの移行は、一見シンプルな「ファイルのコピー作業」に思えます。しかし実際には、ファイル転送・データベース移行・URL書き換えという複数の工程が絡み合っており、いずれか一つでも手順を誤ると、表示崩れや500エラーが発生します。

移行が一筋縄でいかない理由——ファイルとDBが別管理である点

WordPressは、テーマやプラグインなどのファイル群と、投稿・設定情報を格納するデータベース（MySQL）を別々に管理しています。ローカル環境では両者が同じマシン上で連携していますが、本番サーバーへ移行する際は、それぞれを個別に移動させる必要があります。

特に問題が起きやすいのが次の3つのポイントです。

• ファイル転送の漏れ：FTPでのアップロード時に、wp-contentフォルダ内の一部ファイルが転送されていないケース
• DB接続情報の不一致：wp-config.phpに記載するデータベース名・ユーザー名・パスワードが本番環境と合っていないケース
• URL書き換えの未実施：データベース内にローカルのURL（例：http://localhost/）が残ったままになっているケース

これらは独立した工程に見えますが、一つでも抜け落ちるとサイト全体が正常に動作しなくなります。

この記事でカバーする内容と対象読者

本記事では、WordPressをローカル環境から本番サーバーへ移行する全手順を、FTPによる手動移行とプラグインを使った移行の両方を比較しながら解説します。移行前の準備確認から、DB操作、URL一括置換、移行後の動作確認まで、工程ごとに具体的な手順を説明します。

Web制作の現場で移行作業を担当する方や、初めてローカルから本番への移行に取り組む方が、手順を迷わず進められることを想定した内容です。

ローカル環境から本番移行でつまずくのはなぜか

WordPressのローカル環境から本番サーバーへの移行は、一見シンプルな作業に見えます。しかし実際には、ファイル転送・データベース移行・URL書き換えという複数の工程が連動しており、どれか一つでも手順を誤ると表示崩れや500エラーが発生しやすい構造になっています。

移行が一筋縄でいかない理由——ファイルとDBが別管理である点

WordPressのデータは、大きく「ファイル」と「データベース」の2種類に分かれています。テーマやプラグイン、メディアファイルはサーバー上のディレクトリに保存されますが、投稿内容・設定情報・URLはMySQL（マイエスキューエル）データベースに格納されています。

この2つは独立して管理されているため、ファイルだけ転送してもデータベースが一致していなければサイトは正常に動作しません。さらに、データベース内にはローカル環境のURL（例：http://localhost/mysite）が埋め込まれているため、本番URLへの一括置換を忘れると、リンク切れや管理画面へのアクセス不能が起きます。

加えて、サーバー接続情報を記述するwp-config.phpの書き換えも必要です。ファイル・DB・設定ファイルの3点をすべて正しく対応させて、初めて移行が完了します。

この記事でカバーする内容と対象読者

本記事では、WordPressのローカル環境から本番サーバーへの移行手順を、FTPを使った手動移行とプラグインを使った方法の両面から解説します。移行前の確認事項から、ファイル転送・DB移行・URL置換の各工程、移行後の動作確認まで、一連の流れを順を追って説明しています。

Web担当者やフリーランスのWeb制作者など、移行作業を自分で進める方が、どの工程でつまずきやすいかを把握した上で判断できるような粒度を意識して構成しています。

移行前に確認すべき前提条件と準備事項

移行作業をスムーズに進めるには、作業を始める前に本番サーバーの環境情報とローカル環境の出力形式を正確に把握しておくことが重要です。準備不足のまま作業を進めると、ファイル転送後にWordPressが起動しない・データベース接続エラーが解消できないといったトラブルに直結します。

本番サーバーの環境要件チェックリスト

移行前に、以下の項目を本番サーバーのコントロールパネルや契約情報から確認しておきます。

• PHPバージョン：WordPress本体・使用プラグインが対応しているバージョンか確認します。PHP 8.0以上を要求するプラグインも増えているため、ローカルと本番でバージョンが一致していることが理想です。
• MySQLバージョン：WordPressが推奨するMySQL 8.0またはMariaDB 10.4以上を満たしているか確認します。
• ディスク容量：wp-contentフォルダ内のメディアファイルが多い場合、容量不足で転送が途中停止するケースがあります。アップロード前に余裕を確認してください。
• FTPアクセス情報：ホスト名・ユーザー名・パスワード・ポート番号の4点を手元に用意します。SFTP接続が推奨されているサーバーでは、ポート番号が異なることがあります。
• データベース接続情報：phpMyAdminのURL・DBホスト名・DB名・DBユーザー名・DBパスワードを確認します。これらは後工程のwp-config.php書き換えで使います。

ローカル環境別の注意点——LocalWP・MAMP・XAMPPの違い

ローカル環境の種類によって、WordPressファイルの格納場所とエクスポート方法が異なります。

• LocalWP（Local by Flywheel）：サイトデータは「~/Local Sites/サイト名/app/public/」以下に格納されています。LocalWPには「Export」機能があり、zip形式でサイト一式を書き出せますが、このzipファイルはLocalWP専用フォーマットのため、本番への直接インポートには使えません。FTPで転送する場合はpublicフォルダ内のファイルを直接使用します。
• MAMP：ドキュメントルートは「/Applications/MAMP/htdocs/」（Mac）が標準です。phpMyAdminは「http://localhost:8888/phpMyAdmin/」からアクセスできます。
• XAMPP：ドキュメントルートは「C:xampphtdocs」（Windows）が標準で、phpMyAdminは「http://localhost/phpmyadmin/」から操作します。

移行前バックアップ——取得すべき対象と方法

移行作業は本番データを上書きするリスクを伴います。作業前に必ず以下の2点をバックアップしておきます。

• WordPressファイル一式：wp-content・wp-config.php・.htaccessを含むすべてのファイルをFTPでダウンロードするか、サーバーのスナップショット機能を利用します。
• データベース：phpMyAdminの「エクスポート」機能を使い、SQL形式で出力します。ファイル名に日付を入れておくと、後から復元する際に判別しやすくなります。

本番サーバーに既存サイトが稼働している場合は、バックアップなしに上書きすることは避けてください。移行の失敗時に元の状態へ戻せなくなるリスクがあります。

移行前に確認すべき前提条件と準備事項

移行作業そのものよりも、事前の確認不足が原因でトラブルが発生するケースは少なくありません。本番サーバーの環境要件をローカルと合わせておくこと、バックアップを確実に取得しておくことが、スムーズな移行の前提条件になります。

本番サーバーの環境要件チェックリスト

移行前に以下の項目を必ず確認してください。ローカルと本番でバージョンが大きく異なると、プラグインの動作不良や画面の白抜けといったエラーが発生しやすくなります。

• PHPバージョン：WordPress本体が推奨するバージョン（執筆時点では8.1以上）と本番サーバーの設定を照合する
• MySQLまたはMariaDBのバージョン：MySQL 5.7以上、またはMariaDB 10.3以上が推奨。古いバージョンではSQL構文の非互換が起きることがあります
• ディスク容量：アップロード済みメディアファイルが多い場合、容量不足で転送が中断されることがあります。本番サーバーの空き容量をあらかじめ確認してください
• FTPアクセス情報：ホスト名・ユーザー名・パスワード・ポート番号（通常21番、SFTPは22番）を手元に用意しておく
• phpMyAdminのアクセスURL：コントロールパネル（cPanelやplesk等）からアクセスできるか確認する
• 最大アップロードサイズの制限：php.iniのupload_max_filesizeとpost_max_sizeの値を確認し、必要に応じてサーバー側で変更を依頼する

ローカル環境別の注意点——LocalWP・MAMP・XAMPPの違い

ローカル環境によって、エクスポートされるファイル構成やデータベースへのアクセス方法が異なります。移行手順を誤る原因になりやすい点なので、使用ツールを事前に把握しておくことが重要です。

• LocalWP：WordPressファイルは「app/public」フォルダ配下に格納されています。本番へのアップロード時は、このpublicフォルダ内のファイルをサーバーのドキュメントルートへ転送します。データベースはLocalWPの管理画面から「Adminer」経由でエクスポートできます
• MAMP：WordPressファイルはMAMPの「htdocs」フォルダ内に置かれます。データベースのエクスポートはブラウザからlocalhost:8888/phpMyAdminにアクセスして行います
• XAMPP：MAMPと同様に「htdocs」フォルダを使用します。phpMyAdminのポート番号はデフォルトで80番です。Windowsユーザーが多く、パスの区切り文字（バックスラッシュ）が原因で設定ファイルのパスが崩れることがあります

移行前バックアップ——取得すべき対象と方法

本番サーバーに既存のサイトが稼働している場合、移行作業の前に必ずバックアップを取得してください。取得すべき対象は以下の2点です。

1. WordPressファイル一式：FTPクライアント（FileZillaなど）でサーバーからローカルへダウンロードする。wp-content/uploads内のメディアファイルが大量にある場合は時間がかかるため、余裕を持ったスケジュールで対応してください
2. データベース：phpMyAdminから対象のデータベースを選択し、「エクスポート」タブで.sqlファイルとして出力する。エクスポート形式は「カスタム」を選ぶと、テーブルの選択や文字コード（utf8mb4）の指定が可能です

ローカル環境側のバックアップも同様に取得しておくと、万一の復旧時に役立ちます。特にLocalWPを使った本番アップロードの場合は、作業前の状態をスナップショットとして保存しておくことを推奨します。

移行方法の選択肢——プラグイン vs 手動（FTP＋phpMyAdmin）

WordPressのローカルから本番への移行方法は、大きく「プラグインを使う方法」と「FTP転送＋phpMyAdminによる手動移行」の2つに整理できます。どちらが正解かは状況次第です。手順の前にまず選定の軸を整理しておくことで、作業ミスや手戻りを減らせます。

プラグイン移行（All-in-One WP Migration・Duplicator）のメリットと限界

All-in-One WP MigrationやDuplicatorといったプラグインは、ファイルとデータベースを一括でパッケージ化し、移行先にインポートするだけで作業が完結します。コマンド操作やSQL知識が不要なため、制作者以外の担当者でも扱いやすい点が最大のメリットです。

ただし、無料版には制限があります。All-in-One WP Migrationの無料版はインポートできるファイルサイズの上限が512MBに制限されており、画像が多いサイトや運用歴の長いサイトでは上限を超えるケースが少なくありません。上限を引き上げるには有償の拡張プランが必要になります。また、プラグインが生成するパッケージファイルに破損があった場合、原因の特定が難しくなる点もリスクとして認識しておく必要があります。

手動移行（FTP＋phpMyAdmin）が必要になるケース

以下のような状況では、手動移行を選択するほうが安全です。

• サイトの総容量が大きく、プラグインのサイズ制限に引っかかる場合
• 移行先サーバーにWordPressがインストールできない、またはプラグインの動作環境が整っていない場合
• 本番環境とローカル環境でPHPやMySQLのバージョンが大きく異なり、パッケージの互換性に不安がある場合
• 移行対象がマルチサイト構成で、プラグインが対応していないケース

手動移行はFTPでファイルを転送し、phpMyAdminでデータベースをエクスポート・インポートしたうえで、URL置換を別途実行するという複数のステップが必要です。工数はかかりますが、各工程を個別に確認できるため、問題発生時の切り分けがしやすくなります。

方法別比較表——作業工数・リスク・向いている規模

どちらの方法を選ぶにしても、移行前にローカル環境でバックアップを取得しておくことが前提です。方法の選定に迷う場合は、まずサイトの総容量を確認し、512MBを超えるようであれば手動移行を検討するという判断基準が実用的です。

移行方法の選択肢——プラグイン vs 手動（FTP＋phpMyAdmin）

WordPressのローカルから本番への移行方法は、大きく「プラグインを使う方法」と「FTP転送＋phpMyAdminによる手動移行」の2択に整理できます。どちらを選ぶかによって、作業工数・リスク・対応できるサーバー環境が大きく変わります。手順の詳細に入る前に、まず自分の状況に合った方法を選ぶことが、移行失敗を防ぐうえで重要です。

プラグイン移行（All-in-One WP Migration・Duplicator）のメリットと限界

All-in-One WP MigrationやDuplicatorといったプラグインは、ファイルとデータベースをひとつのパッケージにまとめてエクスポート・インポートできるため、操作がシンプルです。FTPやphpMyAdminの知識がなくても移行を完了できるケースが多く、小規模サイトや初めて移行を行う担当者には向いています。

ただし、無料版のAll-in-One WP Migrationはインポートできるファイルサイズに上限（512MB）があります。画像や動画が多いサイト、長期運用で投稿数が多いサイトでは、この上限を超えるケースが少なくありません。また、サーバー側のPHP設定やパーミッション制限によって、プラグインが正常に動作しない環境も存在します。

手動移行（FTP＋phpMyAdmin）が必要になるケース

以下のような状況では、手動移行を選択する必要があります。

• サイトの総容量が512MBを超えており、プラグインの無料版では対応できない
• レンタルサーバーのセキュリティ設定により、プラグインのインポート処理がタイムアウトする
• LocalWPなどのローカル環境からエクスポートしたデータをそのままプラグインが認識しない
• 本番サーバーへのWordPressインストール権限がなく、既存環境への上書きが必要

手動移行はFTPクライアント（FileZillaなど）でファイルを転送し、phpMyAdminでデータベースをエクスポート・インポートする手順を踏みます。工数はかかりますが、サーバー環境の制約を受けにくく、大規模サイトでも確実に移行できます。

方法別比較表——作業工数・リスク・向いている規模

プラグイン移行は手軽さが最大のメリットですが、「手軽に完了できる条件が揃っているか」を先に確認することが重要です。サイトの容量・サーバーのPHPバージョン・アップロード上限（upload_max_filesize）を事前に把握したうえで、どちらの方法が自分の環境に合っているかを判断してください。

【手順①】WordPressファイルをFTPで本番サーバーへ転送する

ファイルの転送は、移行作業の最初の工程です。転送対象の範囲を正確に把握し、wp-config.phpの書き換えを適切に行うことで、後続のDB移行がスムーズに進みます。

転送対象ファイルの構成——wp-content・wp-config.phpを中心に

ローカルのWordPressディレクトリにあるファイル一式が転送対象です。主な構成は以下のとおりです。

• wp-content/：テーマ・プラグイン・アップロード画像をすべて含む最重要ディレクトリ
• wp-config.php：データベース接続情報が記載された設定ファイル
• wp-includes/ / wp-admin/：WordPressのコアファイル。ローカルと本番でバージョンが同じであれば再アップロードを省略できるケースもありますが、確実を期すなら転送対象に含めます
• .htaccess：パーマリンク設定や基本認証などを制御するファイル

.htaccessはサーバー環境によって記述内容が異なる場合があります。ローカルの設定をそのまま上書きすると500エラーが発生するケースがあるため、本番サーバーの既存の.htaccessをバックアップしてから上書きするか、差分を確認したうえで手動でマージする方が安全です。

FTPクライアントの設定と接続確認

FTPクライアントにはFileZillaが広く使われています。接続に必要な情報は、サーバー契約時に発行される以下の4点です。

• ホスト名（FTPサーバーのアドレス）
• ユーザー名
• パスワード
• ポート番号（通常はFTPが21、SFTPが22）

サーバーパネル（cPanelやXserverの管理画面など）でFTPアカウントを発行し、FileZillaの「クイック接続」または「サイトマネージャー」に入力します。接続後、本番サーバーのドキュメントルート（public_html/やwww/など）に移動できれば準備完了です。接続が確認できたら、ローカルの全ファイルを選択してドラッグ＆ドロップでアップロードします。ファイル数が多い場合は完了まで数十分かかることもあります。

wp-config.phpの編集——本番DB情報への書き換え箇所

ローカルのwp-config.phpには、ローカルDB用の接続情報が記載されています。本番サーバーにアップロードする前、またはアップロード後にサーバー上で直接編集し、以下の4箇所を本番DBの情報に書き換えます。

• DB_NAME：本番サーバーで作成したデータベース名
• DB_USER：データベースのユーザー名
• DB_PASSWORD：データベースのパスワード
• DB_HOST：多くの共有サーバーでは「localhost」のままで問題ありませんが、サーバー会社によって異なるため管理画面で確認します

書き換えが完了したwp-config.phpをアップロードすれば、ファイル転送の工程は完了です。次の手順ではデータベースのエクスポート・インポートへ進みます。

【手順①】WordPressファイルをFTPで本番サーバーへ転送する

ファイルの転送は、移行作業の最初のステップです。転送対象の構成を正確に把握したうえで、FTPクライアントの設定・接続・アップロードを順番に進めていきます。

転送対象ファイルの構成——wp-content・wp-config.phpを中心に

ローカルのWordPressディレクトリには多くのファイルが存在しますが、転送対象は原則としてWordPressのルートディレクトリ全体です。特に重要なのは以下の3点です。

• wp-content/：テーマ・プラグイン・アップロードメディアが格納されており、サイト固有のカスタマイズがすべて含まれます
• wp-config.php：データベース接続情報が記載された設定ファイルです。本番環境用に書き換えが必要なため、転送前後で内容を確認します
• .htaccess：パーマリンク設定などを制御するファイルです。ローカルと本番でサーバー環境が異なる場合、記述内容を調整する必要があります

wp-core（WordPressのコアファイル群）については、本番環境にすでに同バージョンがインストール済みであれば上書きで問題ありません。バージョンが異なる場合は、ローカルと本番で一致させておくことを推奨します。

FTPクライアントの設定と接続確認

FTPクライアントはFileZillaが広く使われています。接続に必要な情報は、ホスティングサービスの管理画面から取得します。

1. FileZillaを起動し、「サイトマネージャー」から新規サイトを追加します
2. ホスト名・ポート番号・ユーザー名・パスワードを入力します。セキュリティの観点から、FTPSまたはSFTPが選択できる場合はそちらを使用します
3. 接続後、本番サーバーの公開ディレクトリ（例：public_html/ または www/）を表示させます
4. ローカル側のWordPressルートディレクトリを選択し、サーバー側へドラッグ＆ドロップでアップロードします

転送ファイル数が多い場合、アップロードには数十分かかるケースがあります。転送中にセッションが切断されると再接続で再開できますが、完了後はファイル数・更新日時をサンプルで照合しておくと安心です。

wp-config.phpの編集——本番DB情報への書き換え箇所

wp-config.phpはアップロード前、またはサーバー上での直接編集のどちらでも対応できますが、アップロード前にローカルで編集してから転送する方が安全です。書き換えが必要な箇所は以下の4項目です。

• DB_NAME：本番サーバーで作成したデータベース名
• DB_USER：データベースのユーザー名
• DB_PASSWORD：データベースのパスワード
• DB_HOST：多くのレンタルサーバーでは「localhost」ですが、サーバーによって異なります

また、.htaccessはローカル用の記述をそのまま流用しないことが重要です。特にmod_rewriteの設定がサーバー環境によって異なる場合、パーマリンクが正常に動作しないトラブルが起きやすいです。移行後にWordPressの管理画面から「設定 → パーマリンク」を一度保存し直すと、.htaccessが自動的に再生成されるため、これを活用するのが確実です。

【手順②】データベースをエクスポート・インポートする

ファイル転送が完了したら、次はデータベースの移行です。WordPressのコンテンツ（投稿・固定ページ・設定値など）はすべてMySQLデータベースに格納されているため、このステップを誤ると本番サーバーでサイトが正常に表示されません。

ローカルDBのエクスポート——phpMyAdminの操作手順

ローカル環境のphpMyAdmin（XAMPPであれば http://localhost/phpmyadmin でアクセス）を開き、WordPressが使用しているデータベースを選択します。その後、以下の手順でエクスポートしてください。

1. 上部メニューの「エクスポート」タブをクリックする
2. エクスポート方式は「詳細」を選択する
3. 「出力」セクションで「ファイルとして保存」を選択する
4. 文字セットを utf8mb4 に設定する
5. 形式は「SQL」のまま「実行」をクリックする

エクスポートされた .sql ファイルは、インポート時に使用するので、ファイル名と保存場所を確認しておきましょう。

本番サーバーへのDB作成とインポート手順

本番サーバーのコントロールパネル（cPanelやさくらのコントロールパネルなど）でデータベースを新規作成し、データベースユーザーを割り当てます。その後、本番サーバーのphpMyAdminにアクセスし、作成したデータベースを選択して「インポート」タブから .sql ファイルをアップロードしてください。

インポート完了後、wp-config.php の以下の3項目を本番環境の値に書き換えることが必要です。

• DB_NAME：本番サーバーで作成したDB名
• DB_USER：割り当てたDBユーザー名
• DB_PASSWORD：設定したパスワード

文字コード・照合順序の設定ミスを防ぐポイント

インポート時に最も多いトラブルが、文字コードの不一致によるエラーです。ローカル環境が utf8mb4 で設定されているにもかかわらず、本番サーバー側のDBが utf8（3バイト文字のみ対応）で作成されていると、絵文字や一部の特殊文字を含むデータのインポートが失敗するケースがあります。

DB作成時には、文字セットを utf8mb4、照合順序を utf8mb4_unicode_ci に統一するのが確実です。また、テーブルプレフィックス（初期値は wp_）がローカルと本番で一致しているかも確認してください。wp-config.php の $table_prefix の値と、インポートしたテーブル名の先頭文字列がずれていると、WordPressがテーブルを認識できずエラーになります。

【手順②】データベースをエクスポート・インポートする

ファイルの転送が完了したら、次はデータベースの移行です。WordPressのコンテンツ（投稿・固定ページ・設定値など）はすべてMySQLデータベースに格納されているため、この手順を誤ると本番環境でサイトが正常に表示されません。

ローカルDBのエクスポート——phpMyAdminの操作手順

ローカル環境（XAMPPやMAMPなど）のphpMyAdminにアクセスし、対象のデータベースを選択します。上部メニューの「エクスポート」をクリックし、以下の設定で進めてください。

• エクスポート方式：詳細を選択する
• フォーマット：SQLを選択する
• 「CREATE TABLE文を追加する」にチェックを入れる
• 文字セット：utf8mb4を選択する

設定を確認したうえで「実行」をクリックすると、.sqlファイルがダウンロードされます。このファイルが本番環境へ持ち込むデータの本体になります。

本番サーバーへのDB作成とインポート手順

本番サーバーのコントロールパネル（cPanelやロリポップの管理画面など）から、新しいデータベースとデータベースユーザーを作成します。作成後、そのユーザーにデータベースへの全権限を付与してください。

次に、本番サーバーのphpMyAdminで作成したデータベースを選択し、「インポート」タブからエクスポートした.sqlファイルをアップロードして実行します。インポート完了後、テーブル一覧が表示されれば成功です。

文字コード・照合順序の設定ミスを防ぐポイント

インポート時にエラーが発生するケースで特に多いのが、文字コードと照合順序の不一致です。ローカルと本番の設定が合っていないと、日本語が文字化けしたり、インポート自体が失敗したりします。

データベース作成時とインポート時の両方で、以下の設定を統一してください。

• 文字コード（キャラクターセット）：utf8mb4
• 照合順序（コレーション）：utf8mb4_unicode_ci

また、wp-config.phpに記載されているテーブルプレフィックス（$table_prefix）の値が、インポートしたテーブル名と一致しているかも必ず確認してください。デフォルトは「wp_」ですが、セキュリティ対策として変更しているケースも少なくありません。プレフィックスが一致していないと、WordPressがテーブルを認識できずログイン画面でエラーが出ます。

【手順③】データベース内のURLを本番URLに一括置換する

なぜURLの置換が必要か——シリアライズデータの問題

データベースのインポートが完了しても、そのままでは本番環境で正常に表示されないケースがほとんどです。WordPressのデータベース内には、ローカル環境のURL（例：http://localhost/mysite）が投稿本文・メニュー・ウィジェット設定など、あらゆる箇所に埋め込まれています。これらを本番URLに書き換えなければ、画像の表示崩れやリンク切れが発生します。

注意が必要なのは、シリアライズデータの存在です。WordPressはPHPのシリアライズ形式でデータを保存しており、文字列の長さ情報も一緒に記録されています。たとえば、単純なSQL文でURLを置換すると文字数がずれてしまい、データ構造が破損してしまいます。手動でSQL文を書く方法はこのリスクを見落としがちなため、専用ツールを使った置換が実務上の標準です。

Search Replace DBを使った安全な置換手順

Search Replace DBは、シリアライズデータを自動的に考慮しながらURL置換を行えるWebベースのツールです。以下の手順で進めてください。

1. Search Replace DBの公式サイトからzipファイルをダウンロードし、解凍する
2. 解凍したフォルダをFTPで本番サーバーのWordPressルートディレクトリにアップロードする
3. ブラウザで https://本番ドメイン/フォルダ名/ にアクセスする
4. 「replace」欄にローカルURL（例：http://localhost/mysite）、「with」欄に本番URL（例：https://example.com）を入力する
5. 「dry run」で置換対象の件数を確認した後、「live run」を実行する
6. 完了後は必ずフォルダをサーバーから削除する（セキュリティリスクになるため）

dry runで事前に件数を確認できるため、意図しない置換が起きないかチェックしてから本番実行に移れる点が実用的です。

WP-CLIを使う方法——コマンド一例と注意点

サーバーにSSH接続できる環境であれば、WP-CLIを使う方法も有効です。以下のコマンド一行で、シリアライズデータを壊さずに置換できます。

wp search-replace ‘http://localhost/mysite’ ‘https://example.com’ –all-tables

このコマンドはWP-CLIがシリアライズデータのバイト数を自動で再計算するため、手動SQLよりも安全です。実行前に –dry-run オプションを付けて置換件数を確認する習慣をつけておくと、作業ミスを防ぎやすくなります。なお、マルチサイト構成の場合は –network オプションの追加が必要です。環境によって対応状況が異なるため、事前にWP-CLIのバージョンを確認しておくことをおすすめします。

【手順③】データベース内のURLを本番URLに一括置換する

なぜURLの置換が必要か——シリアライズデータの問題

データベースのインポートが完了した後、そのまま本番サイトを表示しようとするとレイアウトが崩れたり、内部リンクが切れたりするケースが少なくありません。原因の多くは、データベース内に残存するローカルURL（例：http://localhost/mysite）です。

WordPressはコンテンツだけでなく、ウィジェット設定やカスタムフィールド、テーマのオプションデータなども同じデータベースに保存しています。これらの一部はシリアライズ形式（PHPの配列・オブジェクトを文字列化したデータ形式）で格納されており、URLの文字数が変わると内部のバイト数カウントがずれてデータ構造が破損します。

そのため、単純なSQL文のREPLACE()関数でURLを置換すると、シリアライズデータを破壊してしまうリスクがあります。この点は手動のSQL置換だけを解説する情報では見落とされがちな注意点です。

Search Replace DBを使った安全な置換手順

Search Replace DB（interconnect/it社が公開しているツール）は、シリアライズデータを自動的に検出し、バイト数を再計算しながら安全に置換できるブラウザベースのツールです。以下の手順で実施します。

1. Search Replace DBの公式サイトからZIPファイルをダウンロードし、フォルダ名を推測されにくい任意の名前に変更する
2. 変更後のフォルダをFTPで本番サーバーのWordPressルートディレクトリにアップロードする
3. ブラウザでhttps://本番ドメイン/変更後フォルダ名/にアクセスし、設定画面を開く
4. 「Replace」欄にローカルURL（例：http://localhost/mysite）、「With」欄に本番URL（例：https://example.com）を入力する
5. 「Run」を実行し、置換件数が表示されたら完了を確認する
6. 作業完了後は必ずフォルダをサーバーから削除する（放置するとセキュリティリスクになります）

WP-CLIを使う方法——コマンド一例と注意点

サーバーにSSH接続できる環境であれば、WP-CLI（WordPressのコマンドラインインターフェース）を使った置換も有効な選択肢です。以下のコマンド一例が基本的な書式になります。

wp search-replace ‘http://localhost/mysite’ ‘https://example.com’ –all-tables

WP-CLIのsearch-replaceコマンドもシリアライズデータに対応しており、バイト数の再計算を自動で行います。--all-tablesオプションを付けることで、マルチサイト構成やプラグインが独自に作成したテーブルも含めて一括置換できます。

実行前に--dry-runオプションを追加すると、実際には置換せずに対象件数だけを確認できるため、本番実行前の事前確認として活用することをお勧めします。

置換完了後は、WordPress管理画面の「設定 → 一般」でサイトURLとWordPress URLが正しく本番URLになっているかを確認してください。

【手順④】プラグインを使った移行——All-in-One WP Migrationの手順

手順①〜③で解説したFTPとphpMyAdminを使った手動移行は、仕組みを理解するうえで有効です。一方、操作ミスのリスクを抑えたい場合や、短時間で移行を完了させたい場合には、プラグインを活用する方法が現実的な選択肢になります。

なかでもAll-in-One WP Migrationは、WordPressのファイルとデータベースを1つのファイルにまとめてエクスポートできるプラグインです。FTPやSQLの操作に不慣れな担当者でも手順を追いやすく、小〜中規模サイトの移行で広く使われています。

エクスポートファイルの作成と容量確認

LocalWPで構築したローカル環境のWordPress管理画面に、All-in-One WP Migrationをインストールします。プラグインを有効化したら、左メニューの「All-in-One WP Migration」→「エクスポート」を開きます。

エクスポート先は「ファイル」を選択します。処理が完了すると、拡張子「.wpress」のファイルがダウンロードされます。このファイルにはWordPressのコアファイル・テーマ・プラグイン・メディア・データベースがすべて含まれています。

ダウンロード前に、ファイルサイズを確認しておきます。無料版では後述の容量制限があるため、事前に把握しておくことが重要です。

本番サーバーへのインポート手順

本番サーバーにも、同じバージョンのAll-in-One WP Migrationをインストールします。WordPressがまだインストールされていない場合は、先にサーバー側へWordPressをセットアップしておく必要があります。

1. 本番環境の管理画面で「All-in-One WP Migration」→「インポート」を開く
2. 「インポート元」から「ファイル」を選択し、先ほどの「.wpress」ファイルをアップロードする
3. 確認ダイアログで「開始」をクリックし、処理完了を待つ
4. インポート完了後、管理画面へのログインを求められた場合はローカル環境のID・パスワードで入る

インポートが完了すると、URLの置換（手順③相当の処理）もプラグインが自動で行います。手動でのSQL操作が不要になる点が、このプラグインの大きな利点です。

無料版512MB制限の回避策——分割エクスポートと代替プラグイン

All-in-One WP Migrationの無料版には、インポートできるファイルサイズの上限が512MBという制限があります。画像ファイルが多いサイトや、運用歴の長いサイトではこの上限を超えるケースが少なくありません。

対処法として、以下の選択肢があります。

• メディアファイルを除外してエクスポートする：エクスポート設定の「高度なオプション」から「メディアライブラリを除外する」を選択し、画像などはFTPで別途転送する
• 有料の拡張機能を導入する：公式の「Unlimited Extension」を購入すると容量制限が解除されます。単発の移行作業であれば費用対効果を検討する余地があります
• 代替プラグインを使う：「Duplicator」はサイトをパッケージ化して移行できるプラグインで、無料版でも大容量サイトに対応しやすい構成になっています。移行対象のサイト規模に応じて使い分けを検討してみてください

All-in-One WP Migrationは操作の手軽さが魅力ですが、容量制限への対処を事前に計画しておくことで、移行当日のトラブルを防ぐことができます。

【手順④】プラグインを使った移行——All-in-One WP Migrationの手順

FTPやphpMyAdminを使った手動移行は確実性が高い一方、操作ステップが多く、設定ミスが起きやすい面があります。サイト規模が小〜中程度であれば、All-in-One WP Migrationを使うことで、ファイルとデータベースをまとめてエクスポート・インポートでき、作業工数を大幅に削減できます。

エクスポートファイルの作成と容量確認

まずローカル環境のWordPress管理画面に、All-in-One WP Migrationをインストールします。プラグインを有効化したら、左メニューの「All-in-One WP Migration」→「エクスポート」を開きます。

エクスポート先として「ファイル」を選択すると、サイト全体（テーマ・プラグイン・メディア・データベース）を1つの.wpress形式のファイルにまとめてダウンロードできます。エクスポート完了前に画面上でファイルサイズの目安が表示されるため、512MBを超えていないか必ず確認してください。

本番サーバーへのインポート手順

次に本番サーバー側のWordPress管理画面で同じプラグインをインストール・有効化します。「All-in-One WP Migration」→「インポート」を開き、先ほどダウンロードした.wpressファイルをドラッグ＆ドロップするだけでインポートが始まります。

インポート完了後はWordPressから一度ログアウトし、本番サーバーの管理者アカウントで再ログインしてください。プラグインがインポート時にデータベース内のURLを本番URLへ自動置換するため、手順③で実施したURL一括置換は省略できます。

無料版512MB制限の回避策——分割エクスポートと代替プラグイン

無料版では1ファイルあたり512MBのインポート上限が設けられています。この制限を超えるサイトに対しては、主に以下の3つのアプローチで対処できます。

• 分割エクスポート拡張（有料）：公式の「Basic Extension」を購入すると上限が解除されます。大規模サイトへの移行を繰り返す場合は費用対効果が高い選択肢です。
• php.iniでアップロード上限を引き上げる：本番サーバーのphp.iniまたは.htaccessでupload_max_filesizeとpost_max_sizeを変更することで、無料版でも大きなファイルをインポートできる場合があります。サーバー設定の変更可否はホスティング環境によって異なります。
• 代替プラグインへの切り替え：「Duplicator」や「WPvivid Backup」も同様の移行機能を持ち、無料プランでの容量制限が緩やかなケースがあります。ファイルサイズが大きい場合は比較検討する価値があります。

プラグインによる移行は、手動移行に比べてURLの置換やファイル配置の手間が少なく、操作ミスのリスクを抑えやすい方法です。ただし容量制限への対処を事前に計画しておくことが、スムーズな移行のポイントになります。

移行後の動作確認チェックリスト——よくある失敗パターンと対処法

ファイル転送とデータベース移行が完了しても、動作確認を省略するとトラブルに気づくのが遅れます。移行直後は必ず以下の手順でチェックを行い、問題があれば原因を特定してから対処してください。

移行後チェック項目一覧——トップ・固定ページ・管理画面・フォーム

• トップページの表示：レイアウト崩れ・画像の表示欠けがないか確認する
• 固定ページ・投稿ページ：複数ページを開き、内部リンクが正しく機能するか確認する
• 管理画面へのログイン：https://本番ドメイン/wp-admin/ にアクセスし、ログインできるか確認する
• お問い合わせフォーム：テスト送信を行い、メールが届くか確認する
• 外部リンク・SNSシェアボタン：ローカル環境のURLが混入していないか確認する
• SSL（HTTPS）の適用：ブラウザのアドレスバーに鍵マークが表示されるか確認する

よくある失敗パターンと原因・対処法の対応表

移行後に発生しやすいトラブルは、原因がある程度パターン化されています。現象ごとに原因と対処法を整理しておくと、再発時の対応が速くなります。

• 内部リンク切れ：データベース内にローカルのURL（例：http://localhost/site/）が残っているのが原因です。「手順③」で実施したURL一括置換が不完全な場合に起こります。Search Replace DBなどのツールで再度置換を実行してください。
• 画像が404エラーになる：FTP転送時にwp-content/uploads/フォルダの転送が漏れているケースがほとんどです。アップロードフォルダを丸ごと再転送してください。
• 管理画面にログインできない：データベースの接続情報（wp-config.php内のDB_HOST・DB_NAME・DB_USER・DB_PASSWORD）が本番環境の値と一致していないのが原因です。サーバーの管理パネルで確認した値に書き直してください。
• CSSが当たらない・レイアウトが崩れる：テーマファイルの転送漏れ、またはデータベース内のsiteurl・homeの値がローカルURLのままになっている場合に発生します。wp_optionsテーブルの該当レコードを本番URLに書き換えてください。
• パーマリンクが崩れて404になる：移行後に.htaccessが再生成されていないことが原因です。後述のパーマリンク再保存で解消できます。

パーマリンク設定の再保存——見落としがちな最終ステップ

移行後に個別の投稿や固定ページへアクセスすると404エラーになる場合、パーマリンク設定の再保存で解消できるケースが少なくありません。手順は以下のとおりです。

1. WordPress管理画面にログインする
2. 「設定」→「パーマリンク設定」を開く
3. 設定値を変更せず、そのまま「変更を保存」をクリックする

この操作により、.htaccessが本番環境のパスで書き直され、リライトルールが正しく反映されます。移行のたびに必ず実行すべき最終確認ステップです。

移行後の動作確認チェックリスト——よくある失敗パターンと対処法

ファイル転送とデータベース移行が完了しても、それで作業終了ではありません。移行直後は表示崩れやリンク切れが発生しやすく、本番公開前に必ず動作確認を行う必要があります。確認漏れが多いのは「移行できた」という安心感から確認が甘くなるタイミングです。

移行後チェック項目一覧——トップ・固定ページ・管理画面・フォーム

• トップページの表示：レイアウト崩れ・画像の欠落がないか
• 固定ページ・投稿ページ：複数ページを実際に開き、内部リンクが正しく機能するか
• 管理画面へのログイン：wp-adminにアクセスでき、正常にログインできるか
• お問い合わせフォーム：テスト送信を行い、メールが届くか
• 画像・CSSの読み込み：ブラウザの開発者ツールでコンソールエラーが出ていないか
• 外部リンク・SNSボタン：URLが本番ドメインに差し替えられているか

よくある失敗パターンと原因・対処法の対応表

• 内部リンク切れ：URLの一括置換が不完全な場合に発生します。wp_optionsテーブルのsiteurl・home、および投稿本文内のURLにローカルドメインが残っていないか、Search Replace DBなどで再確認してください。
• 画像が404になる：wp-contentフォルダの転送漏れが主な原因です。FTPクライアントでuploadsディレクトリが正しくアップロードされているか確認し、不足分を再転送します。
• 管理画面にログインできない：wp-config.phpのデータベース接続情報（DB_NAME・DB_USER・DB_PASSWORD・DB_HOST）が本番環境の値と一致していない場合がほとんどです。ホスティングの管理パネルで発行した認証情報と照合してください。
• CSSが当たらない（デザインが崩れる）：テーマのURLが旧ドメインのまま残っていることが原因です。wp_optionsのtemplate・stylesheetの値と、テーマ内のハードコードされたURLを確認します。
• パーマリンクが崩れて個別ページが404になる：.htaccessの設定が反映されていない状態です。後述の再保存で解消できるケースがほとんどです。

パーマリンク設定の再保存——見落としがちな最終ステップ

移行後に個別記事や固定ページへのアクセスが404になる場合、パーマリンク設定の再保存で解消することがほとんどです。管理画面の「設定」→「パーマリンク」を開き、何も変更せずに「変更を保存」ボタンをクリックするだけで.htaccessが再生成されます。この手順はファイル移行のたびに必要になるため、チェックリストの最後に必ず組み込んでおくことをおすすめします。

移行作業をツールで効率化する——CLANE ONEのFTP統合機能

バラバラなツール行き来が移行ミスを生む——現場の構造的な問題

WordPressのローカルから本番への移行作業では、複数のツールを並行して操作する場面が続きます。FTPクライアントでファイルを転送しながら、コードエディタでwp-config.phpの接続情報を書き換え、phpMyAdminでデータベースをインポートし、WordPress管理画面でURL置換の結果を確認する——この一連の流れは、タブやウィンドウを何度も切り替えながら進めることになります。

ツールをまたぐたびに、「どのファイルを転送済みか」「置換前のURLはどちらだったか」といった確認作業が発生します。手順が多いほど、見落としや誤操作が起きやすくなります。特に転送先のパス指定ミスや、DB接続情報の書き換え漏れは、移行後のサイトが正常に表示されない原因として頻繁に挙がります。

統合ワークスペースで移行工程をどう扱うか

CLANEが提供するCLANE ONEは、FTPクライアント・コードエディタ・WordPress管理画面の操作を、ひとつのワークスペース上で完結できる構成になっています。ローカルで編集したファイルをそのまま本番サーバーへ転送し、wp-config.phpの書き換えも同じ画面内で行えるため、ツール間の行き来による確認コストを抑えることができます。

移行手順そのものが変わるわけではありませんが、「どのツールで何を操作しているか」を意識し続ける負荷が減ることで、手順の抜け漏れを防ぎやすくなります。複数のWordPressサイトを管理する担当者や、移行作業を定期的に行う制作環境では、こうした統合環境が作業精度の維持に寄与するケースがあります。

移行作業をツールで効率化する——CLANE ONEのFTP統合機能

バラバラなツール行き来が移行ミスを生む——現場の構造的な問題

WordPressのローカル環境から本番サーバーへの移行作業では、複数のツールを同時に使うことが一般的です。FTPクライアント（FileZillaなど）でファイルを転送しながら、phpMyAdminでデータベースを操作し、コードエディタでwp-config.phpの接続情報を編集する——こうした作業はタブやウィンドウを頻繁に切り替えながら進めることになります。

この行き来が、移行ミスの温床になりやすい構造的な問題があります。たとえば、FTPで転送中にエディタ側の修正を先行させてしまい、古いファイルで上書きしてしまうケースや、どのツールでどこまで作業が完了しているか把握しにくくなる状況は少なくありません。作業ログが分散するため、エラー発生時に原因を特定しづらいという問題もあります。

統合ワークスペースで移行工程をどう扱うか

CLANEが提供するWeb制作ツール「CLANE ONE」は、FTPクライアント・コードエディタ・WordPress管理画面をひとつのワークスペース上で扱える設計になっています。移行作業においては、ファイルの編集から転送、サーバー上の確認までを画面を切り替えずに完結できるため、操作の抜け漏れが生じにくい環境を整えられます。

意思決定者の視点では、ツール間の連携ミスによる手戻りや、担当者ごとの作業環境のばらつきを減らせる点が実務上のメリットになります。移行手順そのものを標準化したい場面で、ツールの統合は作業品質の安定に寄与します。

まとめ——移行手順の全体像と選択のポイント

本記事で解説した移行作業を、工程フロー形式で整理します。

1. 前提条件の確認（PHPバージョン・DB種別・パーミッション）
2. ファイルのFTP転送（wp-config.phpは本番用に書き換え）
3. データベースのエクスポート＆インポート（phpMyAdmin使用）
4. DB内URLの一括置換（Search Replace DBなどを使用）
5. 動作確認・パーマリンク再設定・リダイレクト確認

プラグイン移行（All-in-One WP Migration）は、FTPやphpMyAdminの操作に不慣れな場合や、工数を最小化したい小〜中規模サイトに適しています。一方、手動移行（FTP＋phpMyAdmin）は、容量制限を受けやすい大規模サイトや、ファイル構成を細かく管理したい案件に向いています。

最後に、移行作業における最重要確認ポイントを3点に絞って提示します。

• wp-config.phpのDB接続情報：本番サーバーのDB名・ユーザー名・パスワード・ホスト名に正しく書き換えられているかを必ず確認します。ここが誤ったままだとサイト全体が表示されません。
• DB内のURL置換漏れ：ローカルURLが残っていると、画像・CSSの読み込みエラーやリンク切れが多発します。置換後は実際にページを開いてブラウザの開発者ツールでエラーがないかを確認してください。
• パーマリンク設定の再保存：移行直後は.htaccessが正しく機能せず、固定ページや投稿ページが404になるケースがあります。管理画面の「設定 ＞ パーマリンク」を開いて保存するだけで解消できます。

この3点を移行後のチェックリストの先頭に置いておくと、よくある初歩的なトラブルの大半を防ぐことができます。

まとめ——移行手順の全体像と選択のポイント

ここまで解説してきた移行作業の流れを、工程フロー形式で整理します。

1. 前提条件の確認（PHP・MySQLバージョン、サーバー容量、FTP接続情報）
2. 移行方法の選択（プラグイン移行 or 手動移行）
3. WordPressファイルのFTP転送
4. データベースのエクスポート・インポート
5. データベース内URLの一括置換
6. 移行後の動作確認・不具合対処

移行方法の選択については、サイト容量が512MB未満かつ手順に不慣れな場合はプラグイン移行、容量超過・サーバー制限がある場合や細かく制御したい場合は手動移行が適しています。どちらが優れているというわけではなく、環境条件と担当者のスキルによって使い分けるのが現実的です。

移行作業における最重要確認ポイント3点

• wp-config.phpのDB接続情報：データベース名・ユーザー名・パスワード・ホスト名を本番環境の値に必ず書き換える
• URL一括置換の完了確認：置換漏れがあると画像や内部リンクが表示されないため、Search Replace DBなどで確認する
• パーマリンク設定の再保存：移行直後は.htaccessの書き換えが反映されていないことが多く、管理画面から一度保存し直すだけで解決するケースがほとんどです

この3点を押さえておくことで、移行後の主要なトラブルの大半を未然に防ぐことができます。移行手順そのものはシンプルですが、確認の抜け漏れが失敗の原因になりやすい作業です。本記事のチェックリストを手順書として活用することをお勧めします。