WP-CLIでウェブサイトを移行する方法

大規模なWordPressサイトを管理していて、新しいホストに移行する必要がある場合、WP-CLIを使用すると、より高速でスクリプト化しやすい方法で移行できます。

これにより、大規模なデータベースでPHPタイムアウトが発生することはありません。さらに、複数のサイトで繰り返し実行したり、自動化したりできるプロセスが得られます。

このチュートリアルでは、WP-CLIを使用してWordPressサイトを移行する方法を説明します。終了時には、サイトは新しいサーバーで実行され、訪問者が新しいホストにアクセスする前に、サイトが機能していることを確認できます。

主なポイントは次のとおりです：

• WP-CLIによる移行は、大規模サイトの場合、プラグインベースの移行よりも高速ですが、両方のサーバーでSSHアクセスが必要であり、各サーバーにWP-CLIがインストールされている必要があります。
• wp search-replaceの--preciseフラグは、このチュートリアルで最も重要なコマンドです。これがないと、シリアライズされたデータがサイレントに破損し、テーマの設定、ウィジェット、プラグインのオプションがエラーメッセージなしでリセットされます。
• 古いサーバーから新しいサーバーにwp-config.phpをコピーすると、間違ったデータベース認証情報が引き継がれます。インポートする前に、新しいサーバーでDB_NAME、DB_USER、DB_PASSWORD、DB_HOSTを更新する必要があります。
• 移行が正常に完了したことを確認する前に、DNSを切り替えないでください。ステップ7では、wp option get、wp core verify-checksums、およびhostsファイルプレビューを使用したDNS前のチェックリストをカバーします。
• wp duplicator buildは、開始前にターミナルからサイト全体のバックアップを作成します。移行中に問題が発生した場合、Duplicatorの災害復旧URLは、古いサーバーでSSHなしで元のサイトを復元します。
• 新しいドメインに移行する場合は、search-replaceコマンドに--skip-columns=guidを含めてください。GUIDを置き換えると、RSSサブスクリプションが壊れます。

目次

WP-CLIを使用してWordPressサイトを移行する場合

WP-CLIは、すべての移行に適したツールではありません。コマンドラインルートを選択する方が理にかなっている場合（および別の方法がより適している場合）は次のとおりです。

WP-CLIを使用する場合：

• ブラウザベースのツールが転送中にPHPタイムアウトまたはメモリ制限に達するほどサイトが大きい場合
• ホストがブラウザ経由で完全なバックアップを作成するために十分な一時ディスクスペースを提供しない場合
• 複数のサイトを移行し、繰り返し可能なスクリプト化されたプロセスを希望する場合。bashスクリプト内のwp duplicator buildは、手動作業なしでバッチバックアップを処理します
• すべてのステップを完全に制御したい場合：転送されるもの、置換されるもの、DNS変更前に検証されるもの

次のような場合は、代わりに移行プラグインを検討してください。

• ソースまたは宛先サーバーでSSHアクセスができない場合
• コマンドラインに慣れていない場合
• 進捗インジケーターとロールバックが組み込まれた、ガイド付きのビジュアルプロセスを希望する場合

どちらを使用するかは、セットアップと好みに依存します。

開始する前に必要なもの

コマンドを1つ実行する前に、これらすべてを準備してください。移行中に何か（特にデータベースの認証情報やファイルパス）を紛失すると、半端にインポートされたデータベースと、両方のサーバーでダウンしているサイトで終わることになります。

• 両方のサーバーへのSSHアクセス。このプロセスでは、古いサーバーと新しいサーバーでコマンドを実行する必要があります。
• 両方のサーバーにWP-CLIがインストールされていること。まだインストールされていない場合は、公式インストールガイドに従ってください。ステップ7の検証手順で、古いサーバーだけでなく新しいサーバーでも必要になります。
• 古いサーバーにDuplicator Proがインストールされ、アクティブになっていること。このバックアップ/移行プラグインには、wp duplicator build、wp duplicator info、およびwp duplicator cleanupコマンドがあります。
• 新しいサーバーに、完全な権限を持つユーザーでデータベースが既に作成されていること。wp db importはデータベースを作成しません。存在しない場合、インポートは失敗します。
• 新しいサーバーのデータベース認証情報（DB_NAME、DB_USER、DB_PASSWORD、DB_HOST）を準備してください。これらはステップ4で必要になります。
• 両方のWordPressインストールの絶対ファイルパス。各WordPressのルートディレクトリ内でpwdを実行し、出力を便利な場所にコピーしてください。
• ドメインを変更する場合：古いURLと新しいURLを、プロトコル（https://またはhttp://）を含め、データベースに表示されるとおりに正確にコピー/貼り付けできるように準備してください。

