WordPressの固定ページだけエラーになったら？公開画面と管理画面を分けて確認する

公開表示と管理操作を分けて確認する

公開画面は訪問者が読むページ、管理画面は担当者が記事や設定を扱う画面です。同じサイトでも、開く場所や行う操作が異なります。「サイトが見える」「管理画面にログインできる」「固定ページの一覧が開く」「変更を保存できる」は、それぞれ確認する結果が違います。

訪問者側では、実際に読むURLを確認する

まず公開トップと、更新したいサービス案内のURLを開き、期待する本文が表示されるかを見ます。片方を見ただけで、もう片方や全ページも正常とはしません。確認した時刻とページを対応させておくと、技術担当が管理画面側の記録と比べやすくなります。

公開トップが表示されない場合は、訪問者への影響がある症状として伝えます。ただし、トップを開けなかったことだけで、全ページの停止、データ消失、管理画面へのログイン失敗まで確定するわけではありません。まだ試していない場所は未確認として残します。

担当者側では、ログイン・一覧・編集・保存を分ける

普段使う管理画面へ通常の方法でログインし、どの操作で止まったかを確認します。「固定ページ」を押した時点でエラーなのか、一覧は開くが特定のページの編集で止まるのか、編集はできるが保存が終わらないのかを区別してください。途中まで進めたことは、その後の成功を意味しません。

未保存の原稿があるときは、再読込や画面を閉じる前に、会社で承認された保管先へ作業内容を残します。エラーが出る画面で保存を繰り返したり、同時に別の担当者が同じページを変更したりすると、何を試した結果かが追いにくくなります。いったん更新作業を止め、試した範囲を整理します。

架空例で見る、公開ページと固定ページ一覧の違い

次は説明用の二つの架空サイトです。小さな会社サイトでは、公開トップとサービスページの表示、管理画面へのログインが記録されています。一方、「固定ページ」の一覧では重大なエラーの記録があります。他の管理メニュー、管理者メール、原因、修正後の結果は未確認です。

もう一つは別サイトで、公開トップが表示されない記録だけがあります。先のサイトが悪化した場面でも、修正後の場面でもありません。サービスページや管理画面の状態は、この記録からはわかりません。

公開ページが見えるとき、固定ページの編集画面も使えると言えるでしょうか。図では、会社サイトの公開トップ・サービス案内と、担当者側のログイン・固定ページ一覧を別の領域として見ます。別サイトの公開トップの記録は、その下の独立した欄です。

説明図の原画を開く

会社サイトの例でわかるのは、訪問者側の二つの表示と、担当者側の一覧エラーが併存していることです。「公開表示があるから問題なし」とも、「重大なエラーだから全サイト停止」とも言えません。技術担当には、公開URLの表示記録と、固定ページ一覧を開いた操作・エラー文を一緒に渡します。

別サイトの例では、公開トップを開けない影響から確認を始めます。ただし、一覧や編集の状態は未確認なので、会社サイトの例と同じ原因・同じ対処を当てはめません。いずれも、管理者メールや原因、対処後の結果を別の画面の表示から補うことはできません。

URL・時刻・操作・エラー文を残す

「固定ページが壊れた」だけでは、公開ページと管理画面のどちらを指すのかが伝わりません。次の情報を同じ記録にまとめると、確認する画面と技術担当が調べる時間帯を絞れます。

• いつ、どこを見たか：確認した日時と時間帯、公開URLまたは管理画面内の場所。対象ページが複数あるときは、それぞれの結果を分けます。
• 何をしたか：ログイン後に「固定ページ」を選んだ、一覧から対象を開いた、保存を押した、など止まる直前までの操作。ログインした担当や利用したブラウザーの違いも、わかる範囲で添えます。
• 何が出たか：エラー文を省略せず記録します。画面を撮る場合は、氏名、メール、未公開原稿、認証情報が写らないようにします。
• 何がまだできないか：公開表示、一覧、編集、保存を別々に記載します。未実施の操作は「未確認」とし、失敗や成功に置き換えません。
• 直前に何が変わったか：更新、追加機能やテーマの変更、担当交代など、記録で確かめられるものを添えます。心当たりがないことは、変更がなかった証明にはなりません。

