【エラー対応あり】WordPressサーバー移設・移転方法【プラグインなしで全てのデータを移動、マルチサイトも対応】

2021-04-13
2021-04-14
wordpress
環境構築

この記事では、作業中発生しやすいエラーの解説も行いながら、Wordpressの引っ越し（サーバー移設・移転）の方法を解説します。

プラグインを利用しない方法となり、マルチサイトの移設にも対応します。

WordPressのコンテンツ以外の主な変更点は：

サーバーのOSをCentOSからUbuntuへ
WebサーバーをApacheからNginxへ

の２点です。

今回のWordpressサーバー移設に利用するOS、ミドルウェア等は以下のとおりです。

サーバーOS：CentOS 7.6
Webサーバー：Apache/2.4.6
PHP：7.1.31
Mysql：Ver 15.1 Distrib 5.5.60-MariaDB
Wordpress：5.7
SSL(HTTPS): Let’s encrypt※マルチサイト化（２サイト）

サーバーOS：Ubuntu 20.04.2 LTS
Webサーバー：nginx/1.18.0
PHP：7.4
Mysql：mysql Ver 15.1 Distrib 10.3.25-MariaDB

各種バーション確認コマンドは以下のとおりです

//OSの種類とバージョン

$ grep -H "" /etc/*version ; grep -H "" /etc/*release

//Apacheのバージョン確認

$ httpd -v

//Nginxのバージョン確認

$ nginx -v

//PHPのバージョン確認

$ php -v

//mysqlのバージョン確認

$ mysql --version

＊マルチサイトの移設を例に解説していますが、シングルサイト（マルチサイト化していない）でも、基本同じ方法となります。

シングルサイトの移設を行う場合、目次の「【STEP-6】マルチサイトの表示対応」をとばして作業してください。

1 【STEP-1】移設元サーバーのデータ取得（バックアップ）
- 1.1 WordPressのデータの取得
- 1.2 データベースのデータの取得
2 【STEP-2】移設先サーバーの環境構築
- 2.1 移転先サーバーへのOSインストールと初期設定
- 2.2 WordPressをインストールするためのミドルウェア等のインストールと初期設定
3 【STEP-3】移設先サーバーへのデータ移行（データベース）
4 【STEP-4】移設先サーバーへのデータ移行（Wordpressデータ）
- 4.1 移転先サーバーへのWordpressデータのアップロード
5 【STEP-5】ネームサーバーの変更
- 5.1 ローカル環境で動作、表示の確認
- 5.2 移設先サーバーでのHTTPS化
6 【STEP-6】マルチサイトの表示対応
7 【STEP-7】ネームサーバーの変更、最終確認

スポンサードリンク

【STEP-1】移設元サーバーのデータ取得（バックアップ）

まず、移設元のデータを取得します。

よく、wordpressのアップデートを行う時などに、「データのバックアップを行ってください」と言われますが、このような時に行うバックアップのとり方と同様です。

取得するデータは

WordPressのデータ(“wp-“で始まるファイル・フォルダ)
データベースのデータ

の２種類となります。

WordPressのデータの取得

移設元のサーバーからデータを取得するには、FTPソフトを利用すると便利です。

今回は、Macを利用して作業するためFilezillaを利用します。

移設元のサーバーに接続したら、ドメインルート以下のファイル、フォルダをダウンロードし、ローカル環境に取得します。

私の環境の場合、ドメインルートへのパスは以下のとおりです。

/var/www/html

以下の範囲のファイル、フォルダをダウンロードします。

データベースのデータの取得

データベースの取得には、phpMyAdmin を利用し、対象の管理ページへアクセスします。

デフォルトでは、サイトURL/phpMyAdmin（https://sample.com/phpMyAdmin/ ）などですが、セキュリティ対策でphpMyAdminの部分を変更する場合もあるので、それぞれの環境に合わせアクセスします。

ユーザー名や、パスワードをお忘れの方は、先程ダウンロードしたwordpressのデータの中のwp-config.php を開くと以下のような情報が記載されているので、そちらを参考にします。

define('DB_NAME', 'wordpress');

define('DB_USER', 'root');

define('DB_PASSWORD', 'password');

define('DB_HOST', 'localhost');

ログインし管理ページにアクセスしたら、①左のメニュー欄より移設元のデータベースを選択し、②エクスポートを選択します。

エクスポート方法がデフォルトでは、「簡易-最小限のオプションだけ表示」になっているので「詳細-可能なオプションをすべて表示」を選択し、設定を変更します。

↓↓↓

生成オプションの設定変更

追加コマンド：内の「DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT / TRIGGER　コマンドを追加する」にチェックを加えます。

スポンサードリンク

データ作成オプション

作成するクエリの最大長を［1000］に変更します。

以上のように、設定を変更したら［実行］をクリックしてデータをダウンロードします。

対象のデータベース名.sql(wordpress.sql等)のファイルがダウンロードされます。

これで移設元のデータの準備は完了です。

【STEP-2】移設先サーバーの環境構築

移設先サーバーの環境構築の手順としては、大きく以下のようになります。

VPSサーバーなど移転先サーバーへのOSインストールと初期設定（セキュリティー対策）
WordPressをインストールするためのミドルウェア等のインストールと初期設定

移転先サーバーへのOSインストールと初期設定

今回はさくらのVPS サーバーを利用し、OSとしUbuntuを利用する方法とします。

＊エックスサーバーのWordpress専用クラウド型レンタルサーバーwpX Speed は設定が簡単で、表示速度が早い特徴がありますが、利用するリモートサーバーへのSSH接続ができないため、今回は利用していません。

OSのインストール及び、インストール後のセキュリティーの対策についてはこちらの記事を参考にしてください。

・【Ubuntu20.04】VNCコンソールでの初期設定（ユーザーネーム、パスワード、パーティション）
・サーバーセキュリティー対策【秘密鍵を用いたSSHログイン設定(ubuntu,mac)】

WordPressをインストールするためのミドルウェア等のインストールと初期設定

今回は、PHP、Nginx、MariaDBを利用する方法とします。

ミドルウェア等のインストールと初期設定についてはこちらの記事を参考にしてください。

・【wordpressの環境構築】Ubuntu20.04,Nginx,PHP7.4,MariaDB

注意）サーバー移設の際は、移設元のデータにwordpressも含まれているため、上記の記事で紹介しているwordpressのインストールをする必要はありません。対象の箇所（wordpressのダウンロード以降）をとばして設定を行ってください。

【STEP-3】移設先サーバーへのデータ移行（データベース）

移設先サーバーへのデータ移行する手順は、以下のようになります。

移設先サーバーのデータベースに移設元で取得したデータベースデータのインポート
移設先サーバーに移設元で取得したWordpressデータをアップロード

移設先サーバーでデータベースデータのインポート

phpMyAdminのインストール

データのインポートをphpMyAdminを利用して行うために、まずはphpMyAdminのインストールを行います。

$ sudo apt install phpmyadmin

インストール作業の中でコンソール画面が以下のような表示になりますので、必要な情報を設定し進めます。

チェックは入れず［OK］を選択

［Yes］を選択

パスワードを入力して［OK］を選択

確認用のパスワードを入力して［OK］を選択

phpMyAdminのインストール後の初期設定

移設先のIPアドレス（設定予定のドメイン）を利用してphpMyAdminのページへアクセスできるように、下記の設定を行います。

phpMyAdminファイルのシンボリックリンクの作成

$ sudo ln -s /usr/share/phpmyadmin /var/www/html/phpmyadmin

ファイル権限の設定

$ sudo chmod 775 -R /usr/share/phpmyadmin/

ファイル所有者の設定

$ sudo chown www-data:username -R /usr/share/phpmyadmin/

wordpressコンフィグファイルの作成

NGINXの場合、/etc/nginx/sites-available/ こちらのディレクトリにdefault ファイルがありますが、今回はwordpress用にコンフィグファイルを作成します。

sudo vim /etc/nginx/sites-available/wordpress.conf

ファイル作成後は、以下のように編集します。

server {

listen 80;

listen [::]:80;

root /var/www/html;

index index.php index.html index.htm;

server_name xxx.xxx.xxx.xxx(ipアドレス) sample.com www.sample.com;

client_max_body_size 100M;

autoindex off;

location / {

try_files $uri $uri/ /index.php?$args;

}

location ~ \.php$ {

include snippets/fastcgi-php.conf;

fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;

fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

include fastcgi_params;

}

ファイル作成後はsites-enabled ディレクトリにシンボリックリンクを作成します。

$ sudo ln -s /etc/nginx/sites-available/wordpress.conf /etc/nginx/sites-enabled/

NGINXの設定ファイルの削除

$ sudo rm /etc/nginx/sites-available/default

$ sudo rm /etc/nginx/sites-enabled/default

NGINXの再起動

$ sudo systemctl restart nginx

コンフィグファイルの確認

以下のコマンドで、編集したコンフィグファイルの内容を確認します。

$ sudo nginx -t

以下のように表示されれば確認OKです。（エラーが表示される場合はメッセージ内容を参考に修正します）

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

phpMyAdminの動作確認

ブラウザにhttp://サーバーのIPアドレス/phpmyadmin/ を入力します。

こちらのログイン画面が表示されればOKです。

この記事で紹介しているデータベースの設定では、rootでのログインはできない設定なので、登録したユーザー名でログインします。

ログイン後画面を確認すると、作成したデータベースが表示されていません

これは、rootでログインしていなく、表示の権限がないためです。

登録したユーザーに権限を与えて、表示や編集を行えるようにします。

ユーザーに権限を付与するため、rootでログイン

$ sudo mysql -u root -p

以下のコマンドでユーザーに権限を与えます。

> GRANT ALL PRIVILEGES ON *.* TO 'username'@'localhost' WITH GRANT OPTION;

設定の変更を保存し、データベースを抜けます。

> FLUSH PRIVILEGES;

> EXIT;

もう一度、登録したユーザーでログインすると、すでに作成したデータベースを確認する事ができます。

データベースデータのインポート

移設先サーバーでphpmyadminが利用できるようになったので、移設元で取得したデータを移設先へインポートさせます。

移設先サーバーにてphpmyadminを開きます。

左側メニューから、作成したデータベースを選択します。

上部のメニューから［インポート］を選択します。

次にアップロードするファイルに移設元でエクスポートしたファイルを選択します。

［実行］を選択し、インポートを完了させます。

以下のように表示されればインポートの完了です。

エラーが発生する場合の対処

発生しやすいエラーとして、データベース内のデータ容量が大きすぎるケースがあります。

インポートの実行を行うと以下のような表示になります。

こちらのエラーに対応するために、アップロードできるデータの上限を上げる作業を行います。

php-fpmの設定

$ sudo vim /etc/php/7.4/fpm/pool.d/www.conf

ファイル最後の行に以下の内容を追加して編集します。

;php_admin_value[memory_limit] = 32M

php_admin_value[upload_max_filesize] = 32M

php_admin_value[post_max_size] = 32M

編集後後は、nginxとphp-fpmを再起動しもう一度インポートを試します。

$ sudo systemctl restart nginx

sudo systemctl restart php7.4-fpm.service

【STEP-4】移設先サーバーへのデータ移行（Wordpressデータ）

移転先サーバーへのWordpressデータのアップロード

wp-config.phpの編集

wordpressのデータをアップロードする際に移設先で新規に作成したデータベースの情報と、移設元から取得したデータベースの情報を共通のものにする必要があるので、確認及び編集を行います。

すでにダウンロードしているwp-config.phpを確認し、移設先のデータベース情報に共通させます。

define('DB_NAME', 'wordpressdb');

define('DB_USER', 'username');

define('DB_PASSWORD', 'password');

define('DB_HOST', 'localhost');

WordPressデータのアップロード

FTPソフトを利用してデータのアップロードを行います。

データの設置場所は、今回は/var/www/html としています。

権限エラーが出る場合

以下のコマンドで権限の設定を変更します。

$ sudo chown -R username /var/www/html

$ sudo chmod -R 755 /var/www/html

$ sudo systemctl restart nginx

データのアップロードが終わった後は、/var/www/htmlの権限をwww-data にします(所有者が管理ユーザーのままだた、画像のアップロード等の時エラーとなります)。

$ sudo chown -R www-data:www-data /var/www/html

$ sudo chmod -R 755 /var/www/html

$ sudo systemctl restart nginx

【STEP-5】ネームサーバーの変更

データベース、Wordpressのデータの移設が完了しましたら、ネームサーバーを変更し、移設先のサーバーで利用していたドメインを利用できるよう編集します。

ローカル環境で動作、表示の確認

移設先の本番環境のネームサーバーを変更する前に、ローカルの環境で移設先での動作、表示が正しく行われるか確認します。

今回はMacのhostsファイルを使用する方法で確認します。

Macの場合、hostsファイルは以下のディレクトリにあります。

/etc/hosts/

以下のように、移設先の「IPアドレス］［スペース］［ドメイン名］を加え編集します。

xxx.xxx.xxx.xxx sample.com

ファイルを編集したら、ブラウザで動作・表示の確認をします。

この際HTTPS化した状態では、アクセスできないので、http://sample.com というように入力し確認します。

通常通りに表示され、画面遷移、新規の投稿、問い合わせ機能等が問題なく動作する事を確認します。

リダイレクトされて確認できない場合

表示の確認のために、移設先サーバーのIPアドレスをURL欄に入力する場合や、上記のhostsファイルの設定をして表示を確かめる際に、矯正的にリダイレクトされて確認できない場合があります。

よく起こるパターンとして、http でアクセスしてもhttps のドメインへリダイレクトされる事があります。

多くの場合、移設元データベースのwp_options でsiteurl と、home が移設前のまま（httpsで指定）されているので、phpmyadminにログインして編集します。

移設前と移設後でドメインを変更する場合も同様に対応します。

上記の方法でもリダイレクトされて表示の確認が行えない場合は、wp-config.php 内を確認します。

下記のような表示があり、指定が違っている場合は修正、編集を行います。

define('WP_SITEURL', 'https://sample.com');

移設先サーバーでのHTTPS化

この段階でネームサーバーを変更しても、HTTPでの接続にしか対応していませんので、移設先のサーバーへHTTPS化の対応を行います。

移設元のletsencryptディレクトリの取得

letsencryptディレクトリは/etc/letsencrypt となります。

FTPソフトでダウンロードするために、所有者と権限を変更します。

sudoをつけるか、root権限で作業

$ sudo chown -R username:username /etc/letsencrypt

$ sudo chmod -R 755 letsencrypt

FTPソフトでダウンロード

移設先へのletsencryptディレクトリのアップロード

今度は、ダウンロードと反対の作業を行います。

さきほどダウンロードしたletsencryptディレクトリを、移設先の/etcにアップロードします。

etcディレクトリの所有者変更（root → usernameへ）

$ sudo chown -R username:username /etc

FTPソフトでアップロード

etcディレクトリの所有者変更（username → rootへ）（元の所有者設定に戻す）

$ sudo chown -R root:root /etc

FTPソフトでletsencryptディレクトリをダウンロードする際や、ダウンロード後にディレクトリの所有者を変更する際に、以下のようなエラーになりsudoコマンドが使えなくなった場合は以下の方法で対応します。

username is not in the sudoers file. This incident will be reported.

もともとはsudo可能なユーザー一覧に登録されていたユーザーなのに、そのリストからはずされてしまいこのようなエラーとなります。
root権限になって作業したくても、sudoコマンドが使えないので、ユーザー権限を変える事ができません。

またすでに、rootでのログインは禁止しているので、ログインし直す方法もつかえません。

そのため、VPSサーバーのコントロールパネル等のコンソール等で作業をします。
この場合、ユーザー名：root、パスワード：でrootの権限の状態（#）でログインできます。

# usermod -aG wheel username

これで、sudoコマンドが利用できます。

letsencryptディレクトリの所有者、権限の変更（権限設定に戻す）

$ sudo chmod -R 700 /etc/letsencrypt/live

$ sudo chmod -R 700 /etc/letsencrypt/keys

$ sudo chmod -R 700 /etc/letsencrypt/archive

$ sudo chmod -R 700 /etc/letsencrypt/accounts

$ sudo chmod -R 755 /etc/letsencrypt/renewal-hooks

$ sudo chmod -R 755 /etc/letsencrypt/renewal

再起動

$ sudo systemctl restart nginx

sudo: /etc/sudoers.d is owned by uid 1000, should be 0

権限の変更後にsudoが利用できなくなった場合は、こちらの方法を参考に対応してください。
https://arch.jpn.org/archives/586
https://askubuntu.com/questions/513523/sudo-doesnt-work-etc-sudoers-is-owned-by-uid-1000-should-be-0

再起動

$ sudo systemctl restart nginx

移設先にcertbotのインストール

sudo apt install certbot

SSL証明書を参照できているか下記のコマンドを実施

sudo certbot certificates

下記のような表示になれば、参照されています。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Found the following certs:

Certificate Name: sample.com

Domains: tomato-love.com

Expiry Date: 2021-06-30 17:07:14+00:00 (VALID: 81 days)

Certificate Path: /etc/letsencrypt/live/sample.com/fullchain.pem

Private Key Path: /etc/letsencrypt/live/sample-love.com/privkey.pem

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

下記のような内容でエラ−がでる場合は、/etc/letsencrypt/archive/sample.com/ 内のファイルがシンボリックリンクではなく、実態ファイルとしてアップロードされている事があります。

expected /etc/letsencrypt/live/sample.com/cert.pem はシンボリックリンクになっている事が必要という内容

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Renewal configuration file /etc/letsencrypt/renewal/sample.com.conf produced an unexpected error: expected /etc/letsencrypt/live/sample.com/cert.pem to be a symlink. Skipping.

/etc/letsencrypt/live/sample.com/ 内のファイルをシンボリックリンクに変更します。

まずは、ディレクトリ内のファイルを上書きできるように全て削除します。

# rm /etc/letsencrypt/live/sample.com/*

/etc/letsencrypt/liveファイルの権限を変更します。

# chmod -R 777 /etc/letsencrypt/live

移設元のサーバにアクセスし、/etc/letsencrypt/liveファイルの内容を確認します。

$ cd /etc/letsencrypt/live/sample.com

la -l コマンドを行います。

例えば以下のような内容の場合：

lrwxrwxrwx 1 root root 40 Apr 2 03:07 cert.pem -> ../../archive/sample.com/cert12.pem

lrwxrwxrwx 1 root root 41 Apr 2 03:07 chain.pem -> ../../archive/sample.com/chain12.pem

lrwxrwxrwx 1 root root 45 Apr 2 03:07 fullchain.pem -> ../../archive/sample.com/fullchain12.pem

lrwxrwxrwx 1 root root 43 Apr 2 03:07 privkey.pem -> ../../archive/sample.com/privkey12.pem

# ln -s ../../archive/sample.com/chain12.pem chain.pem

chain12.pem というように数字を合わせる必要があります。

live ディレクトリ内のファイルから、移設前と同じシンボリックリンクにします

ディレクトリの移動

cd /etc/letsencrypt/live/sample.com

ln -s ../../archive/sample.com/cert12.pem cert.pem

ln -s ../../archive/sample.com/chain12.pem chain.pem

ln -s ../../archive/sample.com/fullchain12.pem fullchain.pem

ln -s ../../archive/sample.com/privkey12.pem privkey.pem

再起動

$ sudo systemctl restart nginx

エントリーファイルの編集

$ sudo vim /etc/nginx/sites-available/wordpress.conf

wordpress.confを以下のように編集します。

# http wwwなしからのリダイレクト

server {

listen 80;

listen [::]:80;

server_name mydomainname.com;

return 301 https://$host$request_uri;

}

# http https wwwありからのリダイレクト

server {

listen 80;

listen 443 ssl;

server_name www.mydomainname.com;

ssl_certificate /etc/letsencrypt/live/mydomainname.com/fullchain.pem;

ssl_certificate_key /etc/letsencrypt/live/mydomainname.com/privkey.pem;

return 301 https://mydomainname.com$request_uri;

}

# リダイレクトを流される側の設定

server {

listen 443 ssl default_server;

server_name mydomainname.com;

ssl on;

ssl_certificate /etc/letsencrypt/live/mydomainname.com/fullchain.pem;

ssl_certificate_key /etc/letsencrypt/live/mydomainname.com/privkey.pem;

root /var/www/html;

index index.html index.htm index.nginx-debian.html index.php;

location / {

try_files $uri $uri/ /index.php?args;

}

location ~ \.php$ {

include snippets/fastcgi-php.conf;

fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;

}

すでにあるシンボリックリンクの削除

$ sudo rm /etc/nginx/sites-enabled/wordpress.conf

編集後のシンボリックリンクの作成

$ sudo ln -s /etc/nginx/sites-available/wordpress.conf /etc/nginx/sites-enabled/

再起動

$ sudo systemctl restart nginx

コンフィグファイルの確認

$ sudo nginx -t

証明書更新の自動化

証明書が参照されれている事が確認できたので、更新の自動化を行います。

crontabの編集

$ sudo crontab -e

下記のような表示が出たら、お好みのエディターの形式を選択。

no crontab for root - using an empty one

Select an editor. To change later, run 'select-editor'.

1. /bin/nano <---- easiest

2. /usr/bin/vim.basic

3. /usr/bin/vim.tiny

4. /bin/ed

Choose 1-4 [1]:

ファイル内に下記の内容を追加
＊この場合は、毎月1日5時にnginxの停止、letsencrypt証明書の更新、nginnxの開始を行う

00 05 01 * * sudo systemctl stop nginx; sudo letsencrypt renew; sudo systemctl start nginx

nginxの最起動

$ sudo service nginx restart

【STEP-6】マルチサイトの表示対応

※シングルサイトで移設を行っている場合は、こちらのSTEP−６はとばしてください。

移設先のWebサーバーはNginxとなるため、マルチサイト機能の各サイト間の遷移等の動作は、Nginxのエントリーファイルで設定する必要があります。

現在のエントリーファイルに以下のコードを追加します

　# wordpress parmanet settings

try_files $uri $uri/ /index.php?$args;

# add / to end

rewrite /wp-admin$ $scheme://$host$uri/ permanent;

# Pass uploaded files to wp-includes/ms-files.php

rewrite /files/$ /index.php last;

# Rewrite multisite '.../wp-.*' and '.../*.php'.

if (!-e $request_filename) {

rewrite ^/[_0-9a-zA-Z-]+(/wp-.*) $1 last;

rewrite ^/[_0-9a-zA-Z-]+.*(/wp-admin/.*\.php)$ $1 last;

rewrite ^/[_0-9a-zA-Z-]+(/.*\.php)$ $1 last;

}

エントリーファイルの編集

$ sudo vim /etc/nginx/sites-available/wordpress.conf

wordpress.confを以下のように編集します。

# http wwwなしからのリダイレクト

server {

listen 80;

listen [::]:80;

server_name mydomainname.com;

return 301 https://$host$request_uri;

}

# http https wwwありからのリダイレクト

server {

listen 80;

listen 443 ssl;

server_name www.mydomainname.com;

ssl_certificate /etc/letsencrypt/live/mydomainname.com/fullchain.pem;

ssl_certificate_key /etc/letsencrypt/live/mydomainname.com/privkey.pem;

return 301 https://mydomainname.com$request_uri;

}

# リダイレクトを流される側の設定

server {

listen 443 ssl default_server;

server_name mydomainname.com;

ssl on;

ssl_certificate /etc/letsencrypt/live/mydomainname.com/fullchain.pem;

ssl_certificate_key /etc/letsencrypt/live/mydomainname.com/privkey.pem;

root /var/www/html;

index index.html index.htm index.nginx-debian.html index.php;

location / {

try_files $uri $uri/ /index.php?args;

}

location ~ \.php$ {

include snippets/fastcgi-php.conf;

fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;

}

# wordpress parmanet settings

try_files $uri $uri/ /index.php?$args;

# add / to end

rewrite /wp-admin$ $scheme://$host$uri/ permanent;

# Pass uploaded files to wp-includes/ms-files.php

rewrite /files/$ /index.php last;

# Rewrite multisite '.../wp-.*' and '.../*.php'.

if (!-e $request_filename) {

rewrite ^/[_0-9a-zA-Z-]+(/wp-.*) $1 last;

rewrite ^/[_0-9a-zA-Z-]+.*(/wp-admin/.*\.php)$ $1 last;

rewrite ^/[_0-9a-zA-Z-]+(/.*\.php)$ $1 last;

}

すでにあるシンボリックリンクの削除

$ sudo rm /etc/nginx/sites-enabled/wordpress.conf

編集後のシンボリックリンクの作成

$ sudo ln -s /etc/nginx/sites-available/wordpress.conf /etc/nginx/sites-enabled/

再起動

$ sudo systemctl restart nginx

コンフィグファイルの確認

$ sudo nginx -t

＊SSL化の設定をした後にコンフィグファイルの確認をし、確認は問題なく行われるが以下の警告メッセージ表示が表示される場合

nginx: [warn] the "ssl" directive is deprecated, use the "listen ... ssl" directive instead in /etc/nginx/sites-enabled/wordpress.conf:25

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

ssl on; をコメントアウトします。

listen 443 ssl default_server;

server_name sample.com;

ssl on;

↓↓↓

listen 443 ssl default_server;

server_name sample.com;

#ssl on;

【STEP-7】ネームサーバーの変更、最終確認

最終的にネームサーバーの変更を行う前に、もう一度ローカルのPC（macの場合は/etc/hostsファイルの利用）で、HTTPS化での動作、表示を確かめます。

アクセスした際に、以下のようにApacheのindex.htmlが表示される場合

どちらかの方法で対応します。

デフォルトで設置されているhtmlファイルの削除
Nginxエントリーファイルのindexの編集

デフォルトで設置されているhtmlファイルの削除

ルートディレクトリから、index.html を削除します。

ついでに、index.nginx-debian.html も削除します。

$ cd /var/www/html

$ rm index.html

$ rm index.nginx-debian.html

Nginxエントリーファイルのindexの編集

wordpress.conf内のindexを編集して、php.indexを優先的に利用するようにします。

index index.html index.htm index.nginx-debian.html index.php;

↓↓↓

index index.php index.html index.htm index.nginx-debian.html;

移設元どおりに表示が確認され、各ページへの遷移や問い合わせページの機能が通常どおり動くようであれば、ネームサーバーを変更します。

最後に移設元のサーバーを停止し、最終の表示、動作確認ができればOKです。

お疲れ様でした。

以上、プラグインなしで全てのデータを移動（マルチサイトも対応）するWordpressのサーバー移設・移転の方法を解説しました。

作業時間が無い場合や、作業中にエラーや表示の不具合が発生し、解決できない場合は専門の業者のWordPressサーバー移転代行「サイト引っ越し屋さん」や、ココナラ等のスキルマーケット内のサービスに作業を依頼するのも良いかもしれません。

サイト引っ越し屋さんの場合30,000円前後、ココナラの場合5,000〜10,000円が作業依頼の相場とみて良いと思います。