WP-CLIを使用してWordPressサイトを移行する方法

ここで行うこと。各ステップは前のステップに直接基づいているため、順番に進めてください。

• ステップ1：wp duplicator infoおよびwp duplicator buildで、事前チェックを実行し、完全なバックアップを作成します。
• ステップ2：wp db exportを使用して、古いサーバーからデータベースをエクスポートします。
• ステップ3：rsyncおよびscpを使用して、WordPressファイルとデータベースを新しいサーバーに転送します。
• ステップ4：新しいデータベース認証情報を使用して、新しいサーバーのwp-config.phpを更新します。
• ステップ5：wp db resetおよびwp db importを使用して、新しいサーバーでデータベースをリセットしてインポートします。
• ステップ6：wp search-replaceを使用してURLを更新します（ドメイン変更のみ）。
• ステップ7：DNSに触れる前に、キャッシュをフラッシュして移行を検証します。
• ステップ8：DNSを更新して公開します。
• ステップ9：wp duplicator cleanupを使用して、古いサーバーをクリーンアップします。

ステップ1：元のサイトをバックアップする

何かをエクスポートする前に、元のサーバーにクリーンな復元ポイントが必要です。移行中に何か問題が発生した場合、慌てることなく、動作するサイトに戻れるようにしたいはずです。

WordPressのバックアップ保護にはDuplicatorを使用しています。これは150万以上のWordPressプロフェッショナルに利用されているバックアップおよび移行プラグインで、WP-CLIコマンドが組み込まれています。

つまり、ターミナルから離れることなく、サイト全体のバックアップを作成できるということです。コマンドラインワークフローでは、これは重要です。

まず、Duplicatorのバックアップ設定が正しく機能していることを確認します。古いサーバーにSSHで接続し、WordPressのルートディレクトリに移動して、次を実行します。

wp duplicator info

これが正常に完了したら、バックアップを作成します。

wp duplicator build

これにより、ターミナルからサイト全体のバックアップが作成されます。

デフォルト以外の特定の場所にバックアップを保存したい場合は、次を使用します。

wp duplicator build --dir=/path/to/backup/location

wp duplicator build --helpを実行して、事前定義されたバックアップテンプレート用の--template=<ID>や、--phpsqldump、--phpzip、--duparchiveなどのアーカイブエンジンオプションを含む、利用可能なすべてのフラグを確認してください。

この移行で何か問題が発生した場合、Duplicatorの災害復旧URLは、古いサーバーでWordPressが完全にロックアウトされている場合でもサイトを復元できます。これは、他のものを触る前に、あなたのセーフティネットとなります。

ステップ2：古いサーバーからデータベースをエクスポートする

古いサーバーで、WordPressのルートディレクトリに移動し、データベースをエクスポートします。

wp db export site-backup.sql

完了すると、次のように表示されます: Success: Exported to 'site-backup.sql'。

ファイルは現在のディレクトリに保存されます。次のステップで転送するため、その場所をメモしておいてください。

次に進む前に、やっておくべきことがあります。もし.sqlファイルが/public_htmlや/htdocsのようなウェブからアクセス可能なディレクトリ内に保存された場合は、転送後すぐに移動または削除してください。

公開された.sqlファイルは、ユーザー名、ハッシュ化されたパスワード、およびサイト上のすべてのコンテンツを含む、データベースの完全なコピーです。これは理論上のリスクではありません。

WordPressのマルチサイトネットワークを移行している場合は、ネットワーク全体のデータをキャプチャするために--all-tablesを追加します。

wp db export site-backup.sql --all-tables

ステップ3：WordPressファイルとデータベースを新しいサーバーに転送する

新しいサーバーに移動する必要があるのは2つです: WordPressファイルと、先ほど作成した.sqlエクスポートファイルです。

