Hara Daizo WordPressのURL変更は、設定画面の値を直すだけで終わる作業ではありません。WordPress本体の設置場所を変えず公開URLだけ変える、サブディレクトリからドメイン直下へ見せる、別ドメインへ移転するという3ケースで、必要なファイル操作、データ置換、リダイレクトが異なります。
最初に「WordPressアドレス」と「サイトアドレス」の役割を分け、現行サイトを戻せる状態にします。この記事では3ケース別の操作、管理画面に入れなくなった場合の復旧、URL置換とSEOの注意点まで説明します。サーバー変更を伴う一式の作業は「移行作業全体の流れ」と照合して進めてください。
WordPressで変更できるURLの種類
WordPressの一般設定には、役割の違う二つのURLがあります。
- WordPressアドレス（URL）：wp-admin、wp-includesなどWordPress本体のファイルが置かれた場所
- サイトアドレス（URL）：訪問者がサイトを開く公開側の入口
WordPress公式文書は、両方に「https://」を含め、末尾へスラッシュを付けない形式を案内しています。通常のルート設置では二つは同じです。WordPress本体を「/wordpress」などへ置き、公開側だけドメイン直下にする構成では異なります。
作業内容は次の3ケースに分けます。
| ケース | 例 | 主な変更 |
|---|---|---|
| 公開URLだけ調整 | www有無、httpからhttps | 設定、証明書、転送、混在URL |
| サブディレクトリから直下表示 | /wordpress/から/へ | URL設定、index.php、.htaccess |
| 別ドメインへ変更 | old.exampleからnew.example | DNS、証明書、DB置換、301、検索設定 |
ログインページのパスをセキュリティプラグインで変える操作は、サイトURLやドメイン変更とは別です。目的が管理画面入口の変更なら「ログインURLの変更」を確認してください。
記事や固定ページ一件のURL変更も別作業です。その場合は投稿のスラッグと「パーマリンク設定」を確認し、旧URLから対応する新URLへ転送します。
URLを変更する前の準備
URLを先に変更すると、管理画面から追い出され、画像やCSSが旧URLを参照することがあります。変更前にファイル、データベース、DNS、証明書、転送をそろえます。
準備する項目は次のとおりです。
- 対象ケースと完成後の正規URLを一つ決める
- WordPressファイルとデータベースをバックアップする
- 現在のWordPressアドレスとサイトアドレスを記録する
- サーバー、ドメイン、DNS、SSLの管理権限を確認する
- 旧URLを含む場所を検索し、置換範囲を見積もる
- メール、フォーム、決済、外部APIの登録URLを洗い出す
- 失敗時に戻す値、ファイル、担当者を決める
完全な取得範囲と復元確認は「作業前のバックアップ」で整理できます。ECや予約サイトでは、DBを戻す間に増えた注文を失わないよう、書き込み停止時間と差分保全も決めます。
ドメイン変更では、切替前に新ドメインの所有権、DNS設定、TLS証明書、メールアドレスへの影響を確認します。URLは変えても同じサーバーを使う場合と、新サーバーへ同時移転する場合を混同しないでください。
ステージングで試す場合は、検索エンジンからのアクセスを制御し、メール・決済をテスト用にします。公開時にnoindexやBasic認証を外し忘れないよう、解除項目も作業表へ入れます。
管理画面からサイトアドレスを変更する方法
同じサーバー、同じ設置場所のまま公開URLを調整するだけなら、管理画面の「設定」から「一般」を開き、WordPressアドレスとサイトアドレスを目的に合わせて変更します。保存直後にログインURLやCookieの対象が変わるため、再ログインが必要になることがあります。
httpからhttpsへ変える場合は、先に正しいTLS証明書を設定し、新しいHTTPS URLでWordPressファイルへ到達できることを確認します。その後に二つのURLをhttpsへ変更し、httpからhttpsへのリダイレクト、内部URLの置換、混在コンテンツを確認します。
www有無の変更も同様に、正規ホスト名を一つ選びます。DNSで両方が到達し、サーバーが両ホストを受け付け、非正規側から正規側へ一回の恒久転送になることを確認します。
変更後は、サイトマップ内のURLが新しい正規URLになっているかを確認します。生成方法や検索エンジンへの送信は「サイトマップ設定」で確認できます。
マルチサイトではURLがネットワーク設定や複数テーブルへ関係し、単一サイト向けの手順をそのまま使えません。ネットワーク構成、サブドメイン型・サブディレクトリ型、ドメインマッピングの文書に従ってください。
サブディレクトリからドメイン直下へ変更する方法
WordPress本体をサブディレクトリに残したまま、訪問者にはドメイン直下で見せることができます。この構成では、WordPressアドレスはサブディレクトリ、サイトアドレスはルートにします。
たとえば本体が「https://example.com/wordpress」にあり、公開側を「https://example.com」にする場合の流れは次のとおりです。
- 一般設定でサイトアドレスだけを「https://example.com」へ変更する
- サブディレクトリ内のindex.phpと.htaccessをルートへコピーする
- ルート側index.phpのWordPress読込パスをサブディレクトリに合わせる
- パーマリンクの画面を保存して規則を更新する
- ルートURL、投稿、管理画面、画像を確認する
「コピー」と「移動」を取り違えないでください。WordPress本体をサブディレクトリに残す方式では、コアファイル一式をルートへ移す必要はありません。ルートに既存のindex.phpや.htaccessがある場合は、上書き前に保存し、ほかのアプリケーションや転送規則との衝突を確認します。
旧サブディレクトリの公開URLが検索結果や外部リンクに残るなら、各旧URLから対応するルートURLへ転送します。転送の実装とループ回避は「リダイレクト設定」で確認できます。
WordPressのドメインを変更する手順
別ドメインへの変更は、WordPress設定、サイト内データ、サーバー、DNS、検索エンジンを一つの移転として扱います。新旧ドメインを同時に利用できる期間を確保すると、安全に切り替えられます。
基本の手順は次のとおりです。
- 新ドメインを取得し、所有権と更新設定を確認する
- 新サーバーまたは既存サーバーへ新ドメインを追加する
- 新ドメインのTLS証明書を発行する
- ファイルとDBを新環境へ用意する
- WordPressアドレスとサイトアドレスを新ドメインへ変更する
- DB内の旧URLをシリアライズ対応ツールで置換する
- パーマリンク、キャッシュ、外部連携を更新する
- 旧URLから新URLへ一対一の301リダイレクトを設定する
- DNSを切り替え、表示、管理、送信処理を確認する
- Search Console、解析、広告などの登録を更新する
新環境を公開前に確認する際、ローカルのhostsファイルやホスティングのプレビュー機能を使う方法があります。仮ドメインでDBを全面置換してから本番ドメインへ再置換すると履歴が増えるため、完成時のURLを想定した検証方法を選びます。
旧ドメインは転送と所有権維持のために必要です。移転直後に解約すると、外部リンク、古いブックマーク、メール内URLから新サイトへ案内できません。保持期間はサイト規模と契約条件に合わせて決めます。
管理画面へ入れない場合の変更・復旧方法
URLを誤って保存して管理画面に入れない場合でも、データベースを初期化する必要はありません。WordPress公式文書には、wp-config.php、データベース、WP-CLIなど複数の修正方法があります。
最も戻しやすい方法は、wp-config.phpへ正しい値を一時的に固定することです。
define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );WP_HOMEは公開側URL、WP_SITEURLはWordPress本体のURLです。設定すると管理画面の一般設定から編集できなくなり、データベース内の値自体は変わりません。復旧後に恒久構成を決め、不要なら定数を削除します。
データベースへアクセスできる場合は、対象サイトのoptionsテーブルでhomeとsiteurlを正しい値へ戻します。テーブル接頭辞はwp_とは限りません。編集前にDBをバックアップし、別のWordPressのテーブルを選んでいないか確認してください。
WP-CLIが使える環境では、homeとsiteurlのオプションを更新できます。現在値を表示してから変更し、対象パスと対象URLが正しいか確認します。
WordPress公式のRELOCATE方式は一時復旧に使えますが、ログイン先からsiteurlを書き換える性質があります。作業後に残すと危険な構成になるため、公式手順どおり必ず削除します。
URL変更後に必要な設定
URLが開けただけでは完了ではありません。サイト内と外部サービスに旧URLが残っていないか確認します。
変更後の確認項目は次のとおりです。
- パーマリンクを保存し、投稿や固定ページを開く
- メニュー、ウィジェット、ロゴ、画像、CSS背景を確認する
- キャッシュプラグイン、サーバーキャッシュ、CDNを削除する
- フォーム送信、メール内リンク、パスワード再設定を試す
- 決済の戻り先、Webhook、OAuthコールバックを更新する
- canonical、OGP、構造化データ、フィードを確認する
- robots.txtとサイトマップのURLを確認する
- 旧URLから新URLへの応答を複数ページで確認する
- アクセス解析とSearch Consoleの設定を更新する
メールアドレスのドメインも変える場合は、Webサイトとは別にDNSのMX、SPF、DKIM、DMARCやメールボックス移行が必要です。サイトURLを変えただけでメールが自動移行されるわけではありません。
URL置換でデータを壊さないための注意
WordPressのDBには、文字列の長さを含むシリアライズ形式で設定が保存されることがあります。SQLの単純なREPLACEやテキストエディターでの一括置換は、長さ情報を壊してテーマやウィジェットの設定を読めなくする可能性があります。
WP-CLIのsearch-replaceは、シリアライズされたデータを考慮して置換します。実行前にdry-runで対象件数を確認し、バックアップ後に本実行します。
wp search-replace 'https://old.example' 'https://new.example' --skip-columns=guid --dry-run結果が想定どおりなら、dry-runを外して実行します。マルチサイトではnetworkオプションや対象テーブルが変わるため、単一サイト用コマンドをそのまま使いません。プラグイン独自テーブルや別プレフィックスの表を含めるかも確認します。
WordPress公式文書は、投稿テーブルのGUIDを変更しないよう強く注意しています。GUIDはフィードなどで投稿を識別する値であり、サイト移転に合わせて通常のURLとして置換する対象ではありません。
置換後も、テーマファイルへ直書きしたURL、CSSファイル、外部サービス側設定、バックアップ内の文字列は別です。対象ごとに変更し、秘密情報を含むDBダンプは作業後も安全に保管・削除します。
SEO評価を引き継ぐための注意点
Google公式は、URL変更を伴うサイト移転で、新旧URLの対応、恒久リダイレクト、内部リンク、サイトマップ、Search Console、監視を整えるよう案内しています。移転中は一時的にクロールや検索表示が変動する可能性があります。
引き継ぎの要点は次のとおりです。
- 可能な限りURLのパス構造を維持する
- 旧URLごとに最も対応する新URLへ301または308で転送する
- リダイレクトチェーンとループを作らない
- 新URLを内部リンク、canonical、サイトマップへ反映する
- 旧・新サイトをSearch Consoleで確認する
- robots.txt、noindex、認証が公開を妨げていないか確認する
- 404、サーバーログ、検索トラフィックを継続監視する
トップページへの一括転送は、内容の対応関係がないページには適しません。削除したページに代替がなければ、正しい404または410を返します。
Googleのサイト移転手順では、新サイトの容量やクロール受入れも確認項目です。CDNやWAFがGooglebotを誤って遮断しないか、新サーバーが旧URLからの転送を含むアクセス増に耐えられるかを見ます。
URL変更で起こるトラブルと対処
URL変更後の代表的な症状は、原因の層ごとに分けると対応しやすくなります。
| 症状 | 主な確認先 | 対処の方向 |
|---|---|---|
| 管理画面へ入れない | home、siteurl、Cookie | wp-config.phpやDBで正しい値へ戻す |
| リダイレクトが繰り返す | WordPress、サーバー、CDN | 正規化規則を一つにまとめる |
| CSS・画像が読めない | DB内旧URL、キャッシュ、CORS | 安全な置換とキャッシュ削除 |
| 一部ページが404 | パーマリンク、.htaccess、Nginx規則 | 規則を再生成・確認する |
| HTTPS警告が出る | 混在コンテンツ、証明書 | http資産を置換し証明書を確認する |
| フォームや決済が戻らない | 外部サービス登録URL | コールバックとWebhookを更新する |
最初にブラウザの最終URLとHTTP応答を確認し、WordPress内のリダイレクト、Webサーバー、CDNを一層ずつ切り分けます。複数のプラグインでHTTPS化やwww統一を行うと規則が競合しやすいため、どこで正規化するか決めます。
旧URLが残る場所を発見しても、DB全体を再び無条件置換しません。対象テーブルと値を確認し、バックアップ、dry-run、結果確認を繰り返します。
よくある質問
基本のURL変更に加え、TLS証明書、httpからhttpsへの恒久転送、混在コンテンツ、外部サービスのコールバックを確認します。証明書が使える前にWordPress側をhttpsへ変えると管理画面へ入れなくなるため、順序が重要です。
Webサイトのドメイン変更だけでは、メールボックスや過去メールは移りません。新ドメインのメールを使うなら、メールサービス、MX、送信認証、アカウント、転送、利用端末を別途設定します。
記事の編集画面でスラッグを変更し、旧記事URLから新記事URLへ一対一の恒久リダイレクトを設定します。内部リンク、canonical、サイトマップも新URLになっているか確認してください。
まとめ
WordPressのURL変更は、公開URLの調整、サブディレクトリから直下表示、別ドメインへの移転のどれかを先に特定します。WordPressアドレスは本体ファイルの場所、サイトアドレスは訪問者向けの入口であり、目的によって同じ値にも別の値にもなります。
作業前にファイルとDBを保存し、管理画面に入れない場合の戻し方を用意してください。変更後は、シリアライズ対応のURL置換、パーマリンク、証明書、外部連携、旧URLごとのリダイレクト、検索エンジン向け設定まで確認して完了です。