WordPressサーバー移行 完全ガイド｜手順・注意点・失敗例まで網羅

WordPressのサーバー移行は、「いつかやらないと…」と思いながらも、いざ取りかかると不安が一気に増える作業です。

「移行したらサイトが見られなくなる“ダウンタイム”って出るの？」
「DNSとかネームサーバーって、どこをどう触ればいいのか分からない…」
「移行後に404が増えたり、画像が消えたり、管理画面に入れなくなったらどうしよう」
「SEO評価が落ちて、アクセスが激減したら困る」
「メールやフォームが止まって、問い合わせを取りこぼしたら最悪…」
「プラグイン移行、手動移行、かんたん移行…結局どれが正解？」

こんな悩みを抱えたまま、見よう見まねで進めてしまうと、移行自体はできても「一部が動かない」「原因が分からない」という状態になりがちです。特に初心者ほど、作業の手順より“準備と確認”が抜けて失敗しやすいのがWordPress移行の怖いところ。

そこで本記事では、WordPressサーバー移行を 最短かつ安全に終えるための考え方と手順を、初心者にも分かるように整理しました。

• あなたに合う移行方法（かんたん移行／プラグイン／手動／代行）の選び方
• 移行前に決めるべき分岐（ドメイン・メール・外部連携）
• 失敗しないための事前準備（バックアップ・更新停止・互換性チェック）
• DNS切替のコツと、切替直後の“表示混在”の正しい対処
• よくある失敗例（404、500/503、画像が出ない、SSLループ、メール不達）の原因と解決策
• 移行後チェック（表示・機能・SEO・セキュリティ）と、旧サーバー解約前の最終確認

読み終えるころには、「何から始めて、どの順番で、どこを確認すればいいか」が明確になり、移行作業を“怖いイベント”から“管理できる手順”に変えられるはずです。
あなたのサイトが止まらず、SEOも守りながら、安心してサーバー移行を完了させましょう。

サイト引っ越し屋さん公式サイト

最初に結論：あなたの状況別「最短で安全」な移行ルート

WordPressのサーバー移行で「最短」かつ「事故りにくい」ルートは、次の3点でほぼ決まります。

• 移行先サーバーに“自動移行（かんたん移行）機能”があるか
• サイト規模（データ量・機能の複雑さ・止められなさ）
• ドメイン変更があるか（URLが変わるか）

迷ったら、まずは下の表で“あなたの最適解”を決めてから動くのが安全です。

ルート	体感の難易度	つまずきやすい点	向いている人
自動移行機能	低	対象外データ・特殊設定が移らない	初心者、標準的なサイト
プラグイン移行	中	容量制限・復元失敗・環境差	中小規模、ある程度操作できる
手動移行（ファイル＋DB）	高	DB設定・URL置換・権限・SSL	大規模/特殊構成、上級者
代行（プロ）	低（作業は任せる）	依頼範囲の抜け漏れ	止められないサイト、時間がない

レンタルサーバーの“自動移行機能”が使えるなら最優先

結論から言うと、初心者が一番ミスしにくいのは 移行先サーバーが用意している「かんたん移行」系の機能です。
多くのケースで、手動よりも工程が少なく、復旧も容易です ✅

自動移行が向いている典型例

• 1サイト運用で、構成がシンプル（ブログ・企業サイトなど）
• WordPress標準の仕組みで運用（特殊なサーバー設定が少ない）
• 「できるだけ短時間で、確実に移したい」

ざっくり手順（流れだけ先に掴む）

1. 移行先でドメインを追加（または仮URLで受け口を作る）
2. 移行元サイトの情報を入力して移行開始
3. テスト移行（可能なら）で表示・管理画面・フォームを確認
4. 本番移行 → 最終確認
5. DNS（ネームサーバー）切り替え

ここが落とし穴（自動移行でも要チェック）⚠️

• 移行対象外のデータがある
  例：.htaccess や wp-content 以外のファイル、バックアップ系プラグインのデータなど、サービスによって“移らない範囲”が明記されています。
• メールは別物になりやすい
  サーバーのメールを使っている場合、移行時に「メールアドレス／受信データ」まで自動で移るとは限りません。
• キャッシュ/WAF/リダイレクトなど サーバー側設定は引き継がれないことがある
  → 移行後に「表示はできるけど挙動が変」の原因になりがちです。

初心者向けのコツ

• 可能なら “テスト移行→本番移行” の順で進める
  「切り替える前に動作確認」ができるだけで安心感が段違いです。
• 移行後チェックは 重要ページ（TOP/人気記事/LP/お問い合わせ）から先に
  全部を一気に確認しようとすると、疲れてミスが増えます。

サイトが大きい／制限に当たりそうなら「手動」か「代行」を検討

自動移行が最優先とはいえ、すべてのサイトに万能ではありません。
次のどれかに当てはまるなら、早めに「手動」または「代行」へ寄せたほうが安全です。

“大きい/難しい”の目安

• 画像・動画が多く、データ量が大きい（アップロードが重い）
• 会員機能・決済・予約など、止まると困る機能がある
• カスタム投稿・独自プラグイン・特殊なリダイレクトなど、構成が複雑
• 移行手段（自動/プラグイン）の 容量制限や対象外に引っかかりそう

手動移行を選ぶべきケース（上級寄り）

• 大容量でプラグイン移行が現実的でない
• 特殊な構成があり、移行範囲を“自分で完全にコントロール”したい
  （ファイル・DB・設定を把握して移す必要がある）

代行を選ぶべきケース（初心者でも合理的）

• 売上や問い合わせに直結し、ダウンタイムが許されない
• 自分が作業する時間が取れない／失敗時の復旧が不安
• “サイト移行”だけでなく、メール・SSL・DNS・リダイレクトまで面倒を見てほしい

代行で失敗しないポイント（依頼範囲の抜けを防ぐ）

• 「どこまで含むか」を最初に言語化して渡す
  • DNS切替は誰がやる？
  • SSL設定は含む？
  • メール移行は含む？
  • ドメイン変更の301は含む？
• “移行後の動作確認”の範囲（フォーム/決済/会員ログイン等）もセットで決める

ドメイン変更の有無で難易度が一段上がる（ここで分岐）

サーバー移行は、実は 「URLが変わるかどうか」 で難易度が大きく変わります。
ここを曖昧にすると、SEOやアクセスに影響が出やすいです。

分岐はこの2つだけ

• A：ドメインそのまま（URLは同じ） → 難易度は上がりにくい
• B：ドメイン変更あり（URLが変わる） → 難易度が一段上がる

A：ドメインそのままの場合（やることの要点）

• 主作業は「新サーバーへ中身を移す」＋「DNS切替」
• 失敗しやすいのはこの3点
  • DNS反映のタイムラグで表示が混在する
  • SSL（https）周りの設定不足で警告が出る
  • キャッシュが残って古い表示が見える

👉 初心者は “旧サーバーをすぐ解約しない” のが鉄則です。
切替後もしばらく並行稼働できる状態だと、復旧が一気にラクになります。

B：ドメイン変更ありの場合（難易度が上がる理由）

• 追加で必要になる代表例
  • 301リダイレクト（旧URL → 新URL を正しく対応付け）
  • WordPress内部のURL置換（画像パス・リンクなど）
  • Search Consoleなど外部ツールの再設定

特に重要なのが 301リダイレクトの設計です。
雑にトップへ飛ばすと、ユーザー体験もSEOも崩れやすいので、基本は “旧1ページ→新1ページ” の対応表を作るのが安全です。

初心者がやりがちな危険ポイント

• WordPress内のURLを“適当な置換”で一括変更する
  → データ形式の都合で壊れることがあります（安全な手順が必要）。
  ここに不安があるなら、代行を選んだほうが結果的に安いことも多いです。

サイト引っ越し屋さん公式サイト

WordPressを移行したほうがいいサイン（乗り換え判断）

「移行すべきか迷う…」という時は、“体感”ではなく“症状＋数字”で判断すると失敗しにくいです。
ここでは初心者でも確認しやすいサインを、原因の切り分け→次の一手までセットで整理します。

表示が遅い・安定しない（速度/応答/エラーが増えた）

遅さの原因は「画像が重い」などサイト側のこともありますが、サーバー側がボトルネックになっているなら移行の価値が高いです。

移行を疑うサイン（体感＋見える症状）

• ページが開くまでに「間」がある（特に管理画面）
• 特定の時間帯だけ急に遅くなる
• 500 / 502 / 503 が出る、または「重大なエラー」が増えた
• 画像最適化やキャッシュを入れても改善が頭打ち

初心者でもできる“切り分け”

• 同じページを スマホ回線/別回線でも試す（回線の問題を除外）
• 管理画面 → サイトヘルスで警告が増えていないか確認
• 直近で入れたプラグインを一度停止して変化を見る（原因がサイト側の可能性）

次の一手（遠回りしない順）

1. まずは「画像圧縮・キャッシュ・不要プラグイン整理」で改善するか確認
2. それでも遅いなら、サーバーのCPU/メモリ不足・混雑の可能性が高い
3. サーバー側の問題が濃厚なら、上位プラン or 別サーバーへ移行が最短

✅ポイント：改善策をいくつも積むより、“サーバーの土台”を変えたほうが早いケースがあります。

容量・同時アクセス・リソース不足が見え始めた

WordPressは、記事が増えるほど「容量」よりも先に リソース（処理能力）が限界になりやすいです。

よくある不足パターン

• ディスク容量が上限に近い（特に画像・バックアップ）
• 同時アクセス時に表示が崩れる／タイムアウトが増える
• 管理画面の操作が重い（投稿編集、画像アップロードなど）

見落としがちな“増え続けるデータ”

• uploads（画像）：毎記事少しずつ増える
• バックアップ：自動保存で想像以上に溜まる
• ログ/キャッシュ：プラグインが蓄積することがある

チェックしやすい目安（ざっくりでOK）

• 画像が多いサイトで「容量が常にギリギリ」
• アクセス増のタイミングで 503 が出る
• 画像アップロードが途中で止まる/失敗する

次の一手（無駄打ちを減らす）

• 容量だけが原因なら
  → 画像整理・バックアップ世代数を減らす・外部ストレージ活用も選択肢
• 同時アクセスや管理画面の重さが主因なら
  → 移行（または上位プラン）で“処理能力”を確保したほうが早い

⚠️注意：容量に余裕があっても、処理能力が弱いと遅さは解決しません。

PHP/SSL/セキュリティ面の更新が追いつかない

これは移行判断でかなり強いサインです。
WordPressは推奨環境が更新されるため、古いPHP/DBのままだと安全面と互換性の両方で不利になります。

移行を強く検討したい状況

• サーバー側の制約で PHPのバージョンを上げられない
• SSL（HTTPS）の設定や更新が不安定（警告が消えない）
• セキュリティ機能（WAF・自動バックアップ等）が弱い/有料オプションだらけ
• サイトヘルスで「古いバージョン利用」警告が常に出る

初心者向けの理解（なぜ危ない？）

• 古い環境だと、最新テーマ/プラグインが動きにくくなる
• サポートが切れたバージョンは、脆弱性リスクが上がる
• 結果として「更新できない → 放置 → さらに危険」という悪循環になりがち

次の一手

• 「設定でPHPを切り替えられるサーバー」へ移行すると、運用が一気にラクになります
• セキュリティ面（無料SSL・WAF・バックアップ/復元）も、最初から含まれるサービスを選ぶと総合コストが下がりやすいです

✅ポイント：移行は面倒でも、“更新できる環境”を確保するのが長期的に最も安全です。

コストと性能のバランスが悪い（費用だけで決めない）

「安いから正解」とは限りません。特にWordPressは、月額以外の“隠れコスト”が効いてきます。

費用対効果が悪いサイン

• 月額は安いのに、必要機能がオプションで増えていく
• 復元（リストア）が有料、または難しくて不安
• 表示速度や安定性が悪く、機会損失（離脱・CV低下）が出ている
• サポートが弱く、トラブル時に時間を奪われる

比較するときの“見るべき項目”（月額以外）

• 自動バックアップの有無（世代数・復元のしやすさ）
• SSL（無料・自動更新か）
• WAF/セキュリティ機能が標準か
• サイト移行機能の有無（テスト移行できるか）
• サポート体制（問い合わせ手段・対応時間）

簡易判断表（どちらが得か）

状況	まず検討	移行の優先度
月額は安いが、遅くて離脱が増えている	移行	高
機能が足りずオプション課金だらけ	移行	高
今の環境で速度も安定も問題なし	現状維持	低
PHP/SSL/セキュリティ更新が詰んでいる	移行	最優先

