WordPressのサーバー移転をダウンタイムなしで行う手順｜記事数もプラグインも多いサイトで切替当日にやること

サーバー移転を自力でやる前提で、「ダウンタイムをゼロにしたい」「記事数が多く、プラグインも多い」という条件がついている場合、探すべき情報は移行プラグインの使い方ではありません。作業の順番です。先に結論を書きます。

ダウンタイムが出るのは、移す作業と切り替える作業を同じ時間にやろうとするからです。ゼロにする方法は1つで、新サーバーに複製を作って先に完成させ、DNS（ドメインの向き先）の切り替えを最後に回す。この形にすると、切替当日にやることは「差分の同期」と「検証」だけになり、サイトが止まる時間そのものが発生しません。

順番にすると、こうなります。

1. 移行前に3つ決める（更新を止める時間・切り戻す方法・検証するURLの一覧）
2. 新サーバーへ複製する（記事数とプラグインが多いサイトはツール選びで詰まる）
3. 複製した瞬間に、新環境を検索から隔離する
4. DNSを切り替える前に、新サーバー側で本番URLの表示を実測する
5. 切替当日は差分だけ同期して、DNSを向ける
6. 切替後に全URLを機械的に検証する

弊社は名古屋でホームページ制作と運用を行っています。200ページ超・記事168本規模の切り替えを行った実務から、当日の段取りと、複製直後に壊れやすい箇所を順に書きます。

なぜ「移してから切り替える」とダウンタイムがゼロになるのか

ドメインは、DNSという仕組みで「このドメインはこのサーバー」と結び付けられています。サーバー移転とは、この向き先を旧サーバーから新サーバーへ変える作業のことです。

ここで押さえておきたいのが、新サーバーへの複製は、DNSを変えなくても先に作れるという点です。旧サーバーは訪問者に対して通常どおりサイトを配信し続けたまま、裏で新サーバーに同じサイトを組み立てられます。両方が同時に生きている状態を作ってから、最後に向き先だけ変える。切り替えの瞬間に何かを復元したり組み立てたりする必要がないので、止まる時間が生まれません。

逆に、ダウンタイムが数時間になるのは、旧サーバーからデータを書き出し、新サーバーに復元し、そこから動作確認を始める、という順番でやったときです。この順番だと「復元に失敗している時間」がそのまま停止時間になります。記事数が多くプラグインが多いサイトほど復元に時間がかかり、失敗する箇所も増えるため、この順番は避けます。

手順1：移行前に3つ決めておく

作業を始める前に決めておくと、当日の判断が要らなくなります。

• 更新を止める時間：ブログや商品情報を毎日更新しているサイトでは、複製を作った後に本番へ書かれた記事が、新サーバー側に存在しません。「複製後も記事は本番で書き続ける・新サーバー側は触らない」と決めておき、切替直前にデータベースだけ再同期する段取りにします。この一手を入れておけば、更新を止める時間は実質ゼロにできます
• 切り戻す方法：切替直前に、旧サーバーのファイル一式・画像などのアップロード領域・.htaccess・データベースをまとめて取得しておきます。実案件では合計約90MB、書き戻せば10分程度で元に戻せる状態を作ってから切り替えました。「戻せる」と分かっていると、当日の判断が速くなります
• 検証するURLの一覧：切替後に確認すべきURLを、作業前に洗い出しておきます。トップページだけ見て確認を終えると、ほぼ確実に見落とします。記事・固定ページ・カテゴリ・画像・フォーム送信まで、行数のあるリストにしておきます

手順2：新サーバーへ複製する

ここでツール選びを誤ると、時間を大きく失います。実際に試した結果を書きます。

手段	実際に起きたこと	向いている場面
無料の移行プラグイン（All-in-One WP Migration等）	無料版に512MB／1GBの容量制限があり、バックアップからの復元は有料。記事と画像が積み上がったサイトでは早々に上限に当たる	小規模サイト
サーバー標準の「かんたん移行」機能	移行元サイトへのログインに失敗して進まないことがある（パスワードに使われた記号や、ログイン試行回数の制限が原因になりやすい）	条件が合えば手軽
WPvivid等の別プラグイン	上の2つが通らなかったサイトで、これを使って完了した	容量が大きいサイトの実務解
サーバー会社の「サイトコピー」機能	同一サーバー内での複製。1.1GBのサイトで数秒	同じサーバー内に検証環境を作るとき

判断の目安はシンプルで、無料プラグインを最初から本命にしないことです。容量制限に当たってから乗り換えると、その分だけ作業日が伸びます。

