WordPressサーバー移行,ドメインそのままで引っ越しする完全ガイド

WordPressを新しいサーバーへ移行する際、サイトを停止したりデータを失うリスクを負う必要はありません。このガイドでは、/etc/hostsテスト、DNS TTL短縮、完全なロールバック戦略を使った最も安全な方法を解説します。この手順に従えば、訪問者に気づかれることなくWordPressサイトを新しいサーバーへ移行できます。

私たちは数百件のWordPress移行を経験してきましたが、新しいサーバーへのWordPress引っ越しは常に重要な作業です。

最初のルール：金曜日の深夜24時に作業を開始しないでください。問題が発生した場合、修正する時間が必要になります。B2Bサイトの場合は、トラフィックが少ない時間帯を選び、問題を修正する時間を確保してください。あなたのスケジュールに最適な時間を選びましょう。


Copied!理由は単純です。問題が発生する可能性があり、解決に数時間かかることがあります。誰も朝まで作業したくありませんし、壊れたWordPressサイトで目覚めたくもありません。
理由は単純です。問題が発生する可能性があり、解決に数時間かかることがあります。誰も朝まで作業したくありませんし、壊れたWordPressサイトで目覚めたくもありません。

このガイドが存在する理由：実際に遭遇した移行の問題

最近のWordPressサーバー移行で、適切な準備があれば回避できたさまざまな問題を経験しました。

DNSが間違ったバージョンのドメインを指していた：DNSレコードがwwwバージョンを指していましたが、サイトは非wwwバージョンで設定されていました。DNS変更の瞬間、即座に失敗。設定の不一致によりサイトが読み込まれませんでした。

絵文字が原因でデータベースエクスポートが失敗：データベースのコンテンツに絵文字が保存されていました。標準的なエクスポートは、文字エンコーディングエラーでインポート時に失敗しました。解決にはUTF-8mb4パラメータを使った特別なエクスポート手順が必要でした。

サードパーティサービスのIPホワイトリスト：サードパーティのメールAPIにIPホワイトリスト制限がありました。新しいサーバーではすべて正しく設定されていましたが、IPホワイトリストを更新するまでメールが送信されませんでした。

これらの経験から、ほとんどの移行問題を防ぐ2つの重要な技術を学びました。DNS変更前の/etc/hostsテストと、事前のDNS TTL短縮です。パフォーマンス向上、コスト削減、プロバイダー変更など、どのような理由でWordPressを新しいサーバーへ移行する場合でも、このガイドではサイトを停止せずに移行する両方の技術を解説します。

プロセスに入る前に、基本的な事項を確認しましょう。

DNSとTTLの理解：移行に時間がかかる理由

DNSとは？

DNS（Domain Name System）は、基本的にインターネットの電話帳です。誰かがブラウザにexample.comと入力しても、コンピュータは実際にそのウェブサイトがどこにあるか知りません。DNSサーバーに「example.comのIPアドレスは何ですか？」と尋ね、DNSサーバーが「123.456.789.012です」と応答します。その後、ブラウザはそのIPアドレスに接続します。

TTLとは？なぜ重要なのか？

TTL（Time To Live）は、DNSサーバーがこの回答を記憶（キャッシュ）できる時間です。TTLが3600秒（1時間）に設定されている場合、世界中のDNSサーバーは、更新を再確認する前に1時間ドメインのIPアドレスをキャッシュします。

歴史的に、TTL値は2日間（172,800秒）に設定されていました。これが「DNS伝播には24〜48時間かかる」とよく聞く理由です。このアドバイスは、この歴史的なデフォルト値から来ています。WordPressサイトを別のIPアドレスへ移行する場合、TTL設定によっては、世界中のすべてのDNSサーバーが新しい情報を取得するまで最大2日かかることがあります。

移行中のTTL問題

TTLを5分に短縮しても、すべてのDNSリゾルバーがこの値を尊重するわけではありません。より長くキャッシュする場合もあります。これが、DNSレコード変更後すぐに古いサーバーをシャットダウンできない理由です。

ステップ1：バックアップを取る