💡結論：「月額＋事故リスク＋作業時間」まで含めたトータルで考えると、移行したほうが安いケースがよくあります。

サイト引っ越し屋さん公式サイト

移行前に整理する3つの分岐（ここが曖昧だと失敗する）

WordPressのサーバー移行で失敗が起きる典型は、作業手順そのものよりも 「前提条件が途中で変わる」 パターンです。

そこで最初に、次の3つだけは“確定”させてから動きます。

• ドメイン（URL）が変わるか
• メールはどこで運用しているか
• 外部連携（フォーム/決済/広告/解析/CDNなど）に何があるか

ポイントは、決める順番です。
おすすめは ①ドメイン → ②メール → ③外部連携（影響範囲が大きい順）です。

ドメインは「そのまま」か「変更」か

まずはここで難易度が変わります。
「サーバーだけ移す」のか、「サイトの住所（URL）も変える」のかは別問題です。

判断	影響範囲	やることが増える主な項目	初心者の事故ポイント
ドメインそのまま	小〜中	DNS切替、SSL、表示チェック中心	DNS反映の混在、SSL警告、キャッシュの誤認
ドメイン変更あり	大	301リダイレクト、URL置換、Search Console対応など	旧URLを新TOPへ雑に飛ばす、置換で崩壊、計測が途切れる

判断を早く確定させるコツ

• 「サーバーが不満だから乗り換える」だけなら、基本は ドメインそのまま が安全
• ブランド刷新・商標・ドメインが長すぎる等の理由で どうしても変える 場合は、移行作業の前に次を用意します

ドメイン変更ありの場合に、移行前に作るもの（これがないと高確率で迷子になります）

• URL対応表（旧→新）：主要ページからでOK（全部を一気にやらない）
• 301の実装場所：サーバー側（.htaccess等）か、別の仕組みか
• Search Consoleの対応方針：移転後にやる手続きがある（※URL変更時）

✅初心者向けの結論：
迷うなら 「まずはドメインそのまま移行」→落ち着いてからドメイン変更 の2段階もアリです。
一発で両方やると、トラブル時に原因特定が難しくなります。

メール運用はどこか（サーバー／Google Workspace等）

サーバー移行で“静かに致命傷”になりやすいのがメールです。
サイトが表示できても、メールが止まると問い合わせ・通知・決済メールなどが落ちます。

ここは 「メールの実体はどこにあるか」 でやることが変わります。

まず確認すること（初心者でも一発で整理できる質問）

• 独自ドメインのメール（例：info@あなたのドメイン）を使っている？
• そのメールは サーバーのメール機能？それとも Google Workspace / Microsoft 365？
• 送信フォーム（お問い合わせ）や自動返信は、どのメールアドレスから送っている？

パターン別：移行時の注意点

1) サーバーのメールを使っている場合

• DNS切替のタイミングで MXレコード（メールの行き先） も変わることがある
• メールボックスの移行（過去メールを残すか）も検討が必要
  • 「受信できればOK」なのか
  • 「過去メールも新環境で見たい」なのか
    ここを曖昧にすると、後から復旧が大変です

2) Google Workspace等を使っている場合

• やるべきことはシンプルで、基本は MXがGoogleのまま維持されることを確認 するだけ
• ただし、次のケースは要注意です
  • ネームサーバーを変更する（例：Cloudflareへ移す等）
    → DNSレコードを“全部”引き継がないと、MXが消えてメール停止が起こり得ます

初心者向けの安全策（メール停止を防ぐ）

• DNS周りを触る前に、現状のDNSレコードを控える
  最低限、A/AAAA、CNAME、MX、TXT（SPF/DKIM/DMARCが入っていることが多い）
• ネームサーバー変更を伴うなら
  「先にDNSレコードを新しいDNSへコピー → その後にネームサーバー変更」 の順にする
• 移行直後は、必ずテストをセットで実施
  • 外部メール（Gmailなど）→ 独自ドメインへ送信して受信できるか
  • 独自ドメイン → 外部へ送信できるか
  • フォーム送信 → 管理者通知・自動返信が届くか

外部連携の洗い出し（フォーム/決済/広告/解析/CDN）

ここをやらずに移行すると、移行後にこうなりがちです。

• 「ページは見えるけど問い合わせが来ない」
• 「決済は通ったのに通知が届かない」
• 「広告の審査が外れた／収益が落ちた」
• 「アクセス解析が止まって原因が追えない」

そこでおすすめは、移行前に “連携台帳”を1枚作る ことです（メモ帳でもOK）。

連携台帳に書く項目（これだけで復旧が早くなる）

• 連携サービス名（例：フォーム、決済、広告、解析、CDN）
• 管理画面URLとログイン方法
• どこにドメイン/URLが登録されているか（設定画面名）
• 移行後にやる作業（チェック項目）
• テスト方法（どうなれば成功か）

連携先の棚卸しチェック（後で困りやすい順）

フォーム・自動返信

移行後に最優先でテストする対象です（機会損失が直撃します）。

チェック例

• 送信先メールが正しい（宛先の変更が必要な場合あり）
• 自動返信が届く（差出人・SPFなどで迷惑メールに落ちる場合も）
• reCAPTCHA等のキーがドメイン変更で影響しないか（導入している場合）

テストの型（おすすめ）

• ①自分で送る → ②別メールでも送る（迷惑メール判定の差を見る）

決済・会員

「表示」よりも 裏側の通知（Webhook等） が止まると事故になります。

チェック例

• 決済完了後の戻り先URL（サンクスページ）が正しい
• 会員ログイン・メール通知・自動更新が動く
• APIキーやWebhookの許可ドメイン、IP制限がある場合は更新

初心者向けアドバイス

• 本番で試せない場合は、サービス側の「テストモード」があるか確認

広告タグ

広告は「貼ってある」だけでは不十分で、ドメインの整合が求められることがあります。

チェック例

• 広告タグが移行で消えていない（テーマ差し替えで消えることがある）
• 表示速度が悪化していない（広告の読み込みが遅いと体感が落ちる）
• ドメイン変更時は、広告側のサイト登録や審査条件に抵触しないか確認

GA・GTM

解析は移行後のトラブル原因を追う生命線です。まず“計測が続いているか”を確保します。

チェック例

• GAの計測ID（G-から始まる）が出力されている
• GTMのコンテナが正しく読み込まれている
• ドメイン変更時は、参照元が分断されないか（必要ならクロスドメインの検討）

Search Console

ドメインが同じなら、基本は大きく変わりません。
ドメイン変更がある場合のみ、移転の手続きや監視が重要になります。

チェック例

• 新ドメインでプロパティを用意（必要な場合）
• 重要URLのインデックス状況を確認
• 301が正しく効いているか（URL検査で確認）

CDN・WAF

見落とすと「新サーバーへ切り替えたのに古い表示」「403が出る」などの原因になります。

チェック例

• CDNキャッシュのクリア（切替直後は特に）
• WAFのルールで管理画面やAPIが弾かれていないか
• ネームサーバー変更を伴う場合は、DNSレコードが欠けていないか再確認

サイト引っ越し屋さん公式サイト

事前準備：移行の成否は8割ここで決まる

WordPressのサーバー移行は、作業手順そのものより 「準備の抜け」 で失敗します。
ここでは初心者でも迷わないように、“集める→止める→守る（バックアップ）→整える（移行先）” の順で整理します。

必要な情報一覧（ログイン・FTP/SSH・DB・DNS・SSL）

移行当日に「ログインできない」「どこがDNSかわからない」が起きると詰みます。先に全部そろえます。

1) 管理画面の入口を4つ確保（最重要）

• WordPress管理画面（/wp-admin）
• レンタルサーバーの管理パネル
• FTP / SFTP / SSH（ホスト名・ユーザー名・パスワード・ポート）
• DB管理（phpMyAdmin等のURL）

2) データベース情報（手動移行・復旧で必須）

• DB名
• DBユーザー名
• DBパスワード
• DBホスト名
  ※ これらは多くの場合 wp-config.php に書かれています。

3) DNS（ドメインの行き先）情報

• ドメイン管理会社（レジストラ）のログイン
• いまの ネームサーバー（NS） がどこか
• DNSレコードの控え（最低限：A/CNAME/MX/TXT）

4) SSL（https）関連

• 現在 https で見られているか
• 強制リダイレクトの有無（http→https、wwwの有無）
• CDN/WAFを使っているか（使っているなら設定画面のログインも）

あるとさらに安心（トラブル時に効く）

• WordPressのプラグイン一覧（スクショでOK）
• .htaccess を触っている場合は内容をメモ
• フォーム/決済/広告/解析の管理画面リンク（別メモ）

更新停止（コンテンツ凍結）のタイミングと周知

移行でよくある事故は「移行中に記事更新して差分がズレる」ことです。
初心者ほど、いったん凍結したほうが安全です。

凍結が必要な理由（初心者向けに一言で）

• 移行は“コピー”なので、移行後に旧サイトで更新すると 新旧で内容が食い違う ためです。

凍結の基本ルール

• 凍結開始：最終バックアップ直前
• 凍結解除：新サーバーで表示・投稿・フォームがOKになった後

凍結のやり方（サイト種別で変える）

• ブログ中心：
  • 記事公開を止める（下書きに回す）
  • コメントを一時停止（必要なら）
• 企業サイト（問い合わせが重要）：
  • 移行時間を短く取り、フォーム送信テストを最優先
• EC/会員/予約：
  • 可能ならメンテ画面にして注文を止める
  • 止められないなら 代行や段階移行も検討（リスクが跳ね上がる）

周知（小さくても効果大）

• チームがいるなら、短いテンプレでOK
  • 「◯日◯時〜◯時は更新しない」
  • 「急ぎの修正はSlack/LINEへ」
• 自分1人でも、メモに書いておく（焦ると忘れます）

フルバックアップの取り方（ファイル＋DB＋設定）

移行の保険はバックアップです。
ポイントは 「作る」だけでなく“戻せる形か” です。

おすすめのバックアップ方針（初心者向け）

• 二重化する：
  1. サーバー提供の自動バックアップ（あれば）
  2. 自分で取るバックアップ（ファイル＋DB）

ファイルのバックアップ

• FTP/SFTPでダウンロード（容量が大きいと時間がかかるので余裕を確保）
• 可能なら圧縮（zip）して転送回数を減らす

DBのバックアップ

• phpMyAdmin等でエクスポート（.sql）
• できれば「文字コード」「圧縮」設定を確認（失敗しにくくなる）

バックアップの“品質チェック”（ここが独自性ポイント）

• サイズが極端に小さくないか（途中で失敗しているサイン）
• .sqlが開けるか（空ファイルでないか）
• できればテスト環境に復元してみる
  → これができると、移行も復旧も成功率が一気に上がります ✅

最低限押さえるバックアップ対象

/wp-content（themes/plugins/uploads）／wp-config.php／.htaccess／DB（.sql）

この5つを押さえれば、最低限「戻れる」可能性が高いです。

• /wp-content/
  • themes：テーマ
  • plugins：プラグイン
  • uploads：画像などのメディア
• wp-config.php
  • DB情報や各種設定が入る重要ファイル
• .htaccess
  • リダイレクトやパーマリンク設定が関係（環境によっては無い/別場所）
• DB（.sql）
  • 投稿・固定ページ・ユーザー・設定が入る

💡補足：WordPress本体（/wp-admin 等）は再取得できますが、wp-content とDBは再現できません。

移行先サーバー側の下準備（PHP/DB/容量/権限/キャッシュ）

移行先の準備が甘いと、「移したのに動かない」が起きます。
初心者は “移す前に、受け口を整える” のが鉄則です。

事前にやること（チェックリスト）

• PHPバージョンを確認し、必要なら設定（移行元より古いのは避ける）
• DB（MySQL/MariaDB）の用意（新規作成・ユーザー・権限）
• 容量と転送量に余裕があるか確認
• キャッシュ機能やWAFが強い場合、最初は控えめに（移行中の誤検知を避ける）
• 可能なら「テスト用URL」や「一時表示」で確認できる状態にする

互換性チェック（WordPress・PHP・MySQL/MariaDB）

初心者が押さえるべきは「推奨環境」と「現実の互換性」の両方です。

最低限の考え方

• 移行先は、WordPressが推奨する環境に近いほど安全
• ただし、サイト側（テーマ/プラグイン）が古いと 新しいPHPで動かない ことがある

チェックの順番（失敗しにくい）

