WordPressの引っ越し。サブドメイン型、サブディレクトリ型ドメインからの移転・変更

投稿者: | 2016/12/31
0件のコメント

「サーバー構築。WordPressを Ubuntu 16.04、Apache、PHP7.0、MySQL環境にインストール」の続編です。

サイト移転（ドメイン取得移転）のきっかけは、使っている OS（ubuntu 12.04 LTS）のサポート期限が 2017年4月でもうすぐ切れるから。理由はもう一つあって、ルーターを入れ替える計画を立てていて、元サイトので使っていたドメインが、YAMAHA製ルーターを使っている限り無償であったネットボランチDNSサービスを利用していたため。

ただし、リニュアルと言っても、サイトの見た目や中身は変わらず、、

元のサイトと移転先サイトのサーバー仕様

新たなサーバー機は、予備に買っておいたマザーボード Gigabyte J1900N-D3Vを使った自作PC。同じGigabyteの C1007UN-Eからの変更である。ケースは ANTECの ISK100から、これも同じく ANTECの ISK110-VISAへ。厳密に言えば若干ながら CPU性能は低下。ただ、Webサーバーとして動作させる分には、速度差を体感できる程の差は無い。そもそもアクセスが無い。

元のサイトのドメインは、サブディレクトリ型であり、サブドメイン型でもある。

元のサイトと移転先サイトの仕様
元のサイト 移転先サイト
サーバ設置場所 自宅の居間
ハードウエア Gigabyte C1007UN-E Gigabyte J1900N-D3V
ドメイン名 rarak.aa0.netvolante.jp rarak.jp
サイトURL http://rarak.aa0.netvolante.jp/blog/ https://rarak.jp/
OS ubuntu12.04 ubuntu16.04
webサーバー Apache2.2 Apache2.4
データベース MySQL5.5 MySQL5.7
スクリプト言語 PHP 5.3 PHP 7.0

調べてみてビックリ。公式セキュリティサポートの期限が切れているアプリケーションモジュールがちらほら（汗

OSベンダー（ubuntuやCentOSなど）によりセキュリティ修正が引き続き行われているとは言え、apt-getに任せっきりはやはり良くないなと、あらためて思ってみたり。

しかし、だからと言って、アプリケーション・ミドルウエアを闇雲にアップデートするのはこの上なく危険で、思わぬエラーを吐いたり、動作しなくなることは稀に良くある。そしてその復旧作業は煩雑極まりなく、せっかくの休日が平気で 1～2日潰れる。場合によっては週を跨ぐことも、、

人柱たる先人様達に感謝

移転作業前のサーバー設定

移転作業開始前に移転先サーバーで次の作業を完了させる。

  • LinuxOS（ubuntu）をインストールし、ネットワークなどの基本設定を終了させる。
  • Apacheをインストール。
  • Apacheのドキュメントルート等を正しく設定。
  • PHP、MySQL（もしくは MariaDB）をインストールし、Apacheとの連携接続を確認。

上のサーバー設定は以下の記事（当サイト内）が参考になるかもしれません

移転作業の手順

wordpressドメイン移転の手順大まかに次の5つのステップで移転作業をすすめる。

データベース内のドメイン名データの置換には、強力なツールが準備されているので、是非これを利用したい。

ちなみに、wordpressフォルダのコピーと、データベースのエクスポートは、そのまま WordPressのバックアップとなるので、覚えておくと損しない。ネイティブな方法なのでプラグインを使うより余程信頼性が高い。

Step.1　WordPressフォルダのコピー

♦元のサイトのwordpresフォルダーを移転先サイトのドキュメントルートへ丸ごとコピー。

Step.2　データベースのエクスポートとインポート

♦元のサイトのMySQLデータベース内の wordpress全体のデータをエクスポートする。

♦エクスポートされたファイルを使い、移転先のMySQLデータベースへインポートする。

Step.3　MySQLデータベース内ドメイン名データの置換

♦移転先サイトのドメイン名をMySQLデータベース内のデータに反映するため、専用ツールを用い置換する。

Step.4　WordPressと MySQLの接続設定

♦移転先サイトのWordPressの[ wp-config.php ]を編集し、データベースと接続する。

Step.5　移転先サイトへ 301リダイレクト

♦元のサイトの[ .htaccess ]に 301リダイレクトを設定し、移転先サイトへ誘導する。




WordPressフォルダのコピー

wordpressフォルダーのコピーとペースト元のサイトから、どんなに悪どい手を使ってでも丸ごとコピーし、移転先サイトに、そのままペーストする。

“.”で始まる隠しファイルや、同じく”∼”で終わる隠しファイルも全てコピーする。

#元のサイトで、ドキュメントルートフォルダからストレージデバイス（メモリーカードなど）へコピー
sudo cp -a /var/www/blog/wordpress /storagedevice
#移転先サイトで、ストレージデバイスから、ドキュメントルートフォルダへコピー
sudo cp -a /storagedevice /var/www/wordpress