重要： このガイドは、サーバーのIPアドレスが変更されるWordPress移行に適用されます。同じサーバー上のステージングドメインから本番ドメインへ移動する場合（例：staging.example.comからexample.com）、Webサーバーの設定を調整するだけで済みます。このシナリオではDNS変更は含まれません。

言うまでもありませんが、あえて言います：完全なバックアップを取ってください。 「ホストが自動バックアップをしていると思う」というバックアップではありません。実際にコンピュータにダウンロードした、「自分で復元できる」バックアップです。

WordPressサイトからバックアップすべきもの

WordPressデータベースの完全エクスポート
ルートフォルダ全体（通常はpublic_htmlまたはwwwフォルダ）
SSL証明書（新しいホストで自動処理されない場合）

WordPressバックアップの3つの方法

オプション1：ホスティングプロバイダーの完全バックアップ

多くのホスティングプロバイダーは、ルートフォルダ、データベース、SSL証明書を含む完全なバックアップパッケージを提供しています。現在のホストがこれを提供しているか確認してください。ダウンロードして安全に保管しましょう。これはWordPressサーバー移行で最も簡単なオプションです。

オプション2：バックアップまたは移行プラグイン

さまざまなバックアップおよび移行プラグインが利用可能です（ここですべてをテストするわけではありませんが、ほとんどのコンセプトは同じです）。

プラグインバックアップ/移行の一般的な動作：

現在のWordPressサイトにバックアッププラグインをインストール
プラグインがデータベースとルートフォルダの完全バックアップを取得
プラグインがこれを圧縮ファイルとして、サーバー上にローカル保存するか、Amazon S3などのクラウドサービスに保存
新しいホストで、新規WordPressと同じプラグインをインストール
プラグインをバックアップファイルに指定（新しいサーバーにコピーするか、クラウドストレージから）
プラグインがすべてを自動的に復元

オプション3：手動バックアップ（完全制御方式）

これにより、WordPressサイトを新しいホストへ移行する際に何が起こっているかを完全に制御し、理解できます。

1. データベースエクスポート：


Copied!mysqldump -u username -p --default-character-set=utf8mb4 database_name > backup.sql
mysqldump -u username -p --default-character-set=utf8mb4 database_name > backup.sql

--default-character-set=utf8mb4 パラメータは、WordPressコンテンツに絵文字や特殊な国際文字が含まれている場合に重要です。これがないと、絵文字が正しく転送されません。

2. ルートフォルダのダウンロード： FTP/SFTPを使用して、WordPressルートフォルダ全体（public_htmlまたはwww）をダウンロードします。これには以下が含まれます：

wp-content（テーマ、プラグイン、アップロード）
wp-config.php
wp-includes
wp-admin
.htaccess

重要： 常にルートフォルダ全体をコピーしてください。一部のプラグインはwp-content外に独自のフォルダを作成するため、それらを見逃したくありません。すべてをコピーすることで、何も残さないことを保証します。

3. SSL証明書： 新しいホストが自動SSL（Let’s Encryptなど）を提供しない場合、現在のホストからSSL証明書をダウンロードします。

SSLに関する注意： Cloudflareを使用している場合、設定に失敗してもSSL証明書を自動的に作成します。または、Let’s Encrypt経由で数秒で新しいSSL証明書を生成できます。最初にSSLが完璧でなくても世界の終わりではありません。ただし、サイトを停止しない移行を目指しているため、DNS変更前にSSLを正しく設定する方が良いでしょう。

新しいホストでの手動復元

新しいホストで新しいMySQLデータベースを作成
データベースバックアップファイルをインポート
ルートフォルダバックアップからすべてのファイルを新しいサーバーのルートフォルダにコピー
新しいデータベース認証情報でwp-config.phpを更新
新しいホストでSSLをインストール/設定

SSL設定を忘れないでください。移行後の多くの問題は、単に新しいサーバーでSSLが適切に設定されていないことが原因です。CloudflareやLet’s Encryptがこれを迅速に修正できますが、真のサイト停止なし移行のために、最初から機能させる方が良いでしょう。

