さくらのレンタルサーバでWordPressの保存が403になる原因｜WAFの誤検知とFTPで回避した手順【2026年】

さくらのレンタルサーバでWordPressの保存だけが 403 になるときは、サーバー側のWAFが、管理画面から送った内容を攻撃と判定して止めている可能性があります。まずWAFを一時的に「利用しない」にして、保存が通るかで切り分けます。当社は2026年8月、WAFを切らずにFTPで反映する方法で回避しました。

さくらのレンタルサーバでWordPressの保存が403になる原因：WAFが管理画面からの送信を止めている

サイトは普通に表示される。管理画面にも入れる。それなのに、CSSやコードを含む内容を保存した瞬間だけ失敗する。当社で起きた例では、原因はWordPressではなく、サーバー側のWAFでした。

WAF（Webアプリケーションファイアウォール）とは、Webサイトへの通信の中身を検査し、攻撃と判断したアクセスを遮断する仕組みのことです。さくらの公式ヘルプは、シグネチャ検査やセッション管理などの検査で攻撃と判断したアクセスを遮断する、と説明しています。基本仕様のページによると、ソフトウェアはSiteGuardで、監視の対象はHTTPとHTTPSです。機能紹介のページでは、防ぐ攻撃の例としてクロスサイトスクリプティングやSQLインジェクションが挙がっています。

誤検知とは、攻撃ではない正常な操作を、WAFが攻撃と判定して止めてしまうことです。WordPressの管理画面での保存は、CSSやコードの文字列をそのままサーバーへ送る操作です。さくらの公式ヘルプも、有効にするとソフトウェアやPHPプログラムの動作・インストールに影響が出る場合があると注意しています。公式のトラブルシューティングの403の項にも、WAFが有効なら無効にして改善するか確かめる、という案内があります。

当社の例で返ってきたのは、HTTPステータスの 403 と、短い英語の本文でした。本文にはサーバー事業者の名前と、The server refuse to browse the page. という一文がありました。WordPressが出す画面ではありません。そのため、WordPressの設定やプラグインをいくら調べても、原因は出てきません。

403そのものの原因は、WAFだけではありません。さくらの公式ヘルプが挙げている原因を、出方で分けると次のようになります（出方による分け方は当社の整理です）。

WAFによる403かを切り分けて、WordPressの保存を通す対処手順

手順1：その403がWAFによるものかを切り分ける

1. 403が出る場面を確かめる。 ページを開くだけで出るなら、上の表の上3行を先に見ます。保存や更新のときだけ出るなら、次へ進みます。
2. サーバーコントロールパネルにログインする。 公式ヘルプによると、初期ドメインか追加したドメインでログインします。メールアドレスでログインすると、設定の項目が表示されません。
3. 「セキュリティ」から［WAF設定ドメイン］を開く。 ドメインの一覧が出るので、対象のドメインの［設定］をクリックします。
4. 『利用しない』を選び、『保存する』をクリックする。 設定はドメインごとです。
5. WordPressで、同じ保存をもう一度試す。 通れば、原因はWAFです。通らなければ、WAF以外（国外IPアドレスフィルター、WordPress側の設定）を調べます。
6. 確かめ終えたら、同じ画面で『利用する』に戻す。

WAF検出ログは、その場の切り分けには使えません。公式ヘルプに、前日の検出結果を表示するもので即時表示ではない、と書かれているからです。基本仕様のページによると、ログの保存期間は3ヶ月、保存件数は4,000件です。

手順2：保存を通す方法を選ぶ

3つ目について補足します。SiteGuardの開発元の資料には、.htaccess に書いて特定の検査を外す設定が載っています。ただし同じ資料に、サーバー側の設定で有効にした場合に使える機能で、既定では無効だと書かれています。さくらのレンタルサーバで使えるかどうかは、公式では確かめられませんでした。当社も試していません。

手順3：WAFを切らずに、FTPで変更を反映する

WAFの監視の対象はHTTPとHTTPSです。FTPでファイルを置く経路は、管理画面からの送信とは別の経路になります。当社の記録でも、FTPで置いたファイルは403になりませんでした。

1. 変更前のファイルを手元に控える。 触る予定のファイルと、今の「追加CSS」の中身を保存しておきます。
2. 変更をファイルにする。 CSSの修正なら、CSSをページの <head> に出すだけの小さなプラグインにします。
3. FTPソフトかファイルマネージャーで置く。 基本仕様のページによると、暗号化通信（FTPS接続）が使えます。sftpはプランと条件つきです。ファイルマネージャーは1ファイル25MB以下です。
4. 置いたファイルのサイズが、手元と同じかを確かめる。
5. サイトの主要なページが開けるかを確かめる。 トップ、申し込みや購入の入口、管理画面を見ます。
6. ページキャッシュを使っているサイトでは、キャッシュを消す。
7. 実際の表示で、変更が効いているかを確かめる。

当社が使ったのは、WordPressのmu-plugins（must-useプラグイン）です。mu-pluginsとは、wp-content/mu-plugins に置いたPHPファイルが、有効化の操作なしで自動的に読み込まれるWordPressの仕組みのことです。形は次のとおりです。クラス名と色は例です。

<?php
/* Plugin Name: Front CSS Fix */
add_action('wp_head', function () {
    echo '<style id="front-css-fix">.example-button{color:#fff !important}</style>';
}, 100);

WordPressの公式ドキュメントによると、mu-pluginsは管理画面から無効にできず、更新の通知にも出ません。止めるときは、ファイルを消します。置いたことを記録に残さないと、後から誰も気づけなくなります。

裏方で実際に起きた例：追加CSSの保存が403になり、FTPで回避した2026年8月

ここからは、僕の会社（株式会社UrakaTA）の運用記録からの転記です。お客さんの案件なので、サイトが分かる情報は伏せています。

