WordPressが急に403 Forbiddenになる7つの原因と対処法【2サイト同時ダウン→データ復旧の実例あり】
昨日まで普通に見られていたWordPressサイトが、ある日突然「403 Forbidden アクセスしようとしたページは表示できませんでした。」と表示されてしまった――。サイト運営者にとって、これほど心臓に悪い瞬間はありません。
実は先日、Webサイト制作を行っている私のもとに「2つのサイトが同時に403エラーになり、アクセスが完全にゼロになってしまった」というご相談がありました。当初は、2026年7月に発覚したWordPress本体の緊急脆弱性「wp2shell」に伴うサーバー会社側のセキュリティ強化が原因かと思われたのですが、調べを進めると真相はまったく別のところにあり、さらに途中では「サイトのデータが過去の状態に巻き戻る」という背筋の凍る展開まで待っていました。
この記事では、WordPressサイトが「急に」403エラーになる場合に考えられる原因を網羅的に解説したうえで、実際にご相談いただいた事例の経緯と、原因特定から解決までの道のりを紹介します。今まさに403エラーでお困りの方は、対処フローの章から読んでいただいても構いません。
403 Forbiddenエラーとは?
403 Forbiddenは、「サーバーはリクエストを受け取ったが、アクセスを許可しなかった」ことを意味するHTTPステータスコードです。サーバーが落ちている(500系エラー)わけでも、ページが存在しない(404エラー)わけでもなく、サーバーが意図的にアクセスを拒否している状態を指します。
ここが重要なポイントで、「拒否している」ということは、サーバー側の何らかの設定・制限・防御機能が働いているということです。つまり原因は、大きく分けて「自分(サイト側)の設定の問題」か「サーバーやセキュリティ機能による遮断」のどちらかに絞られます。
特に「昨日まで正常だったのに急に403になった」場合は、自分で設定を触っていない限り、サーバー側で何かが変わった可能性が高いと考えられます。
サイトが急に403エラーになる7つの原因
急な403エラーの原因として代表的なものを、深刻度の高いものから順に見ていきます。
原因1 サイト改ざん・マルウェア感染によるサーバー側の強制制限
最も深刻なケースです。WordPressの脆弱性やプラグインの欠陥を突かれてサイトが改ざんされると、ファイルが書き換えられたり壊されたりして、サイト自体が正常に動かなくなることがあります。さらに、レンタルサーバー会社はサイトの改ざんやマルウェア設置を検知すると、被害の拡大を防ぐためにアカウント単位・ドメイン単位で強制的にアクセス制限をかけることがあります。この場合、サイト全体が403エラーになります。
このケースの特徴は、サーバー会社から「不正なファイルを検知したためアクセスを制限しました」といった趣旨の個別メールが届いていることです。403エラーが出たら、まずサーバー会社からのメールを確認しましょう。
原因2 乗っ取りによるスパムメール大量送信・不正リダイレクト
サイトが乗っ取られると、攻撃者はそのサーバーを踏み台にしてスパムメールを大量送信したり、訪問者を悪質なサイトへ強制的にリダイレクトさせる仕掛けを埋め込んだりします。サーバー会社はこうした異常な挙動(短時間での大量メール送信、不審な外部への大量リダイレクトなど)を監視しており、検知すると被害者を増やさないためにサイトを強制停止・アクセス制限します。
この場合も結果として403エラーになりますが、根本原因は乗っ取りなので、制限を解除してもらう前に改ざんファイルの除去・パスワード変更・脆弱性の修正といった復旧作業が必要になります。自力での対応が難しい場合は、サーバー会社のサポートや復旧専門業者に相談することをおすすめします。
原因3 CloudflareなどのCDN経由の正常なアクセスまで遮断された
Cloudflareのような CDN(コンテンツ配信ネットワーク)を導入すると、訪問者のアクセスはすべてCloudflareのサーバーを経由してレンタルサーバーに届きます。つまりレンタルサーバーから見ると、訪問者が誰であれ、アクセス元はすべて「Cloudflareの(国外)IPアドレス」になります。
ここでサーバー会社がセキュリティ強化を行い、攻撃を送ってくるIPアドレスや国外IPからのアクセスを遮断すると、CloudflareのIPがまとめてブロック対象になってしまうことがあります。CloudflareのIPが遮断されるということは、そこを経由してくる正常な訪問者のアクセスまで全部403になるということです。不正なことは何もしていないのに、サイト全体が突然表示されなくなります。重大な脆弱性が流行して攻撃が急増している時期は、こうした「巻き込まれ遮断」のリスクも高まります。
原因4 WordPress本体・プラグインのアップデートによる不具合
WordPress本体やセキュリティ系プラグインのアップデート(自動更新を含む)をきっかけに403エラーが発生することもあります。よくあるのは次のようなパターンです。
「アップデートした直後から」という時系列の一致があれば、このケースを疑いましょう。セキュリティプラグインを一時的に無効化する(FTPやファイルマネージャーでプラグインフォルダの名前を変える)ことで切り分けができます。
原因5 WAF・海外IPアクセス制限などサーバーのセキュリティ機能
エックスサーバーをはじめとする国内レンタルサーバーには、WAF(Webアプリケーションファイアウォール)や海外IPからのアクセス制限といったセキュリティ機能が用意されています。これらは通常はサイトを守ってくれる心強い機能ですが、まれに正常な操作を攻撃と誤検知して403を返すことがあります。
「記事の保存だけ403になる」「特定のページだけ403になる」といった部分的な403は、WAFの誤検知が典型です。サーバーパネルのWAF設定を一時的にオフにして再現するか確認すれば切り分けできます(確認後は必ずオンに戻しましょう)。
原因6 パーミッション・.htaccessの設定ミス
ファイルやフォルダのパーミッション(権限設定)を誤って700や000などに変更してしまった場合や、.htaccessに誤った記述をしてしまった場合も403エラーになります。心当たりのある操作(FTPソフトでの作業、プラグインでの一括変更など)をした直後であれば、このケースです。フォルダは755、ファイルは644が基本です。
原因7 サーバー移行後、DNSが旧サーバーを向いたままだった
意外と見落とされがちなのがこのケースで、次章で紹介する相談事例の真の原因もこれでした。レンタルサーバーの移行機能(エックスサーバーの「新サーバー簡単移行」など)を使ってサーバーを切り替えたのに、ドメインのDNS(Aレコード)が旧サーバーのIPアドレスを指したままになっていると、サイトは旧サーバーで動き続けます。特にCloudflareなどの外部DNSを利用している場合、サーバー会社側で切り替え操作をしてもDNSは自動では書き換わらないため、この状態に気づきにくいのです。
旧サーバーには利用期限があるため、期限が切れた瞬間に旧サーバーへのアクセスは遮断され、ある日突然、全アクセスが403になります。それまで何ヶ月も普通に使えてしまうことがあるのが、このケースの怖いところです。
【相談事例】2サイト同時に403→データが過去に巻き戻る→無事復旧までの一部始終
ここからは、実際にご相談いただいた事例を、特定できない形で時系列に沿って紹介します。原因の「思い込み」がいかに危ないか、そして「データが消えたように見えても諦めてはいけない」ことがよくわかる事例です。
背景 WordPress本体の緊急脆弱性「wp2shell」の混乱期だった
ご相談があったのは2026年7月下旬。ちょうどその直前、WordPress本体に「wp2shell」(CVE-2026-63030)と呼ばれる重大な脆弱性が発覚した時期でした。REST APIのバッチ機能(/wp-json/batch/v1)を起点に、ログイン不要(認証不要)でサイトを乗っ取れてしまうという極めて深刻なもので、WordPress運営元が異例の強制アップデートを実施したほか、世界中でこの脆弱性を狙った攻撃・スキャンが大量に発生していました。
影響を受けるバージョンと修正版は次のとおりです。
| 影響を受けるバージョン | 修正版(これ以降に更新) |
|---|---|
| 6.8.0〜6.8.5 | 6.8.6以降 |
| 6.9.0〜6.9.4 | 6.9.5以降 |
| 7.0.0〜7.0.1 | 7.0.2以降 |
これを受けてエックスサーバーは2026年7月19日早朝、サーバー側の暫定対策として当該エンドポイントへの通信遮断を実施し、利用者に注意喚起のメールを配信していました。つまり「サーバー会社がセキュリティを強化した直後」というタイミングで、誰もがまずそちらを疑う状況だったのです。
症状 2つのサイトが同時に403、アクセス数が完全にゼロに
ご相談時の状況を整理すると次のとおりです。
「Cloudflareを使っている2サイトだけが」「同時に」「全アクセス」ダウンした――この共通点が、原因究明の出発点になりました。
最初の仮説 ネームサーバーを戻したら「復旧したように見えた」
時期が時期だけに、当初の仮説は「エックスサーバーのセキュリティ強化で、Cloudflareの(国外)IPからのアクセスが遮断されたのではないか」というものでした。そこで応急処置として、ドメインのネームサーバーをCloudflareからエックスサーバーのものに戻し、Cloudflareを経由しない構成に変更。DNSの切り替わりを待つこと約30分、2サイトとも表示が回復し、エラーは消えました。
この時点では「仮説どおり、Cloudflare経由が遮断されていたのだろう」と誰もが思っていました。ところが、本当の問題はここからだったのです。
異変 サイトが「過去の状態」に巻き戻っていた
復旧したはずのサイトをよく見ると、様子がおかしいことに気づきます。最近書いたはずの記事が消えている。WordPress本体のバージョンが古い。プラグインには大量の更新通知。――サイト全体が、数週間前の状態に丸ごと巻き戻っていたのです。
「データが消えてしまったのか」と青ざめる場面ですが、ここで冷静になるべきポイントがあります。ネームサーバーの変更は「どのサーバーに案内するか」を切り替えるだけで、サーバー上のデータを巻き戻したり消したりする力はありません。バージョンやプラグインまで古いということは、データが消えたのではなく、「別の(古い)WordPress」に接続先が切り替わったと考えるのが自然です。つまり、どこかに2つのコピーが存在しているはずなのです。
真の原因 「新サーバー簡単移行」とDNS書き換え漏れの合わせ技
運営者に確認すると、少し前にエックスサーバーの「新サーバー簡単移行」を利用してサーバーを移行していたことがわかりました。これですべての辻褄が合います。時系列で整理すると、こういうことでした。
wp2shellのセキュリティ強化はまったくの無関係で、タイミングが重なっただけの「偶然の一致」でした。思い込みで動いていたら、真の原因には永遠にたどり着けなかったかもしれません。
解決 サポートへの問い合わせで「旧サーバーにデータが残存」と判明
最新データは利用期限の切れた旧サーバーの中。頼みの綱はサーバー会社です。エックスサーバーのサポートに「新サーバー簡単移行を利用したが、外部DNSが旧サーバーを参照し続けていたため、最新データが旧サーバー側にのみ存在する。旧サーバー上のWeb領域とMySQLデータベースの提供・復旧が可能か確認してほしい」と、経緯を時系列で添えて問い合わせました。
結果は――「移行元サーバーにデータが残存しておりました」。サーバー会社側で移行元データへアクセスできるよう調整してもらえることになり、最新データのバックアップを取得して無事復旧できました。利用期限が切れて画面上はアクセスできなくなっていても、サーバー会社側にデータが残っているケースはあるのです。夜遅い時間の問い合わせにも迅速・丁寧に対応いただけたことも付け加えておきます。
この事例のポイントは3つあります。(1)「復旧したように見える」状態を鵜呑みにせず異変に気づけたこと、(2)「データが消えた」と早合点してサイトの再構築や上書き操作をしなかったこと、(3)事実関係を時系列で整理してサーバー会社に問い合わせたこと。特に(2)は重要で、慌てて古いサイトに記事を投稿したり移行のデータコピーをやり直したりしていたら、本当にデータを失っていた可能性があります。
急に403エラーが出たときの対処フロー
ここまでの内容を踏まえて、急な403エラーに遭遇したときの対処手順をフローとしてまとめます。
STEP1 エラーページの「見た目」で遮断場所を特定する
まず、表示されている403ページがどこのものかを確認します。CloudflareのロゴやRay IDが表示されていればCloudflare側での遮断、レンタルサーバーの標準エラーページ(エックスサーバーなら青背景の403ページ)ならサーバー側での遮断です。スクリーンショットを撮っておくと、後でサポートに問い合わせる際にも役立ちます。
STEP2 サーバー会社からのメールと管理画面の通知を確認する
改ざん検知や不正利用による強制制限の場合、サーバー会社から個別の通知メールが届いているはずです。全員向けの注意喚起メールと、自分のアカウント宛の個別通知は別物なので、両方確認しましょう。サーバーパネルにログインして、制限に関する警告が出ていないかも確認します。あわせて、サーバー移行・プラン変更・ドメイン設定変更など「過去に行った操作」も思い出してください。今回の事例のように、数週間〜数ヶ月前の操作が時限爆弾になっていることがあります。
STEP3 CloudflareなどのCDN利用中なら、一時的に経由を外す
CDNを利用している場合は、ネームサーバーをレンタルサーバー側に戻す(またはCloudflareのプロキシをDNSのみモードにする)ことで、CDN経由が原因かどうかを切り分けられます。切り替え後はSSL証明書(レンタルサーバー側の無料SSL)が有効かも確認しましょう。ただし今回の事例のとおり、「表示が戻った=解決」とは限りません。記事の欠落やバージョンの巻き戻りがないか、必ず中身まで確認してください。もし巻き戻っていたら、それは「別のコピーに繋がった」サインです。
STEP4 WordPress本体・プラグインを最新版に更新する
管理画面に入れるようになったら、WordPress本体・プラグイン・テーマを最新版に更新します。特に重大な脆弱性が公表されている時期は、「自動更新されているはず」で済ませず、必ずバージョン番号を目視確認してください。更新をきっかけに403になったと思われる場合は、直前に更新したプラグインを一時無効化して切り分けます。
ログインできない場合、ワードプレス のファイルを操作できるぐらいの知見があれば自分で原因を突き止めるためにファイルサーバーに入ったり FTP で接続していじってみたりしても良いと思いますが、経験がない人は余計なことをしないでまずはサーバーのサポートに連絡をして解決方法が糸口を教えてもらいそのやり方が自分ではできない場合には専門業者にお願いした方が良いです。
私のもとにもこの段階でご連絡いただければスムーズに解決できることが多いですが、自分でファイルの中身をぐちゃぐちゃにしてしまってバックアップもないという状態だと、余計な変更をしてしまったところを私の方で探して直さないといけないので何十倍もやることが増えて費用も時間も何倍もかかる可能性があります。
STEP5 解決しない場合はサーバーのサポートへ時系列を添えて問い合わせる
ここまでで解決しない場合は、サーバー会社のサポートに問い合わせます。その際、「いつから」「どのサイトが」「どんなエラーページが」「何を試したか」「過去にどんな操作をしたか」を時系列で伝えると、調査が格段に早くなります。今回の事例では、この整理された問い合わせが「旧サーバーにデータが残っている」という回答を引き出し、復旧の決め手になりました。
そして覚えておいてほしいのは、データが消えた・巻き戻ったように見えても、サーバー会社側にデータやバックアップが残っていることがあるということです。諦めてサイトを作り直したり、古いデータの上に新しい変更を重ねたりする前に、まず問い合わせてください。上書きしてしまうと、残っていたはずのデータまで本当に失われかねません。
再発防止のためにやっておきたいこと
まとめ
WordPressサイトが急に403 Forbiddenになる原因は、深刻なもの(改ざん・乗っ取りによる強制制限)から、セキュリティ機能の巻き込まれ遮断、アップデートや設定に起因するもの、そして今回の事例のような「過去のサーバー移行が時限爆弾になっていた」ケースまでさまざまです。
共通する初動は、
(1)エラーページの見た目で遮断場所を特定する、
(2)サーバー会社からの通知と「過去に行った操作」を確認する、
(3)直前に変わったこと(セキュリティ強化・アップデート・設定変更・利用期限)と突き合わせる、の3つです。
そして、表示が戻っても中身まで無事かを必ず確認すること。データが消えた・巻き戻ったように見えても、慌てて上書きせず、まずサーバー会社に問い合わせること。今回の事例では、この2つが最新データの救出につながりました。
最後に、この記事を読んだ今、お使いのWordPressのバージョンが修正版になっているか、そして過去にサーバー移行をした方はDNSの向き先が正しいか、ぜひ一度確認してみてください。
アドセンスの審査が心配な方、落ちてしまう方へ。30サイト以上アドセンス審査で合格している筆者が、Googleアドセンスの審査について、公式ポリシーをベースにした対策とチェックリスト33項目をnoteにまとめています。
→ Googleアドセンス審査に通るための本当のことを話します（note）
WordPressの設定・サイト診断のご相談はこちらから。
→ ワードプレスプラクティス（coconala）
WordPressのトラブル対応について、原因別の対処手順をまとめたマニュアルをnoteにまとめています。
→ WordPressが突然表示されなくなった…原因別・完全対処マニュアル（note）
自分での対応が難しい場合は、ココナラのサポートサービスもご利用いただけます。
→ ワードプレスプラクティス（coconala）