WordPress移行前のチェックリスト10項目｜失敗しないための事前準備ガイド | WPセンターブログ

WordPressサイトを新サーバーやテスト環境へ移行する際、「移行手順」だけを知られていても、本番切り替え前の準備が不十分だと思わぬトラブルを招きます。本記事では、移行前に必ず押さえておきたい7のチェック項目を体系的に解説。印刷してそのまま使えるリスト形式で抜け漏れなく事前準備を行い、担当者として確実に「失敗しない移行」を実現しましょう。

移行計画と全体スケジュール策定

WordPressサイト移行を成功させるには、明確な移行計画の立案とスケジュール管理が不可欠です。移行本番の日付だけを決めて準備を後回しにすると、予期せぬ作業遅延や抜け漏れが発生し、ダウンタイムの長期化やデータ欠損といった重大リスクにつながります。

まず、現行サイトの全体像を可視化（現状分析）し、新環境で実現すべき要件やゴールを具体化しましょう。そして、移行の大まかなタイムラインを設定し、各タスクを関係者のロールに落とし込みます。この計画フェーズでポイントとなるのは、移行元と移行先の環境差異、作業の前後関係（依存関係）、および各ステークホルダーの承認フローです。

現状分析とゴール設定

移行前の現状分析では、まず「バージョン」「プラグイン」「テーマ」「カスタマイズ」「データ量」「トラフィックピーク時間帯」「使用中の外部サービス」など、サイトを構成する全要素をリスト化します。これらは移行先サーバーのPHP/MySQLバージョン適合性やリソース要件に影響するため、事前に洗い出しておかなければなりません。

次に、移行後に求められる機能的ゴールと品質要件を定義します。たとえば、「SSL完全移行」「パーマリンクやSEOメタの維持」「レスポンスタイムの最適化」「ダウンタイムを5分以内に抑える」など具体的な数値目標まで落とし込むことで、後工程の判断基準が明確になります。

ロール＆タスクの明確化

移行作業にはWeb担当者、サーバー管理者、開発者（テーマ・プラグイン調整）、運用チーム、さらには上長承認者やクライアントといった多様なステークホルダーが関わります。各人の役割と責任範囲を明示し、タスクごとに期限と依存関係をガントチャートやタスク管理ツール（JIRA、Backlog、Trelloなど）に登録。

たとえば、《バックアップ取得》はサーバー管理者が担当し、《テスト環境でのリストア検証》は開発者が実行、《最終DNS切替》はWeb担当者とドメイン管理者が共同で行う、というように役割を切り分けることで、誰がどこまで完了しているか一目でわかるようになります。これにより、タスクの抜け漏れや二重実行を防止し、移行スケジュールの遅延リスクを最小化できます。

サーバー要件と互換性チェック

移行先サーバーのPHP/MySQLバージョン、および必要なPHP拡張モジュールやサーバーリソース（CPU、メモリ、ストレージ性能）は、現行サイトと完全に一致させることが理想です。バージョン差異やモジュール不足があると、プラグインの機能不全やテーマのレイアウト崩れ、最悪の場合サイトが真っ白になる致命的なエラーを招きます。

ホスティングスペック確認

PHPバージョン：最低でも WordPress 推奨（現時点では 7.4 以上、できれば 8.0以上）
MySQL/MariaDBバージョン：WordPress 要件に合致（MySQL 5.7 以上 / MariaDB 10.3 以上推奨）
Apache/Nginx のモジュール：mod_rewrite、mod_headers など必要モジュールの有効化状況
メモリ上限（memory_limit）：最低 256MB 以上推奨（大規模サイトは 512MB 以上）
PHP実行時間（max_execution_time）：プラグインインストールやバックアップ処理時にタイムアウトしないよう 300 秒以上
ディスク容量とIOPS：メディアライブラリ容量と将来の増加分を含めた余裕
帯域幅（転送量）制限：月間転送量に余裕があるか

これらの数値が不足している場合は、ホスティングプランのアップグレードやリソース追加を事前に手配してください。

ソフトウェア互換性検証

次に、使用中のプラグインやテーマが新環境で正常動作するかを検証します。

PHP拡張モジュール：imagick、mbstring、curl、zip、gd など、プラグインやテーマが依存する拡張が全てインストールされているか。
コマンドラインツール：WP-CLI を使用する場合は、同バージョンの WP-CLI が動作するか。
ライブラリ依存：Composer で管理しているライブラリがある場合は composer install が正常に完了するか。