ステップ2：新しいサーバーでWordPressをセットアップ

すべてのWordPressファイルを移動し、データベースをインポートし、サードパーティサービスを設定します。ただし、まだDNSを変更しないでください。

WordPress固有のセットアップチェックリスト：

[ ] すべてのWordPressファイルを新しいサーバーにアップロード
[ ] 新しいホストで新しいMySQL/Mariaデータベースとユーザーを作成
[ ] データベースバックアップを新しいデータベースにインポート
[ ] 新しいデータベース認証情報でwp-config.phpを更新
[ ] ファイルパーミッションを確認（通常、ディレクトリは755、ファイルは644）
[ ] ドメイン名を変更する場合、データベース内のURLを更新：
wp_optionsテーブルのsiteurlとhomeを更新
またはwp-cliを使用：wp search-replace 'oldsite.com' 'newsite.com'
[ ] .htaccessパーマリンクが機能していることを確認

ステップ3：/etc/hostsファイルを使用したテスト

ここで魔法が起こります。あなたのコンピュータ（サーバーではなく）で、「example.comを尋ねられたら、DNSをチェックする代わりに、この新しいIPアドレスに行け」と手動で指示します。

OSでのhostsファイルの場所

ファイルの場所：

Mac/Linux: sudo nano /etc/hosts
Windows: C:\Windows\System32\drivers\etc\hosts を管理者として編集

OSでファイルの場所が異なる場合や、具体的な手順が必要な場合は、「[あなたのOS名] etc/hosts 変更方法」で検索してください。プロセスはオペレーティングシステム間で似ていますが、セットアップによっては追加の手順が必要になる場合があります。

新しいサーバーのIPアドレスを追加

次の行を追加します：


Copied!123.456.789.012 example.com www.example.com
:: example.com www.example.com
123.456.789.012 example.com www.example.com
:: example.com www.example.com

123.456.789.012 を新しいサーバーのIPv4アドレスに置き換えてください。:: はIPv6アドレスを無効化するためのものです。つまり、DNSサーバーがIPv6アドレスも公開していて、このオプションを追加しない場合、ブラウザがIPv6を取得して/etc/hostsファイルのIPv4の代わりに使用するため、/etc/hostsルールがバイパスされます。

重要なIPv6要件

重要なIPv6に関する注意： サイトがIPv6を使用している場合（多くのサイトが使用しています。例えば、CloudflareはデフォルトでIPv6アドレスを提供します）、IPv6行を必ず追加する必要があります。IPv4アドレスのみを追加し、サイトがIPv6をサポートしている場合、ブラウザは依然としてIPv6経由で古いサーバーに接続し、このテストの目的が無効になります。安全のために両方の行を追加してください。

1つのバージョン（example.com または www.example.com のいずれか）のみを使用する場合は、プライマリドメインだけを追加できますが、両方を追加することですべてをカバーします（ただし必須ではありません）。

何が起こったのか？ あなたのコンピュータは、ウェブサイトがすでに移行したと思っています。しかし、世界の他の人にとっては、何も変わっていません。あなたは未来に生きていますが、他のみんなは現在に留まっています。

ステップ4：すべてを徹底的にテスト

Chromeを開きます。F12キーを押して開発者ツールを開きます。ネットワークタブに移動します。「キャッシュを無効にする」にチェックを入れます。

テストすべき重要なWordPressコンポーネント

WordPressサイトのすべてをテストします：

[ ] ホームページが正しく読み込まれる
[ ] 管理ダッシュボード（/wp-admin）ログインが機能する
[ ] お問い合わせフォーム（Contact Form 7、Gravity Formsなど）
[ ] ECサイトの場合、WooCommerceチェックアウト
[ ] ユーザーログインと登録
[ ] WordPressメディアライブラリを通じた画像アップロード
[ ] プラグイン機能（特に重要なプラグイン）
[ ] テーマのカスタマイズが適切に表示される
[ ] パーマリンク構造が正しく機能する
[ ] 検索機能
[ ] コメント（有効な場合）
[ ] カスタム投稿タイプ
[ ] メール送信（パスワードリセット、通知）
[ ] サードパーティ連携があれば確認

