WordPress のドメイン変更：転送・検索シグナル・メールを一緒に確認

ブランド名を変え、新しいドメインを登録しても、次に行うことは WordPress のサイト URL をすぐ変更することとは限りません。記事内の画像、古い SNS 投稿、検索結果、フォーム通知、仕事用メールは、まだ旧名称を指している可能性があります。旧入口ごとの行き先を決める対応表が必要です。

例えば手作り工房が覚えやすいドメインへ変更し、既存の解説記事を残す場合を考えます。読者が旧記事のリンクから同じ新記事へ行けること、編集者がログインして作業を続けられること、旧メールアドレス宛ての問い合わせも受け取れることが実際の目標です。以下ではこの三つの経路に沿って切り替えます。

旧 URL を整理し、ページごとの新しい行き先を決める

サイトマップ、記事一覧、よく使うナビゲーション、実際に訪問されるページから一覧を作り、画像とダウンロードファイルも含めます。ドメインだけを変更するなら、最初は元のパスを維持すると対応付けが容易です。カテゴリーを整理したり記事を削除したりするなら、各項目の新しい行き先と理由を記録します。

例えば旧 /workshop/ は新サイトの講座案内へ送るべきで、すべての旧記事と一緒にトップページへ送るべきではありません。複数の記事を統合した場合は、その情報を実際に網羅する新ページへ転送できます。削除済みで妥当な代替ページがない場合は、適切な「見つからない」応答を返します。読者が求めた情報を見つけられるかが、対応表の判断基準です。

1. 記事、ページ、メディア、ダウンロード、重要な外部リンクの旧 URL を一覧にする。
2. 各項目に新 URL を指定し、維持・統合・削除の理由を記録する。
3. トップページ、人気の個別ページ、中国語の文字を使ったパス、クエリーパラメーター付きリンクを抜き取り確認する。

バックアップ後にデータベース内の URL 置換をプレビューする

WordPress のサイトアドレスは設定の一部にすぎません。記事、プラグイン設定、ページビルダーには絶対 URL が別途保存されていることがあります。まずファイルとデータベースをバックアップし、アクセスを制限したコピーで WordPress のデータ形式に対応する移行ツールを使います。SQL 全体のドメインをテキストエディターで単純置換すると、シリアライズされたデータを壊すおそれがあります。

技術担当者が WP-CLI を使う場合、公式の search-replace はシリアライズされたデータに対応し、書き込まずに予定内容を報告する --dry-run も備えています。対象テーブル、旧 URL、新 URL を照合してから変更予定件数を確認します。同じデータベースに別サイトもある場合は特に、全テーブルを無条件に含めないでください。

置換するのは変更が必要なサイトの URL です。ドメイン名だけの文字列はメールアドレス、過去の記録、外部サービスの設定にも現れます。すべてを無差別に変更してはいけません。完了後は独自テーマのファイル、CSS、メニュー、プラグインのキャッシュを調べ、表示中のページが旧サイトからリソースを取得しないことを確かめます。

新旧ドメインの双方で HTTPS を維持する

新ドメインには正しい DNS 設定と有効な証明書が必要です。旧ドメインで HTTPS を使っていたなら、転送を続ける間は旧側にも有効な接続を維持します。ブラウザーは転送応答を受け取る前に安全な接続を確立します。旧証明書が失効すると、新サイトに到達する前に警告が表示される場合があります。

ホスト事業者またはサイト管理者が確認済みの対応表に従って恒久的な転送を設定し、旧 URL の応答と最終的な行き先をテストします。Google は 301 や 308 などのサーバー側の恒久的な転送を推奨し、できるだけ直接最終ページに到達させるよう案内しています。ルートドメイン、www、HTTP、HTTPS の規則が互いに行き来する設定は避けます。

1. 新ドメインのルートドメインと www について、主要 URL の方針を統一する。
2. さまざまな旧 URL が意図した新ページに着くかを確認し、転送の有無だけで判断しない。
3. 画像、ダウンロード、フォームに循環、欠けたパス、セキュリティ警告がないか調べる。

検索シグナルと自分で管理できるリンクを更新する

新ページの canonical、サイトマップ、内部リンクは新 URL を指すようにします。公開前にはテスト用のインデックス禁止設定を解除します。Search Console のアドレス変更ツールには適用条件があります。ドメイン間を実際に移動する場合は、公式の要件に従い旧サイトと新サイトを確認し、ツールのチェックを完了します。

このツールは転送を作るものではなく、検索結果を即座にすべて更新するものでもありません。Google は転送をできるだけ長く、通常少なくとも一年維持するよう勧めています。使用中の名刺、ブックマーク、外部リンクがあれば、さらに長く支えることも検討します。移行中には一時的な変動があり得るため、数日で順位が戻るとは約束しません。

自分で変更できる入口も別途予定に入れます。SNS のプロフィール、メールマガジンのフッター、店舗情報、協力サイト、文書中の QR Code などです。クリック数が多いものや取引に関わるものを優先し、担当者と完了日を残します。旧 URL が転送される場合でも、新 URL への直接リンクは待ち時間と将来の保守を減らします。

メールを別の検証対象として扱う

サイトの転送だけでは old.example のメールボックスが new.example に自動変換されません。メールサービスに新ドメインの追加方法、アカウントとエイリアスの規則を確認し、必要な MX レコードと送信者認証を設定します。例えば Google Workspace には主要ドメインの変更と旧ドメインのエイリアスを残す別の手順があり、WordPress の管理画面設定では代用できません。

日常使うメールボックス、フォームの送信元、返信先、アカウント復旧用アドレスを列挙します。旧アドレスでの受信を維持し、顧客に新アドレスを知らせ、外部メールボックスから新旧両方へ送ってみます。受信、返信、送信者の表示を確認してください。転送設定がある場合も、設定保存だけでなく実際に転送先へ届いたか確かめます。

引き継ぎ表を作らずに従業員全員のログインアカウントを同じ日に変更しないでください。メールアドレスで利用者を識別する外部サービスでは、名称変更後に再認証や管理者による調整が必要な場合があります。旧アドレスへの依存を先に調べ、サイトは移行できても管理者がログインできなくなる事態を防ぎます。

実際に起きた問題から切り替え結果を追う

公開後は失敗した URL、フォーム通知、新旧の受信箱を定期的に調べ、問題を URL 対応表に結び付けます。記事のアクセスが減ったら、まず旧 URL が正しい新ページへ転送されるか、そのページがインデックス可能か、画像と内容が完全かを確認し、その後で別の原因を検討します。

旧ドメインの更新と証明書の管理、転送サービスの担当者を残します。元に戻す必要がある場合は、新サイトに追加された記事や問い合わせを先に保存し、どの設定を戻すか判断します。古いバックアップで新しいデータを丸ごと上書きしてはいけません。切り替え記録、アカウントの入口、検証結果を一つの引き継ぎ文書にまとめ、次の管理者にも止められない旧サービスが分かるようにします。

URL を変えずにホストだけを移す

サイトのバックアップと復元を検証する

ドメインとホスティングの更新管理

• チュートリアル
• アプリ・ソフト
• サイト構築・EC
• WordPress