1. 現在のPHP/DBバージョンを把握
2. 主要プラグイン（セキュリティ・キャッシュ・決済・会員系）の対応状況を確認
3. 可能ならテスト環境で動作確認
   • 管理画面ログイン
   • 表示崩れ
   • フォーム送信
   • 画像アップロード

よくある落とし穴

• PHPを上げたら管理画面が真っ白（互換性問題）
• 画像最適化やキャッシュ系が新環境と衝突
• セキュリティ系が移行作業を攻撃と誤判定

➡️対策：移行直後は、キャッシュ・最適化系プラグインを一時停止して検証すると切り分けが速いです。

大容量サイトの対策（圧縮・分割・転送経路の選択）

大容量サイトは、移行そのものより 転送 がボトルネックになります。
初心者は「時間切れ」「途中失敗」を防ぐ工夫が重要です。

まずやる“軽量化”（効果が大きい順）

• バックアップ世代数を減らす（バックアッププラグインの保存物を整理）
• キャッシュを削除（キャッシュ系プラグイン/CDN）
• 不要な画像・使っていないテーマ/プラグインを整理

転送で失敗しにくい工夫

• 可能なら SFTP/SSH を使う（FTPより安定しやすい）
• フォルダ単位で分けて転送（例：uploadsを月別に）
• zip圧縮して転送回数を減らす（ただし解凍できる環境か確認）

移行作業の時間帯

• 深夜〜早朝などアクセスが少ない時間に寄せる
• 作業中は、更新停止・注文停止などのルールを徹底

現実的な判断ライン

• 「転送が何時間もかかりそう」
• 「止められない機能がある」
  この2つに当てはまるなら、代行やサーバーの自動移行機能を優先した方が結果的に早いです。

サイト引っ越し屋さん公式サイト

移行方法の選び方：3+1パターンを比較

WordPressのサーバー移行は、「どの方法を選ぶか」で難易度と失敗率が大きく変わります。
初心者ほど、最初に“選び方の軸”を持つのが安全です。

ここでは、代表的な 3+1パターン（A〜D）を、目的別にわかりやすく整理します。

方法A：サーバー提供の“かんたん移行”

移行先サーバーの管理画面から、必要情報を入力して移行する方法です。
多くの場合、初心者にとって 最短・最小リスクになりやすいのがこれです。

向いている人

• 初めての移行で、できるだけ迷いたくない
• ブログ・企業サイトなど、一般的な構成
• 多少の時間制約はあるが、作業の安全性を優先したい

強み（安心ポイント）

• 手順が少なく、設定ミスが起きにくい
• サーバー側が用意したフローなので、トラブル時の切り分けがしやすい
• テスト移行ができるサービスなら、切替前に動作確認できる（成功率が上がる）✅

注意点（ハマりどころ）

• サーバー側の仕様により、移行対象外が出る場合がある
  例：特殊なリダイレクト設定、独自のサーバー設定、外部連携の一部など
• メール運用やDNS（ネームサーバー変更）が絡むと、別途確認が必要
• 移行後の「細かい調整」（キャッシュ・WAF・SSL・高速化設定）は結局必要になることが多い

初心者向けのコツ

• 可能なら テスト移行 → 本番移行 の順にする
• 切替前に最低限チェックするページを決めておく
  • TOP / 主要記事 / お問い合わせ / 重要LP の4つだけでもOK

方法B：移行プラグインで丸ごと移す

WordPressにプラグインを入れて、サイトをパッケージ化（バックアップ化）→別環境に復元する方法です。
「自動移行がない」「サーバーをまたいで移す」時に便利ですが、容量と環境差がカギになります。

向いている人

• WordPressの基本操作（プラグイン導入・管理画面操作）ができる
• 中小規模のサイトで、データ量が極端に大きくない
• 自動移行が使えないが、手動移行は避けたい

強み

• 手動移行より手順が少ない（DB操作の比率が減る）
• “同じサイトを複製”にも使える（検証環境づくりなど）

注意点（ここで詰まりやすい）

• アップロード上限（サーバー側の制限）に引っかかりやすい
  → ファイルが大きいと、インポートできずに止まることがあります
• 環境差で不具合が出ることがある
  例：PHPバージョン差、キャッシュ系/セキュリティ系プラグインの干渉
• “非公式の改造版”などに頼ると、セキュリティ面で危険になり得ます⚠️
  → 公式の手段（サーバー設定の見直し・正規の拡張機能・別方法）で解決するのが安全です

初心者向けのコツ（成功率が上がる順）

• 移行中だけ キャッシュ/最適化系を一時停止して検証する
• まずは「テスト用の空サイト」に復元して動作確認
• ファイルが大きい場合は、
  • サーバー側の上限を上げる（可能なら）
  • もしくは 方法A / 方法C / 方法Dへ切り替える判断を早めにする

方法C：FTP＋データベースで手動移行

ファイル（WordPress一式）とデータベース（投稿/設定など）を自分で移す方法です。
自由度が高い反面、初心者には難易度が上がります。

向いている人

• 大容量サイトで、プラグイン移行が成立しない
• 構成が特殊で、移行範囲を自分で完全にコントロールしたい
• いざという時に自力で復旧したい（中〜上級）

強み

• 制限を受けにくく、大規模でも対応しやすい
• 仕組みが理解できるので、トラブル対応力が上がる

注意点（初心者がやらかしやすい所）

• DB情報（wp-config.php）や権限設定ミスで、表示できない
• URLの扱い（特にドメイン変更あり）で壊しやすい
• 転送途中の欠損（アップロード漏れ）で「画像だけ出ない」が起きる

初心者が選ぶなら“条件付き”がおすすめ

• 「ドメインそのまま」かつ「構成が比較的シンプル」
• さらに、戻せるバックアップが確実に取れている
  この2つが揃わないなら、無理に手動へ行かない方が安全です。

方法D：移行代行（プロに任せる）

作業を外部に依頼して、設計〜移行〜動作確認まで任せる方法です。
「お金で時間と事故リスクを買わない」ための選択肢として、初心者ほど合理的な場面があります。

向いている人

• 問い合わせ・売上があり、止まると困る
• サイトが複雑（会員/決済/予約/多言語/大量記事など）
• ドメイン変更も同時にやりたい
• 作業時間が取れない／復旧が不安

強み

• ダウンタイム最小化、トラブル対応込みで進められることが多い
• メール・DNS・SSL・301など、周辺領域も含めて整理できる

注意点（代行で失敗しないコツ）
依頼時は「移行します」だけだと、範囲の抜けが起きがちです。
最低でも次の確認を入れると安心です。

• どこまで含む？（例：DNS切替／SSL／メール／フォーム／301／計測）
• 動作確認の範囲は？（重要ページ、フォーム送信、会員ログイン等）
• 納品条件は？（「表示できた」で終わりか、「チェック完了」までか）
• 緊急時の復旧方針は？（旧環境へ戻す基準・作業者の連絡手段）

迷った時の“最短”の決め方（初心者向け）

最後に、選択を一発で決める基準を置いておきます。

• 移行先にかんたん移行がある → まずは 方法A
• 自動移行がない / 小〜中規模 → 方法B（ただし容量制限に注意）
• 大容量 / 特殊構成 / プラグイン移行が無理 → 方法C か 方法D
• 止められない（売上・問い合わせ直結） → 最初から 方法D が安全

💡結論：初心者は「AでできるならA」。無理そうなら「D」も現実的。
“がんばってCで失敗する”のが一番コスト高になりやすいです。

サイト引っ越し屋さん公式サイト

方法A：レンタルサーバーの「かんたん移行」で引っ越す手順

「かんたん移行」は、移行先サーバーの管理画面で必要情報を入力すると、サーバー側が WordPress（データベース＋wp-content中心）を自動コピーしてくれる方式です。
初心者でも成功しやすい反面、“対応条件”の見落としでつまずきが起きやすいので、順番どおり進めましょう。

対応条件・非対応になりやすいケース

まず最初に、「このサイトは“かんたん移行”でいけるか」を判断します。ここを飛ばすと、途中で止まってやり直しになりがちです。

基本的に通りやすい条件（成功しやすい）

• 移行元サイトが 通常のWordPress（会員・決済・予約などの強いカスタムが少ない）
• 移行元URLが 外部からアクセス可能（メンテ画面や制限がない）
• WordPress管理画面にログインでき、ユーザー名・パスワードが正しい
• 容量が極端に大きくない（画像・バックアップが膨大だと時間がかかる）

非対応・失敗になりやすい代表例（先に確認）

• 移行元サイトに Basic認証（ID/パスが別途必要）やアクセス制限がある
• セキュリティ系プラグインで ログイン制限（IP制限・回数制限）が強い
• WAFが厳しく、移行ツールのアクセスがブロックされる
• WordPressがサブディレクトリ配下で、サイトURLの指定が複雑（例：/blog/ など）
• 画像やバックアップが巨大で、移行処理がタイムアウトしやすい
• メールやDNSも同時にガッツリ変える予定（事故要因が増える）

💡迷ったら：
「表示されるけど中身が完全ではない」状態が一番つらいので、テスト移行が可能なら必ずテスト→本番の順で進めるのがおすすめです。

テスト移行（ステージング）で先に動作確認する

テスト移行（ステージング）が使える場合、成功率が一気に上がります。
理由はシンプルで、DNSを切り替える前に“新サーバーで動くか”を確認できるからです。

テスト移行で確認するべき最小セット（これだけでOK）

• 表示：TOP／主要記事（2〜3本）／カテゴリ一覧
• 管理画面：ログインできる／記事編集が開く／画像アップロードができる
• 機能：お問い合わせフォーム送信（通知・自動返信まで）
• SSL：httpsで表示できる（または本番切替後に問題なく設定できる見込み）

テスト移行のコツ（初心者向け）

• テスト環境では、キャッシュ系・最適化系が邪魔をすることがあります
  → もし挙動が変なら、一時停止して切り分けすると原因特定が速いです。
• テストでOKでも、本番切替直前に更新が入ると差分が出ます
  → 本番移行前に コンテンツ凍結（更新停止）をはさむと安全です。

本番移行の流れ（入力項目の意味と注意点）

サーバーによって画面名は違いますが、入力する項目はだいたい共通です。
ここでは「なぜその項目が必要か」を理解しながら進めます。

本番移行の基本ステップ（王道の順番）

1. 移行先サーバーで、移行先ドメイン（または対象サイト）を用意する
2. 管理画面の「かんたん移行」を開き、移行元情報を入力
3. 移行を開始し、完了まで待つ（途中で閉じてもOKな場合が多い）
4. 新環境にアクセスし、動作確認
5. 問題なければ DNS切替へ進む（最終段階）

よくある入力項目は次のとおりです。

• 移行元URL：コピー元のサイトURL
• サイトURL：移行先で公開したいURL（www有無・サブディレクトリ含む場合あり）
• 移行元ユーザー名 / パスワード：WordPress管理画面に入るための情報
• DB名 / DBユーザー / DBパスワード：移行先で使うDB（自動生成される場合もある）
• 任意プラグイン（キャッシュクリア等）：サーバー側の運用をラクにする補助（任意）

URL・管理者情報・接続情報でつまずくポイント

ここは初心者が詰まりやすい“地雷原”なので、先に対策を置いておきます。

URLでのつまずき

• 「wwwあり／なし」を混ぜる
  → 移行先で統一（あとでリダイレクト地獄になります）
• https と http を混ぜる
  → 本番は基本 https。移行中は一時的に http でも、切替後に必ず整えます。
• サブディレクトリ（例：example.com/blog）を忘れる
  → 入力欄に“/blog”まで必要なケースがあります。

管理者情報でのつまずき

• WordPressにログインできるのに、移行で弾かれる
  → セキュリティ系（ログイン制限、2段階認証、WAF）が原因のことが多いです。
  ✅対策：移行作業中だけ、制限を一時的に緩める／専用の管理者ユーザーを作る。

接続でのつまずき（移行元サイト側の事情）

• Basic認証がかかっている
• 海外IPやBot対策でブロックされる
• メンテモードで一般アクセスができない
  → こうなると“かんたん移行”が成立しないことがあるため、先に解除・調整が必要です。

移行ステータスの見方／失敗時の切り分け

移行が止まったときは、闇雲にやり直すより 原因を4つに分けると早いです。

症状	原因の当たり	まずやること
すぐ失敗する	認証・URLミス	URL、ユーザー名/パスワードを再確認（コピペ推奨）
途中で止まる/長い	容量・タイムアウト	画像/バックアップ整理、時間帯変更、別方式検討
完了したのに表示が変	キャッシュ・URL整合	キャッシュ削除、パーマリンク再保存、https整備
管理画面だけ入れない	セキュリティ/リダイレクト	ログイン制限解除、リダイレクト設定確認