ブラウザキャッシュを無効にしたテスト

最終チェックにはシークレットモードを使用してください。なぜか？キャッシュを無効にしていても、ブラウザは巧妙だからです。シークレットモードは偏執モードであり、WordPress移行中は偏執が味方です。

この/etc/hostsテスト方法が、サイトを停止しない移行を可能にします。実際の訪問者が見る前に、新しいサーバーですべてが機能することを確認しています。

重要：WordPressのDNSサーバー変更 vs WebサーバーIP変更

先に進む前に、どのタイプのWordPress移行を行っているかを理解してください：

シナリオ1：WebサーバーIPの変更（同じDNSプロバイダーを維持）
この記事はこのシナリオをカバーしています。ウェブサイトがホストされている場所を変更しますが、DNSレコードは同じDNSプロバイダー（Cloudflare、AWS Route53、またはレジストラなど）に保持します。

シナリオ2：DNSサーバーとWebサーバーの両方を変更
DNSプロバイダーも変更する場合は、2段階で行います：

まず、古いDNSプロバイダーでWebサーバーIPを変更
/etc/hostsメソッドですべてを徹底的にテスト
すべてが機能したら、その後同じレコードですべてDNSネームサーバーを新しいプロバイダーに変更

なぜ分離するのか？両方を同時に変更して何かが壊れた場合、トラブルシューティングが悪夢になります。問題がDNS伝播、DNS設定、またはサーバー設定のいずれであるかがわかりません。

ロールバック戦略：問題が発生したときの準備

DNS TTLとDNSキャッシング動作の理解

WordPressを新しいサーバーへ移行する際、DNSキャッシングの理解は成功する移行に不可欠です。WordPressホスティング変更中にDNSキャッシングが実際にどのように機能するかを以下に示します：

ステージ1：TTL短縮前


Copied!あなたのDNS: TTL = 2日（172,800秒）
DNSリゾルバーA: IPをキャッシュ、48時間後に期限切れ
DNSリゾルバーB: IPをキャッシュ、48時間後に期限切れ
あなたのDNS: TTL = 2日（172,800秒）
DNSリゾルバーA: IPをキャッシュ、48時間後に期限切れ
DNSリゾルバーB: IPをキャッシュ、48時間後に期限切れ

ステージ2：TTLを5分に短縮して12時間経過


Copied!あなたのDNS: TTL = 5分（300秒）
DNSリゾルバーA: まだ古いキャッシュを保持、36時間チェックしない
DNSリゾルバーB: まだ古いキャッシュを保持、36時間チェックしない

（現在のキャッシュが期限切れになったときにのみ、新しいTTLを学習します）
あなたのDNS: TTL = 5分（300秒）
DNSリゾルバーA: まだ古いキャッシュを保持、36時間チェックしない
DNSリゾルバーB: まだ古いキャッシュを保持、36時間チェックしない

（現在のキャッシュが期限切れになったときにのみ、新しいTTLを学習します）

ステージ3：48時間後にTTLを変更


Copied!あなたのDNS: TTL = 5分
DNSリゾルバーA: キャッシュが期限切れ、再度チェック、TTL=5分を確認
DNSリゾルバーB: キャッシュが期限切れ、再度チェック、TTL=5分を確認
あなたのDNS: TTL = 5分
DNSリゾルバーA: キャッシュが期限切れ、再度チェック、TTL=5分を確認
DNSリゾルバーB: キャッシュが期限切れ、再度チェック、TTL=5分を確認

ステージ4：IPアドレスを変更


Copied!あなたのDNS: 新しいIP、TTL = 5分
DNSリゾルバーA: 5分で更新 ✓
DNSリゾルバーB: 5分で更新 ✓
あなたのDNS: 新しいIP、TTL = 5分
DNSリゾルバーA: 5分で更新 ✓
DNSリゾルバーB: 5分で更新 ✓

注意： これは理想的なシナリオです。一部のDNSリゾルバーは、DNSサーバーで設定したTTLに従わない場合があるため、ローカルシステム管理者の決定に従って異なる値を持つ可能性があります。