ファイルにはrsyncを使用します。これは大規模な転送をうまく処理し、進捗を表示し、接続が切断された場合に中断したところから再開できます。

rsync -avz --progress /path/to/old-wordpress/ user@newserver:/path/to/new-wordpress/

スラッシュを付けると、rsyncはディレクトリの内容をコピーします。付けないと、rsyncはディレクトリ自体をコピーするため、新しいサーバーでファイルが想定よりも1レベル深く配置されます。

コミットする前に、何が転送されるかを確認するために、まずドライランを実行します。

rsync -avz --progress --dry-run /path/to/old-wordpress/ user@newserver:/path/to/new-wordpress/

データベースファイルにはscpを使用します。

scp site-backup.sql user@newserver:/path/to/new-wordpress/

すべてを単一のアーカイブに圧縮してから移動したい場合も、可能です。

tar -czf site_files.tar.gz .
scp site_backup.sql site_files.tar.gz user@newserver:/path/to/new-wordpress/

その後、新しいサーバーで展開します。

tar -xzf site_files.tar.gz

このアプローチは、小規模なサイトや、rsync接続よりも単一ファイル転送をより確実に処理するホストに適しています。

ステップ4：新しいサーバーでwp-config.phpを更新する

これは、ほとんどのWP-CLI移行チュートリアルが省略するステップであり、インポート直後に移行が失敗する最も一般的な理由です。

前のステップでWordPressファイルを転送したとき、wp-config.phpも一緒に転送されました。それは正しいファイルですが、古いサーバーのデータベース認証情報が含まれています。今インポートを実行すると、WP-CLIは新しいサーバーに存在しないデータベースに接続しようとします。

SSHで新しいサーバーに接続し、WordPressのルートディレクトリに移動して、wp-config.phpを開きます。

nano /path/to/new-wordpress/wp-config.php

新しいサーバーで作成したデータベースの詳細情報で、以下の4つの値を更新します。

• DB_NAME：新しいサーバーで作成したデータベースの名前
• DB_USER：データベースのユーザー名
• DB_PASSWORD：データベースのパスワード
• DB_HOST：通常はlocalhostですが、ホストに確認してください。一部のマネージドホストでは、ここに異なる値が使用されます。

保存して終了します。nanoの場合は、Ctrl+Oで保存、Ctrl+Xで終了です。

この手順を忘れないでください。認証情報が間違っていると、wp db importは間違ったデータベースに接続するか、「データベース接続確立エラー」で失敗します。そして、原因がwp-config.phpにあるとは限らないため、常に明らかとは限りません。

ステップ5：新しいサーバーでデータベースをリセットしてインポートする

SSHで新しいサーバーに接続し、WordPressのルートディレクトリに移動します。新しいサーバーにWordPressを新規インストールした場合は、インポートする前にデフォルトのテーブルをクリアしてください。この手順をスキップすると、既存のテーブルとエクスポートしたテーブルとの間に競合が発生する可能性があります。

wp db reset --yes

次のように表示されます：成功：データベースがリセットされました。

--yesフラグは、確認プロンプトをスキップします。これがない場合、WP-CLIはすべてのテーブルを削除する前に確認を求めます。

次にデータベースをインポートします：

wp db import site-backup.sql

インポートが確認されたらすぐに、SQLファイルを削除します：

rm site-backup.sql

その後、古いサーバーにSSHで再度接続し、そこでも削除します。

これはオプションの整理整頓ではありません。.sqlファイルがWebからアクセス可能なディレクトリに置かれていると、データベースの完全なコピーが公開されることになります。他の操作を行う前に、両方のサーバーから削除してください。

ステップ6：Search-Replaceを実行してURLを更新する

ドメインを変更せずにホストのみを変更する場合は、この手順をスキップしてステップ7に直接進んでください。URLはすでにデータベースで正しく設定されています。

ドメインを変更する場合、ほとんどの移行が静かに壊れるのはこの段階です。エラーが発生するのではなく、テーマの設定が間違っているように見えたり、ウィジェットが消えたり、プラグインのオプションがデフォルトに戻ったりします。原因はほぼ常に同じです：シリアライズされたデータを正しく処理できなかった検索と置換です。

