WordPressサーバー移行で学んだことと、しくじったこと

2026年6月29日

先日、あるWordPressサイトのサーバー移行を任されました。長くWebの仕事をしている私ですが、サーバーの引っ越しというのは、正直なところ毎回ドキドキします。料理の世界でいえば「営業を止めずに厨房を丸ごと別の場所へ移す」ようなもの。お客さまから見れば、いつも通りサイトが表示され続けていてほしい。でも裏側では、データを運び、設定を組み直し、メールやSSLまで面倒を見なければならない。

しかも今回は、私自身が「これは勉強になったな」と思うことと、「ああ、やってしまった」と頭を抱えたしくじりの両方がありました。せっかくなので、これからご自分でサーバー移行をされる方や、Web担当を兼ねている飲食店オーナーさんのために、固有名は伏せたうえで、つまずきポイントごと正直に書き残しておきます。

なお、この記事に出てくるドメインはすべて example.com という架空の例に置き換えています。あなたのお店のドメインに読み替えながら読んでみてください。

なぜサーバーを移行することになったのか

きっかけは、表示の重さと、契約まわりの見直しでした。アクセスが増えてきたサイトで、ページを開くのに少し待たされる場面が出てきた。だったら思い切って、性能の良い新サーバーへ引っ越そう、という話です。

ただ、移行で一番こわいのは「切り替えた瞬間にサイトが真っ白になる」こと。飲食店でいえば、ランチのピークタイムに看板が消えてしまうようなものです。だからこそ、今回は「お客さまには一切気づかれない、無停止の引っ越し」を目標にしました。その実現のためにとても役立ったのが、次にお話しする「hostsトリック」でした。

学び：DNSを切り替える前に、自分だけ新サーバーを覗き見る

サーバー移行の山場は、ネームサーバー（DNS）の切り替えです。DNSというのは、ざっくり言えば「example.com という名前を、どのサーバー（住所）に案内するか」を決める電話帳のようなもの。ここを新サーバーに向けた瞬間、世界中の閲覧者が一斉に新サーバーを見に行くことになります。

つまり、DNSを切り替えてしまうと、もう後戻りできない本番です。新サーバーの作り込みが甘ければ、表示崩れもフォームの不具合も、全部お客さまに見られてしまう。

そこで使うのが「hostsトリック」。自分のパソコンの中にある hosts（ホスツ）というファイルに一行だけ書き足すと、世界はまだ旧サーバーを見ているのに、自分のブラウザだけ新サーバーを表示できるのです。これなら無停止のまま、本番そっくりの環境を自分だけで先に検証できます。

hostsファイルに一行足す

Macの場合、/etc/hosts というファイルに、新サーバーのIPアドレスとドメインを並べて書きます。

203.0.113.10   example.com
203.0.113.10   www.example.com

左がIPアドレス（新サーバーの住所）、右がドメイン名です。これを保存してブラウザを開き直すと、自分のパソコンだけが新サーバーを見に行くようになります。世界中の他の人は、まだ旧サーバーのまま。ここがこの方法の素晴らしいところです。

この状態で、トップページの表示崩れ、お問い合わせフォームの送信、内部リンクのクリック、画像の表示などをひと通りチェックします。「これなら大丈夫」と確信できてから、最後にようやくDNSを本番で切り替える。順番を逆にしないことが、無停止移行のコツです。

切り替わらない時はDNSキャッシュを消す

ところが、hostsを書き換えても、すぐに新サーバーが表示されないことがあります。パソコンが古い情報を一時的に覚えている（キャッシュ）からです。そんな時はMacで次のコマンドを実行して、キャッシュを掃除します。

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

前半でDNSのキャッシュを消し、後半で名前解決を担当しているプロセスに「設定を読み直して」と合図を送っています。これでブラウザを開き直すと、ちゃんと新サーバーが見えるようになります。

確認が終わったらhostsを元に戻す

検証が終わったら、書き足した行は必ず消します。消し忘れると、DNSを本番で切り替えた後も自分のパソコンだけ古い情報を見続けてしまい、「自分の画面では直っているのに、なぜか他の人には反映されない」と混乱するからです。

私が今回いちばん勉強になったのが、この「元に戻す」一行コマンドでした。

sudo sed -i '' '/example.com/d' /etc/hosts

呪文のようですが、分解すると意味はシンプルです。

sed … テキストファイルを一括で書き換える道具。
-i … ファイルを直接書き換える（in-place、その場で編集）という指定。
''（シングルクォート2つ） … Mac特有の作法で、「バックアップファイルを作らない」という意味。実はMacの sed は -i の直後にバックアップ用の拡張子を必ず要求するクセがあり、何も付けない＝空っぽを渡すことで「バックアップなしで上書きしてね」と伝えています。LinuxやWindowsの解説をそのまま真似すると、ここでエラーになりがちなポイントです。
'/example.com/d' … 「example.com という文字を含む行を削除（delete）せよ」という命令。