切り分けの順番（初心者でも迷わない）

1. 入力ミス（URL・認証）を疑う
2. 次に 移行元の制限（Basic認証、WAF、ログイン制限）
3. 次に 容量・時間（画像やバックアップの多さ）
4. 最後に 移行後の調整不足（キャッシュ、SSL、パーマリンク）

✅“やり直し”の前にやるべきこと

• 重要データ（uploadsやDB）が巨大なら、いきなり連続で試さない
  → 無駄に負荷をかけ、ブロックされることがあります。
• テスト移行があるなら、テストで再現するか確認してから本番へ戻る

切替前の最終チェック（DNS変更に進む前に）

DNS切替は「後戻りはできるが、混乱しやすい工程」です。
切替前に、次だけ確認すれば失敗を大幅に減らせます。

切替前チェックリスト（最低限）

• 新サーバー側で TOP/主要ページが表示できる
• 管理画面にログインできる
• パーマリンク設定を再保存した（設定→パーマリンク→保存）
  ※これだけで404が直ることが多いです
• 画像が表示される（uploadsが移っている）
• お問い合わせフォームの 通知・自動返信が届く
• 可能なら キャッシュ削除（サーバー機能／プラグイン／CDN）

DNS切替に進む前の“安全策”

• 旧サーバーはすぐ解約しない
  → 切替後に「何か足りない」が出たとき、戻したり照合できます。
• 切替直前に更新があるなら、短時間でいいので 更新停止（凍結）を入れる
  → 新旧で内容がズレる事故を防げます。

サイト引っ越し屋さん公式サイト

方法B：プラグイン移行（初心者〜中級）

プラグイン移行は、ざっくり言うと 「移行元でバックアップ（またはパッケージ）を作って、移行先で復元する」 方法です。
サーバーの“かんたん移行”が使えないときの有力候補ですが、成功のカギは プラグイン選び（方式） と 容量制限の扱い にあります。

プラグイン選定の基準（容量制限・復元方式・速度）

プラグイン移行は、同じ「移行プラグイン」でも“中身”が違います。初心者はまず 方式 を見てください。

方式（イメージ）	代表的な特徴	つまずきやすい所	向いているケース
バックアップファイルを作って「アップロード→復元」	管理画面中心で完結しやすい	アップロード上限、タイムアウト	小〜中規模／操作が簡単がいい
パッケージ（ファイル＋DB）を作って「再インストール」	まとめて移せる／空の環境でも復元できるタイプあり	手順がやや多い／サーバー権限	中規模〜／確実に丸ごと移したい
サーバー間転送（外部サーバー等を使って移すタイプ）	大容量でも通りやすい設計のものがある	移行先側の準備（WP設置等）	大容量／旧サーバー負荷を抑えたい

選定で見るポイントはこの3つです。

• 容量制限：インポートが「アップロード型」だと、サーバー側の上限（upload_max_filesize等）に左右されやすい
• 復元方式：
  • 「移行先にWordPressを用意して復元」なのか
  • 「空の環境でも復元できる」タイプなのか
• 速度・安定性：
  • “ダウンロード→アップロード”が必要だと回線と制限に影響される
  • 旧サーバーに負荷がかかりすぎると、途中で止まりやすい

補足：いくつかのプラグインは URL置換（検索置換）やシリアライズ対応 を備えており、移行後のリンク切れリスクを下げられます。これは初心者ほど重要です。

容量制限に当たる時の回避策（分割/メディア整理/別手段）

容量制限は「プラグインの問題」というより、だいたい サーバー側の上限が原因です。対処は次の順で進めると、無駄がありません。

1）まず“軽くする”（最も安全で確実）✅

• キャッシュ削除（キャッシュ系プラグイン／CDN）
• バックアップの世代を減らす（バックアッププラグインの保存物）
• 使っていないテーマ・プラグイン削除
• 重すぎる画像の整理（不要画像、重複画像）

2）分割する（メディアだけ別扱いにする）

• 可能なら「メディアを含めないバックアップ」を先に復元して、あとからメディアを追加
  → 一発で巨大ファイルを通そうとして詰まるのを避けられます。

3）上限を上げる（サーバー側で解決）

• 多くの場合、次の設定値がボトルネックになります（名前だけ覚えればOK）
  • upload_max_filesize（アップロード上限）
  • post_max_size（POST上限）
  • memory_limit（メモリ）
  • max_execution_time / max_input_time（処理時間）
• 初心者は、無理に自分で編集せず サーバーサポートに相談が安全です（ログが出るので話が早いです）。

4）別手段へ切り替える（時間の節約）

• 大容量なら、サーバー間転送型のプラグインを検討する（旧サーバー負荷を抑える設計のものがある）
• それでも厳しい場合は、手動移行や代行へ切り替えた方が結果的に早いです。

移行できる範囲・できない範囲（“丸ごと”の落とし穴）

「丸ごと移行」と言っても、移るのは基本的に WordPressの中身です。
初心者が見落としやすい“移らないもの”を先に知っておくと、移行後の混乱が減ります。

多くのプラグイン移行で移るもの

• 投稿／固定ページ／カテゴリ等（DB）
• テーマ／プラグイン（wp-content）
• 画像などのメディア（uploads）
• ユーザー情報（移行方式によっては上書きされることも）

基本的に移らない（別途対応が必要）⚠️

• DNS（ネームサーバー／Aレコード等）
• SSL証明書の扱い（httpsの設定）
• メール（MX・送受信データ）
• サーバー独自設定（WAF、リダイレクト、Cron、.htaccessの一部など）
• 外部連携の管理画面設定（決済、広告、計測、Webhook等）

つまり、移行後に「サイトは見えるけど…」となりやすいのは、メール／フォーム／決済／計測あたりです。
プラグイン移行後は、これらを“動作テスト”で潰すのが鉄板です。

手順：エクスポート → 新環境用意 → インポート

ここからは、プラグインが違っても通用する 共通の成功手順です。
（細部のボタン名は違っても、流れはほぼ同じです）

ステップ0：移行前の最低条件（1分で確認）

• 移行元・移行先ともに、WordPress管理画面に入れる
• 移行先は「空のWordPress」（新規インストール済み）を用意できている
• 可能なら作業中は更新を止める（差分が出るのを防ぐ）

ステップ1：移行元でエクスポート（バックアップ作成）

• プラグインをインストール→有効化
• バックアップ（またはパッケージ）を作成
• ファイルの保管先を決める
  • PCに保存する
  • もしくはリモートストレージへ（対応している場合）

✅コツ：作成後にファイルサイズが極端に小さくないかだけ確認すると、失敗に早く気づけます。

ステップ2：移行先で新環境を用意（受け口）

• 新サーバーにWordPressをインストール
• 移行元と同じ（または近い）PHPバージョンにする
  → 互換性トラブルを減らせます。
• 同じ移行プラグインをインストール→有効化

ステップ3：インポート（復元）

• バックアップをアップロードして復元
  または、パッケージを使って復元（方式により異なる）
• 復元後、表示確認へ

ステップ4：動作確認（最短で済ませる）
初心者は「全部チェック」で疲れます。まずはこの順でOKです。

1. TOP表示
2. 主要ページ2〜3本
3. 管理画面ログイン
4. お問い合わせフォーム送信（通知・自動返信）

インポート後にログイン情報が変わる場合の注意

プラグイン移行は、ユーザー情報も移すことが多いです。ここで「ログインできない」が起きがちです。

よくある原因

• 移行先で作った管理者が、復元で上書きされた
• 移行元のユーザーがそのまま移ったため、ログインすべきIDが変わった
• セキュリティ系プラグインがログインをブロックしている

初心者向けの対処（上から順に）

• まずは 移行元と同じID/パスでログインを試す
• ダメなら、ログイン画面で パスワード再発行（メール受信ができる状態が前提）
• それでもダメなら、いったんセキュリティ系プラグインを停止して切り分け
  （移行直後は誤判定が起きることがあります）

💡地味に効く予防策：
移行前に「移行専用の管理者ユーザー」を1つ作っておくと、詰まりにくいです。

移行後に必ずやる設定（パーマリンク/キャッシュ/再ログイン）

復元直後は「見えるけど不安定」になりやすいです。最後に整えて完成させます。

必ずやる3点セット（初心者の定番）✅

• パーマリンクの再保存
  設定 → パーマリンク → 何も変えずに「保存」
  → 404が直ることが多いです。
• キャッシュ削除
  • キャッシュ系プラグイン
  • サーバー側キャッシュ
  • CDN（使っていれば）
    → 古い表示が残る混乱を防げます。
• 再ログイン
  一度ログアウトして、管理画面の挙動が安定するか確認

追加で確認したい（トラブル予防）

• 設定 → 一般：
  • WordPressアドレス（URL）
  • サイトアドレス（URL）
    が意図したものになっているか（https、www有無）
• 画像が出ているか（uploadsが欠けていないか）
• フォーム通知・自動返信が届くか（迷惑メールも確認）
• 重要な外部連携（広告・計測・決済）が動いているか

最後に、ドメインそのまま移行なら DNS切替に進みます。
この時点で「新環境で問題なく動く」状態にしておくのが、最短で安全です。

サイト引っ越し屋さん公式サイト

方法C：手動移行（FTP＋DB）（中級〜上級）

手動移行は、WordPressの 「ファイル」 と 「データベース（DB）」 を自分で移して、新サーバーで動く状態に組み直す方法です。自由度が高いぶん、1つのミスが「真っ白」「DB接続エラー」「画像だけ出ない」につながります。
成功率を上げるコツは、“作業を8つに分割して、各工程で確認ポイントを入れる” ことです。

この方法が向くケース（大規模・特殊カスタム・プラグイン不可）

次に当てはまるなら、手動移行が現実的です。

• データ量が大きい（画像・動画・DBが重く、プラグイン移行が通りにくい）
• 特殊な構成（独自カスタム、複数サイト、サブディレクトリ配下など）
• 移行プラグインを使えない（制限・ポリシー・相性・セキュリティ要件）
• トラブル時に自力で復旧できるよう、構造を把握したい

逆に、止められない決済/会員/予約などが絡む場合は、手動移行は難易度が上がります（作業時間と影響範囲が増えるため）。その場合は代行や段階移行も検討が安全です。

手順1：旧サーバーからファイル一式を取得

基本は FTP/SFTP（できればSFTP）や SSH でダウンロードします。
最初に “全部取る” か “必要部分だけ取る” で迷いがちですが、初心者は 「丸ごと」＋「必須だけ別途確認」 が安全です。

必須ディレクトリの確認

uploads（画像）／themes（テーマ）／plugins（プラグイン）

最重要は wp-content 配下です。ここが欠けると、表示崩れや画像欠落が起きます。

• wp-content/uploads/：画像・PDFなどのメディア
• wp-content/themes/：テーマ（子テーマ含む）
• wp-content/plugins/：プラグイン一式

転送ミスを防ぐ小ワザ

• フォルダ単位で分けて落とす（例：uploads → themes → plugins）
• 大容量なら、可能ならSSHで zip してから落とす（転送回数を減らす）
• 転送後に「ファイル数」と「容量」をざっくり照合（体感より効きます）

手順2：データベースをエクスポート（.sql）

DBには、投稿・固定ページ・設定・ユーザー・プラグイン設定が入っています。
エクスポートは、管理画面（phpMyAdmin等）か、SSHがあるならコマンドが安定です。

初心者向けの目安

• DBが軽い → phpMyAdminでも通りやすい
• DBが重い／タイムアウトしがち → SSH（WP-CLIやmysqldump）が安定

必ずやること

• .sql を保存したら、ファイルサイズが極端に小さくないか確認
• 可能なら圧縮して保管（.sql.gz など）

手順3：新サーバーでDB作成・ユーザー権限設定

新サーバーで次を作ります。

• データベース（DB）
• DBユーザー
• そのユーザーにDBへの権限付与

ここで詰まる典型

• DB名は合っているのに、権限が足りず接続できない
• DBホスト名（localhost とは限らない）が違う

この段階で「DBの接続情報」を控えておくと、次の wp-config.php がスムーズです。

手順4：ファイルをアップロード（転送ミスを防ぐ）

旧サーバーから取ったファイルを、新サーバーの公開ディレクトリ（例：public_html など）へアップロードします。

よくある失敗

• uploads だけ途中で失敗して、画像が一部欠ける
• サブディレクトリ構成を間違えて、URLと実体がズレる

安全策

• アップロードも “塊で分ける”（uploadsは最後でもOK）
• 途中でエラーが出たら、むやみに再実行せず、エラー箇所だけやり直す

