WordPressでサイト制作を行う開発者の多くは、いきなり本番サーバー上で作業を始め、不具合やデータ消失といったリスクに直面しがちです。しかし、ローカル環境で安全に開発・検証を行い、本番環境へスムーズに移行することで、トラブルを最小限に抑え、品質の高いサイトを公開できます。本記事では、WordPress ローカル 本番 移行の一連の流れを、XAMPPによるローカル構築から実際の移行手順、さらに移行後のトラブルシューティングまで、段階的かつ詳細に解説します。これを読めば、安心してテストサイトで変更検証し、本番サイトへ反映する方法が身につきます。
ローカル環境構築の重要性と全体フロー
結論: ローカル環境を整えることで、実運用に影響を与えず安全に開発・テストが可能になる。
理由: 本番環境で直接作業すると、プラグインの不具合やコードミスが即時に公開状態へ反映され、ユーザー体験を損ねるリスクがあるため。
具体例: 改修中にCSSが壊れた場合でもローカル上なら影響範囲が限られ、修正後に本番へ正しく反映できる。
なぜローカル開発が必要か
ローカル環境はサーバー構成やPHPバージョン、データベース設定を自由に調整でき、本番環境と同等のテスト条件を再現可能です。
- 高速なフィードバック: ローカルならファイル保存→ブラウザリロードのみで反映。
- リスクフリー: 本番DBへの誤操作を防止し、安全にデータ検証。
- バージョン管理との親和性: Gitなどによるコミット履歴をローカル―共有リポジトリ間で管理しやすい。
全体ステップ俯瞰
- ローカル環境構築: XAMPPでApache/MySQLを準備し、WordPressをインストール。
- テストサイト制作: テーマ・プラグイン開発、UI/UX検証、動作テスト。
- バックアップ取得: ローカルDB・全ファイルのエクスポート。
- 本番環境準備: サーバー要件確認・空のDB作成。
- デプロイ: FTP/SFTPでファイル転送、DBインポート。
- URL・パス置換: 本番ドメインに合わせた検索・置換処理。
- 動作確認・トラブル対応: 画面チェック、.htaccess設定、パーミッション調整。
XAMPPによるローカル環境のセットアップ
WordPressのローカル開発には、XAMPPが最も手軽で汎用性が高い選択肢です。以下では、XAMPPの入手から初期起動、環境確認までの具体的ステップを詳述します。
XAMPPのダウンロード・インストール
結論: 公式サイトから最新のXAMPPをダウンロードし、インストーラーの指示に従ってインストールすれば、ローカルLAMP環境が一度に構築できる。
理由: XAMPPはApache Webサーバー、MySQL（MariaDB）、PHP、phpMyAdminなどの必要コンポーネントを同梱し、手動で個別にインストール・設定する手間を省ける。
具体例: Windows環境で以下の手順を踏むだけで、ApacheとMySQLが自動的にインストールされ、phpMyAdminでデータベース操作が可能になる。
- 公式サイトへアクセス: お使いのOS向けインストーラーを選択。
- インストーラーの実行: ダウンロードしたインストーラーを実行し、Apache, MySQL, PHP, phpMyAdmin が選択されていることを確認してインストール。
- インストールディレクトリ: デフォルトの
C:\xamppを推奨。 - インストール完了: Control Panel起動をチェックし「Finish」。
Apache/MySQL起動と確認
結論: XAMPP Control PanelからApacheとMySQLを起動し、問題なく動作することをブラウザとphpMyAdminで必ず確認する。
理由: サーバーが正常起動しない場合、WordPressインストールやDB操作ができず、以降の作業に支障をきたすため。
具体例: ポート競合や権限不足などのエラーは初期段階で解決し、作業をスムーズに。
- Control Panel起動: 管理者権限で実行。
- Apache/MySQL Start: 緑色表示とPort:80/3306を確認。
- ブラウザ確認: http://localhost/ でウェルカムページ。
- phpMyAdmin確認: phpMyAdmin でダッシュボード。
- トラブル対応: ポート変更やUAC設定で解消。
ローカルWordPressサイトのインストールと初期設定
ローカル環境構築後、最も重要なのがWordPressの正しいインストールと初期設定です。ここで手順を誤ると、後続の移行作業でトラブルが発生しやすくなります。
結論: データベース作成からwp-config.phpの設定を的確に行い、テーマやプラグインの初期導入まで完了させることで、テストサイトとしての基盤を堅牢に構築できる。
理由: WordPressはDB接続情報とファイル構成が一致しないと動作せず、各プラグインやテーマも初期状態で正確に動作しないため。
具体例: wp-config.phpでDB名を誤ると「Error establishing a database connection」が表示される。
データベース作成とwp-config.php設定
- phpMyAdminでDB作成: `wp_local`, UTF8_general_ci。
- WordPress配置:
C:\xampp\htdocs\my_siteにダウンロード解凍。 - wp-config.php編集: DB_NAME, DB_USER, DB_PASSWORD, DB_HOST を設定し、認証キーを追加。
- インストールウィザード: http://localhost/my_site/ でサイト情報を入力。
テーマ・プラグイン初期導入
- テーマ有効化: ダッシュボード「外観 > テーマ」で公式テーマを設定。
- セキュリティ: Wordfence, Sucuriを導入。
- バックアップ: UpdraftPlusでクラウド連携テスト。
- キャッシュ: W3 Total Cacheなどを導入。
- 開発支援: Query Monitorでデバッグ。
- パーマリンク: 投稿名設定し、.htaccess生成確認。
- テスト投稿: 投稿・画像アップ動作を検証。
テストサイトでのテーマ・プラグイン開発と検証
テストサイトは実運用に近い環境であるほど、本番移行後のトラブルを減らせます。開発中はテーマのカスタマイズやプラグイン導入だけでなく、データやバージョン管理まで含めた総合的なワークフローを確立しましょう。
結論: テストサイト上でテーマ・プラグインの開発と動作検証を徹底し、バージョン管理を組み合わせることで、安全かつ再現性のあるリリースが可能になる。
理由: 本番と異なるデータや設定では不具合が見逃され、本番移行後にサイトが崩れるリスクが高まるため。変更履歴が共有されなければ、戻すべきバージョンや原因切り分けが困難になる。
テスト用ユーザーデータの生成
- ダミーデータ生成: WP Dummy Contentで投稿やメディアを生成。
- ユーザー権限テスト: 管理者～購読者で操作フローを確認。
- カスタムフィールド検証: ACFや多言語プラグインで表示確認。
バージョン管理とコミット
- Git初期化: .gitignore設定とコミット。
- ブランチ戦略: main, develop, feature/を運用。
- CI/CD連携: GitHub Actionsで品質ゲート。
本番環境移行のための事前準備
結論: 移行前に完全バックアップと本番サーバー要件チェックを行うことで、万が一問題が起きても迅速にロールバック可能な環境を整え、作業ミスによるダウンタイムリスクを低減できる。
理由: 本番環境はユーザーがアクセスする実稼働サイトであり、データ損失や動作停止は信頼失墜や売上減少に直結するため。
バックアップ取得（DB＋ファイル）
- DBエクスポート: mysqldumpで一貫性あるダンプ。
- ファイルバックアップ: wp-content以下と設定ファイルを完全取得。
- 保管: 本番隔離フォルダ＋外部ストレージに二重保存。
本番環境要件チェック
- PHPバージョン: phpinfo()で確認、拡張モジュール有効化。
- DB文字コード: utf8mb4_unicode_ci、InnoDB必須。
- パーミッション: uploads 755, wp-config.php 600。
- HTTPS: Let’s Encrypt等でSSL設定。
- リソース: ディスク容量・CPU/メモリ余裕確認。
ローカルサイトを本番環境に移行する具体手順
結論: ファイル転送とデータベース移行を順序立てて実施し、URL置換を行うことで、ローカルで構築したサイトを本番サーバーへ正しく移行できる。
理由: ファイルとDBが同期していないとコンテンツが欠落したり、リンク切れ・画像表示不具合が発生するため。
ファイル転送（FTP/SFTP）
- FTPクライアント設定: パッシブFTPまたはSFTP推奨。
- wp-contentアップロード: 差分同期と再開機能利用。
- 設定ファイル配置: 本番用wp-config.php, .htaccess。
- パーミッション設定: uploads 755, wp-config.php 600。
データベースエクスポート／インポート
- エクスポート: phpMyAdminまたはmysqldump。
- インポート: phpMyAdminまたはMySQL CLI。
- テーブルプレフィックス調整: wp-config.phpとの一致を確認。
移行後の確認とトラブルシューティング
結論: 移行完了後は、URL/パス置換と.htaccess・パーミッションを最終確認し、サイト全体の動作検証を行うことで、不具合を早期に発見・修正できる。
理由: 特に画像リンクや内部パス、リダイレクト設定のミスマッチはユーザー体験を大きく損ねるため。
サイトURL／パス置換方法
- WP-CLI:
wp search-replace 'http://localhost/my_site' 'https://example.com' --skip-columns=guid - Better Search Replaceプラグインでドライラン後に実行。
- シリアライズ対応: WP-CLI推奨、一部プラグイン非対応に注意。
.htaccess・パーミッション調整
- .htaccess確認: WordPress標準rewriteルール＋HTTPSリダイレクト。
- パーミッション再確認: uploads 755, wp-config.php 600, .htaccess 644。
- キャッシュクリア: キャッシュプラグインの削除実行。
- 動作テスト: トップページ、投稿ページ、ログイン、HTTPSリダイレクトなど。
まとめ
ローカル環境でのサイト構築から本番移行、移行後の動作確認・トラブルシューティングまでを一貫して実施することで、安全かつ効率的なWordPressサイトデプロイが実現できます。特に、バックアップ取得→要件チェック→段階的デプロイ→置換・検証のフローを厳守することが、公開時のトラブルを防ぎ、信頼性の高いサイト運営につながります。
今すぐローカル環境を整え、本記事の手順に従ってテスト→移行→公開を行い、安心の開発プロセスを実現しましょう。