何かを実行する前に、ドライランを実行します：

wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables --precise --dry-run

これにより、完全な操作が実行され、変更を保存せずに、データベーステーブルごとにいくつの置換が行われるかの表が表示されます。確認してください。

置換が期待されるテーブル（wp_options、wp_posts、wp_postmeta）を探し、カウントが妥当に見えることを確認してください。これらのテーブルで予期しないゼロは、コミットする前に調査する価値があります。

満足したら、–dry-runなしで実行します：

wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables --precise

--preciseが重要な理由：WordPressは一部のデータをシリアライズされたPHPとして保存します。テーマカスタマイザーの設定、ウィジェットの設定、プラグインのオプションなどは、プレーンテキストとして保存されるわけではありません。これらは、文字数を含む構造化されたPHP文字列として保存されます。

標準的なSQLベースの検索と置換は、URL文字列を置き換えますが、これらの文字数を再計算しません。PHPはカウントを読み取り、不一致を見つけ、データをサイレントに破棄します。

テーマがリセットされ、ウィジェットが消えます。エラーは何も発生しません。サイトが見た目におかしくなるだけです。

--preciseフラグは、WP-CLIがSQLの代わりにPHPを使用するように強制します。各値をアンシリアライズし、置換を行い、文字数を再計算し、結果を正しく再シリアライズします。大規模なデータベースでは遅くなります。それでも使用してください。

wp search-replaceがデフォルトで正しくスキップする1つのことは、wp_postsのguid列です。GUIDの置換を強制しようとしないでください。

WordPressのドキュメントでは、GUIDは一定でなければならないと明示的に述べられています。フィードリーダーを識別するために投稿を識別し、変更するとRSSサブスクリプションが壊れます。

マルチサイトネットワークを移行する場合は、--networkフラグを追加してください。

wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables --precise --network

公式WordPressドキュメントでは、異なる順序が説明されています。移行前に古いサーバーの設定 » 一般でURLを更新してから、すでに更新されたデータベースをエクスポートし、新しいサーバーでの検索置換ステップを完全にスキップします。これは機能します。このチュートリアルのアプローチ（まず移行し、その後検索置換）は、URLの変更をコミットする前にドライランを実行できるため、検証が容易です。

ステップ7：DNSを変更する前にキャッシュをクリアして確認する

検索と置換が完了したら、すぐにDNSに進みたくなります。やめてください。

サイトが機能していることを確認する前にDNSを変更すると、見つかった問題はライブの問題となり、実際の訪問者に表示されます。ここで10分かけて、まず新しいサーバーですべてを確認してください。

まずオブジェクトキャッシュをフラッシュします。

wp cache flush

次にリライトルールをフラッシュします。

wp rewrite flush

次に、データベース内のURLが正しいことを確認します。両方実行してください。

wp option get siteurl
wp option get home

どちらも正しいドメインを返すはずです。どちらかが古いドメインを返した場合は、手動で更新できます。

wp option update siteurl 'https://newdomain.com'

wp option update home 'https://newdomain.com'

次に、WordPressコアファイルが破損せずに転送されたことを確認します。

wp core verify-checksums

エラーが返された場合は、どのファイルがフラグ付けされたかをメモしてください。wp-content内の少数の変更されたファイルは予想されることであり、問題ではありません。それらはテーマとプラグインファイルであり、チェックサム比較の一部ではありません。wp-adminまたはwp-includes内のコアファイルのエラーは調査する価値があります。

DNSを更新する前にサイトをプレビューします。ドメインを新しいサーバーのIPアドレスに向ける一時的な行をローカルマシンのhostsファイルに追加します。MacまたはLinuxでは、テキストエディタで/etc/hostsを開き、以下を追加します。

123.456.789.0 yourdomain.com

123.456.789.0を新しいサーバーのIPに置き換えます。ファイルを保存してから、ブラウザでドメインを開きます。あなたは今、他の誰もがまだ古いサーバーにアクセスしている間に、新しいサーバーを見ています。

続行する前に、これらすべてを確認してください。

• ホームページが正しく読み込まれる
• /wp-adminで管理ログインが機能する
• 投稿やページに画像が表示される
• ナビゲーションメニューがそのまま
• ウィジェットがサイドバーまたはフッターに正しく表示される
• テーマの外観がオリジナルと一致する