WordPress移行のための2段階TTL戦略

ステップ1：TTLを下げる（移行の2〜3日前）

Cloudflareのプロキシモードのようなプロキシサービスを使用していない場合は、DNS TTLを5分に短縮します。

重要なタイミング： これは移行の2〜3日前に行ってください。新しいTTLがグローバルに有効になる前に、現在のTTLが期限切れになる必要があります。現在のTTLが2日の場合、5分への短縮は2日経過するまで尊重されません。

ステップ2：必要に応じて迅速なロールバック

TTLを短縮した状態で、WordPressサーバー移行操作中に何かが壊れた場合：

DNSを古いIPにすぐに戻す
ほとんどのDNSリゾルバーは5分で更新（TTLを尊重するもの）
一部はより長くかかる場合がある（TTLを尊重しないもの）
この期間中は両方のサーバーを稼働させ続ける

Cloudflareのプロキシモードを使用している場合： TTL短縮をスキップできます。プロキシにより、DNS伝播の遅延なしにオリジンIPを即座に変更できます。これが即座のロールバックボタンです。

DNS変更：正しく行う

重要：まずサービス依存関係を確認

DNSに触れる前に、現在のプロバイダーに接続するすべてのものを監査してください：

確認すべきWordPress固有のサービス：

メールサービス（SMTPプラグイン、SendGrid、Mailgunなど）
CDN設定（Cloudflare、StackPathなど）
決済ゲートウェイ（Stripe、PayPal WebhookのIP制限付き）
IPホワイトリストを使用するサードパーティAPI
バックアップサービス（UpdraftPlus、BackupBuddyクラウドストレージ）
セキュリティプラグイン（Wordfenceなど）
SSL証明書
予約投稿やバックアップのCronジョブ
外部メディアストレージ（Amazon S3、DigitalOcean Spacesなど）

徹底的に確認してください。サイト自体が完璧に機能していても、サービス依存関係はWordPress移行が失敗する最も一般的な理由の1つです。

実際の移行日

DNSレコードの変更

DNSレコードを新しいIPに変更
古いサーバーをシャットダウンしない
両方のサーバーを監視

TTLウィンドウ中（5分に短縮したことを覚えていますか）、一部のユーザーは古いサーバーに、一部は新しいサーバーにアクセスします。両方を稼働させる必要があります。これがWordPressサーバー移行中にサイトを停止しないための鍵です。

両方のサーバーを稼働させ続ける期間

低トラフィックサイト： おそらく24時間後に古いサーバーをシャットダウンできます
高トラフィックサイト： 完全な元のTTL期間を待つ（短縮する前）
慎重派（推奨）： 72時間待ってアクセスログを確認

IPホワイトリストの落とし穴

常に尋ねてください：「サービスのいずれかがIPホワイトリストを使用していますか？」

例：

決済ゲートウェイ
メールAPI
サードパーティ連携
企業ファイアウォール
分析ツール

「はい」の場合、移行前に新しいサーバーのIPをホワイトリストに登録する必要があります。一部のサービスは、ホワイトリストの更新に24時間かかります。それに応じて計画してください。

WordPress移行チェックリスト

3日前：

[ ] Cloudflareプロキシを使用していない場合、DNS TTLを5分に短縮
[ ] すべてのWordPressプラグインとサービス依存関係を監査
[ ] サードパーティまたはネットワークファイアウォールのIPホワイトリストを更新
[ ] WordPressの完全バックアップを取得（UTF-8mb4のデータベース、すべてのファイル、wp-config.php）

移行日：

[ ] /etc/hostsファイルをセットアップ
[ ] WordPress管理ダッシュボードログインをテスト
[ ] すべての重要なプラグインをテスト
[ ] キャッシュを無効にしてすべてをテスト
[ ] シークレットモードで再度テスト
[ ] メールがまだ機能することを確認（お問い合わせフォーム、パスワードリセット）
[ ] SSL証明書を確認
[ ] 決済処理を確認（該当する場合WooCommerce）
[ ] パーマリンク構造をテスト
[ ] DNSを変更
[ ] 両方のサーバーを稼働させ続ける
[ ] 両方のサーバーのエラーログを監視

