記事338件、画像3,032ファイル、広告タグ271種類。これが、私が別のレンタルサーバーへ移したWordPressサイトの中身です。
移設の作業そのものは16分で終わりました。ドメインの切り替えを含めて2日です。私はシステム開発の技術者ではなく、作業はAIに指示を出して進めました。
短時間で終わったのは、移す作業が機械的だからです。時間がかかったのは別のところでした。
移した理由は、管理画面を1つにしたかったから
移した理由は、性能でも価格でもありません。ドメインを同じ会社で管理して、サーバーとまとめて扱えるようにしたかったからです。
サーバーは1社、ドメインは別の会社、という状態が続いていました。設定を1つ変えるたびに、どちらの管理画面を開くのかを考えることになります。作業そのものは数分でも、その手前の判断が毎回発生します。
サイトが1つならまだ耐えられます。複数を運用するようになると、この判断の回数が増えていきます。それで移すことにしました。
サーバーを選ぶときに何を見ているかは、レンタルサーバーの選び方をまとめた記事に書いています。
移設の準備で、移す前のサーバーの状態が分かった
移設の準備で中身を調べたところ、想定していなかった状態が出てきました。
1つの契約に9つのサイトが同居していて、データベースも共用でした。WordPressの本体は自動のセキュリティ更新だけが当たっている状態で、PHPのバージョンも古いままでした。
さらに、xmlrpc.php という入り口への不正なアクセスが、29日間で3,586件記録されていました。xmlrpc.php は外部のアプリからWordPressを操作するための入り口で、使っていなければ閉じておける場所です。攻撃の対象になりやすく、ねらわれること自体は珍しくありません。問題は、それを防ぐためのセキュリティプラグインが停止したままだったことです。
移そうと思ったきっかけは管理の一元化でしたが、結果としてサーバーの中身を点検するきっかけになりました。移設を考えている方は、移す前に一度、いま入っているものを確認してみることをお勧めします。
記事が欠けていないことを、どう確かめたか
移設で一番怖いのは、記事や画像が抜けることです。しかも抜けたことに気づかないまま、切り替えてしまうのが最悪の形になります。
今回は次の4つを、1つずつ突き合わせました。
- 記事338件を、本文の文字単位で照合
- 記事のURL338件を照合
- 画像3,032ファイルを、ファイルサイズまで含めて照合
- 広告タグ271種類の有無を照合
結果はすべて一致し、欠けは0件でした。
とくに広告タグは、収益が出ているサイトでは死活問題になります。移設の直後は表示されているように見えても、種類が1つ欠けているだけで、その分の収益が止まります。数を数えて確かめておくべき箇所です。
日本語を含むURLも305件ありました。日本語のURLは内部では符号に変換されて扱われるため、移設の途中で崩れることがあります。これもそのまま残っているかを確認しています。
レスポンスサイズで同一性を判断してはいけない
移設の前後でページを比べるとき、返ってくるデータのサイズ（レスポンスサイズ）を比べれば早いように思えます。実際に試したところ、これは使えませんでした。
同じページを2回取得しても、数百バイトの差が出ます。広告や関連記事の表示が毎回変わるためです。サイズだけを見て違うと判断すると、問題のない記事まで疑うことになります。
比べるのは本文そのものにしてください。
1回目にやってしまった、余計な書き換え
今回、実は2回移しています。1回目に余計なことをして、やり直しました。
1回目は、新しいサーバーで表示を確認するために、データベースに記録されているサイトのURLを50か所ほど書き換えました。これで確認はできましたが、切り替えのときに全部を元へ戻す作業が発生します。宿題を自分で作った形です。
2回目は、データベースには手を触れず、wp-config.php に一時的な指定を1行足すだけで確認しました。wp-config.php はWordPressの設定を書いておくファイルで、ここに書いた指定はデータベースの値より優先されます。切り替えるときは、その1行を消せば終わりです。
移設の途中で確認のために書き換える場面が出てきたら、あとで戻す必要があるかどうかを先に考えてみてください。
細かいところでつまずいた3点
そのほか、実際に詰まった箇所です。
サーバー側で用意されている動作確認用のURLが使えず、手元に別の仕組みを立てて表示を確認しました。用意されているものが必ず使えるとは限りません。
HTTPからHTTPSへのリダイレクト、つまり暗号化されていない接続を暗号化された接続へ自動で転送する設定は、いきなり全体に適用しませんでした。存在しないURLを1つだけ対象にした試験用の設定を先に置き、転送が延々と繰り返される状態にならないことを確かめてから、本番に適用しています。この設定は間違えるとサイト全体が開かなくなるので、先に試すやり方をお勧めします。
アクセス解析の設定でも1つ引っかかりました。テーマ側に用意されている入力欄が古い形式のもので、そこへ入れても記録されません。似た名前の欄が複数あるので、いま使われている形式のほうを選ぶ必要があります。
不安はなかった。ただし確認は自分でやった
移設の間、私はほとんど不安を感じませんでした。作業の一つひとつをAIが説明してくれたからです。
ただ、この点は正直に書いておきます。説明が分かりやすいことと、その説明が正しいことは別です。私の場合、記事の数も画像の数も自分で数え直していますし、上に書いたレスポンスサイズの話も、実際に試して分かったことでした。
説明で安心はできますが、確認は自分でやるしかありません。
半年間、2つのサーバーに払い続けた
費用の話を書いておきます。
移設したあとも、元のサーバーの契約を半年ほど残していました。その間、2社分を払っています。
理由は単純で、解約する踏ん切りがつかなかったからです。移し終えて表示も確認しているのに、元のほうを消すのが怖い。この状態が半年続きました。
バックアップは取ってあったので、いま振り返ると、もっと早く解約してよかったと思います。
次に移設するなら、こうする
もう一度同じ作業をするなら、変えたいことが2つあります。
1つは、確認のためにデータベースを書き換えないことです。1回目でやってしまい、戻す作業を自分で作りました。設定ファイルに一時的な指定を足すだけで済みます。
もう1つは、元の契約をいつ解約するかを、移す前に決めておくことです。移し終えたあとに考え始めると、判断が先延ばしになります。私の場合はそれで半年ぶん余計に払いました。
移設そのものは16分でした。長引くのは、確認と、決められないことのほうです。
