WordPress サイトの URL がステージングからライブに変更されたことでダッシュボードが消え、完全にリセットする必要があった方法

公開: 2025-11-15

WordPress サイトを立ち上げるには、多くの場合、すべてを公開する前にテーマ、プラグイン、コンテンツをテストするステージング環境から始める必要があります。これは、Web 開発プロセスにおいて重要なステップです。しかし、URL の変更など、簡単なはずの操作によって WordPress ダッシュボードが消去され、サイトが機能不全に陥り、完全にリセットされるとどうなるでしょうか?まさにそれが私に起こったことです。他の人が同じ間違いをしないように、私の経験を共有したいと思います。

TLDR

サイトの URL を変更して、WordPress サイトをステージング環境からライブドメインに移動しました。残念ながら、これを間違った方法で行うと、管理ダッシュボードが完全に壊れてしまいました。完全にリセットし、データベースを再構成し、バックアップからコンテンツを復元する必要がありました。この記事では、何が問題だったのか、そして自分のサイトで同様の災害を防ぐ方法について説明します。

失敗: URL を不適切に変更する

すべてが順調に進んでいた。私は何週間もかけてレイアウトを調整し、適切なプラグインをインストールし、ステージング環境でモバイルの応答性が問題なく機能することを確認しました。本番稼働の段階になったとき、 [設定] > [一般]画面でWordPress アドレス (URL)とサイトアドレス (URL) の変更についてオンラインで見つけたドキュメントに従いました。それは単純明快に思えた。結局のところ、ステージングドメインをライブドメインに更新する必要があるだけですよね。

間違っている。「変更を保存」をクリックするとすぐに、ダッシュボードが起動されました。再度ログインしようとすると、空白の白い画面、または一般にWordPress の「死の白い画面」として知られる画面が表示されました。私のフロントエンドも正しく読み込まれませんでした。その瞬間、私は重大な間違いを犯したことに気づきました。

問題の根源

WordPress は、重要な URL 情報をデータベースとコードの両方に保存します。ダッシュボード内で変更すると、データベース内のいくつかのレコードのみが更新されます。ただし、私のステージング環境には、ファイルパス、キャッシュ、およびシリアル化された PHP データが古い URL に関連付けられたままでした。データベース全体のステージング URL のすべてのインスタンスを適切に置き換えないと、事態は破綻してしまいます。

私が遭遇した中心的な問題は次のとおりです。

シリアル化の問題: WordPress の一部の設定はシリアル化された PHP 配列として保存されます。 WP-CLIやWP Migrate DBなどの特殊なツールを使用して慎重に処理しない限り、文字列の直接置換は機能しません。
ハードコードされたリンク:ウィジェット、テーマオプション、および一部のカスタム投稿タイプには、ステージングを指すハードコードされた URL がありました。これらはドメイン切り替え後に失敗しました。
管理者のロックアウト:サイトの URL が変更されると、ログインページが壊れたステージングパスにリダイレクトされ、私は完全にロックアウトされました。

回復を試みています

初心者フォーラムで見つかるいくつかの一般的な修正を試しました。

wp-config.phpを手動で編集してdefine('WP_HOME', 'https://livesite.com')およびdefine('WP_SITEURL', 'https://livesite.com')を使用して新しいライブ URL を強制します。
phpMyAdmin にアクセスして、 wp_optionsテーブルを直接更新します。
ブラウザーのキャッシュをクリアし、プラグインを非アクティブ化し、テーマフォルダーの名前を変更します。基本的には、完全な削除以外のすべてのことを試します。

何も機能しませんでした。サイトはフロントエンドとバックエンドの両方でまだダウンしていました。さらに悪いことに、ステージング後の形式でのデータベース構造の最新の完全バックアップを持っていませんでした。ステージングドメインがまだどこでも参照されていました。

苦渋の決断: 完全なリセットと復元

何時間も回復に失敗した後、最善の策は最初からやり直すことだと気づきました。ありがたいことに、投稿コンテンツとテーマのカスタマイズを XML ファイルにエクスポートし、ステージングサイトから FTP 経由で画像とアセットを保存していました。これを使用して、Web サイトの完全なリセットを開始しました。その方法は次のとおりです。

1. WordPress インストールを消去しました

ホスティングプラットフォームのコントロールパネルを使用して、現在の WordPress インストールと破損したデータベースを削除しました。ライブドメインに WordPress を再インストールして、白紙の状態から始めました。

2. 逆輸入されたコンテンツ

WordPress Importerプラグインを使用して、投稿、ページ、基本的なメタデータを含むバックアップ XML ファイルをアップロードしました。メディアファイルが見つからない場合は、手動で再アップロードする必要がありました。

3. 再インストールおよび再構成されたプラグイン

リセットでプラグインの設定が消えてしまったので、それぞれ再インストールして設定し直しました。これには、特にカスタム投稿タイプとユーザーロール構成が含まれる場合に、かなりの時間がかかりました。

4. 再構築されたメニュー、ウィジェット、カスタマイザー設定

残念ながら、特にcustomize_changesetデータを明示的にバックアップしていない場合、このデータは通常のエクスポートに常に含まれるわけではありません。幸運にも開発中に撮影したスクリーンショットを参照して、メニューとウィジェットを手動で再作成する必要がありました。

すべてから学んだこと

この事件は重大な警鐘を鳴らした。あなたが私のように難しい方法でそれらを学ぶ必要がないように、私はこれらの教訓を共有しています。

重要なポイント:

影響を十分に理解していない限り、WordPress 管理パネルからサイト URL を変更しないでください。
WP Migrate DB 、 Duplicator 、またはAll-in-One WP Migrationなどの専用の移行ツールを使用して、ステージングからライブへの移行を処理します。
構造的な変更を行う前に、必ずファイルとデータベースの両方をバックアップしてください。
データベース内の URL はシリアル化されている可能性があるため、単純な文字列の置換は破損につながる可能性があることを理解してください。

推奨される移行戦略

サイトをステージング環境からライブ環境に移行する予定がある場合は、次の戦略を使用してリスクを最小限に抑えてください。

すべてをバックアップする: プラグインまたはホストのツールを使用して、サイトとデータベースの完全バックアップを実行します。
移行プラグインを使用する: WP Migrate DB Proなどのツールは、シリアル化された配列を含む URL を安全に置き換えます。
内部リンクをインテリジェントに更新する: 移行後、シリアル化オプションを有効にしてBetter Search Replaceなどのツールを使用し、内部 URL を正しく更新します。
wp-config.phpは絶対に必要な場合にのみ更新し、URL の変更は GUI だけに依存しないでください。
リダイレクトと SSL を確認する: 新しいライブサイトが適切にリダイレクトされ、HTTPS が設定されていることを確認します。

結論

URL をステージングからライブに変更するのは小さなアクションのように思えますが、WordPress の場合、正しく行われないと壊滅的な結果を招く可能性があります。スムーズなサイトの立ち上げが予定されていましたが、トラブルシューティング、データ復旧、サイトの再構築という 2 日間の試練となりました。移行には真剣に取り組んでください。適切なツールを使用し、ドキュメントを読み、バックアップを作成します。自信がない場合は、開発者を雇ってサポートしてもらうことを検討してください。

現在、私のライブサイトはスムーズに稼働していますが、大きな変更はすべてクローンテスト環境で実行してからライブに移行しています。その 1 つの間違いで何十時間も犠牲になりましたが、この経験から、WordPress の移行には当然の注意と敬意を持って取り組む必要があることも学びました。