手順5：DBをインポート

インポートも、軽いDBは管理画面、重いDBはSSHが安定です。

インポート後に最低限チェックすること

• テーブルが作られている（空じゃない）
• wp_options があり、siteurl / home が入っている（URL整合の判断材料）

手順6：wp-config.phpを移行先に合わせて編集

wp-config.php は、WordPressがDBに繋ぐための心臓部です。
移行後は、ここを 新サーバーのDB情報 に合わせます。

• DB名（DB_NAME）
• DBユーザー（DB_USER）
• DBパスワード（DB_PASSWORD）
• DBホスト（DB_HOST）
• 接頭辞（$table_prefix）

DB名・ユーザー・パスワード・ホスト・接頭辞の確認

超重要ポイント

• 接頭辞（例：wp_）が違うと、WordPressは「テーブルが無い」と判断します
  → 旧DBのテーブル名（wp_posts など）を見て合わせます。

編集後、まずはサイトにアクセスしてみて、

• 「DB接続確立エラー」→ DB情報か権限が原因の可能性が高い
• 真っ白 → PHP互換、プラグイン、権限、WAFなどの可能性

という切り分けができます。

手順7：URL整合（必要な場合のみ）

ドメインそのままなら、多くの場合ここは最小で済みます。
ただし、次のときはURL整合（検索置換）が必要になりやすいです。

• ドメイン変更（example-old → example-new）
• http→https の統一
• www有無の統一
• サブディレクトリ構成が変わる（/blog の有無など）

検索置換の注意点（シリアライズ/文字コード/安全な手順）

DB内には PHPのシリアライズ という形式で保存されるデータがあり、単純な文字列置換で壊れることがあります（特に wp_options やメタ系）。
だからこそ、初心者は “安全な方式” を選ぶのが鉄則です。

安全にやる基本方針

• いきなりSQL直置換をしない
• まずは ドライラン（置換内容の確認）
• 置換前のDBバックアップを必ず保持

代表的な安全策（覚え方だけでOK）

• WP-CLIの search-replace（シリアライズを考慮して置換してくれる）

※URL整合は「必要なときだけ」。不要なら触らないのが最短で安全です。

手順8：パーミッション・WAF・PHP設定で詰まる時

最後に “動かない原因” がサーバー設定側に残ることがあります。ここは症状別に潰します。

1）パーミッション（権限）

• 典型症状：画像アップロード不可、更新でFTP情報を求められる、403が出る
• 目安として多くの環境で
  • ディレクトリ：755（または750）
  • ファイル：644（または640）
  • wp-config.php はより厳しめ（環境次第）
• 777は原則NG（危険＆逆に動作不良の原因になることも）

2）WAF/セキュリティ

• 典型症状：管理画面だけ弾かれる、移行後のログインが不安定
• 対策：移行作業中だけ一時的に緩める／許可設定を入れる（やりっぱなしにしない）

3）PHPバージョン/拡張

• 典型症状：真っ白、特定ページだけエラー
• 対策：移行元と同等〜推奨範囲へ合わせる → プラグインを1つずつ切り分け

最後の仕上げ（最短チェック）

• 管理画面に入れる
• 主要ページが表示される
• 画像が出る
• パーマリンクの再保存（404対策）
• キャッシュ削除（古い表示の混在対策）

サイト引っ越し屋さん公式サイト

公開切替（DNS/ネームサーバー）で失敗しないコツ

DNS切替は、WordPress移行の中でも「やり直しが効くけど混乱しやすい」工程です。
初心者が失敗しないためのコツは、次の4点だけ押さえること。

• 切替を速くする準備（TTL調整）
• 切替前に“新サーバーで動く”ことを手元で確認（hosts）
• 切替直後の“混在”は正常な現象だと理解して対策
• 旧サーバーはすぐ解約せず、保険として残す

TTLを短くして切替を速くする（事前にやる）

TTLは、DNSの情報を「どれくらいの時間キャッシュ（保存）していいか」を示す値です。
これが長いと、切替後も古い行き先が残りやすく、表示の混在が長引く原因になります。

基本方針（初心者向け）

• 切替の前日〜数時間前に、対象レコードのTTLを短めにする
• 切替が落ち着いたら、TTLを元に戻す（短すぎるとDNS問い合わせが増えるため）

どれを短くする？（迷ったらこれだけ）

• Web表示に関係する：A / AAAA / CNAME
• メールも影響が出る可能性がある場合：MX（メール運用が絡む時だけ慎重に）

注意点

• TTLを変えても「即時に全員へ反映」するわけではありません。
  ただし、一般的に 切替後の混在時間を短くしやすくなるのは確かです。
• ネームサーバー（NS）自体を変更する場合は、TTL以前に DNSレコードの“移し漏れ”が最大の事故原因です。
  → A/CNAME/MX/TXT（SPF/DKIM/DMARC）など、必要レコードを先にコピーしてからNS変更が安全です。

hosts等で切替前に新サーバー表示を確認する

DNSを切り替える前に、「新サーバーで本当に動くか」を確認できると、成功率が一気に上がります。
そこで使えるのが hosts（ホストファイル）です。

hostsでできること

• 自分のPCだけ、ドメインの行き先を一時的に新サーバーIPへ向けられる
• つまり、DNS切替前に本番ドメインで表示確認ができます ✅

やる前に知っておくべき注意

• hosts変更は“自分のPCだけ”に効きます（他の人には影響しません）
• 作業後に戻し忘れると、ずっと自分だけ挙動が違って混乱します
  → 確認が終わったら必ず元に戻すのが鉄則です

変更場所（代表例）

• Windows：C:\Windows\System32\drivers\etc\hosts
• Mac / Linux：/etc/hosts

書き方の例（IPは例です）

203.0.113.10 example.com
203.0.113.10 www.example.com

hosts確認で見るべき“最小セット”

• TOPが表示される
• 主要ページ（2〜3本）が表示される
• 管理画面にログインできる
• フォーム送信（通知・自動返信まで）をテストする

補足：CDNやWAFを使っている場合、hostsで見ているのが「CDN側」になり、確認がややこしくなることがあります。そういう時は、CDN設定を一時的に調整して“直で新サーバーを見に行く”確認手順を用意すると安全です。

切替直後に「表示が混在」する現象の理解と対策

DNS切替直後に起こりやすいのが、いわゆる “表示の混在”です。

混在とは？（初心者向けに一言）
同じドメインなのに、人や端末によって

• 新サーバーが表示される人
• 旧サーバーが表示される人
  が一時的に混ざる状態です。

なぜ起こる？（原因は主にキャッシュ）

• ISP（プロバイダ）や社内ネットワークのDNSキャッシュ
• PC/スマホのDNSキャッシュ
• ブラウザキャッシュ
• CDNキャッシュ（使っている場合）

つまり、混在は「失敗」ではなく、切替直後に起こり得る自然な現象です。
大事なのは“混在しても事故にならない”ように設計することです。

混在しても困らないための対策（効果が高い順）

• 更新停止（凍結）を入れる
  → 混在中に記事更新すると、新旧サイトで内容がズレてトラブルが増えます
• 旧サーバー側をすぐ落とさない
  → 旧に当たった人がエラーになるのを防げます
• キャッシュを整理する
  • WordPressのキャッシュプラグイン
  • サーバー側キャッシュ
  • CDNキャッシュ（利用時）
• SSL（https）やリダイレクトの挙動を統一する
  → http↔https、www有無が混在すると、さらに混乱が増えます

混在の“見分け方”

• 表示される内容が違う（最新記事が出ない、デザインが違う）
• 管理画面で見える内容が一致しない
• フォーム送信が届いたり届かなかったりする

この場合、まずは「どっちのサーバーを見ているか」を確認します。
（上級者向けには nslookup / dig が便利ですが、初心者ならサーバー側のアクセスログや、表示内容の差で判断してもOKです）

旧サーバーはすぐ解約しない（並行運用の目安）

DNS切替後にすぐ解約すると、次の事故が起きやすくなります。

• 混在中に旧サーバーへ当たった人が エラーになる
• 「画像だけ出ない」「一部ページが404」など、移し漏れに後から気づけない
• フォームやメールの不達に気づいても、原因切り分けが遅れる

並行運用の考え方（初心者向け）

• 旧サーバーは“バックアップ保険”として残す
• 解約は「問題がないと確信してから」でOK

解約してよい判断チェック（これが全部OKなら安全）

• 新サーバーで 主要ページが安定して表示される
• 管理画面で投稿・更新・画像アップが問題ない
• フォーム通知・自動返信が安定して届く
• Search Console / GAなどの計測が継続している（必要な人だけ）
• CDN/WAF/SSL/リダイレクトの挙動が想定どおり

並行運用の現実的な目安

• 少なくとも「切替直後の混在」が落ち着くまで
• さらに「移行後チェック」と「問い合わせ・決済などの重要導線」の動作確認が終わるまで

コスト面が気になる場合は、旧サーバーを“最小プラン”に落とせるかも含めて検討すると、保険を残しやすくなります（サービス仕様によります）。

サイト引っ越し屋さん公式サイト

移行後チェック：表示・機能・SEO・セキュリティを一括確認

移行直後は「表示はできるけど、どこかが噛み合っていない」状態が起きやすいです。
そこでおすすめなのが、重要度の高い順に“短いチェック”を積み上げるやり方。

• 最優先（今すぐ）：表示・管理画面・フォーム
• 次（当日中）：SSL・キャッシュ・計測
• 仕上げ（数日〜1週間）：SEOの推移・バックアップ運用

この順で進めれば、初心者でも取りこぼしが減ります。

ページ表示チェック（重要URLから順に）

全部を一気に確認しようとすると疲れてミスが増えます。
まずは「事業に効くページ」から潰しましょう。

おすすめの優先順位（コピペ用）

1. TOP
2. 集客の要（上位表示している記事 / 人気記事 / LP）
3. 収益導線（料金・申込・購入・資料請求など）
4. 信頼導線（会社概要・特商法・プライバシーポリシー）
5. カテゴリ一覧 / タグ一覧
6. 全体（サイト内検索、関連記事、パンくず）

チェック観点（短く確実に）

• レイアウト崩れがない（CSS/JSが読めている）
• 画像が欠けていない（特に uploads）
• 404が増えていない（内部リンク、カテゴリ、固定ページ）
• 表示が異常に遅くない（移行前より体感が悪化していない）

💡時短のコツ：
「重要URLリスト」を10〜20本だけ作って、そのリストが全部OKなら“合格”と決めると、作業が終わります。

管理画面チェック（更新/メディア/プラグイン）

移行で一番困るのは「見えるけど更新できない」パターンです。
管理画面では次の3点だけは必ず触って確認します。

1）更新テスト

• 投稿を1本だけ編集→下書き保存→プレビュー
• 固定ページも1枚だけ同様に確認

2）メディアテスト

• 画像を1枚アップロードできるか
  → できない場合、権限（パーミッション）や容量上限が怪しいです。

3）プラグイン周り

• エラー表示が出ていないか（通知・ログ）
• キャッシュ/最適化/セキュリティ系は、移行直後だけ挙動が変わりやすい
  → 不具合が出たら、一時停止→原因切り分けが最短です。

定番の“お守り操作”

• パーマリンク設定を再保存（設定→パーマリンク→保存）
  これだけで404が直ることがよくあります。

SSLチェック（https化・混在コンテンツ・リダイレクト）

移行後のSSLは「鍵マークが出るか」だけでなく、リダイレクトの統一まで確認すると事故が減ります。

最低限チェックする3点

• httpsで開ける（ブラウザに鍵マーク）
• httpで開いたらhttpsへ自動転送される
• wwwあり/なし が混在していない（どちらかに統一）

混在コンテンツ（httpsなのに警告が出る）を疑う場面

• 画像や外部スクリプトが http:// のまま残っている
• テーマ設定やウィジェットに直貼りしたURLが古い

✅初心者向けの判断：
「鍵マークが出ない」「警告が残る」なら、まずは
①キャッシュ削除 → ②http参照の残りを探す の順が安全です。

メール・フォーム送信テスト（自動返信まで）

ここは“表示以上に重要”です。
移行後にフォームが死んでいると、気づかないまま機会損失になります。

テストの型（これで十分）

• お問い合わせフォームから送信（自分の別メールでもう1回）
• 管理者通知が届く
• 自動返信が届く
• 迷惑メールフォルダも確認

届かない時に切り分ける順番

1. フォーム自体が送信エラーになっていないか（画面表示）
2. 宛先メールアドレスが正しいか（設定ミス）
3. サーバー移行でメール運用（MX等）が変わっていないか
4. 迷惑メール判定（到達性）の問題か