これらはテスト環境で事前に検証し、問題があればホスティング提供元にモジュール追加や設定変更を依頼しましょう。

メディアファイル移行戦略

大容量のメディアファイルを安全かつ効率的に移行するには、ファイルサイズ把握と分類、移行ツール選定、実行手順の３ステップで進めると失敗がありません。メディアが適切に移行されないと、画像リンク切れや読み込み遅延が発生し、ユーザー体験とSEOを大きく損ねるリスクがあります。

ファイルサイズ把握と分類

まず、移行対象のメディアフォルダ（通常は /wp-content/uploads）内のディレクトリ構成と容量分布を把握します。

# 容量上位10ディレクトリを確認
du -h wp-content/uploads | sort -hr | head -n 10

これにより、特に容量を占める年/月別フォルダや巨大ファイルを特定可能です。次に、

静的メディア（写真、ロゴ、アイコンなど、滅多に更新しないファイル）
動的メディア（ユーザー投稿の画像、CSVやPDFアップロードなど、頻繁に追加・更新されるファイル）

に分類し、それぞれの優先度を決定します。静的メディアは一括コピー、動的メディアは差分同期ツールでの定期ミラーリングが効果的です。

移行ツールと手順

rsync（Linuxサーバー間）
rsync -avz --progress --delete /path/to/old/uploads/ user@newserver:/path/to/new/uploads/
利点：差分転送により再実行時の高速化、途中中断からの再開が容易。
注意点：--delete オプションは慎重に使用し、必ずバックアップ検証後に実行。
FTP/SFTP
GUIツール（FileZilla、WinSCP）やCLIで接続し、年別フォルダ単位で並列ダウンロード・アップロード。
利点：Windows環境でも手軽に利用可能。
注意点：数千〜数万ファイルの転送では遅延やタイムアウトが発生しやすい。必ず キュー再試行設定 を有効化。
プラグイン利用
「WP Offload Media」「Media Sync」など、メディアをS3やGoogle Cloud Storageなどの外部ストレージに直接オフロード。
利点：本番環境の負荷を軽減しつつ、CDN連携できる。
注意点：初期設定とアクセス権限設定が複雑。移行後のURL書き換え設定を忘れずに。
クラウドストレージ同期
AWS CLI、gsutil を利用し、バケット間で同期。万が一のために バージョニング を有効化しておくと安心です。

実行の流れ

テスト環境で少量データを移行し、画像表示・リンク切れを確認。
本番サーバーで rsync や CLI同期を実施。
完了後にブラウザキャッシュをリフレッシュして動作確認。
最終差分が少ない時間帯（深夜〜早朝）を狙い、再度差分同期を実行し移行完了。

DNS切替とタイミング計画

DNSレコード切替によるダウンタイム最小化には、TTLの事前調整とロールバック手順の準備が鍵です。不適切なTTL設定や切替タイミングの見誤りは、旧・新サーバー混在状態を長引かせ、ユーザーや検索エンジンに不安定なサイトと認識される恐れがあります。

TTL設定と計画

DNSレコード（AレコードやCNAME）のTTL（Time To Live）をデフォルト（3600秒以上）から短縮（300秒以下）に変更するタイミングは、移行予定の48〜72時間前に行うのが一般的です。

72時間前：DNSプロバイダ設定画面でTTLを300秒に変更
48時間前以降：TTL短縮後の反映を確認
移行当日：本番切替30分前までに最終バックアップ・テストを完了し、DNSレコードを新サーバーIPに変更

TTLを短く設定しておくと、DNSキャッシュの有効期限が切れたタイミングで迅速に新サーバーへ誘導され、ダウンタイムを数分以内に抑えられます。

フェールオーバー準備

DNS切替時に問題が発生した場合に備え、ロールバック手順を用意します。手順例：

旧サーバーの保持期間設定：切替後24時間は旧サーバーを停止せず稼働継続。
DNSレコードの再切替スクリプト：APIやCLIを活用し、旧IPに戻す自動スクリプトを用意。
モニタリング設定：切替完了後、外部モニタリング（StatusCake、UptimeRobot）で応答確認。
コミュニケーションチャネル：関係者へ即時連絡できるチャットルーム（Slack、Teams）やメールテンプレートを準備。

