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