すべてがチェックアウトしたら、hostsファイルに追加した行を削除します。次に、DNS更新の準備が整いました。

ステップ8：DNSを更新して公開する

ドメインのAレコードを新しいサーバーのIPアドレスに向けます。これをどこで行うかは、ドメインのネームサーバーがどこに向けられているかによって異なります。ドメインレジストラまたはホスティングプロバイダーのDNSマネージャーのいずれかです。

ログインし、ドメインのAレコードを見つけて、IPを更新します。

DNSの伝播には、レジストラやドメインのTTL（有効期間）設定によって、数分から48時間かかります。その間、一部の訪問者は古いサーバーに、一部の訪問者は新しいサーバーにアクセスします。これは正常なことであり、何か問題が発生した兆候ではありません。

DNSを更新した後、古いサーバーを少なくとも24〜48時間稼働させておいてください。伝播中にシャットダウンすると、一部の訪問者が何も表示されないページにたどり着く可能性があります。

伝播が完了したと確信したら、新しいサーバーで最後のキャッシュフラッシュを実行してください。

wp cache flush

ステップ9：wp duplicator cleanupでクリーンアップする

新しいサーバーが稼働しており、安定していることを確認したら、古いサーバーに戻って以下を実行してください。

wp duplicator cleanup

これにより、ステップ1のビルドプロセス中にDuplicatorが作成したバックアップファイルや一時データが削除されます。古いサーバーを整理し、廃止する前に移行の痕跡をすべてクリアします。

移行が完了したと確信した後にのみ実行してください。バックアップファイルがなくなると、ステップ1の災害復旧オプションも失われます。

バックアップを長期アーカイブとして保持したい場合は、クリーンアップを実行する前にリモートストレージに移動してください。

一般的なWP-CLI移行エラーのトラブルシューティング

慎重な移行でも問題が発生することがあります。ここでは、最も一般的な障害点、その状況、および修正方法について説明します。

インポート後の「データベース接続確立エラー」

表示される内容：インポート直後に、新しいサーバーでWordPressに白い画面または「データベース接続確立エラー」メッセージが表示されます。

原因：wp-config.phpに古いサーバーのデータベース認証情報がまだ含まれています。これはWP-CLI移行で最もよくある間違いであり、設定を更新する前にファイルを転送した場合、見落としやすいです。

修正方法：新しいサーバーでwp-config.phpを開き、DB_NAME、DB_USER、DB_PASSWORD、DB_HOSTを新しいサーバーのデータベースに合わせて更新します。ファイルを保存してサイトをリロードします。

移行後のテーマ設定、ウィジェット、またはプラグインオプションのリセット

表示される内容：サイトは読み込まれますが、テーマが正しく表示されない、ウィジェットが欠落している、またはプラグイン設定がデフォルトに戻っています。エラーメッセージはどこにも表示されません。

原因：--preciseフラグなしでwp search-replaceを実行しました。URLの置換によりデータベース内のシリアライズされたデータが破損し、WordPressは破損した値をサイレントに破棄しました。

修正方法：--preciseおよび--all-tablesフラグを使用してsearch-replaceを再実行します。

wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables --precise

データがすでにひどく破損しており、search-replaceの再実行で設定が復元されない場合は、ステップ1で作成したDuplicatorバックアップを復元し、移行を再度実行してください。

新しいサーバーでの「wp: command not found」

表示される内容：新しいサーバーでWP-CLIコマンドを実行すると、wp: command not foundまたはcommand not found: wpというエラーが返されます。

原因：WP-CLIが新しいサーバーにインストールされていないか、インストールされているがPATHに含まれていません。

修正方法：新しいサーバーにWP-CLIをインストールします。ホスト上でファイルを実行可能にする権限がない場合は、wpの代わりにphp wp-cli.pharを使用してコマンドを実行できます。

rsync が「Permission denied」で終了する

表示される内容：rsync は実行されますが、特定のファイルまたはディレクトリに対する1つ以上の「Permission denied」エラーで早期に終了します。

発生原因：SSHキーが宛先サーバー用に正しく設定されていないか、2つのサーバー間でファイルの所有権の不一致があります。

