WordPressサイト移行の手順｜サーバー引っ越しで失敗しない完全ガイド

生徒

サーバーを乗り換えたいんですが、WordPressの引っ越しって何から手をつければいいですか？ 表示が消えたら怖くて…。

ペン博士

順番さえ守れば怖くないよ。要はファイルとデータベースを運んで、URLを書き換えて、DNSを切り替えるだけ。旧サイトを残したまま新サーバーで確認できるから、失敗しても戻せる。

サーバーの乗り換え、ドメインの変更、本番公開前のテスト環境への複製。WordPressの移行は作業自体は数時間ですが、順番を誤ると表示が崩れたりリンクが切れたりします。

失敗の多くは「DNSを先に切り替えてしまう」「URLの書き換えを本文だけで済ませる」という2点に集中しています。逆に言えば、この2つを外さなければ大きな事故は起きません。

この記事では、移行方法の選び方から、事前準備・実作業・切り替え・移行後の確認まで、順を追って解説します。作業チェックリストも用意しました。

• 移行方法は3つ。どれを選ぶか
• 移行前に必ず取るバックアップ
• プラグインを使った移行手順
• 手動移行の手順（ファイル＋データベース）
• URLの書き換えで失敗しない方法
• DNSを切り替える前に新サーバーで確認する
• SSL証明書とリダイレクトの設定
• 移行後に必ず確認する項目
• よくあるトラブルと対処
• 作業チェックリスト

移行方法は3つ。どれを選ぶか

状況によって適切な方法が変わります。まずここを決めてから作業に入ります。

エックスサーバーやConoHaなど主要なレンタルサーバーにはWordPress簡単移行のような機能があります。対応していれば、これが最も速く確実です。

プラグインでは All-in-One WP Migration や Duplicator が定番です。ただし無料版にはファイルサイズの上限があるため、画像の多いサイトでは途中で止まることがあります。

手動移行は手間がかかりますが、途中で何が起きているかを完全に把握できます。大規模サイトや、プラグインが失敗した場合の最終手段です。

移行前に必ず取るバックアップ

何よりも先にこれをやります。移行が失敗しても元に戻せる状態を作ってから着手してください。

• ファイル一式：wp-content（テーマ・プラグイン・アップロード画像）を含む全ファイル
• データベース：phpMyAdminまたはWP-CLIでエクスポート
• 設定情報の控え：wp-config.phpのDB接続情報、DNSの現在の設定
• 現状の記録：トップと主要ページのスクリーンショット、有効なプラグイン一覧

# WP-CLIが使える環境なら、この2行でバックアップが取れる
wp db export backup-$(date +%Y%m%d).sql
tar -czf files-$(date +%Y%m%d).tar.gz wp-content wp-config.php

# 取得したファイルの中身とサイズを確認しておく
ls -lh backup-*.sql files-*.tar.gz

バックアップは自分のPCにダウンロードするまで完了とはいえません。同じサーバー上に置いたままでは、サーバー側の障害で同時に失われます。

プラグインを使った移行手順

最も使われる方法です。All-in-One WP Migration を例に流れを示します。

【旧サーバー】
1. プラグインをインストール・有効化
2. エクスポート → 「ファイル」を選択
3. .wpress ファイルをダウンロード（数分〜数十分）

【新サーバー】
4. WordPressを新規インストール（バージョンを合わせる）
5. 同じプラグインをインストール・有効化
6. インポート → ダウンロードした .wpress を選択
7. 完了後、パーマリンク設定を2回保存（後述）

インポート後は管理画面のログイン情報が旧サイトのものに置き換わります。新規インストール時に設定したパスワードではなく、旧サイトのID・パスワードでログインしてください。

アップロード上限で止まる場合

<?php
// .htaccess や php.ini で上限を引き上げる（サーバーが許可している場合）
// php.ini の例
upload_max_filesize = 512M
post_max_size = 512M
max_execution_time = 600
memory_limit = 256M

引き上げられない場合は、画像フォルダだけを手動でFTP転送し、残りをプラグインで移すという分割が有効です。wp-content/uploadsを除外してエクスポートできるプラグインもあります。

手動移行の手順

確実性が最も高い方法です。ファイルとデータベースを別々に運びます。

ステップ1：ファイルを転送する

# 旧サーバーで圧縮してから転送すると速い
tar -czf site.tar.gz wp-content wp-config.php .htaccess

# 新サーバーで展開
tar -xzf site.tar.gz

ステップ2：データベースを移す

# 旧サーバーでエクスポート
wp db export old-site.sql
# または phpMyAdmin → エクスポート → 形式:SQL

# 新サーバーでインポート
wp db import old-site.sql
# または phpMyAdmin → インポート