もう1点、同じサーバー会社の中で複製する場合の注意です。「かんたん移行」と「サイトコピー」は別物で、移行機能のほうは移行元（＝稼働中の本番サイト）に一時的なプラグインが入る仕様のものがあります。本番に書き込みを発生させたくない場面では、コピー側の機能を選びます。

手順3：複製した瞬間に、新環境を検索から隔離する

並行稼働で最も注意すべき副作用がこれです。複製した新環境は、旧サイトとまったく同じ内容を、別のアドレスで公開している状態になります。検索エンジンに拾われると重複コンテンツになり、移転が終わった後も検索結果に残ります。

隔離は、複製する前にやります。

• 新環境の公開フォルダに、物理ファイルとしてのrobots.txt（Disallow: /）を先に置いてから複製する。先に置けば、公開状態になっている時間そのものがゼロになります
• WordPress側の「検索エンジンがサイトをインデックスしないようにする」設定も同時に有効にする（管理画面の表示設定）
• ID・パスワード認証（Basic認証）はかけないほうが安全な場合があります。認証をかけると外部ツールやAPI経由の確認が通らなくなり、検証そのものができなくなります

実際に、複製直後の環境が公開設定のままで、サイトマップまで宣言している状態になっていたことがあります。気づいて即座に遮断したため実害はありませんでしたが、放置すればインデックスされる状態でした。複製と遮断は1セットの作業として扱ってください。

手順4：DNSを切り替える前に、新サーバーの表示を実測する

ここが、ダウンタイムゼロの核心です。

新サーバーに複製したサイトを「本番と同じドメインで」表示させて確認したい。しかしDNSはまだ旧サーバーを向いている。この状態で確認する方法があります。DNSを介さず、接続先のサーバーを指定してアクセスするやり方です。

curl --resolve example.com:443:【新サーバーのIP】 -k https://example.com/

これは「example.comへのアクセスを、このIPアドレスへ向ける」という指定です。DNSを一切変更せずに、新サーバーが本番ドメインで何を返すかを実測できます。HTTPSでも通ります（サーバーは接続時に渡されるドメイン名を見て振り分けるため、DNSの状態とは無関係に応答します）。

この方法の利点は、目視ではなくコマンドで確認できることです。手順1で作ったURL一覧をループで回し、全ページのステータスコードと中身を一括で確認できます。パソコンのhostsファイルを書き換える方法でも同じことはできますが、書き換えを戻し忘れる事故が起きるため、確認だけならコマンド側が安全です。

ここで全URLが正常に返ることを確認してから、はじめてDNSを触ります。確認が終わっている状態で向き先を変えるだけなので、切り替えの瞬間に想定外は起きません。

手順5：切替当日にやること

当日の作業は、順番どおりに実行すれば30〜60分で終わります。

1. データベースだけ再同期する（複製後に本番へ書かれた記事を取り込む。取り込む前に、本番と新環境の最終更新日時を比較して差分の有無を確認する）
2. 切替直前のフルバックアップを取る（ファイル・アップロード領域・.htaccess・データベース）
3. DNSを新サーバーへ向ける
4. 手順1のURL一覧で全数検証する
5. 問題があれば切り戻す（手順2のバックアップがあるので判断に迷わない）

DNSの反映には時間差があります。サーバー会社側では反映済みでも、手元のパソコンやスマートフォンは古い情報を一定時間覚えたままです。切替直後に「まだ古いサイトが見える」と焦る必要はありません。並行稼働させているので、どちらに届いても正常なサイトが表示されます。これがダウンタイムゼロの実体です。旧サーバーをこの時点で止めてしまうと、この安全余裕がなくなります。

手順6：切替後の検証は、必ず全URLをループで見る

トップページを開いて表示されたから成功、という確認は成立しません。実案件では、全数検証を回してはじめて見つかった不具合がありました。

サイト内に/wp/のようなサブディレクトリがあり、そこに独自の.htaccessが置かれている場合、上位ディレクトリに書いた転送設定はそのディレクトリ配下では無視されます（子の設定が優先されるため）。切替用の設定を最上位に置いただけでは、そのディレクトリ配下の転送が全部効いていませんでした。トップページも記事一覧も正常に見えるため、目視では見つかりません。

検証で見るべき項目は次のとおりです。

• 記事・固定ページ・カテゴリの全URLがステータス200を返すか（サンプル確認で終わらせない）
• 転送を設定したURLが、意図した先へ正しく飛ぶか
• 画像が実際に表示されるか（後述のとおり、ここは権限で落ちることがあります）
• 問い合わせフォームを実際に送信して、メールが届くか
• アクセス解析のタグが全ページに入っているか
• 記事の投稿先が新サーバーになっているか（ここを直し忘れると「投稿は成功するのにサイトに反映されない」という、気づきにくい状態になります）