MySQLデータベースのエクスポート

元のサイトの MySQLデータベースサーバーから、データを拡張子.sqlファイルとしてダンプ（エクスポート）する。

対象は、MySQL内にある wordpressと言う名のデータベースで、例では backupDB.sqlと言う名のファイルとしてエクスポートしている。

mysql -u root -p
Enter password: 

mysql>show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| test               |
| wordpress          |
+--------------------+
5 rows in set (0.00 sec)
mysql>exit;

#エクスポートダンプコマンドは、mysqldump -u ユーザー名 -p データベース名 > バックアップ先となるファイルのパス
mysqldump -u root -p -x wordpress > backupDB.sql
  • 101：MySQLへ rootでログイン。パスワードを聞いてくるので思い出して！
  • 104：現在格納してあるデータベースの確認。
  • 105∼114：5つのデータベースが格納してあることがわかるが、 wordpress以外は、MySQLがデフォルトで作成したもの。
  • 118：データベース wordpressのバックアップ。HOMEフォルダに backupDB.sqlが出来上がっているはず。
mysqldumpのコマンドオプションについて

-u：-u user_name user_nameはサーバーへの接続時に使用する MySQLユーザー名。ここでは root。
-p：-p[password] passwordはMySQLサーバーに接続する際に使用するパスワード。passwordを指定しない場合は mysqldumpがそれを要求してくる。
-x：データベース内のテーブルをすべてロック。
稼働中にバックアップする際は、[-x]の代わりに [–single-transaction]を指定する。
–single-transaction：アプリケーションをブロックすることなく、START TRANSACTION が発行された時点のデータベースの一貫した状態をダンプ。（singleの前に付く「–」は「-」記号が二つ。ブラウザ等の解釈により繋がって一本の長いダッシュに見える事がある）ただし、ほかの接続でステートメントが発行されば場合、テーブルの内容を取得する SELECT が、正しくない内容を取得したり失敗したりすることがある（[–lock-tables]オプションと排他であるため）。

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

インポートも同様な構文である。こちらは、移転先のサーバーでの作業となる。インポートを実行する前に、あらかじめ格納するためのデータベースを作成しておくこと。

mysql -u root -p
Enter password:

#データベース（wordpress）を作成
mysql>create database wordpress;
mysql>create user 'ユーザー名'@'localhost' identified by 'データベースパスワード';
mysql>GRANT ALL PRIVILEGES ON wordpress.* TO 'ユーザー名'@'localhost';
mysql>FLUSH PRIVILEGES; 

#データベースの存在を確認
mysql>show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| test               |
| wordpress          |
+--------------------+
5 rows in set (0.00 sec)
mysql>exit;

#インポートも次の一行で終了
#mysqldumpではなく、mysqlコマンドであることに注意
mysql -u root -p wordpress < backupDB.sql

MySQLデータベース内のドメイン名データの置換

インポートされたデータベース内のドメイン名置換には、[WordPress Serialized PHP Search Replace Tool]を使用する。公式サイトからダウンロードし、wordpressフォルダ直下（index.phpと同じ階層）に展開する。（2016/12/30現在のバージョンは、3.1.0）かなり頻繁に画面レイアウトが変更されているので、本記事に掲載した画像と異なる可能性があるが、基本操作は同じである。

WordPress Serialized PHP Search Replace Toolの操作[ /searchreplacedb2.php ]とブラウザに入力すると次のような画面が立ち上がる。画面中の replaceと withの項目は、置換対象の文字列と、置換後の文字列である。urlだけではく、ほぼ何でも置換してくれる。例えば、wildswansを WILDSWANS。あるいは、http://を https://へなど。考えようによってはかなり便利なツールである。

  1. 元のサーバーのアドレスを入力する。
  2. 移転先のサーバーのアドレスを入力する。
  3. MySQL内のデータベース名を入力する。ここでは、wordpress。
  4. MySQLデータベースへの接続ユーザー名を入力する。
  5. MySQLデータベースへの接続パスワードを入力する。

WordPress Serialized PHP Search Replace Toolの操作項目を入力し、データベースへ接続し、上の[ dryrun ]ボタンを押すと、置換対象文字列が含まれるテーブルと、テーブル内で置換される数が表示される。dryrunは実際にテーブル内のデータを書き換える訳ではなく、あくまで試行するだけである。

WordPress Serialized PHP Search Replace Toolの操作[ cells changed ]列に表示されている赤いアンダ－ラインのリンク先へ移動すると、変更箇所に黄色いアンダーラインが引かれた実際のソースを確認できる。

WordPress Serialized PHP Search Replace Toolの操作[ live run ]ボタンを押すと実際の置換が実行される。待つこと数十秒。