移行後：

[ ] 24〜72時間両方のサーバーを監視
[ ] WordPressメールが送信されていることを確認
[ ] フォームが送信されていることを確認
[ ] WooCommerceチェックアウトプロセスを複数回テスト（該当する場合）
[ ] すべてのプラグインがまだ機能していることを確認
[ ] WordPress cronジョブが実行されていることを確認
[ ] その後のみ古いサーバーをシャットダウン
[ ] TTLを下げた場合、1週間後に通常のTTLに戻す

低トラフィックサイトのDNS変更には48時間は不要かもしれません

低トラフィックサイト？ ほとんどの訪問者が新規なので、DNS移行はほぼ即座です。彼らのDNSリゾルバーは古いIPをキャッシュしていません。時には、ローカルDNSキャッシュにウェブサイトのIPを持っているのは、あなたと技術担当者だけということもあります。

高トラフィックサイト？ DNSサーバーが5分前、1時間前、12時間前、2日前にIPをキャッシュしたユーザーがいます。彼らは皆、異なるバージョンの現実を見ています。これが、両方のサーバーを稼働させ続ける理由であり、DNS変更前にすべてをテストする理由です。

FAQs

よくある質問

CDNキャッシュはどうですか？パージする必要がありますか？


Copied!古いサイトと新しいサイトが異なる場合、一般的に古いCDNキャッシュファイルが問題を引き起こすことを心配する必要はありません。古いキャッシュは新しいサイトに干渉しません。

主な考慮事項はキャッシュウォーミングです。新しいサーバーではCDNキャッシュが空なので、新しいファイルで再び満たされるまで時間がかかります。つまり、各ページへの最初の訪問者は、CDNがコンテンツを取得してキャッシュする間、読み込み時間が遅くなります。これは正常で一時的なものです。訪問者がページにアクセスすると、キャッシュは自然にウォームアップされます。
古いサイトと新しいサイトが異なる場合、一般的に古いCDNキャッシュファイルが問題を引き起こすことを心配する必要はありません。古いキャッシュは新しいサイトに干渉しません。

主な考慮事項はキャッシュウォーミングです。新しいサーバーではCDNキャッシュが空なので、新しいファイルで再び満たされるまで時間がかかります。つまり、各ページへの最初の訪問者は、CDNがコンテンツを取得してキャッシュする間、読み込み時間が遅くなります。これは正常で一時的なものです。訪問者がページにアクセスすると、キャッシュは自然にウォームアップされます。

移行後にWordPressプラグインを再インストールする必要がありますか？

いいえ。

すべてのWordPressファイルを正しくコピーした場合（wp-content/pluginsを含む）、すべてのプラグインはサイトと一緒に移動します。

ただし、外部サービスを使用する一部のプラグイン（バックアッププラグイン、セキュリティプラグイン、またはキャッシュプラグインなど）は、新しいサーバーで設定を更新または再接続する必要がある場合があります。移行後は常にプラグインの機能を徹底的にテストしてください。

メールは移行中どうなりますか？

このガイドは、ウェブサイト移行専用です。サードパーティのメールサービス（Google Workspace、Microsoft 365、またはその他のメールプロバイダー）を使用していて、メールのDNSレコード（MXレコード、SPF、DKIM）を変更せずにウェブサイトのIPアドレスのみを変更している場合、メールは移行中も完璧に機能します。

メールとウェブサイトホスティングは別です。MXレコードやその他のメール関連のDNSレコードを変更しない限り、ウェブサイトの変更に関係なくメールは正常に機能し続けます。

DNSプロバイダー（ネームサーバー）も変更します。特別な考慮事項はありますか？

はい。DNSプロバイダーとWebサーバーの両方を変更する場合は、2段階で行います：