これにより、切替トラブル時にも1クリックで復旧でき、サービス信頼性を確保できます。

関係者への周知と報告体制構築

サイト移行は単なる技術作業ではなく、社内外の多くの関係者と連携するプロジェクトです。関係者への不十分な周知は、「いつ切り替わるのか分からない」「作業時間中に問い合わせが増える」などの混乱を招き、サポート対応負荷や社内不信感を高めるリスクがあります。移行を円滑に進めるために、開始前の通知フロー策定と移行当日のリアルタイム報告体制を確立しましょう。

通知・承認フロー設定

ステークホルダーリストの作成
社内：Web担当チーム、開発チーム、運用サポート、カスタマーサポート、上長、経営層
社外：ドメイン管理会社、ホスティングベンダー、主要顧客（大口取引先）、パートナー企業
コミュニケーションチャネル指定
社内：Slack／Teams の専用チャンネル、定例メール
社外：メール通知、LINE WORKS グループなど
通知タイミングと内容
- 移行72時間前：TTL変更完了報告と移行スケジュール再共有
- 移行24時間前：テスト結果のサマリーと最終確認依頼
- 移行2時間前：作業開始通知とリスク・緊急連絡先の再提示
- 移行完了直後：完了報告と動作確認URL、今後の監視スケジュール
承認フロー
各ステップでの責任者承認（ゴー／ノーゴー判断）は電子サインまたは承認コメントを記録。変更管理ツール上でワークフロー自動化推奨。

リハーサルとドリル実施

フルリハーサル
テスト環境を本番環境に極力近づけ、DNS切替を模擬。各ステークホルダーによる連絡・承認フローを実演し、所要時間を計測。
障害シナリオドリル
バックアップリストア失敗、DNS反映遅延、SSL証明書設定ミス、プラグイン干渉による白画面などのトラブルに対応する演習を実施。
ドキュメント整備
リハーサル・ドリル結果を踏まえて手順書、トラブルシュートガイド、連絡網リストを最新版に更新し、オンラインナレッジベースとPDFで共有。

セキュリティ・SEO事前対策

移行後にセキュリティリスクや検索順位の急落を防ぐため、SSL設定やSEOパラメータの引継ぎを漏れなくチェックしましょう。これを怠ると、ユーザー通信の盗聴リスクや、リダイレクトミスによる404増加でSEO評価が著しく低下する恐れがあります。

SSL証明書とHTTPS設定

事前証明書発行・検証
Let’s Encrypt や商用SSLを用いて証明書を新サーバーにインストールし、test.example.comで動作確認。
証明書更新計画
本番移行日から逆算し、有効期限が30日以内のものは事前更新。自動更新設定（cron + Certbot）を事前テスト。
HTTPS強制リダイレクト
Nginx：return 301 https://$host$request_uri;
Apache：.htaccessにRewriteCond %{HTTPS} !=on→RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]を設定。
Mixed Content チェック：ブラウザコンソールや Why No Padlock で、全リソースがHTTPSか確認。
HSTS（HTTP Strict Transport Security）
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload ヘッダを設定。

SEOパラメータ引継ぎ

メタタグ・タイトルタグの維持
テーマの header.php を差し替えずに、既存のメタタイトル・メタディスクリプションがそのまま適用されるか確認。
301リダイレクト計画
URL構造変更時はサーバー設定またはプラグイン（Redirection）で301リダイレクトを設定。リダイレクトマップ作成後、Screaming FrogやSearch Consoleでチェッカー実行。
XMLサイトマップ再生成
最新URLでサイトマップを再生成し、robots.txtへのパスを更新。
Search Console・Analytics 設定
Search Console プロパティを移行先にも追加、サイトマップ提出。Analytics コード（UA-/G-）が正しく読み込まれているか確認。

まとめ

本記事では、移行計画とスケジュール策定からバックアップ検証、サーバー要件チェック、メディア移行戦略、DNS切替、関係者周知、セキュリティ＆SEO対策まで、失敗しないための7の事前準備を詳しく解説しました。これらを体系的に押さえることで、ダウンタイムやデータ欠損、検索順位低下といった重大トラブルを未然に防げます。担当チームと共有して、「安心・確実なWordPress移行」を実現しましょう。