2026年8月、ある物販のECサイトで、ボタンの文字が背景とほぼ同じ色になって読めない、という相談を受けました。原因はテーマが出しているCSSの色の組み合わせで、直すCSSは1行です。ブラウザの上で仮に当てて、パソコンの幅とスマートフォンの幅の両方で読めることを確かめました。

追加CSSとは、WordPressのカスタマイザー（外観のカスタマイズ画面）にある、テーマを上書きするCSSを書き足すための欄のことです。ここに1行を足して保存したところ、403で失敗しました。

最初に疑ったのは、自分が足した1行です。記録に残っている試行は、次のとおりです。

決め手は2行目でした。何も変えていない内容でも保存できないなら、原因は足した1行ではありません。403の本文にサーバー事業者の名前があったことと合わせて、サーバー側のWAFだと判断しました。ルール1つなら通り、全文だと止まる理由までは、特定していません。

つまりこのサイトでは、追加CSSの保存という機能そのものが、実質的に使えなくなっていました。今回の1行に限らず、今後のデザインの調整すべてに関わる話です。

反映の方法は3つ考えました。WAFを一時的に切る、FTPで置く、検査の一部を外す、の3つです。切り替えは、お客さんにサーバーの画面で操作してもらう必要があります。当社は、WAFには触れずにFTPで置く方法を選びました。

FTPで置いてからも、1回やり直しています。最初はテーマのCSSファイルの末尾に書き足しました。ところが、CSSファイルのURLに付く版の文字列が変わらず、ブラウザ側のキャッシュの期限も長い設定でした。最近サイトを見た人、つまり不具合を知らせてくれたお客さん本人の画面には、古いCSSが残ります。そこでCSSファイルは元に戻し、小さな専用プラグインでHTMLの中に直接CSSを出す形に変えました。HTMLに入っているCSSは、CSSファイルのキャッシュに左右されません。

もう1つ、つまずいた点があります。プラグインを更新しても、お客さんの画面に反映されませんでした。このサイトはページキャッシュのプラグインで、できあがったHTMLをサーバーに保存していました。HTMLの中のCSSは、保存された時点のものが配られ続けます。お客さんから「キャッシュを消しても反映されない」と言われた原因は、ブラウザではなくサーバー側のキャッシュでした。サーバーのキャッシュを消して、反映を確かめています。

調べ始めてから反映までにかかった時間は、記録に残していないので書きません。

監視のアクセスまで403で止められた

同じサイトで、2026年8月の終わりにもう1つ起きました。保守のために当社が作った稼働監視が、トップ・商品一覧・カートの3ページを毎分取りに行っていたところ、商品一覧とカートが403で返されるようになりました。対応は2つです。トップは1分ごとのまま、商品一覧とカートは5分ごとに間隔を空けました。あわせて、403は「サイトが落ちた」ではなく「計測が止められた」と数え、稼働率の計算から外しています。

機械のアクセスが403で断られる側の話は、Claude CodeでURLが読めない・WebFetchが403になる時の対処にも書きました。

WAFの403を再発させないための運用ルール

この件の記録から、次の5つを運用ルールとして整理しました。

• 保存が失敗したら、何も変えずに保存し直す。 それでも失敗するなら、自分の変更ではなく環境が原因です。当社はこの1手で、原因を切り分けられました。
• 引き継いだサイトでは、WAFの状態と、管理画面で保存できるかを最初に確かめる。 使えなくなっている機能に、作業の途中で気づくと手戻りになります。
• 見た目の修正は、置き場所を1か所にまとめる。 当社は、テーマのファイルへの書き足しをやめ、専用プラグイン1つに集めました。どこに何を足したかを、記録に残します。
• ファイルを置いたら、サーバーのキャッシュを消すところまでを手順にする。 キャッシュを避けるURLで確かめると、自分には直って見えても、お客さんには届いていないことがあります。
• 監視や自動取得は、間隔を空ける。 403を「落ちた」と数えると、誤った警報と誤った稼働率が出ます。

原因がサイト・ツール・環境のどこにあるかを先に切り分ける考え方は、AI導入の失敗事例7つの「失敗6」にも書いています。

業務でWAFを切る・FTPで回避するときの注意

誰がコントロールパネルに入れるかを、先に確かめる。 WAFの切り替えは、サーバーの契約者の画面で行います。制作会社や保守の担当が入れないことは珍しくありません。お客さんに切り替えを頼むなら、戻す操作と、戻したことの確認までを依頼に含めます。

FTPで置くファイルは、誤りがあるとサイトが止まる。 管理画面の保存と違い、止めてくれるものがありません。当社の手元にはPHPの文法を確かめる道具が無かったため、後に別の対策を置いたときは、本体を別のファイルに分けました。読み込む側で失敗を受け止め、本体に誤りがあってもサイトは動き続ける作りです。

プラグインのフォルダに、.php 以外のファイルを残さない。 上の作りで本体を .php 以外の拡張子にしたところ、そのファイルが外から平文で読める状態になっていました。当社の失敗です。気づいた日に、外から読めないように閉じました。作業の控え（バックアップ）のファイルも同じです。置いたままにしません。

保守の手間を、作る前に見込んでおく。 WordPressは自由度が高い分、こうした保守の手間が自分たちに返ってきます。作り方ごとの保守の違いは、ホームページの作り方3通りの比較に書きました。

当社の記録にあるのは、さくらのレンタルサーバの1つのサイトで、追加CSSの保存と、自動のアクセスが403になった例です。投稿の保存や、ほかのレンタルサーバでの記録はありません。「管理画面の保存だけが失敗する」「原因がWordPressかサーバーか分からない」というときは、下のフォームからご相談ください。切り分けから一緒に見ます。