💡小技：
件名に「移行後テスト」と入れておくと、後から探しやすいです。

キャッシュ/CDN/画像最適化の再設定

移行直後はキャッシュが“古い情報を正しく保存する”ことがあります。
最初は、整えてからキャッシュが基本です。

まずやること（順番が大事）

1. WordPress側キャッシュを削除（キャッシュ系プラグイン）
2. サーバー側キャッシュを削除（レンタルサーバー機能）
3. CDNを使っているならCDNキャッシュを削除
4. その後、必要なら最適化（画像・縮小・遅延読み込み）を再有効化

移行後に“効き方が変わりやすい”設定

• 画像のWebP化/配信設定
• 圧縮・縮小・遅延読み込み
• JS/CSSの結合・最小化
  → ここはやりすぎると崩れやすいので、1つずつONが安全です。

検索エンジン対応（サイトマップ/インデックス/速度）

ドメインが同じ移行（URL変更なし）でも、Googleは「ホスティング変更」を検知し得ます。
大事なのは “落ちても焦らず、監視できる状態にしておく” ことです。

当日〜数日でやること

• XMLサイトマップが正しく生成されているか確認
• Search Consoleでサイトマップ送信（必要なら再送）
• 主要ページのインデックス確認（URL検査で数本だけ）
• 速度が悪化していないか（体感＋計測）

URL変更ありの場合は追加で重要

• 旧→新の301リダイレクトが正しく機能しているか
• Search Consoleの移転手続き（該当する場合）

Search Console / GAで見るべき変化

移行直後のチェックは「数字の上下」よりも、異常のサインを見ます。

Search Consoleで見るポイント

• カバレッジ/ページのインデックス状況：急に除外が増えていないか
• クロールの様子：アクセスできていない兆候がないか
• URL検査：重要URLが取得できるか（数本でOK）
• エラー：サーバーエラー（5xx）が出ていないか

GA（GA4）で見るポイント

• リアルタイムでアクセスが計測されるか（まず“生きてるか”確認）
• 計測が二重になっていないか（PVが不自然に増える等）
• 参照元が激変していないか（リダイレクトや計測タグの問題サイン）

💡判断のコツ：
移行直後は小さな揺れが出ることがあります。
ただし 「5xx増加」「インデックス急減」「計測ゼロ」 は揺れではないので、優先的に原因を潰します。

バックアップ自動化・監視・更新運用の見直し

移行は“引っ越し”ではなく、運用を整えるチャンスです。ここをやると、次回が圧倒的にラクになります。

最低限やるべき運用セット

• 自動バックアップをON（世代数・復元手順も確認）
• 復元できるかの確認（最低でも「復元画面まで到達」）
• WordPress/テーマ/プラグイン更新のルール化
  • まずは月1でもOK（更新ゼロが一番危険）
• 監視（できれば）
  • サイトが落ちたら通知
  • セキュリティ通知（ログイン試行など）

おすすめの“運用メモ”

• いつ・何を・誰が更新するか
• 緊急時の戻し方（バックアップの場所、復元手順）
• 外部連携の一覧（フォーム/決済/計測/CDN）

このメモがあるだけで、移行後トラブルの復旧速度が変わります。

サイト引っ越し屋さん公式サイト

よくあるトラブル集（症状→原因→解決の順で）

移行直後のトラブルは、「原因が1つ」より「複数が重なっている」ことが多いです。
まずは共通の切り分けをしてから、症状別に潰すと迷いません。

最初の3分チェック（全トラブル共通）

• いま表示しているのは新サーバー？旧サーバー？（DNS混在・CDNキャッシュで勘違いしがち）
• キャッシュを消す（ブラウザ／キャッシュ系プラグイン／サーバーキャッシュ／CDN）
• 更新停止（凍結）を入れる（新旧で内容がズレると原因特定が難しくなる）

404が増えた（パーマリンク/.htaccess）

症状

• TOPは見えるのに、記事や固定ページが 404 になる
• カテゴリ一覧だけ404、特定の投稿だけ404 など

主な原因

• パーマリンク（リライトルール）が移行でリセットされた
• .htaccess が移っていない／壊れている／上書きされた
• サーバー側がリライトを受け付けていない（Apache/Nginx設定、WAFなど）
• URLの統一（www有無・https）が中途半端で、別URLに飛ばされて404

解決手順（初心者が安全に進める順）

1. パーマリンクを再保存
   管理画面 → 設定 → パーマリンク → 何も変えずに「変更を保存」
2. .htaccess の存在を確認（Apache系）
   • ない／空／明らかに短い場合は要注意
3. キャッシュを削除（キャッシュ系プラグイン・サーバーキャッシュ・CDN）
4. サブディレクトリ運用（例：/blog/）の場合、URL設定を再確認
   • 設定 → 一般 → WordPressアドレス / サイトアドレス
5. それでもダメなら、サーバー側のリライト設定・WAFが原因の可能性
   • レンタルサーバーなら「WordPressが動く推奨設定」へ
   • Nginx環境なら .htaccess ではなく Nginx設定が必要な場合あり

再発防止のコツ

• 移行直後は、「パーマリンク再保存」→「キャッシュ削除」をセットにする
• .htaccess を独自にいじっているなら、変更点をメモしておく（差分が命綱）

500/503/DB接続エラー（PHP・メモリ・DB情報）

症状

• 画面が真っ白／500（Internal Server Error）
• 503（Service Unavailable）や「一時的にアクセス不可」
• データベース接続確立エラー が出る

主な原因（ざっくり分類）

• DB接続エラー：wp-config.php のDB情報ミス／DBサーバー停止／権限不足
• 500系：PHPの互換性（バージョン差）／プラグイン衝突／メモリ不足／権限不整合
• 503系：サーバーが混雑／リソース上限／WAFが誤検知／キャッシュや最適化の暴走

解決手順（最短ルート）

1. エラーの種類を確定
   • “DB接続”と出ている → DBから疑う
   • 500/503で曖昧 → まずプラグイン・PHPから疑う
2. DB接続エラーの定番チェック（wp-config.php）
   • DB名 / ユーザー / パス / ホストが移行先の情報になっているか
   • 手動移行なら テーブル接頭辞（例：wp_） も一致しているか
3. プラグイン衝突の切り分け（管理画面に入れない時でもできる）
   • wp-content/plugins を一時的に plugins_off などにリネーム
   • 直ったら、戻して1つずつ有効化して犯人を特定
4. PHPバージョンを移行元に近づける（できる範囲で）
   • いきなり最新にしすぎると、古いプラグインが落ちやすいです
5. メモリ不足のケア（症状：管理画面が重い/白い、特定操作で落ちる）
   • サーバー側のメモリ上限を見直す（可能なら）
   • 重い最適化・バックアップ処理は一時停止

補足（VPS/上級向け）

• サーバーログ（Webサーバー / PHP / DB）を見ると一発で原因が分かることがあります。

画像が出ない（uploads欠落・パス・CDN）

症状

• 画像が×になる／サムネが消える
• 画像だけ旧サーバーを参照しているように見える

主な原因

• wp-content/uploads が移っていない／一部欠けている（転送失敗）
• 画像URLが旧URLのまま（ドメイン変更・http→httpsの整合漏れ）
• パーミッション（権限）不正で読み取り不可
• CDNが古いキャッシュを握っている、またはCDN設定が旧サーバー向きのまま

解決手順

1. uploads の存在と容量を確認
   • 移行元と比べて極端に小さいなら転送漏れの可能性大
2. 画像の直URLを開いてみる
   • 404 → ファイルがない／パスが違う
   • 403 → 権限（パーミッション）やWAF
3. キャッシュ/CDNをクリア
   • CDN利用時は特に「画像だけ古い」が起きます
4. ドメイン変更やhttps統一をした場合は、URL整合（安全な検索置換）を検討
   • 雑な置換は壊れやすいので、できれば安全な手順（WP-CLI等）で

再発防止

• 大容量サイトは uploads を“最後にまとめて”移すより、月別フォルダ単位で転送→照合すると失敗に気づきやすいです。

管理画面に入れない（URL/リダイレクト/セッション）

症状

• /wp-admin が開けない
• ログインしてもすぐログアウトする
• リダイレクトが繰り返される

主な原因

• サイトURL（https / www有無）が統一されていない
• キャッシュ・Cookieが古い（移行直後あるある）
• セキュリティ系プラグインがブロック（IP制限・ログイン回数制限など）
• WAFが誤判定
• SSL設定が中途半端で、http↔httpsを行ったり来たり

解決手順

1. ブラウザのCookie削除（対象ドメインだけでOK）→再ログイン
2. 設定 → 一般 の
   • WordPressアドレス（URL）
   • サイトアドレス（URL）
     を確認し、意図した形に統一（https、www有無）
3. セキュリティ系プラグインを一時停止して切り分け
   • 入れない場合：FTPで該当プラグインのフォルダ名を一時変更
4. WAFを一時的に緩める（作業中だけ）→原因がWAFならルール調整
5. どうしても入れない場合の最終手段
   • wp-content/plugins を一時的に無効化（全停止）してログイン確認
   • 直ったら1つずつ戻して原因特定

httpsループ・警告が消えない（HSTS/キャッシュ）

症状

• 「リダイレクトが多すぎます」
• httpsにしたのに「保護されていない」警告が残る
• 端末によって挙動が違う（ある端末だけ直らない）

主な原因

• http→https、www有無、CDN側の転送が 二重に効いてループ
• 混在コンテンツ（httpsページ内でhttp素材を読み込んでいる）
• ブラウザがHSTSを記憶していて、挙動が固定化している
• CDNキャッシュが古い転送ルールを保持している

解決手順（安全に潰す順）

1. 転送ルールを“1か所に寄せる”
   • サーバー側・WordPress側・CDN側で重複していないか確認
   • ルールが複数あるほどループしやすいです
2. 混在コンテンツを潰す
   • 画像・JS・CSSが http:// のまま残っていないか
   • テーマ設定、ウィジェット、直貼りURLも要注意
3. キャッシュを総クリア
   • ブラウザ（強制再読み込み）
   • WordPressキャッシュ
   • サーバーキャッシュ
   • CDNキャッシュ
4. HSTSが疑わしい時の考え方
   • 「別ブラウザでは直る」のに「特定ブラウザだけ直らない」→HSTS/サイトデータが濃厚
   • まずはサイトデータ削除（Cookie/キャッシュ）を試す
   • それでもダメなら、ブラウザのHSTSポリシー削除が必要なケースもあります（上級者向け）

再発防止

• ルールは「どこが正」と決める（例：CDNで統一、またはサーバーで統一）
• 移行直後に、最適化（JS/CSS結合など）を一気にONにしない（原因が増える）

メールが届かない（MX/SPF/DKIM/送信制限）

症状

• お問い合わせ通知が届かない
• 自動返信が届かない
• 送信はできるが受信できない（または逆）

主な原因

• ネームサーバー変更時に MXレコードが消えた／間違った
• SPF/DKIM/DMARC（TXTレコード）が移し漏れ、到達率が落ちた
• サーバーの送信制限（迷惑メール対策）でブロックされた
• フォームの宛先/差出人設定が古いまま
• DNSの反映（TTL/キャッシュ）で一時的に不安定

解決手順（初心者が詰まらない順）

1. まず“受信”と“送信”を分けてテスト
   • Gmail等 → 独自ドメインへ送る（受信テスト）
   • 独自ドメイン → Gmailへ送る（送信テスト）
2. DNSのMXを確認（メールの行き先）
   • Google WorkspaceならGoogleのMXになっているか
   • サーバーメールなら、そのサーバー指定のMXになっているか
3. TXTレコード（SPF/DKIM/DMARC）の確認
   • ネームサーバー変更をした人ほど“移し漏れ”が起きます
4. フォームの 宛先/自動返信 設定を確認
   • 管理者通知の宛先
   • 自動返信の差出人
5. 送信制限・到達率が疑わしい場合
   • SMTP送信（認証付き送信）に切り替えると改善することがあります
   • 大量送信や短時間の連投は避ける（移行テストもやりすぎ注意）

再発防止

• ネームサーバーを変える前に、DNSレコード（A/CNAME/MX/TXT）を丸ごと控える
• 移行後は「フォーム→通知→自動返信」までを定期テスト（最低でも年1）

サイト引っ越し屋さん公式サイト

ドメイン変更も同時に行う場合（URL変更ありの移行）