たとえば問い合わせるなら、「公開トップとサービス案内は確認時に表示された。管理画面にはログインできるが、『固定ページ』を選ぶとエラーが出る。確認時刻、対象画面、エラー文は添付した。他メニューと管理者メールは未確認」という形で、観測と未確認を並べます。実際の日時・URL・エラー文は自分の確認記録から記入します。

別の担当者では一覧が開く場合も、そこから権限が原因と決めません。同じ対象・操作まで確認したかをそろえ、編集・保存の結果も分けて比べます。管理者権限を増やして試す方法を、原因調査の代わりにはしません。

メール・回復モード・ログを権限のある担当が調べる

重大なエラーという表示は、調査の出発点です。その文だけで、特定のプラグイン、テーマ、PHP、サーバー設定が原因だとは決まりません。兼任編集担当は、表示と操作の記録をそろえ、WordPressを管理する担当や契約先の保守・ホスティング窓口へ確認します。

管理者メールと回復モードは、届いた内容と条件を確かめる

WordPressには、致命的なPHPエラーが起きた際に、管理者への通知や調査用のログインを助ける「回復モード」があります。通常のページ読込で起きる対象エラーなど、作動する条件があります。メールが届かない場合もあるため、「受信箱にないからエラーではない」とは判断できません。WordPress公式の回復モードの説明で、対象と通知の仕組みを確認できます。

管理者メールを確認できる担当に、通知の有無と記載された対象・時刻を確認してもらいます。回復用リンクや認証情報は公開の相談欄や共有資料へ貼りません。回復モードで管理画面に入れた場合も、そのセッションで調査できることと、訪問者側の問題が直ったことは別です。

ログと変更履歴を照合してから、対処を決める

ログは、システムが残すエラーなどの記録です。権限のある担当が、発生した時刻・操作と照らして、関係するエラー、直前の変更、対象となる追加機能やテーマを調べます。古い警告や別の操作の記録を、今回の直接原因として扱わないことが大切です。WordPress公式の重大なエラーの案内も、管理者メールやデバッグによる調査を入口にしています。

変更が必要な場合は、担当が事前保存の状態、影響する機能、戻す方法、試験用環境の有無を確認したうえで範囲を決めます。追加機能を一斉に停止したり、本番のPHP設定を変えたりすると、予約・問い合わせ・表示など別の機能にも影響し得ます。原因をまだ調べていない段階で、兼任担当がそれらを一律に実行する手順にはしません。

詳細なエラーを記録する機能と、訪問者の画面へ表示する機能も別です。WordPress公式のデバッグ資料は、変更前の試験環境や適切なバックアップの確認を示し、本番でのデバッグ利用を推奨していません。設定ファイルやログの調査は権限のある担当が扱い、公開画面へ機密情報を出す方法で確認を進めないでください。

対処後は同じ画面と編集・保存を確かめる

「対処した」という連絡を受けたら、変更内容と確認対象を担当に聞き、最初の記録と同じURL・操作で試します。技術担当がエラーの発生を調べた結果と、編集担当が通常の更新を再開できる結果を対応させるためです。

1. 公開表示：最初に調べたトップとサービス案内を開き、期待する本文を確認します。一覧が直ったことだけで、公開側も確認済みとはしません。
2. 管理画面の一覧：通常のログインと「固定ページ」を開く操作を試し、一覧や対象ページを選べるかを確かめます。
3. 対象ページの編集・保存：会社の承認された試験範囲で、対象ページを開き、保存が完了し、保存した内容を再び開いて確認できるかを試します。公開中の原稿を無断で変更して試験しません。
4. 必要な公開反映：公開の承認がある変更では、公開URLで意図した内容を確かめます。下書き保存の成功を、そのまま公開完了にしません。

再びエラーになる場合は、その時刻、対象、操作、表示を追加し、試した変更を増やす前に担当へ返します。一覧は使えるが保存は未確認なら、その違いを残します。再開は、必要な確認ができた作業範囲に限って判断し、未確認の操作や別ページへ広げません。

バックアップから戻せるかを確かめる方法は別環境で行う復元テスト、制作会社から受け取る権限や資料は管理先・データ・コードの引継ぎで詳しく説明しています。ここで扱うのは、現在のエラーの影響範囲と、対処後に同じ操作を確かめる判断です。