ステップ3：wp-config.php を書き換える

<?php
/** 新サーバーのデータベース情報に差し替える */
define( 'DB_NAME', '新しいDB名' );
define( 'DB_USER', '新しいDBユーザー' );
define( 'DB_PASSWORD', '新しいパスワード' );
define( 'DB_HOST', 'localhost' );   // サーバーによって異なる

/** 移行中の確認用にデバッグを一時的に有効化してもよい */
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DEBUG_LOG', true );

DB_HOSTはサーバーによってlocalhostではないことがあります。契約情報を確認して正確に入れてください。ここを間違えると「データベース接続確立エラー」になります。

URLの書き換えで失敗しない方法

ドメインが変わる場合の最重要工程です。ここを雑にやると、画像が表示されない・リンクが旧ドメインを向くといった不具合が残ります。

# WP-CLIなら1コマンドで安全に置換できる（シリアライズ対応）
wp search-replace 'https://old-domain.com' 'https://new-domain.com' --all-tables --dry-run

# 問題なければ --dry-run を外して実行
wp search-replace 'https://old-domain.com' 'https://new-domain.com' --all-tables

SQLのREPLACEで一括置換するのは避けてください。WordPressはウィジェットやテーマ設定を「シリアライズ」という形式で保存しており、単純な文字列置換では文字数の情報がずれてデータが壊れます。

置換対象は本文だけではありません。設定値・カスタムフィールド・ウィジェット・テーマオプションにもURLが入っています。必ず--all-tablesで全体を対象にしてください。

DNSを切り替える前に新サーバーで確認する

移行事故の多くはここで起きます。DNSを切り替えてから確認すると、問題があった場合に本番が壊れた状態で公開されます。

正しい順序は「新サーバーで表示確認 → 問題なければDNS切り替え」です。切り替え前に確認するには、PCのhostsファイルを使います。

# macOS: /etc/hosts  /  Windows: C:\Windows\System32\drivers\etc\hosts
# 新サーバーのIPアドレスとドメインを書く
203.0.113.10   example.com
203.0.113.10   www.example.com

# 編集後にDNSキャッシュを消す（macOS）
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# 自分だけ新サーバーを見ている状態か確認
ping example.com

この状態なら、自分のPCだけが新サーバーを見ているため、一般の閲覧者には影響がありません。表示・リンク・フォーム送信まで確認してから、DNSを切り替えます。

確認が終わったらhostsの記述は必ず削除してください。消し忘れると、切り替え後にキャッシュの問題を追いかけることになります。

SSL証明書とリダイレクトの設定

DNSを切り替えたら、SSLとリダイレクトを整えます。この2つが抜けると、警告表示や重複コンテンツの原因になります。

SSL証明書

• 新サーバーで証明書を発行（多くは無料のLet’s Encryptが使える）
• DNS切り替え後でないと発行できない場合がある
• 発行後、https://で表示されるか確認する
• 混在コンテンツ（http読み込み）が残っていないかを検証する

リダイレクト

# httpsへ統一
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

# 旧ドメインから新ドメインへ（ドメイン変更時・旧サーバー側に置く）
RewriteCond %{HTTP_HOST} ^old-domain\.com$ [NC]
RewriteRule ^(.*)$ https://new-domain.com/$1 [R=301,L]

ドメインを変更した場合、旧ドメインからの301リダイレクトは最低1年は維持してください。検索エンジンの評価を引き継ぐために必要です。

移行後に必ず確認する項目

表示されたから完了、ではありません。次の10項目を確認してください。

特に見落とされやすいのが9番目です。テスト環境で検索エンジンによるインデックスを許可しないにチェックを入れたまま本番移行すると、サイト全体が検索結果から消えます。

よくあるトラブルと対処

移行作業で遭遇する代表的な症状と、その原因です。

2番目は移行後にほぼ必ず起きます。「設定 → パーマリンク設定」を開いて何も変更せずに保存するだけで直ります。覚えておくと慌てません。

作業チェックリスト

印刷して手元に置ける形でまとめました。上から順に潰していけば完了します。

【事前】
[ ] ファイル一式のバックアップをローカルに保存
[ ] データベースのエクスポートをローカルに保存
[ ] 有効なプラグイン一覧を記録
[ ] 主要ページのスクリーンショットを保存
[ ] 新サーバーのDB情報・IPアドレスを控える

【移行】
[ ] 新サーバーにファイルを配置
[ ] データベースをインポート
[ ] wp-config.php のDB情報を書き換え
[ ] URLを search-replace で置換（--all-tables）