つまりこの一行は、「example.com を含む行を、バックアップを作らずにその場で消す」という意味になります。手で開いて消してもいいのですが、コマンドで確実に消せると気持ちがいいものです。

ひとつ、初心者がつまずく点も添えておきます。sudo（管理者として実行）を付けたコマンドを打つと、パスワードを求められます。ここで入力するのはMac本体のログインパスワードです。そして、打っても画面には何も表示されません。「●」も出ません。これは故障ではなく、セキュリティ上わざとそうなっている仕様です。私も昔は「あれ、キーボード効いてない？」と何度も打ち直したものですが、見えないまま正しく入力してEnterで通ります。

しくじり：セキュリティを固めたつもりが、自分が締め出された

さて、ここからが本記事の核、私の盛大なしくじり話です。

WordPressには、ログイン画面を守るためのセキュリティプラグインがあります。代表的なのが SiteGuard 系の機能で、本来 wp-login.php という決まったアドレスにあるログイン画面を、自分だけが知る別のアドレスに変えてくれる。乗っ取り対策としてとても有効で、私もありがたく使っていました。

ところが、です。

移行作業では All-in-One WP Migration という定番の引っ越しプラグインを使いました。データも画像も設定も、まるっと新サーバーへ運んでくれる優れもの……なのですが、この手の移行ツールは .htaccess（エイチティーアクセス）というサーバーの設定ファイルを持っていってくれないのです。

そして問題は、SiteGuard の「ログインURL変更」が、まさにこの .htaccess の書き換えルールで成り立っているということ。

つまり、新サーバーでは——

.htaccess が運ばれていないので、ログインURLを変更するルールが消えている
だから自分で設定したカスタムのログインアドレスは404（ページが見つからない）
かといって本来の wp-login.php も、プラグインの設定だけは残っているのでやはり404

両方の入り口が閉ざされ、自分で自分を管理画面から締め出してしまったわけです。セキュリティを固めたつもりが、固めた本人が中に入れない。まさに、鍵をかけた家のドアの前で鍵を失くした気分でした。

どうやって入り直したか

幸い、抜け道はあります。締め出されても、FTP（サーバーにファイルを出し入れする仕組み）でサーバーの中身には触れます。そこで、原因になっているプラグインのフォルダ名を変えて、一時的に無効化しました。

wp-content/plugins/siteguard      ← もとのフォルダ名
wp-content/plugins/siteguard.off  ← 末尾に .off を付けてリネーム

WordPressは「フォルダ名が変わって見つからないプラグイン」を、自動的に「停止」とみなしてくれます。これでログインURL変更の縛りが外れ、本来の wp-login.php から無事に入れました。入れたら、プラグインを正しく設定し直し、フォルダ名も元に戻して、もう一度きちんと有効化する。これで一件落着です。

この失敗からの教訓

二度と同じ轍を踏まないよう、自分への戒めとして書いておきます。

移行前に、ログイン保護系プラグインはいったん止めておく。少なくとも、カスタムログインのアドレスは紙にメモしておく。
それでも締め出されたら、慌てずFTPでプラグインのフォルダ名をリネームして一時無効化する。
.htaccess に依存する機能（ログインURL変更、リダイレクト、アクセス制限など）は、移行ツールでは運ばれないことが多い、と頭の片隅に置いておく。

セキュリティは大切ですが、固めれば固めるほど、いざという時に自分の首を絞めることがある。「守りを固めるなら、自分の逃げ道も一緒に用意しておく」。これが今回いちばん身にしみた教訓でした。

あわせて気をつけたい、移行まわりの小さな学び

最後に、今回ぶつかった細かい注意点を、軽くまとめておきます。

場面	つまずき	対処
大きいサイトの移行	ブラウザからのアップロードが途中で詰まる	バックアップファイルをFTPで直接置いてから取り込む
SSL（鍵マーク）	移行後に「保護されていない通信」表示	サーバー側でLet’s Encrypt（無料SSL）をON、http→httpsの強制リダイレクトを `.htaccess` に追記
メールの不達	新サーバーから送るメールが迷惑メール扱い	送信はメール側サーバー経由（SMTP）にする

最後のメールの話は補足しておきます。今回、Webサイトは新サーバー、メールは旧サーバーのまま、という分け方をしました。すると、新サーバーから送る自動メール（お問い合わせの自動返信など）が、受け取り側に「なりすましかも」と疑われ、迷惑メールフォルダに入りやすくなったのです。これは、メールの正当性を証明するDKIMといった仕組みが、Webサーバー側では整っていないため。送信処理をメール側のサーバー（SMTP）に通すことで、ぐっと受信トレイに届きやすくなりました。