ドメイン変更を伴う移行は、サーバー移行より一段むずかしくなります。理由はシンプルで、「検索エンジン・ユーザー・外部サービスが参照する“住所”が変わる」からです。
成功のコツは、作業を ①設計 → ②リダイレクト → ③URL置換 → ④Search Console → ⑤外部サービス の順に固定して、1つずつ潰すことです。

旧URL→新URLの設計（1対1でマッピングする）

まず、旧URLと新URLを1対1で対応させる「移転台帳」を作ります。ここが雑だと、移行後に404増加・評価の引き継ぎ漏れ・ユーザー迷子が起きやすいです。

おすすめの作り方（初心者でも迷いにくい）

• 旧サイトのURLを集める（どれか1つでOK）
  • 旧サイトのサイトマップ
  • Search Consoleの「インデックス」や「ページ」レポート（主要URLの抽出）
  • アクセスの多いURL（GAの上位ページ）
• 台帳は「重要度順」に並べる
  1. 上位表示・流入が多いページ → 2. 収益導線 → 3. その他

設計ルール（これだけ守ると強い）

• 基本は 旧ページ → 新ページ（同等内容）に直行
  • 「全部トップへ」は短期的に楽でも、長期的に不利になりやすいです。
• 統一ルールを先に決める
  • https固定
  • wwwあり/なし固定
  • スラッシュの有無、カテゴリ構造など
• 消すページがある場合の扱いも決める
  • 似た内容のページがある → そこへ転送
  • 代替がない → 削除（“無理やり転送”より明確にする判断も必要）

台帳テンプレ（この列だけあれば運用できます）

• 旧URL
• 新URL
• 種別（記事/固定/カテゴリ/商品/LP）
• 優先度（高/中/低）
• 対応（301 / 統合 / 削除）
• チェック済（✅）

301リダイレクトの実装（漏れなく・チェーンさせない）

Googleは、URLが恒久的に変わるなら 恒久リダイレクト（301/308） を推奨しています。
ここで重要なのは、「漏れなく」＋「1回で最終URLへ（チェーン禁止）」です。

やってはいけない例（チェーン）

• http://old.com/page → https://old.com/page → https://new.com/page
  このように段階が増えるほど、確認も復旧も面倒になります。できるだけ 1回で https://new.com/page へ。

実装の考え方（初心者向け）

• “最初の入口”で一気に新ドメインへ送る
  • サーバー（旧ドメイン側）で、旧ドメインの全リクエストを新ドメインへ
• パスが変わるURLだけ「個別301」を追加
  • 例：/old-service/ → /services/ など

代表例（Apache / .htaccess）

RewriteEngine On
RewriteCond %{HTTP_HOST} ^(www\.)?old-example\.com$ [NC]
RewriteRule ^(.*)$ https://new-example.com/$1 [R=301,L]

代表例（Nginx）

server {
  server_name old-example.com www.old-example.com;
  return 301 https://new-example.com$request_uri;
}

チェック方法（最短）

• 重要URLだけでOKなので、以下を確認
  • 旧URLにアクセス → 新URLへ1回で転送される
  • 転送先が 200で表示される
  • 404にならない
    （可能なら curl -I でステータス確認すると早いです）

運用の目安

• リダイレクトは短期で外すと事故ります。しばらく維持して、検索・外部リンク・ブックマークの行き先を安定させます。

WordPress内URLの安全な置換手順

ドメイン変更後、WordPress内には旧ドメインが残りがちです（画像URL、内部リンク、設定、ウィジェットなど）。
ただし、DBにはシリアライズされたデータがあるため、単純な置換は壊れることがあります。そこで「安全なやり方」を選びます。

安全な置換の鉄則（初心者向け）

• 置換前に DBバックアップ（必須）
• まず ドライラン（置換の試算） をする
• 置換は WP-CLI など“シリアライズ対応”の手段で行う

WP-CLIの例（まずはドライラン）

wp search-replace 'https://old-example.com' 'https://new-example.com' --dry-run

本番反映（例）

wp search-replace 'https://old-example.com' 'https://new-example.com' --all-tables

置換後に“残りがち”な場所（チェックリスト）

• テーマ設定（ロゴ画像URL、フッター文言のリンク）
• ウィジェット（直貼りリンク）
• 画像最適化/CDNプラグインの設定
• SEOプラグインの設定（OGP、canonical関連）
• 埋め込みコード（計測タグ、広告タグ）

Search Consoleの手続き・サイトマップ再送信

ドメイン変更では、Search Console側の手当てが重要です。基本は次の流れです。

手順（迷わない順）

1. 新ドメインをSearch Consoleに追加・確認（所有権の確認）
2. 旧→新の 301/308が整っていることを確認
3. Change of Address（アドレス変更）ツールを実行（条件を満たす場合）
4. 新ドメインのサイトマップを送信（必要なら再送）
5. 以後は監視（急変だけを拾う）

Googleは、URL変更を伴う移転手順と、移転後の影響を抑える考え方をガイドしています。

移行後1〜2週間で見るべき“異常サイン”

• 旧URLのクロールが増え続け、新URLが増えない
• 5xxが増える（サーバー不安定）
• 404が増える（マッピング漏れ）
• インデックスが大きく減って戻らない（何か根本が崩れている）

外部サービスの更新（広告/決済/解析/メール配信）

ドメイン変更は「WordPressが動く」だけでは終わりません。外部サービスが旧ドメインを参照していると、計測が途切れる／広告が無効／決済通知が死ぬなどが起きます。

優先度の高い順チェック（初心者向け）

• 解析
  • GA / GTM：タグが新ドメインで発火しているか、リアルタイムで確認
• 広告・アフィリエイト
  • 許可ドメイン登録、計測用パラメータ、リンク先の自己参照（旧ドメインが残っていないか）
• 決済・会員・予約
  • 戻り先URL（サンクスページ）
  • Webhook通知先URL（旧ドメインのままだと致命的）
• メール配信/CRM
  • 送信ドメイン認証（SPF/DKIM/DMARC）
  • フォームの通知先・自動返信文面内リンク
• セキュリティ・CDN
  • WAF/CDNのオリジン、SSL、キャッシュクリア
• reCAPTCHA等のドメイン依存
  • 許可ドメインを新ドメインに追加

仕上げの確認（最低限）

• お問い合わせ：送信 → 管理者通知 → 自動返信（リンクが新ドメインか）
• 購入/申込：テスト決済（可能なら）→ 通知が届くか
• 計測：リアルタイムでPV/イベントが入るか

サイト引っ越し屋さん公式サイト

移行代行を使う判断基準（“費用”より“事故リスク”で決める）

移行代行を選ぶべきかどうかは、「安いか高いか」よりも、失敗したときの損失（事故リスク）で判断するほうが合理的です。
おすすめは、次の3要素で考えること。

• 影響：止まったらどれだけ困るか（売上・問い合わせ・信用）
• 確率：自力でやると事故りそうか（複雑さ・不慣れ・時間不足）
• 復旧難度：失敗時に戻せるか（バックアップ品質・検証環境・技術）

この3つのどれかが高いなら、代行は「コスト」ではなく保険として機能します。

依頼したほうがよいケース（止められない/大規模/売上直結）

初心者が“代行に寄せた方が結果的に得”になりやすいのは、次のタイプです。

1）止められない（ダウンタイム許容が小さい）

• 24時間いつでも問い合わせが入る
• 広告出稿中／キャンペーン中／メディア掲載直後
• 予約・決済・会員ログインがある

→ このタイプは、移行作業の失敗＝そのまま機会損失につながるので、代行の価値が高いです。

2）大規模・複雑（“移行作業”より“確認作業”が重い）

• 画像・投稿が多く、データ量が大きい
• 多言語／複数サイト（マルチサイト含む）／サブディレクトリ運用
• 特殊なリダイレクト、CDN/WAF、独自コードが多い

→ 大規模ほど「移せたか」より「漏れなく動くか」の検証が大変です。

3）売上直結の導線が多い（“見える”だけでは合格にならない）

• 決済後のサンクス、Webhook、会員メールなど“裏側”が多い
• 重要LPが複数あり、計測（GA/GTM）が必須
• 広告・アフィリエイトが収益の中心

→ 「表示OK」で終えると、移行後に静かに売上が落ちる危険があります。

自分でやってもOKになりやすいケース（逆に）

• 小〜中規模で構成がシンプル（ブログ中心）
• 自動移行（かんたん移行）やテスト移行が使える
• バックアップと復元手順が確立していて、検証もできる

見積で確認すべき範囲（DNS/メール/SSL/リダイレクト）

代行で一番多い失敗は、「移行の範囲が曖昧」なまま発注して、あとから追加費用や想定外の抜けが出ることです。
見積依頼の時点で、次の項目を「含む／含まない」で明文化しましょう。

見積チェックリスト（そのまま貼って使える）

A. 移行作業の範囲

• WordPress本体（ファイル・DB）移行
• テーマ・プラグイン・メディア（uploads）移行
• 旧→新の差分対応（移行中の更新が入った場合）

B. 公開切替（DNS）

• DNS切替の実作業（誰がやる？）
• TTL調整の案内／実施
• 切替後の混在期間の扱い（旧サーバー並行運用の方針）

C. メール（事故が多い）

• MX/SPF/DKIM/DMARC の確認・移行
• サーバーメールの移行（メールボックス・過去メール）対応有無
• フォーム通知・自動返信の到達テストまで含むか

D. SSL・リダイレクト

• 無料SSL設定・自動更新の確認
• http→https、www有無の統一
• 混在コンテンツ（http素材）の確認
• ドメイン変更がある場合の 301設計〜実装（URL対応表の作成含むか）

E. 動作確認（ここが“代行の価値”）

• 重要ページの表示確認（本数を合意：例 20URL）
• 管理画面（投稿更新・画像アップロード）
• フォーム・決済・会員ログインなど重要機能のテスト
• GA/GTM計測の動作確認（リアルタイム確認まで含むか）
• 失敗時のロールバック（旧環境へ戻す）条件と手順

追加費用が出やすいポイント（先に潰す）

• ドメイン変更（URL変更）を含む移行
• メール移行（特に過去メールの引継ぎ）
• CDN/WAF（Cloudflare等）の設定変更
• 決済・会員・予約など、外部サービスの設定更新
• 超大容量（転送やDBインポートが重い）

コツ

• 「移行」ではなく、“切替後に売上・問い合わせ・計測が通常運転になるまで”をゴールに置くと、見積の抜けが減ります。

権限の渡し方とセキュリティ（共有方法のルール）

代行を使うなら、最重要は「パスワードを雑に渡さない」ことです。
安全性と作業効率を両立するために、次のルールが現実的です。

渡す前に決める“最低限ルール”

• 共有は原則、期限付き（作業完了後に無効化）
• 個人アカウントの共有は避ける（専用アカウントを作る）
• 権限は最小限（必要な範囲だけ渡す）
• 連絡手段と緊急時フローを決める（停止・ロールバック判断）

具体的な渡し方（おすすめ順）

1）専用アカウントを作る（推奨）

• サーバー管理画面：代行用ユーザー（可能なら）
• WordPress：移行専用の管理者（作業後に削除）
• DNS：編集権限だけのユーザーが作れるなら分離

2）パスワード共有は“使い捨て前提”

• 使い回ししない強いパスワードを発行
• 作業完了後に 必ず変更（またはアカウント削除）

3）2段階認証・IP制限の扱い

• 2FAがあるなら、代行の作業手順に組み込む（無理に切らない）
• IP制限やWAFで弾く場合は、作業時間だけ緩める／許可リストに入れる

作業後に必ずやる“後片付け”

• 代行用アカウントの削除 or 無効化
• パスワード総入れ替え（サーバー・WP・DB・DNS）
• WAF/IP制限/Basic認証など、緩めた設定を元に戻す
• バックアップ設定・監視設定の確認（移行後運用へ）

判断の基準を一言でまとめると
「失敗しても自分で短時間に戻せる」なら自力でもOK。
「止まると困る／戻せない／裏側が複雑」なら、代行で事故リスクを買い取るのが合理的です。

サイト引っ越し屋さん公式サイト

コピペ用チェックリスト（作業前→中→切替直後→1週間後）

そのまま貼って使えるように、チェックボックス形式でまとめました。
「全部やろう」とすると疲れるので、まずは 太字の項目だけでも押さえると失敗率が下がります。

作業前（情報・バックアップ・更新停止）

