WordPress の不具合の原因を調べる方法
ステータスコードだけでは判断できません。サイトが死んでいても 200 が返るケースがあります。
見えている症状から選ぶ
| 見えているもの | まず疑う |
|---|---|
| ログを見ても何も出ていない | 起動前のエラーは debug.log に入らない |
| 誰がいつ設定やプラグインを変えたか分からない | WordPress は操作の記録を残さない |
| サイトヘルスに「重大な問題」が出ている | ループバック不通による偽陽性 |
| 監視は正常なのに壊れている | HTTP 200 で返る障害 |
| REST API のエラーが監視に出ない | REST の Fatal は 200 で返る |
直前にやった操作から探す場合は 直前にやったことから引く へ。
このテーマの記事
- WordPressのエラーログはどこにある？debug.logの場所と見方WordPressのログはどこにあり、どの障害がどこに記録されるかを実測で一覧化。max_input_vars超過はPHPログだけ、外部リダイレクトループはどこにも出ない。
- WordPressは誰が何を変えたか記録しない — 操作ログの実測誰がプラグインを有効化したか、いつ設定を変えたかをWordPressは記録しません。操作の前後でデータベースがどう変わるかを実測。ログイン履歴も残らないことと、運用で決めておくことをまとめます。
- WordPressサイトヘルスの「重大な問題」の意味と対処法サイトヘルスに出る「重大な問題」の意味と対処法。REST APIやループバックの検査はサイト自身への通信で判定するため、正常でも赤くなる偽陽性がある。実害のある項目とそうでない項目を実測で仕分け。
- サイトが壊れているのに監視は正常（HTTP 200）— WordPressの落とし穴サイトが死んでいるのに監視がHTTP 200を返す仕組みを、別原因の4障害で実測。display_errorsが有効だとヘッダが先に確定する。REST APIのFatalが200で返る理由も解説。