WordPressサイトが立ち上がらない時の現状調査｜WP-CLI鉄板コマンド完全ガイド【実例付き】
「昨日まで普通に見られていたWordPressサイトが、今朝はなぜか立ち上がらない」。ローカル環境でも本番でも、これは前触れなくやってきます。管理画面にすら入れず、真っ白な画面とにらめっこ――そんな経験はありませんか。
結論から言うと、こういうときは闇雲に触らず「層」を順番に切り分けるのが最短ルートです。そしてその切り分けを高速にこなしてくれるのが WP-CLI（WordPressをコマンドラインから操作するツール）。この記事では、筆者が実際に遭遇した「サイトが立ち上がらない」トラブルを題材に、現状調査の鉄板コマンドを打つ順番ごとに解説します。
📌 この記事でわかること
- サイトが立ち上がらないときの切り分けの順番（DB → PHP → 環境）
- そのまま使えるWP-CLIの鉄板コマンド7本と、それぞれが確認している層
SELECT 1って結局なに？という素朴な疑問への答え- 「CLIは通るのにブラウザで開けない」ときに見るべき場所
まず「原因は3つの層のどこか」と考える
サイトが開けないとき、原因は大きく3つの層に分けられます。この地図を頭に入れておくだけで、調査の迷子になりません。
| 層 | 代表的な原因 | 主な症状 | 確認の手段 |
|---|---|---|---|
| ① データベース | 接続情報ミス・MySQL停止・テーブル破損 | 「データベース接続確立エラー」 | WP-CLI |
| ② PHP・プラグイン・テーマ | 致命的エラー（Fatal error） | 真っ白な画面（白画面） | WP-CLI |
| ③ 環境側 | Webサーバー停止・ポート不一致・名前解決失敗 | そもそも繋がらない／タイムアウト | curl・hosts・ログ |
ポイントは、内側（①②）から順に潰していくこと。そして①②を一気に確認できるのがWP-CLIです。
なぜWP-CLIが効くのか（と、唯一の弱点）
WP-CLIはコマンドを実行するたびに、内部でWordPressをブラウザと同じように読み込み（ブートストラップ）ます。つまり、ブラウザやWebサーバーを介さずに、WordPress本体・DB・プラグイン・テーマの状態を直接のぞけるわけです。
ただし弱点が1つあります。WP-CLIが見えるのは「WordPressより内側」だけ。Webサーバーの設定、ポート、ドメインの名前解決といった環境側（外側）はまったく見えません。だからWP-CLIは、curl やログ確認とセットで使うのが鉄則です。
現状調査の鉄板コマンド【打つ順番つき】
ここからが本題です。筆者がトラブル時に上から順に流すコマンドを紹介します。まずは全体像を一覧で。
| # | コマンド | 確認する層 | 見るポイント |
|---|---|---|---|
| 1 | wp --info | 土台 | PHPのバージョン・パス |
| 2 | wp config get DB_HOST | 接続先 | どこのDBに繋ごうとしているか |
| 3 | wp db query "SELECT 1" | ① DB | DBに繋がるか（疎通） |
| 4 | wp option get siteurl | ① DB＋URL | URL・ポートの不一致 |
| 5 | wp eval '...' | ② PHP | 起動できるか（Fatal検知） |
| 6 | wp plugin list | ② プラグイン | 犯人候補の洗い出し |
| 7 | wp core verify-checksums | ② コア | ファイルの破損・改竄 |
1 ＆ 2. まず土台と接続先を押さえる
wp --info # PHPのバージョン・iniのパスを確認
wp config get DB_HOST # 接続しようとしているDBの場所
wp config get DB_NAME # データベース名「想定と違うPHPで動いていた」「接続先が思っていたDBと違った」は、意外とよくある落とし穴。最初に土台と接続先を確認しておくと、このあとの結果を正しく読めます。
3. wp db query “SELECT 1″｜DBに本当に繋がるか
wp db query "SELECT 1"切り分けの主役その1。結果はシンプルです。
- 1 が返る → DBに接続できている
- エラー → 認証失敗・ホスト/ソケット違い・MySQL停止など、原因は①のDB層で確定
💡 そもそも「SELECT 1」とは？
SELECT 1 は、テーブルも条件も使わず「1という値を返すだけ」の最小のSQLです。計算が目的ではなく、DBに繋がって応答が返るかを確かめるためだけの使い捨てクエリ。いわば「pingのSQL版」で、接続のヘルスチェックとして広く使われます。wp db check（整合性チェック）より軽く速いので、DBテストの一手目に最適です。
4. wp option get siteurl / home｜URL・ポート不一致を疑う
wp option get siteurl
wp option get home
# 出力例 → https://web-navigator.blog/webnavi-blogこのコマンドはDBから値を読むので、成功すれば「DB接続OK」のもう一つの証拠にもなります（一石二鳥）。同時に、サイトのURLやポートが今の環境と一致しているかを確認できます。URL・ポートのズレは「開けない」の最頻出原因。ここは最重要です。
5. wp eval｜致命的エラー（白画面）を切り分ける
wp eval 'echo "BOOT_OK";'
# 出力 → BOOT_OK切り分けの主役その2。wp eval はWordPressをプラグイン・テーマまで含めて完全に読み込んでからPHPを実行します。BOOT_OK が出れば「最後まで起動できている」証拠。逆にここでFatal errorが出たら、白画面の原因はプラグインかテーマだと一気に絞り込めます。
6 ＆ 7. 犯人候補とコアの健全性を確認
wp plugin list --status=active --field=name # 有効なプラグイン一覧
wp theme list --status=active --field=name # 使用中テーマ
wp core verify-checksums # コアファイルの破損・改竄チェック直前に入れた・更新したプラグインやテーマが怪しいときの当たりをつけます。原因が絞れたら wp plugin deactivate <名前> で一時的に止めて復旧を試す、という流れです。verify-checksums は公式と照合してファイルの破損やマルウェア混入も検知できます。
この順番で、何が分かるのか
上から流すと、原因の層が次のように切り分けられます。
SELECT 1でコケる → DBが原因- DBは通るが
evalでFatal → PHP・プラグイン・テーマが原因 - 全部パスするのに開けない → 環境側（Webサーバー・ポート・名前解決）が原因
2本柱は wp db query（疎通）と wp eval（起動）。この2つで「DBか／PHPか」がスパッと分かれます。
WP-CLIで確認できる項目別ガイド
WP-CLIで確認できる内容は、目的ごとに分けて見ると理解しやすくなります。サーバー環境、URL設定、DB接続、プラグイン・テーマ、コアファイルの順に確認すると、原因の切り分けがしやすくなります。
- エックスサーバーでWP-CLIを使う前の確認チェックリスト
- WP-CLIでWordPressのURL設定とDB接続を確認する方法
- WP-CLIでプラグイン・テーマの状態を安全に確認する方法
- WP-CLIでWordPressコアファイルの破損・改ざんを確認する方法
今回の真犯人：WP-CLIは全部パスした
冒頭のトラブルに戻ります。上のバッテリーを流した結果、SELECT 1 も option get siteurl も eval も、すべて正常。さらにサーバーへ直接アクセスして確かめると――
curl -i -H 'Host: 対象ドメイン' http://127.0.0.1:<ポート>/
# → HTTP/1.1 200 OK（トップページが完全に表示された）WordPressもDBもWebサーバーも、何ひとつ壊れていなかったのです。なのにブラウザで開けない。残る容疑は1つ、環境側＝ドメインの名前解決でした。
ping 対象ドメイン.local # → 名前解決できず
grep '対象ドメイン' /etc/hosts # → エントリが存在しない！真犯人は /etc/hosts に対象ドメインの行が無いことでした。サーバーは元気に動いているのに、ブラウザが「そのドメインがどこにあるか」を解決できず、入口にすら辿り着けていなかったのです。hosts に該当行を追記する（ローカル開発ツールなら一度サイトを再起動して書き直させる）ことで解決しました。
✅ 今回の教訓
WP-CLIが全部パスしたら、犯人はWordPressの外（環境側）にいる。WP-CLIは「内側の無実を証明する」ことで、調査範囲を一気に外へ絞り込んでくれる。
Local環境を使う人向けの注意点
ローカル開発ツール「Local」で、同梱のPHPから直接WP-CLIを叩く場合、MySQLのソケット指定でつまずきがちです。wp option get siteurl が「データベース接続確立エラー」になっても、それはサイトの障害ではなくCLI側がLocal専用のソケットを見ていないだけのことがあります。
- PHPの
mysqli.default_socketをLocalのソケットへ向ける（php -d mysqli.default_socket=...）と、localhost指定でも繋がる wp db queryは内部でmysqlクライアントを呼ぶため、PHPとは別にクライアント側のソケット指定が必要（既定の/tmp/mysql.sockを見て失敗する）
⚠️ 取り違えに注意
「CLIだけDBエラー、でもサイトは表示される」という食い違いを見たら、まずソケットの指定を疑うこと。サイト本体の障害と取り違えないのが大切です。
まとめ
サイトが立ち上がらないときは、闇雲に触らず「DB → PHP・プラグイン → 環境」の順で層を切り分けるのが近道です。WP-CLIの鉄板バッテリーを上から流せば、原因がどの層にあるかを短時間で特定できます。
この記事の要点
- 原因は3つの層（DB／PHP・プラグイン／環境）に分けて考える
db query "SELECT 1"＝疎通、eval＝起動、の2本柱で大半が切り分く- WP-CLIが全部パスしたら、原因はWordPressの外。最後は
curl・/etc/hosts・ログまで確認
トラブル対応は、犯人を見つける以上に「無実の容疑者を素早く外していく」ことの積み重ねです。次にサイトが立ち上がらなくなったら、ぜひこの順番で落ち着いて切り分けてみてください。