【確認（DNS切替前）】
[ ] hosts に新サーバーのIPを書いて表示確認
[ ] トップ・記事・固定ページを開く
[ ] 画像とCSSが新ドメインを向いているか
[ ] フォーム送信テスト
[ ] hosts の記述を削除

【切替】
[ ] DNSを新サーバーへ変更
[ ] 反映を待つ（数分〜48時間）
[ ] SSL証明書を発行・確認
[ ] リダイレクト設定

【事後】
[ ] パーマリンク設定を保存し直す
[ ] noindex設定が入っていないか確認
[ ] 解析タグの計測を確認
[ ] 旧サーバーは1ヶ月ほど残しておく

最後の項目が地味に重要です。移行直後は気づかない不具合が出ることがあるため、旧サーバーは即解約しないでください。1ヶ月ほど残しておけば、いつでも切り戻せます。

テスト環境・ローカルへの複製

本番の移行だけでなく、検証用のコピーを作るときも同じ手順が使えます。ただし2点だけ追加の配慮が要ります。

検索エンジンに拾わせない

管理画面 → 設定 → 表示設定
 → 「検索エンジンがサイトをインデックスしないようにする」にチェック

テスト環境が検索結果に出ると、本番と重複コンテンツになります。あわせてBasic認証をかけておくと、URLが漏れても閲覧されません。

AuthType Basic
AuthName "Staging"
AuthUserFile /path/to/.htpasswd
Require valid-user

メール送信を止める

テスト環境から実際の顧客にメールが飛ぶ事故を防ぎます。問い合わせフォームの通知や、自動返信が該当します。

<?php
/** テスト環境ではメール送信を無効化する */
if ( strpos( $_SERVER['HTTP_HOST'] ?? '', 'staging.' ) === 0 ) {
	define( 'WP_ENVIRONMENT_TYPE', 'staging' );
}

<?php
// staging判定時はメール送信をキャンセルする
add_filter( 'pre_wp_mail', function ( $null ) {
	if ( wp_get_environment_type() === 'staging' ) {
		return true;   // 送信せず成功扱いにする
	}
	return $null;
}, 10, 1 );

本番へ戻すときにこの記述を消し忘れないよう、環境判定で自動的に切り替わる形にしておくのが安全です。

ドメイン変更を伴う場合のSEO手当て

サーバーだけの移行ならURLは変わりませんが、ドメインも変える場合は検索評価の引き継ぎ作業が加わります。

• 301リダイレクト：旧ドメインの全URLを、新ドメインの対応するURLへ1対1で転送する
• Search Consoleのアドレス変更：新旧両方のドメインを登録し、変更ツールで申請する
• サイトマップの再送信：新ドメインのサイトマップを送信する
• 内部リンクの修正：本文中の絶対URLを新ドメインに置換する
• 被リンク元への連絡：主要な参照元にURL変更を伝える

# 個別ページも含めて1対1で転送する（トップへまとめない）
RewriteEngine On
RewriteCond %{HTTP_HOST} ^old-domain\.com$ [NC,OR]
RewriteCond %{HTTP_HOST} ^www\.old-domain\.com$ [NC]
RewriteRule ^(.*)$ https://new-domain.com/$1 [R=301,L]

よくある失敗が全URLをトップページへ転送してしまうことです。個別記事の評価が引き継がれず、検索流入が大きく落ちます。必ずパスを保ったまま転送してください。

順位は一時的に下がることがあります。1〜3ヶ月かけて戻るのが一般的なので、直後の変動で慌てて設定を変えないでください。

大規模サイトを分割して移行する

画像が数GBある、記事が数千本あるといったサイトでは、一括移行が時間切れで失敗します。分割して運びます。

# 1. 画像以外を先に移す
tar -czf core.tar.gz --exclude='wp-content/uploads' wp-content wp-config.php

# 2. 画像は年別に分けて転送する
tar -czf uploads-2024.tar.gz wp-content/uploads/2024
tar -czf uploads-2025.tar.gz wp-content/uploads/2025
tar -czf uploads-2026.tar.gz wp-content/uploads/2026

# 3. rsyncが使えるなら差分転送が最も速い
rsync -avz --progress wp-content/uploads/ user@new-server:/path/wp-content/uploads/

rsyncが使えるなら最優先で検討してください。途中で止まっても差分から再開できるため、大量ファイルの転送で最も確実です。

データベースが大きい場合

# 不要データを削除してからエクスポートすると軽くなる
wp post delete $(wp post list --post_status=trash --format=ids) --force
wp transient delete --all
wp db optimize

# それでも大きい場合はテーブル単位でエクスポート
wp db export --tables=wp_posts,wp_postmeta posts.sql

リビジョンと期限切れtransientの削除だけで、データベースが半分以下になることも珍しくありません。移行前の掃除は、そのまま移行後の表示速度改善にもつながります。