• [ ] 移行方法を確定（かんたん移行／プラグイン／手動／代行）
• [ ] ドメイン変更の有無を確定（URLが変わるなら301設計が必要）
• [ ] メール運用を確認（サーバーメール／Google Workspace等）
• [ ] 外部連携を棚卸し（フォーム・決済・広告・GA/GTM・Search Console・CDN/WAF）
• [ ] WordPress管理画面にログインできる（管理者ID/パス確認）
• [ ] サーバー管理画面にログインできる
• [ ] FTP/SFTP/SSH情報を控えた（ホスト・ユーザー・パス・ポート）
• [ ] DB情報を控えた（DB名／ユーザー／パス／ホスト）※手動移行や復旧で必須
• [ ] DNSの現状を控えた（A/CNAME/MX/TXT など）※ネームサーバー変更するなら必須
• [ ] 更新停止（凍結）の時間帯を決めて周知（自分だけでもメモ）
• [ ] フルバックアップを取得（ファイル＋DB）
  • [ ] wp-content（themes/plugins/uploads）
  • [ ] wp-config.php
  • [ ] .htaccess（環境によって場所/有無が異なる）
  • [ ] DB（.sql）
• [ ] バックアップが壊れていないか軽く確認（サイズが極端に小さくない）
• [ ] 移行先サーバーで受け口を用意（ドメイン追加／WordPress新規設置など）
• [ ] PHPバージョンを確認（移行元より極端に古くしない）
• [ ] 大容量の場合、不要データ整理（キャッシュ・古いバックアップ・不要テーマ等）

作業中（移行漏れ・権限・表示確認）

• [ ] 移行中は更新しない（投稿・商品・フォーム設定など）
• [ ] 移行の対象範囲を再確認（メール/DNS/外部サービスは別作業になりやすい）
• [ ] 新環境で最低限の表示確認
  • [ ] TOP
  • [ ] 重要ページ（上位記事/LP/料金/申込）
  • [ ] 画像が出る（uploadsが欠けていない）
• [ ] 管理画面にログインできる
• [ ] 画像を1枚アップロードできる（権限/容量の確認）
• [ ] パーマリンクを再保存（設定→パーマリンク→保存）🧩
• [ ] キャッシュ系・最適化系・セキュリティ系が邪魔していないか
  • [ ] 不具合があれば一時停止して切り分け（原因を増やさない）
• [ ] ドメイン変更がある場合のみ
  • [ ] 旧→新URL対応表（重要URLだけでも）を用意
  • [ ] 301の方針（1回で最終URLへ、チェーンさせない）を決めた
  • [ ] 新ドメイン側の表示確認（SSL含む）

切替直後（DNS反映・SSL・フォーム・速度）

• [ ] DNS切替を実施（A/CNAME など）
• [ ] 切替直後の混在を想定（旧サーバーは残す）
• [ ] 自分の環境で「新サーバー表示」を確認できた（キャッシュ削除も含む）
• [ ] SSL確認
  • [ ] httpsで鍵マークが出る
  • [ ] http→httpsへ転送される
  • [ ] www有無が統一されている（どちらかに寄せる）
• [ ] フォーム送信テスト（最重要） ✉️
  • [ ] 管理者通知が届く
  • [ ] 自動返信が届く
  • [ ] 迷惑メールフォルダも確認
• [ ] 速度・安定性の確認
  • [ ] 体感で遅くなっていない
  • [ ] 500/503が出ていない
• [ ] キャッシュ/CDNの整理
  • [ ] WordPressキャッシュ削除
  • [ ] サーバーキャッシュ削除
  • [ ] CDNキャッシュ削除（使っている場合）
  • [ ] 画像最適化やJS/CSS最適化は、問題がないのを確認してから順にON

1週間後（エラー監視・インデックス・メール到達）

• [ ] 404/500/503などのエラーが増えていない
• [ ] 画像欠落・表示崩れが残っていない（重要導線を再チェック）
• [ ] Search Console（使っている人だけ）
  • [ ] サイトマップを確認（必要なら再送）
  • [ ] 主要URLのインデックス状況を確認（数本でOK）
  • [ ] 5xx/404の急増がないか確認
• [ ] GA（使っている人だけ）
  • [ ] リアルタイムに計測が入っている
  • [ ] 二重計測っぽい不自然な増加がない
• [ ] メール到達の再チェック（地味に遅れて問題が出る）
  • [ ] フォーム通知・自動返信が安定して届く
  • [ ] 送信元ドメイン認証（SPF/DKIM/DMARC）をいじった場合、到達が落ちていない

旧サーバー解約前（最終バックアップ・完全切替確認）

• [ ] 旧サーバー側の最終バックアップを取得（ファイル＋DB）
• [ ] 旧→新の差分がない（移行中に更新したものがあれば反映済み）
• [ ] 全体の最終確認（最低限）
  • [ ] TOP／主要ページ／申込導線／問い合わせ が正常
  • [ ] 管理画面で更新・画像アップができる
  • [ ] httpsやリダイレクトが想定どおり
  • [ ] 外部連携（広告/決済/解析/CDN）が正常
• [ ] ドメイン変更がある場合のみ
  • [ ] 旧URL→新URLの301が主要ページで機能
  • [ ] 旧URLが404になっていない（対応表の漏れチェック）
• [ ] 代行や外注が絡んだ場合
  • [ ] 共有したアカウントの無効化／パスワード変更
  • [ ] 一時的に緩めたWAF/IP制限を元に戻す
• [ ] 解約（または縮小）を実施
  ※不安が残るなら「解約」ではなく、まずは「最小プラン化」も検討

サイト引っ越し屋さん公式サイト

FAQ（よくある質問）

ダウンタイムは出る？ 最小化するには？

結論から言うと、「URLは変えない」＋「旧サーバーを残して並行運用」にすると、ダウンタイムはかなり小さくできます。
ただし現実には、DNSの反映やキャッシュの影響で、切替直後に一時的な“揺れ”が起きることがあります。

ダウンタイムが出やすいパターン

• 切替の瞬間に旧サーバーを止めてしまう
• 移行中に記事更新・注文・会員登録などが動き続けて差分が生まれる
• メール・CDN・WAFなど周辺要素も同時に大きく変える

最小化のコツ（初心者向けに重要度順）

• 切替前に新サーバーで動作確認する
  できればテスト移行（ステージング）。なければ hosts 等で自分だけ先に確認。
• TTLを事前に短くする（A/CNAMEなどWeb系レコード中心）
  反映の“長引き”を減らしやすくなります。
• 更新停止（凍結）を短時間だけ入れる
  「最終バックアップ→本番移行→DNS切替→重要テスト完了」まで。
• 旧サーバーをすぐ解約しない
  切替後もしばらく旧サーバーを稼働させておくと、混在しても致命傷になりにくいです。
• 最初にテストするのは“表示”より“フォーム”
  表示OKでも、問い合わせが落ちると機会損失が大きいので、送信→通知→自動返信まで確認。

💡目安：ブログ・企業サイトの多くは、上のセットで「実質ほぼ停止なし」に近づけられます。
一方、決済・予約・会員が絡む場合は、ダウンタイム最小化の難易度が上がるため、代行や段階移行も現実的です。

SEO評価は落ちる？ 影響を抑えるポイントは？

URLが変わらない“サーバー移行だけ”なら、基本的には大崩れしにくいです。
ただし、移行後にサーバーエラーが増えたり、表示速度が悪化したりすると、検索パフォーマンスに影響が出る可能性があります。

影響を抑えるポイント（URL変更なしの場合）

• 5xx（500/503）を出さない：移行直後の負荷や設定不備に注意
• 重要ページが安定して200で返る（404増加を防ぐ）
• robots.txt / noindex / 認証（Basic認証など）を本番に残さない
• 表示速度が落ちていないか（キャッシュ・画像最適化を再設定）
• Search Consoleで「エラー急増」がないかだけ監視（やりすぎなくてOK）

URLが変わる（ドメイン変更・http→https統一含む）場合
ここは別物で、SEO影響は出やすいです。対策の柱はこの3つだけです。

1. 旧→新を1対1で301（恒久）転送
   • 「全部トップへ」は避け、基本は同等ページへ
   • なるべくリダイレクトチェーン（多段転送）を作らない
2. 内部の整合を取る
   • 内部リンク、canonical、サイトマップなどを新URL基準に揃える
   • WordPress内のURL置換は、壊れにくい手順で行う（シリアライズ注意）
3. Search Console側の手続きと監視
   • 新ドメインのプロパティ追加
   • 必要に応じてアドレス変更ツール
   • サイトマップ送信、主要URLの検査、404/5xx監視

✅考え方としては、SEOは「作業直後の順位」よりも、“Googleが新URLを理解できる材料を揃えたか”で結果が変わります。

作業時間の目安はどれくらい？

作業時間は、方法×サイト規模×外部連携の多さで決まります。
初心者が計画を立てやすいように、ざっくり目安をまとめます（実転送時間はデータ量で大きく変わります）。

方法	小〜中規模の目安	時間が延びる要因
かんたん移行	1〜3時間	データ量が多い／移行元の制限（WAF等）／テスト不足
プラグイン移行	2〜6時間	容量制限／復元失敗／環境差（PHP差など）
手動移行（FTP+DB）	4〜10時間	DBが大きい／転送漏れ／URL整合が必要
代行	依頼〜完了は数日〜	確認範囲が広いほど期間は伸びる（作業自体は短いことも）

時間を読むときのコツ

• “移す時間”より“確認の時間”が実は長い
  → 重要URLリストを作ると短縮できます。
• ドメイン変更ありは別枠で、追加で数時間〜（設計・301・外部更新・監視）が乗ります。
• 旧サーバーをすぐ解約しない前提なら、作業を分割できる
  → 体力とミスが減ります。

失敗したら戻せる？ 復旧の手順は？

多くの場合、戻せます。鍵になるのは次の2つです。

• 移行前のフルバックアップがある
• 旧サーバーを一定期間残している

最短の“戻す”手順（DNS切替後に問題が出た場合）

1. 更新を止める（凍結）
   新旧で差分が増えると復旧が難しくなります。
2. DNSを旧サーバーに戻す（A/CNAMEなど）
   旧サーバーが生きていれば、これが最速で復旧になります。
3. フォーム・メール・決済など重要導線の復旧確認
   表示より先に確認（機会損失が大きいので）。
4. 原因を切り分けて新サーバー側を直す
   直ったら、改めてテスト→再切替。

復旧でつまずきやすい点

• DNS反映の混在で「戻したのに直らない」と感じる
  → キャッシュ削除、時間を置く、別端末で確認。
• 移行後に新サーバーで更新してしまい、旧へ戻すと内容が戻る
  → だから凍結が重要です。

“戻す”より“直す”が早いケース

• 404増加：パーマリンク再保存、.htaccess整合で短時間に復旧することが多い
• 画像欠落：uploads転送漏れを追加アップロードで解決できることがある
• 管理画面ログイン不可：URL統一・Cookie削除・セキュリティ系の一時停止で切り分け

💡おすすめの安全設計：
切替前に「戻す方法（DNSをどこに戻すか）」をメモしておくと、緊急時に迷いません。

サイト引っ越し屋さん公式サイト

まとめ

WordPressのサーバー移行を成功させる最大のコツは、難しい操作を覚えることではなく、「準備→移行→切替→確認」を正しい順番で進め、抜けを作らないことです。

特に重要なのは次のポイントでした。

• 移行方法は、基本的に かんたん移行（自動）→プラグイン→手動→代行の順に検討する
• 事前に ドメイン変更の有無／メール運用／外部連携を整理しておく（ここが曖昧だと事故る）
• 移行の成否は準備で決まる
  • フルバックアップ（ファイル＋DB）
  • 更新停止（凍結）
  • 移行先の互換性チェック（PHP/DB/容量）
• DNS切替は「混在が起こり得る」前提で設計し、旧サーバーはすぐ解約しない
• 移行後は、表示だけで満足せず
  • フォーム送信（通知＋自動返信）
  • SSL（https、混在コンテンツ、リダイレクト）
  • キャッシュ/CDN
  • Search Console/GAの計測
    を“短いチェックリスト”で一括確認する

もし移行後に不具合が起きても、焦る必要はありません。
404・500/503・画像欠落・ログイン不可・SSLループ・メール不達などは、原因のパターンがある程度決まっています。症状→原因→解決の順で切り分ければ、落ち着いて復旧できます。

そして最後に、移行を安全に終えるための鉄則はこれです。

✅ 「戻せる状態（バックアップ＋旧サーバー）を確保してから切替する」
この一線を守るだけで、失敗しても致命傷になりません。

本記事の手順とチェックリストを使って、あなたのWordPressサイトを 止めずに・迷わずに・SEOも守りながらサーバー移行を完了させてください。

サイト引っ越し屋さん公式サイト