結論から言うと、「データベース接続確立エラー」は記事が消えた合図ではありません。
WordPressが記事や設定を保存しているデータベースへ接続できない状態です。最初にサーバー障害の有無を確認し、次に
wp-config.php
の
DB_NAME
、
DB_USER
、
DB_PASSWORD
、
DB_HOST
と、サーバー管理画面の値を一文字ずつ照合します。
再インストールやデータベース削除はしません。直前に「サーバー移転」「データベースパスワード変更」「復元」「契約サーバー側のメンテナンス」のどれがあったかで確認順を変えると、初心者でも安全に原因を絞れます。
- サーバー会社の障害・メンテナンス情報を見る
- 直前に自分が変更した設定を一つだけ思い出す
-
サーバーのファイルマネージャーで
wp-config.phpをダウンロードして控えを残す - 4つの接続情報を、推測せず管理画面の表示と照合する
症状で最初の確認先を決める
同じエラー文でも、発生したタイミングによって原因の当たりが変わります。闇雲に4項目を書き換えるより、直前の出来事から一番可能性が高い場所を先に確認します。
| エラーが出た場面 | 最初に見る場所 | よくある原因 |
|---|---|---|
| 何も変更していないのに突然 | サーバー会社の障害・メンテナンス情報 | データベースサーバーの一時障害、契約状態 |
| DBパスワード変更の直後 |
DB_PASSWORD
|
管理画面とwp-config.phpのパスワード不一致 |
| サーバー移転・復元の直後 |
DB_NAME
、
DB_USER
、
DB_HOST
|
移転元の値が残っている、ユーザー権限がない |
| 新規インストールの途中 | 入力したDB情報と作成済みDB | 接頭辞を含む正式名の入力漏れ |
| 特定の時間だけ発生 | 障害情報、利用状況、サーバーログ | 一時的な高負荷や接続数上限 |
サーバー全体の障害なら、設定を書き換えても直りません。公式の障害情報に該当がある場合は、復旧予定を確認し、設定変更を止めて待つのが正解です。該当がなく、自分の変更直後に発生したなら、変更した項目から照合します。
wp-config.phpを安全に開く
wp-config.php
は通常、
wp-admin
、
wp-content
、
wp-includes
フォルダーと同じ階層にあります。サーバー管理画面の「ファイルマネージャー」、またはFTPソフトでWordPressの設置先を開いてください。
- 対象ドメインの公開フォルダーを開く
-
wp-contentが見えることを確認する -
wp-config.phpをPCへダウンロードし、変更前の控えにする - サーバー上の編集機能、またはテキストエディターで開く
別ドメインの
wp-config.php
を開くと、正しい値を直しても対象サイトは復旧しません。最初にフォルダー名とURLの対応を確認してください。また、ファイルの内容を問い合わせ掲示板やSNSへ貼るのは危険です。データベース名やユーザー名、パスワードは公開しません。
define( 'DB_NAME', '契約環境のデータベース名' );
define( 'DB_USER', 'そのDBへ接続するユーザー名' );
define( 'DB_PASSWORD', 'そのユーザーのパスワード' );
define( 'DB_HOST', 'サーバー指定のホスト名' );
引用符の内側だけが値です。行末のセミコロン、
define
、括弧は消しません。全角の引用符へ変わったり、行を途中で折ったりするとPHPのエラーになるため、スマートフォンのメモ帳で編集するよりPCのテキストエディターを使う方が安全です。
「管理画面に入れないなら何も確認できない」と思い込んでいました。
サーバー側のファイルマネージャーは別に開けるんですね、ちょっとだけ道が見えてきました。
そこに気づけたのは大きいよ。
WordPressが止まっていても、契約サーバーの管理画面からファイルとデータベースを確認できるんだ。
でも、似た名前のフォルダーがいくつもあって少し不安です。
慌てて別サイトのファイルを開いたら、余計にややこしくしそうで手が止まります。
急がなくて大丈夫だよ。
対象ドメインの公開フォルダーを選び、その中に
wp-content
があることを確認してから、まずダウンロードだけしよう。
4つの接続情報を一文字ずつ照合する
1. DB_NAMEは接頭辞まで含めて比べる
DB_NAME
は記事を保存しているデータベースの正式名です。レンタルサーバーでは、契約IDやサーバーIDが先頭に自動付加される場合があります。「blog」だけでなく「契約ID_blog」のように表示された正式名全体を比べます。
複数のデータベースがある場合は、phpMyAdminで中身を開く前に、まず名前と作成時期を確認します。推測で別のDB名へ変更すると、別サイトへ接続したり、新規インストール画面が出たりする可能性があります。
2. DB_USERとアクセス権を分けて確認する
DB_USER
の文字列が合っていても、そのユーザーが対象データベースへアクセスできなければ接続できません。サーバー管理画面のデータベース一覧で、対象DBの「アクセス権所有ユーザー」「権限付与済みユーザー」などの欄を確認します。
エックスサーバーの公式マニュアルでは、サーバーパネルの「MySQL設定」からデータベース、MySQLユーザー、アクセス権を管理できると案内されています。表示名が似ていても、「ユーザーが存在すること」と「そのDBへ権限があること」は別の確認です。
3. DB_PASSWORDは変更履歴から確認する
パスワードは管理画面に平文表示されないことが多いため、心当たりがないまま何度も変更しないでください。変更する必要がある場合は、先に新しいパスワードを安全な場所へ控え、サーバー側の変更完了後に
wp-config.php
の
DB_PASSWORD
も同じ値へ更新します。
片方だけ変えると必ず不一致になります。変更後にエラーが出た場合は、サーバー側のパスワード変更が完了した時刻と、ファイルを保存した時刻を照合すると切り分けやすくなります。
4. DB_HOSTをlocalhostと決めつけない
DB_HOST
はデータベースサーバーの場所です。
localhost
を使う環境もあれば、専用のホスト名が指定される環境もあります。移転時は移転元のホスト名が残りやすいため、移転先サーバーの管理画面や公式マニュアルに表示された値を使います。
原因別の直し方と成功状態
| 見つかった原因 | 直す操作 | 成功したと判断する状態 |
|---|---|---|
| DB名・ユーザー・ホストの不一致 | 正しい値を1項目だけ反映し保存 |
公開ページと
/wp-admin/
が開く
|
| DBユーザーの権限なし | 対象DBへ既存ユーザーのアクセス権を付与 | 接続エラーが消え、記事一覧が表示される |
| パスワード変更後の不一致 | 同じ新パスワードをwp-config.phpへ反映 | ログイン画面または公開ページが表示される |
| サーバー障害 | 設定を変えず公式復旧を待つ | 障害情報が復旧済みになり表示が戻る |
| 契約・容量の問題 | 契約状態や容量警告を確認し、必要な対応を行う | サーバー管理画面の警告が解消し表示が戻る |
ファイルを保存したら、キャッシュだけで判断せず、公開ページと
/wp-admin/
を別タブで開きます。トップページだけでなく、既存記事を1本開き、タイトルと本文が以前どおり表示されることを確認してください。
エラーが変わらない場合は、いったん変更前の
wp-config.php
に戻します。複数項目を同時に変えると、どの変更が効いたか分からなくなります。「1項目変更→保存→公開ページ確認」を守ります。
サーバーのMySQL一覧を見ると、データベース名とユーザー名がよく似ています。
ユーザー名が表示されているから権限もあると思って進みそうになりました。
そこが間違えやすい分岐だね。
ユーザー一覧に名前があるだけでは足りないから、対象データベースの「アクセス権所有ユーザー」に同じ名前があるかまで見よう。
もし権限がなかったら、新しいユーザーを作るより今のユーザーを追加する方がいいですか。
失敗した時に元へ戻せる進め方を選びたいです。
wp-config.phpに書かれた既存ユーザーが管理画面にもあるなら、まずそのユーザーへ対象DBの権限を付けるのが分かりやすいよ。
追加前の画面を控えておけば、違った時も権限を外して元へ戻せるね。
初心者が避けるべき操作
- WordPressを再インストールする： 既存データを上書きする危険があり、接続情報の不一致は解決しません。
- データベースを削除する： 記事・固定ページ・設定の保存先そのものを失う可能性があります。
- 4項目を一度に変更する： 原因と正しい組み合わせが分からなくなります。
- 他サイトのwp-config.phpをコピーする： 別DBへ接続する危険があります。
- 接続情報を公開して質問する： 認証情報の漏えいにつながります。
- 根拠なくデータベース修復を実行する： 接続前の問題と、接続後のテーブル破損は別です。
管理画面へ入れない状態でも、サーバー会社のサポートへ相談できます。問い合わせには「エラーが出始めた日時」「直前に行った操作」「対象ドメイン」「確認した4項目」「障害情報の該当有無」を伝えます。パスワードそのものは送らないでください。
データベース管理を確認しやすい環境を選ぶ
今回のエラーだけでサーバー移転を急ぐ必要はありません。ただし、MySQLのユーザー・アクセス権・バックアップ・サポート窓口を一つの管理画面から確認できることは、初心者が復旧するときの大きな助けになります。現在のサーバーで確認場所が分からず、今後もWordPressを長く運営する人は、次回更新時の比較材料にしてください。
エックスサーバー
向いている人： WordPressとMySQLの設定、アクセス権、サポート情報を管理画面で確認しやすくしたい人。
利点： 公式マニュアルにMySQLデータベース、ユーザー、アクセス権、パスワード変更の確認手順が用意されています。
不要な人： 現在のサーバーで原因を特定でき、管理画面やサポートに不満がない人は、このエラーだけを理由に移転する必要はありません。
注意点： 契約すれば既存サイトの接続エラーが自動で直るわけではありません。移転する場合も、DB名・ユーザー・ホストは移転先の値へ正しく合わせます。
料金： プランやキャンペーンで変わるため、申込み前に公式ページの最新料金と契約期間を確認してください。
エックスサーバーのMySQL管理機能と最新料金を見る広告・PRを含みます。料金・特典・仕様は公式ページで最新条件をご確認ください。
よくある質問
記事データは本当に消えていませんか？
接続情報の不一致や一時障害なら、データベース内の記事は残っている可能性が高いです。ただし、データベースを削除した、誤った復元をしたなど別の操作がある場合は状況が異なります。再インストールや削除をせず、まず接続を戻してください。
管理画面に入れないのに、どうやって直しますか？
WordPress管理画面ではなく、契約サーバーの管理画面からファイルマネージャーとデータベース設定を開きます。FTP接続が使える場合は、FTPでwp-config.phpを確認することもできます。
DB_HOSTはlocalhostでよいですか？
サーバーごとに異なります。localhostを使う環境もありますが、専用ホスト名が必要な環境もあります。現在契約しているサーバーの管理画面または公式マニュアルの表示を使ってください。
データベース修復を実行すれば直りますか？
接続情報が違う段階では、修復より先に接続を戻す必要があります。接続後にテーブル破損を示す別のエラーが確認できた場合のみ、公式手順やサポート案内に沿って検討します。
サポートには何を伝えればよいですか？
対象ドメイン、発生日時、直前の変更、障害情報の確認結果、DB_NAME・DB_USER・DB_HOSTを照合したか、権限を確認したかを伝えます。DB_PASSWORDそのものは送らないでください。
最初は記事が全部なくなったと思って頭が真っ白でした。
でも、サーバー障害と4つの接続情報を分けて見れば、慌てて再インストールしなくていいんだと思えました。
怖い画面を見ても、危ない操作を止めて確認順を作れたね。
それができれば、原因を一つずつ安全に減らしていけるよ。
まだパスワードを変える場面は緊張しそうです。
先に今のファイルを控えて、変更するなら片方だけ置き去りにしないよう気をつけます。
それで十分だよ。
推測で増やさず、管理画面の正しい値と一項目ずつ合わせれば、復旧への道筋はちゃんと見えてくるからね。
まとめ：消えたと決めつけず、接続経路を順番に戻す
データベース接続確立エラーでは、最初に障害情報を確認し、次に
wp-config.php
とサーバー管理画面の
DB_NAME
、
DB_USER
、
DB_PASSWORD
、
DB_HOST
を照合します。ユーザー名だけでなく、対象データベースへのアクセス権も確認してください。
変更前ファイルを控え、1項目ずつ変更して公開ページと管理画面を確認します。再インストール、DB削除、複数項目の同時変更は避けます。ここまで確認しても戻らない場合は、行った操作と確認結果を整理して契約サーバーのサポートへ相談しましょう。
参考： WordPress公式「Editing wp-config.php」 、 エックスサーバー公式「MySQLの設定」