忘れがちなのが、wordpressフォルダ直下に展開した[WordPress Serialized PHP Search Replace Tool]の削除。外部からこれにアクセスされると、くぁwせdrftgyふじこlp

WordPressと MySQLの接続設定

移転先の[ wp-config.php ]を編集し、MySQLのユーザー名とデータベースパスワードに合わせる。

cd /var/www/
sudo cp wordpress/wp-config-sample.php wordpress/wp-config.php
sudo vi wordpress/wp-config.php
  /** WordPress のためのデータベース名 */
  define('DB_NAME', 'wordpress');
  /** MySQL データベースのユーザー名 */
  define('DB_USER', 'ユーザー名');
  /** MySQL データベースのパスワード */
  define('DB_PASSWORD', 'データベースパスワード');

以上で、設定完了。移転先サイトhttp://*******.jp/にアクセスし、動作が確認出来るはずである。あとは、移転先のサイトの[ .htaccsess ]や各フォルダやファイルのパーミッションの修正をして終了。




元のサイトに.htaccessを設置し、移転先サイトへ 301リダイレクトしてあげる

このまま移転したサーバーを公開してしまうと、検索エンジンに重複と認識され、手痛いペナルティが果される場合がある。そのため、旧サイト[ http://rarak.aa0.netvolante.jp/blog/ ]へ訪れた方々を新サイト[ ]へ案内するためのリダイレクト設定をする。

WordPress Serialized PHP Search Replace Toolの操作元のサイトの[ wordpress ]フォルダの直下（index.phpと同じ階層）に[.htaccess ]を置き、次の行を追加する。

旧サイトから移転先のサイトへ誘導するためにリダイレクト設定すると、ほぼ一ヶ月程度で各検索サイトの urlが新サイトのそれに置換されていた。2016/12/20時点での旧サイトへのアクセスはゼロである。画像は、Search Consoleから拾ったインデックスステータスの切り替え前後の様子。

<IfModule mod_rewrite.c>
RewriteEngine on
RewriteBase /
RewriteRule ^(.*) /$1 [R=301,L]
</IfModule>

検索サイトへのドメイン変更通知は必要か？

サイト移転後、Search Console上で元のサイトのアドレス変更の通知を送信したり、同じく、Bing Web マスター ツールでサイト移転の申請を行うのが望ましい。ただ、これが困難な場合がある。今のところ Search Consoleからはサブディレクトリ型のドメイン移転通知は出来ない（サブドメイン型は通知可能）。

実際、元のサイトはサブドメイン型であり、サブディレクトリ型でもあるので、これに該当する。が、ご覧のようにサイトインデックスはしっかりと切り替わってくれている。また、検索順位もほぼそのままであった。

301リダイレクトを許可しないレンタルサーバーを利用していた場合

301リダイレクトを許可しないレンタルサーバーも存在する。これが一番厄介で、その時は、元のサイトに「rel=”canonical” リンク要素」を設定することとなる。

ドメイン移転後に元のサイトが残っていると、サーチエンジンに独自性の無い重複サイトと判断されてしまう。301リダイレクト以外でこれを防ぐ手段が「canonicalの設定」。記載箇所は、元のサイトの<head>要素内で次のように設置する。

<head>
<link rel="canonical" href="/♠♣♥♦">
</head>

ご覧のように少々問題がある。つまり、記事やページの投稿毎に ♠♣♥♦部分を変更しつつ、都度設置していくこととなる。また、カテゴリやタグページを index対象ページにしていた場合は、さらにそれぞれに設定する必要がある。WordPressには、それを可能にするプラグインが公開されているが、完璧ではない。

また、サイトの自動転送方法の一つに、「meta要素のrefresh」がある。設置箇所は、同じように元のサイトの<head>要素内で次のように記載する。

<head>     
<meta http-equiv="refresh" content="0;URL=/♠♣♥♦" >    
</head>

301リダイレクト同様、自動転送させる際に使われる機能である。しかしながら、301のようにリクエストしたページが別のページへ恒久的に移動したことを示すことはしない。

結局、移転先サイトへ自動的に転送させるコードであると共に、検索エンジンに元のサイトの評価を新しいサイトにほぼそのまま引き継がせる機能を持つ 301リダイレクトを使う以外、手段はあるにしても問題を抱えることとなる。

将来、サイト移転を検討しなければならない時期が訪れたときに、この機能が使える、使えないでは雲泥の差が生じる。何より、サーチエンジンが移転の際は 301リダイレクトを使うことを推奨している。レンタルサーバーの使用を今後新たに導入検討する際にはこの機能が使えるか否かは要件の一つとして加えることを推奨したい。（無料のブログ用サイトサーバー以外、大抵は対応しているはずである）

と言うことで、旧サイトは2016/12/21を以て閉じさせていただきました。今までありがとうございます。そして今後ともよろしくお願い致します。




コメントを残す

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です