サーバー選びと移行のタイミング

移行を決めたら、次はどこへ移すかといつ実施するかです。ここを外すと、移行そのものが無駄になります。

移行先を選ぶときの確認項目

見落としやすいのが転送量です。画像の多いメディアサイトでは、記事数よりも画像の総容量が効いてきます。現在の月間転送量を管理画面で確認してから選んでください。

実施するタイミング

• 曜日：火〜木。金曜や連休前は、問題が出たときに対応できない
• 時間帯：アクセスが最も少ない時間。解析で確認してから決める
• 避ける時期：キャンペーン中、繁忙期、記事の公開予定日の直前
• 予備日：翌日を空けておく。DNS反映と事後確認のため

WithMediaのような学習系メディアでは、土日の早朝がアクセスの谷になります。自サイトの日別・時間帯別のアクセスを見て決めるのが確実です。

関係者への共有

移行日が決まったら、記事の更新担当や広告運用の担当に事前共有します。移行中に記事を更新すると、その内容が新サーバーに引き継がれず消えます。

【サーバー移行のお知らせ】
日時：2026年9月2日（火）6:00〜9:00
影響：この時間帯は記事の更新を停止してください
　　　閲覧は継続できます（表示が新旧どちらかになります）
反映完了：9月4日（木）を目処
連絡先：担当者名・連絡手段

この更新停止のお願いが抜けると、移行後に「書いたはずの記事が無い」という事故が起きます。作業前後の30分ずつを含めて、余裕を持った時間で伝えてください。

まとめ

WordPressの移行は「バックアップ → ファイルとDBを運ぶ → URLを置換 → 新サーバーで確認 → DNS切り替え」の順で進めます。最大の注意点は2つで、1つはDNSを切り替える前にhostsファイルで表示確認をすること、もう1つはURL置換にWP-CLIのsearch-replaceかBetter Search Replaceを使うことです。SQLの単純置換はシリアライズされた設定を壊します。移行後はパーマリンク設定を保存し直し、noindexが残っていないかを必ず確認してください。旧サーバーは1ヶ月ほど残しておけば、問題があってもすぐ切り戻せます。

よくある質問（FAQ）

移行にかかる時間はどれくらいですか？

小規模サイトなら作業自体は1〜2時間程度です。ただしDNSの切り替えが世界中に反映されるまで最大48時間かかるため、全体では2〜3日を見ておくと安全です。アクセスの少ない時間帯に作業し、切り替え後しばらくは表示を監視してください。

移行中にサイトが見られなくなりますか？

正しい手順なら、ほぼ停止時間なしで移行できます。旧サーバーを稼働させたまま新サーバーを構築し、hostsファイルで確認してからDNSを切り替えるためです。DNSの反映中は、閲覧者によって新旧どちらかのサーバーが表示されます。この間は記事の更新を止めてください。

URLの置換をSQLのREPLACEでやってはいけないのはなぜですか？

WordPressはウィジェットやテーマ設定を「シリアライズ」という文字数情報を含む形式で保存しています。単純な文字列置換をすると文字数の記録と実際の長さがずれ、設定が読み込めなくなります。WP-CLIのsearch-replaceやBetter Search Replaceはこの形式に対応しています。

移行後に記事が404になります。

リライトルールが再生成されていないためです。管理画面の「設定 → パーマリンク設定」を開き、何も変更せずに「変更を保存」を押してください。ほとんどの場合これで解決します。直らない場合は.htaccessが正しく転送されているか確認してください。

旧サーバーはいつ解約していいですか？

移行完了から1ヶ月ほど空けることを推奨します。移行直後には気づかない不具合が後から見つかることがあり、旧サーバーが残っていればすぐ切り戻せます。ドメインを変更した場合は、301リダイレクトを維持するために最低1年は旧環境を残してください。

あわせて読みたい関連記事

• WordPressが真っ白で表示されない原因と対処法
• Web制作のバックアップ運用ガイド
• WordPress 404エラーの原因と解決方法｜完全ガイド

AIスキルで、未来の自分をアップデート！

今なら完全無料でAIを学べる！

• 動画や実践で楽しく学べる：初心者でも安心のカリキュラム
• スマホ・PCどちらでもOK：好きな時間に学習できる
• 料金は一切ナシ：0円でAIスキルが身につく

目的に合わせて選べる「AI副業」「AI転職」「AI活用」の3コースを用意。副収入・キャリアチェンジ・日常の生産性アップまで、あなたのゴールに合わせてAIを学べます。

会員登録はカンタン30秒で完了します。まずは公式LINEから、無料でAI学習をスタートしましょう！