1. DNSを古いプロバイダーに保持
2. 古いDNSプロバイダーでWebサーバーのIPアドレス（Aレコード）のみを変更
3. このガイドで説明されている/etc/hostsメソッドを使用して徹底的にテスト
4. すべてが完璧に機能したら、**その後**ネームサーバーを新しいDNSプロバイダーに変更
5. すべてのDNSレコード（A、MX、TXT、CNAMEなど）が新しいDNSプロバイダーで同一であることを確認

なぜか？両方を同時に変更して何かが壊れた場合、それがDNS設定の問題、DNS伝播の問題、またはサーバー設定の問題であるかがわかりません。変更を分離することで、トラブルシューティングがはるかに簡単になります。

両方のサーバーをどのくらいの期間稼働させ続けるべきですか？

低トラフィックサイトの場合は最低24時間。高トラフィックサイトまたは高いTTL（2日など）があった場合は、少なくとも72時間待ちます。古いサーバーのアクセスログを確認してください。トラフィックがごくわずか（通常の1%未満）になったら、シャットダウンしても安全です。

TTLを下げるアクセス権がない場合はどうすればよいですか？

一部のDNSプロバイダーはTTL変更を許可していないか、ホスティングプロバイダーがDNSを管理している場合があります。この場合：

より長い移行ウィンドウを計画（両方のサーバーを24〜72時間稼働）
プロキシモードを有効にしたCloudflareの無料プランの使用を検討
ロールバックが遅くなるため、/etc/hostsテストメソッドをさらに厳密に使用
最もトラフィックが少ない期間に移行をスケジュール

/etc/hostsでメール送信をテストできますか？

はい、ただし注意点があります。アプリケーションからメールが生成および送信されていることをテストできます。ただし、メール送信サービスがIPホワイトリストを使用している場合は、テスト前に新しいサーバーのIPをホワイトリストに追加してください。そうしないと、メールはアプリケーションから送信されているように見えますが、メールサービスによって拒否されます。

CloudflareのプロキシモードとDNSのみモードの違いは何ですか？

プロキシモード（オレンジ色のクラウド）：

Cloudflareがリバースプロキシとして機能します。訪問者はCloudflareのサーバーに接続し、Cloudflareがオリジンサーバーに接続します。DNS伝播なしでオリジンIPを即座に変更できます。

DNSのみモード（グレーのクラウド）：

CloudflareはDNSレコードを管理するだけです。IPを変更すると、TTLに基づく通常のDNS伝播遅延の影響を受けます。移行の場合、プロキシモードは即座のロールバック機能を提供するため、はるかに安全です。

予想外だった？

WordPressを新しいホストへ移行することは、ストレスであるべきではありません。WordPress移行がストレスになるのは、手順をスキップしたり、「たぶん大丈夫だろう」と思い込んだりするときだけです。

思い込まないでください。準備してください。

テストには/etc/hostsを使用してください。プロキシを使用していない場合は、早めにTTLを短縮してください。シークレットモードでテストしてください。WordPressプラグインの依存関係とサードパーティサービスの統合を確認してください。移行中は両方のサーバーを稼働させ続けてください。そして、データベースに絵文字がある場合は、UTF-8mb4エンコーディングで適切なバックアップを取ってください。

これらの手順に従えば、サイトを停止することなくWordPress移行が完了します。

昔のWindowsのオセロ/リバーシゲームを思い出します。チャットで自由に入力できず、事前定義されたメッセージしか選択できませんでした。最も象徴的なメッセージの1つは：

「予想外だった？」

これは、相手が負けたときに表示されるメッセージでした。準備不足で移行が失敗し、サイトが動かなくなったとき、まさにこの気分になります。「こんなことになるとは思わなかった」と。このガイドを使用すれば、次の移行でそんな失敗をすることはありません。

About the Author

Selim Koç

CEO & CTO

Began his tech journey in 1994, earning his DOS certificate while in middle school. His dedication to software development led him to pursue a high school diploma in the software department, followed by a bachelor’s degree at Boğaziçi University. Selim was also awarded a scholarship from JASSO to study for a year at Waseda University in Japan.

Selim founded a software company in 2009 that has successfully served multinational clients for over 15 years. His goal is to make high-tech solutions, emphasizing speed and security, accessible to everyone.