第１ WordPressが開けないとき，最初に何を確かめるか
WordPressのサイトが開けないときは，表示されたエラー，アクセス先，確認した時刻及び確認方法を記録し，公開ページ，WordPress管理画面及びサーバー管理画面を分けて確認する。
Cloudflareの５２２エラー，４０３エラー，ブラウザーの接続タイムアウトは，同じ意味ではない。
別の環境で開ける場合もあるため，１回の取得結果だけで，全利用者が閲覧できない状態が続いていると判断しないことが大切である。
本記事は，Cloudflareの公式説明と，レンタルサーバー会社の案内の一例であるmixhostの公式説明を踏まえ，初動の確認手順を示すものである。
個別の障害原因，ホスティング会社の責任又は一定時間内の復旧を判定するものではない。
PHPの更新前後のバックアップや互換性試験については，PHPの緊急セキュリティ更新とWordPress保守を参照されたい。
第２ ５２２と４０３，ブラウザーのタイムアウトの違い
１ ５２２はCloudflareから配信元への接続のタイムアウトを示す
Cloudflareの「Error 522」によれば，５２２は，Cloudflareがオリジンサーバーとの通信でタイムアウトした場合に生じる。
オリジンサーバーとは，サイトのデータを配信する元のサーバーをいう。
利用者のブラウザーとCloudflareの間が動いていても，Cloudflareから配信元への通信が正常に完了しているとは限らない。
公式説明には，.htaccess，iptables又はファイアウォールによるCloudflareのIPアドレスのレート制限・遮断（最も多い原因とされている），配信元の過負荷・停止，DNSに設定された配信元IPアドレスの不一致など，複数の原因候補が挙げられている。
したがって，５２２という表示だけから，サーバー故障，WordPressの不具合又は特定の事業者の責任のいずれかに原因を限定することはできない。
サポートへの連絡では，原因の決め付けよりも，発生したURL，時刻及びエラー画面を伝えることを優先する。
２ ４０３はアクセスが拒否された応答である
Cloudflareの「Error 403」は，４０３がアクセス権限に関する拒否の応答であり，配信元のアクセス制限やCloudflareのセキュリティ機能などでも発生し得ると説明している。
４０３を受け取ったことは，５２２と同じ接続タイムアウトが続いていることを意味しない。
ただし，応答が変わっただけで，ページが正常に閲覧できるようになったともいえない。
通常のブラウザーでは開ける一方，AIの取得機能やコマンドによる確認では４０３となった場合は，両方の結果を併記する。
その比較だけで特定のWAFルールやIP制限が原因と確定することはできないため，必要に応じて管理者がログや設定を確認する。
拒否を回避するために，無断でアクセス制限を解除したり，取得元を次々に変えたりすることは初動手順に含めない。
３ ブラウザーの接続タイムアウトは，HTTPのエラー番号と区別する
ブラウザーに接続タイムアウトが表示され，HTTP応答を確認できない場合は，そのまま接続タイムアウトとして記録する。
画面にない５２２又は４０３という番号を推測して付けない。
cPanelのログインページ自体が開かない場合と，ログインページは開くが認証できない場合も，別の症状として扱う。
第３ cPanelも開けないときの確認順序
公開サイト，WordPress管理画面及びcPanelについて，対象ごとに，開けるか，エラーが出るか，応答がないかを整理する。
公開サイトとcPanelの両方に問題があれば，WordPressの記事編集だけで解決できるとは限らないと考え，ホスティング会社への照会を優先する。
同時に開けないという事実だけで，サーバー全体の停止や事業者の過失まで確定するものではない。
① 契約先のマイページ等で，利用中のサービスと正しいcPanel接続先を確認する。
② 公式の障害・メンテナンス情報を確認し，自分の利用サービスや対象サーバーが含まれるかを確かめる。
③ ログインページの表示と，その後のログイン成功を別々に記録する。
④ 解消しない場合は，公開ページとcPanelの症状をまとめて，契約先の正規窓口に問い合わせる。
mixhostの「cPanelへアクセスできません」には，ログイン情報の相違，一定回数のログイン失敗等に伴う一時的な制限が案内されている。
また，アクションに失敗した旨のエラーが表示される場合について，メンテナンス中の可能性を説明している。
ログインを繰り返す前に，表示された症状と公式の説明が対応しているかを確認したい。
サポートに契約情報やグローバルIPアドレスを求められた場合は，正規の非公開窓口で提供し，SNSの告知には記載しない。
第４ Always Onlineで記事が見えても，復旧とは限らない
Cloudflareの「Always Online」は，配信元に接続できない際に，キャッシュやInternet Archiveの保存済みページを利用して，サイトの一部を表示する機能である。
Cloudflareはサイトの全ページの写しを保存するものではなく，配信元がオフラインの間は動的なコンテンツを提供できないと説明されている。
ショッピングカートやコメント欄のような動的な部分を利用しようとした閲覧者には，配信元の停止によるエラーページが表示されるとされる。
保存版である旨のバナーが表示されている場合は，現在の配信元が動いている証拠として扱わない。
トップページの文章が読めても，最新記事，サイト内検索，管理画面又は問い合わせフォームまで利用できるとは限らない。
復旧を確認する際は，保存版の表示と現在のページの表示を区別し，必要な機能も個別に確かめる。
問い合わせ等の業務上の入口については，閲覧だけでなく，管理者が許可したテストの範囲で送信・受信まで確認することを勧める。
第５ 問い合わせに残す記録と告知文
１ 観測した時刻と実際の障害開始・終了を区別する
記録には，最終正常確認，最初の異常確認，最後の異常確認及び異常確認後の最初の正常確認を分けて残す。
例えば，ある時刻に異常を確認し，その３０分後に正常表示を確認したとしても，前者が障害の開始時刻，後者が復旧作業の完了時刻であるとは限らない。
継続監視をしていない時間帯を含め，観測した範囲と分からない範囲を分けることで，サポートへの説明を正確にできる。
時刻には日本時間又はUTCなどの時間帯も付ける。
記録項目は，URL，確認時刻・時間帯，通常のブラウザーか自動取得か，ログイン状態，表示文言又は確認できたHTTP状態，直前の変更内容及び確認できた影響範囲を基本とする。
パスワード，認証用リンク及び個人情報を含む画面は，公開用の記録から除く。
２ サポートへの問い合わせ例
次の項目を記入すれば，症状を整理して伝えやすい。
不明な欄は，推測で埋めず，不明とする。
① 対象サービス・ドメイン：契約先と対象サイトを記載する。
② 確認した時刻と時間帯：最終正常，最初の異常，直近の確認を分ける。
③ 公開サイトの症状：対象URLと表示されたエラーを記載する。
④ WordPress管理画面・cPanelの症状：ログインページの到達可否と認証後の状態を分ける。
⑤ 比較した環境：通常のブラウザー，自動取得，別回線等の実際に確認した結果のみを記載する。
⑥ 確認してほしい事項：対象サービスの障害・制限の有無，対応状況，次の状況案内の見込みを照会する。
３ 原因未確定の場合の告知例
閲覧できない状態を確認した段階では，例えば，次のような文例が考えられる。
「現在，当サイトに接続しづらい，又は閲覧できない事象を確認しています。サーバー会社に状況を照会中です。状況が分かり次第，改めてお知らせします。」
この文例は，実際に確認した影響と対応状況に合わせて使用する。
特定のサーバーの故障が確認されていない段階では，故障箇所や責任主体を確定したような表現を避ける。
復旧見込みについても，サーバー会社の案内がないのに，過去の別の障害の所要時間から断定しない。
第６ 復旧確認はどこまで行うか
復旧の確認は，次の段階に分けると，確認できた範囲を説明しやすい。
公開ページが読めたこと，管理画面にログインできたこと及び問い合わせが届いたことは，それぞれ別の確認結果である。
① 通常のブラウザーでトップページと主要記事を開き，保存版のバナーやエラー表示がないかを確認する。
② 未ログインの閲覧とログイン中の閲覧を区別し，可能な範囲で別の回線・端末からも確認する。
③ WordPress管理画面とcPanelについて，ログインページへの到達と，権限のある担当者によるログイン後の操作を分けて確認する。
④ サイト内検索，画像，重要なリンク，問い合わせフォーム及びメール受信を，そのサイトの用途に応じて確認する。
⑤ 確認したURL，時刻，方法及び結果を残し，未確認の機能を復旧確認済みの範囲に含めない。
記事の更新や問い合わせ送信の結果が不明なときは，同じ操作を繰り返す前に，保存内容や受信状況を確認する。
複数のAIや担当者が関わる場合の重複更新防止については，複数のAIエージェントでWordPressを安全に更新する方法も参照されたい。
第７ 原因調査と責任の判断を分ける
障害時には，まず，どの接続先で何が起きたかを確認し，次に，ログや運営会社の調査結果から原因を調べるという順序が適切である。
エラー画面から分かる通信上の症状と，契約上の義務違反の有無は分けて検討する必要がある。
Web制作・保守会社とホスティング会社の担当範囲については，Web制作・保守会社にPHPを更新する責任はあるかを参照されたい。
第８ 出典
① Cloudflare「Error 522」
② Cloudflare「Error 403」
③ Cloudflare「Always Online」
④ mixhost「cPanelへアクセスできません」
公式資料の確認日は令和８年１１月３日である。