修正方法：まずssh user@newserverでSSHキーアクセスを確認します。それが失敗した場合は、rsyncを再試行する前にキー認証を解決してください。接続は機能するが特定のファイルが拒否される場合は、ホストが使用するWebユーザー（Ubuntuでは通常www-data、cPanelホストではアカウントのユーザー名）に一致するように、新しいサーバー上の転送済みファイルのchownが必要になる場合があります。

サイトは読み込まれるが画像が表示されない

表示される内容：ページは正しく読み込まれますが、サイト全体で画像が壊れた画像アイコンとして表示されます。

発生原因：wp-content/uploadsフォルダが完全に転送されなかったか、投稿コンテンツ内のハードコーディングされた画像URLがsearch-replaceで見逃されたかのどちらかです。

修正方法：転送されなかったファイルをキャッチするために、uploadsフォルダのみを対象にrsyncを再実行します。

rsync -avz --progress /path/to/old-wordpress/wp-content/uploads/ user@newserver:/path/to/new-wordpress/wp-content/uploads/

次に、画像URLが古いドメインを参照していないか確認するために--dry-runでsearch-replaceを再実行します。

何も機能しない：復元して最初からやり直す

サイトが完全に壊れていて、明確な原因を特定できない場合は、中途半端に移行された状態のデバッグに何時間も費やさないでください。ステップ1で作成したDuplicator Proバックアップを復元してください。

Duplicatorの災害復旧URLは、WordPressがロックアウトされている場合でも、古いサイトを元に戻すことができます。

クリーンで正常に動作する状態に戻ったら、手順をゆっくりとやり直してください。何かをコミットする前にrsyncとwp search-replaceで–dry-runを使用し、インポートを実行する前にwp-config.phpの認証情報を再確認してください。

よくある質問（FAQ）

サイトは新しいサーバーにあります。次に確認すべきことはこちらです。

データベースをエクスポートし、ファイルを転送し、wp-config.phpを更新し、インポートし、検索と置換を実行し、新しいサーバーですべてを確認し、DNSを切り替えました。これが完全な移行です。

最初の48時間は注意する価値があります。DNSの伝播により、その間も一部の訪問者は古いサーバーにアクセスするため、まだ廃止しないでください。

キャッシュレイヤーが古いコンテンツを提供していないか確認してください。伝播が確認されたら、新しいサーバーでキャッシュを完全にフラッシュすると10秒で完了し、多くの表示の問題を排除できます。

伝播が完了した後も問題が残っている場合は、何も変更する前に診断ツールとしてwp search-replace --dry-runを使用してください。

wp search-replace 'https://olddomain.com' 'https://newdomain.com' --all-tables --precise --dry-run

これにより、変更を加えることなく、古いドメインをまだ含んでいるテーブルが表示されます。検索と置換のミスなのか、テーマファイルにハードコードされているのかを確認する最も速い方法です。

カスタムテーマファイルのハードコードされたURLは、検索と置換ではまったく検出されません。テーマコード内で手動で見つけて更新する必要があります。

Duplicator Proを使用して自信を持って移行する

バックアップなしの移行はギャンブルです。サーバーは予期せぬ動作をしたり、インポートが中断されたり、シリアライズされたデータが検索と置換で常にきれいに処理されるとは限りません。

開始前に復元ポイントがあるということは、これらの状況のいずれも深刻な問題ではなく、軽微な遅延で済むということです。

Duplicator Proは、ターミナルから単一のコマンドwp duplicator buildでバックアップを作成します。そして、何か問題が発生した場合でも、災害復旧URLにより、WordPressが完全にロックアウトされていても元のサイトに戻すことができます。

150万以上のWordPressのプロフェッショナルがDuplicator Proを使用してサイトのバックアップ、移行、クローンを作成しています。あなたも参加しましょう！

このチュートリアルがお役に立った場合は、これらのガイドもブックマークする価値があります。

• WordPressウェブサイトを新しいホストに移動する方法
• 移行後にWordPressにログインできない理由
• DNS移行を正しく行う：最も一般的な間違いを回避する方法
• 移行後のWordPressテストチェックリスト完全版
• ウェブサイト移行前にコンテンツを監査する方法
• WordPressサイトを無料で移行する方法