複製直後に壊れやすい箇所

移転で問題が起きるポイントは、ほぼ決まっています。事前に知っていれば、確認項目として潰せます。

症状	原因	対処
トップページは出るが、他が動かない・APIがエラーになる	.htaccessの基準パス（RewriteBase）が旧環境のパスのまま	新環境のパスに書き換える。トップだけは表示されるので気づきにくい
WordPressが表示されず、サーバーの初期ページが出る	サーバーが置いた初期のindex.htmlが優先されている	初期ページのファイルを削除する
管理画面にログインできない	データベースのテーブル接頭辞を変えた際の、権限情報の更新漏れ	接頭辞を変える作業はテーブル名だけを対象に置換する。ユーザー権限の記録も併せて更新しないとログインできなくなる
一部ページのURLが変わってしまった	テーマ独自の設定が複製時に引き継がれなかった	複製後、URL構造に関わる設定を実物のURLで突き合わせる
画像だけ表示されない	ファイルの読み取り権限（パーミッション）が閉じている	403と404は別物。403はファイルが存在するのに読めない状態＝権限を疑う

最後の権限については補足します。サーバー間でファイルを同期するコマンドには、権限の設定ごとコピーする動作があります。この場合、手元で権限が閉じていたファイルは、その状態のまま本番へ運ばれます。FTPでアップロードする運用では起きないため、サーバー間コピーへ切り替えたタイミングで初めて発生する種類の不具合です。同期の際に権限を明示指定する（ファイル644・ディレクトリ755）ことで防げます。同じフォルダの中で表示される画像と表示されない画像が混在していたら、この線をまず疑ってください。

旧サーバーはいつ止めるか

切替直後には止めません。目安は次のとおりです。

• 旧サーバーの契約は、切替後しばらく維持する。DNSの反映には時間差があり、切り戻す可能性も残ります
• 旧サイトのファイルは削除せず、フォルダ名を変えて寝かせる。消してしまうと「あのページの元データを見たい」に対応できません
• 旧ドメインからの転送設定は、最低でも数か月維持する。転送は旧ドメインを保有している間しか効かないため、解約した瞬間に過去のリンクやブックマークからの流入が途切れます

まとめ

WordPressのサーバー移転でダウンタイムをゼロにする方法は、新サーバーで完成させてから、DNSの切り替えを最後に回すという順番の設計です。

• 移す作業と切り替える作業を分離すれば、止まる時間そのものが発生しない
• 記事数・プラグインが多いサイトでは、無料プラグインの容量制限で足止めされやすい。ツールは最初から容量に耐えるものを選ぶ
• 複製した新環境は、複製する前に検索から遮断する
• DNSを切り替える前に、接続先を指定する方法で新サーバーの表示を全URL実測する
• 切替後の検証は目視ではなく、URL一覧をループで確認する

記事数が多いサイトでは「どのURLが、切替後にどこへ着地するか」を全件で把握できているかが結果を分けます。まず、URL一覧を作るところから始めてください。

サーバー移転やホームページの構成変更をご検討中の方は、LINEからご相談ください。現在のサイトの構成を確認したうえで、移転の可否と手順をお伝えします。

FAQ

Q. サーバー移転でSEOの評価は下がりますか？

URLが変わらないサーバー移転であれば、評価が落ちる要因は基本的にありません。落ちるとすれば、移転時にページが消えている・転送設定を誤っている・表示速度が大きく悪化しているといった、移転作業側の問題です。切替後に全URLを検証する工程を必ず入れてください。

Q. 移転作業中に、ブログの更新を止める必要はありますか？

段取り次第で、ほぼ止めずに済みます。「複製後も本番側で更新を続け、切替直前にデータベースだけ再同期する」形にすれば、更新を止める時間は最小になります。逆に、この再同期を飛ばすと、複製後に書いた記事が新サーバーに存在しない状態になります。

Q. 自力でやるか、制作会社に頼むかの判断基準はありますか？

判断材料は、記事数・プラグインの数・独自設定の多さです。ページ数が少なく、標準的なテーマとプラグインだけで動いているサイトは自力で完了できます。数百ページ規模、カスタム投稿やテーマ独自設定がある、フォームや予約システムが業務に直結している場合は、切替後の検証工数が跳ね上がるため、外部に任せたほうが安全です。