WordPressのページ、フォーム、ブロックエディター、REST APIで「406 Not Acceptable」と表示されることがあります。URLは存在し、ログインもできているのに、特定の操作や端末、外部連携だけが拒否される症状です。
406は、クライアントが「この形式・言語・圧縮方式の応答を受け取りたい」と伝えたものの、サーバーが条件に合う応答を用意できず、既定の応答も返さなかった状態です。送信本文の形式を表すContent-Typeより、受け取り条件を表すAccept系ヘッダーを先に確認します。
WAFやセキュリティプラグインを全面停止したり、すべての応答形式を無条件で許可したりしないでください。発生したURLと時刻を残し、要求ヘッダー、応答ヘッダー、同時刻ログから返答元を絞れば、安全性を保ったまま直せます。
先に結論：406エラーは8段階で確認する
- 編集中の本文やフォーム入力を退避し、連続送信を止める
- 完全なURL、操作、HTTPメソッド、発生時刻、406を記録する
- 同じURLが通常のブラウザでも失敗するか、一度だけ比較する
- Accept、Accept-Language、Accept-Encodingを確認する
- 応答ヘッダーと本文から、CDN・WAF・Webサーバー・WordPressのどこが返したか絞る
- REST API、Apacheのコンテンツネゴシエーション、キャッシュ設定を確認する
- 要求条件かサーバー側の提供形式を一か所だけ修正する
- 復旧後、通常ページ・保存・フォームと非対応要求の拒否を確認する
「送信したJSONの形式が違う」と考えてしまいがちですが、それは415の確認領域です。迷う場合はWordPressの415 Unsupported Media Typeを直す確認順と見比べてください。
406 Not Acceptableとは？
RFC 9110の406 Not Acceptableは、要求で受け取った事前交渉用ヘッダーに照らすと、対象リソースにクライアントが受け入れられる現在の表現がなく、サーバーが既定表現も提供しない状態と定義されています。
ここでいう「表現」は、同じページのHTMLとJSON、同じ内容の日本語版と英語版、gzip圧縮版と非圧縮版などです。URLが同じでも、クライアントの希望に応じて別の表現を返す仕組みをコンテンツネゴシエーションと呼びます。
ただし、要求条件に合う表現がないとき、サーバーは必ず406を返すわけではありません。RFCでは、そのヘッダー条件を尊重して406を返すか、条件を無視して応答を返すかをサーバーが選べます。そのため、同じ設定ミスでも環境によって406になる場合と、別形式が返る場合があります。
403・405・406・415の違い
| 表示 | 主な意味 | 最初に確認するもの |
|---|---|---|
| 403 Forbidden | 認証状態にかかわらずアクセスを拒否 | WAF、権限、IP制限、アクセスルール |
| 405 Method Not Allowed | そのURLで使用したメソッドが非対応 | URL、GET・POST等、Allowヘッダー |
| 406 Not Acceptable | 受け取り条件に合う応答を提供できない | Accept、Accept-Language、Accept-Encoding |
| 415 Unsupported Media Type | 送信した内容の形式が非対応 | Content-Type、Content-Encoding、実本文 |
406と403は、実際のサービスや防御製品で同じような拒否画面になることがあります。エラー画面の文言だけで決めず、ブラウザのNetwork欄にある実際のステータス、応答ヘッダー、WAFイベントを確認してください。403ならWordPressの403 Forbiddenを安全に直す手順へ切り替えます。
Accept系ヘッダーの役割を整理する
| ヘッダー | 伝える希望 | 例 |
|---|---|---|
| Accept | 受け取りたいメディアタイプ | text/html、application/json、image/* |
| Accept-Language | 受け取りたい言語 | ja、en-US |
| Accept-Encoding | 受け取れる圧縮などの符号化 | gzip、br、identity |
| Accept-Charset | 受け取りたい文字集合 | 現在は送信を省略するクライアントが多い |
各候補にはq値で優先度を付けられ、0は「受け入れない」という意味です。たとえば、利用できる応答がJSONだけなのに、送信側がAccept: text/htmlだけを許し、ワイルドカードも含めなければ、406の原因になり得ます。
一方、ヘッダー自体がない場合は、その観点について希望を示していない扱いです。原因確認のために闇雲にヘッダーを増やすより、標準的なブラウザや利用ライブラリの既定値へ戻し、過度に狭い条件が追加されていないかを確認する方が安全です。
WordPressで406が出る主な原因
1．外部連携やJavaScriptがAcceptを狭く指定している
REST APIや外部APIの呼び出しで、実際に返せるのがJSONなのにHTMLだけを要求したり、独自のメディアタイプだけを許したりすると、提供形式と受け取り条件が一致しません。APIクライアント、JavaScript、プラグイン更新後に始まった場合は、送信コードや設定で追加されたAcceptを確認します。
2．言語・圧縮形式の候補が提供側と合わない
多言語ページや圧縮配信で、クライアントが受け入れる言語・符号化を狭く指定し、サーバー側に対応版がないと406になる可能性があります。ただし、通常のブラウザは複数候補や既定値を送るため、特定の自動処理や拡張機能だけで再現するなら、その要求を優先して確認します。
3．ApacheのMultiViewsやtype-mapが表現を選べない
Apache HTTP ServerのContent Negotiationでは、type-mapまたはMultiViewsを使って、ファイル名、メディアタイプ、言語、符号化などから最適な表現を選びます。移行や.htaccess変更後に特定URLだけ失敗する場合は、MultiViewsが有効か、候補ファイルの拡張子や言語情報が正しいかをサーバー管理者と確認します。
WordPressのパーマリンク設定とMultiViewsが意図せず干渉することもあるため、既存の.htaccessを全面的に書き換えず、テスト環境で対象ディレクトリの設定だけを検証します。
4．CDN・WAF・セキュリティ製品が406を返している
防御層が不審な要求を検知した際、製品やルールによって406相当の応答を返す場合があります。この場合は厳密なコンテンツネゴシエーションではなく、防御ルールの拒否として使われている可能性があります。応答のServer情報、リクエストID、WAFイベント、発生時刻を照合してください。
正当な操作が誤検知されていたら、全体を停止せず、該当ルール、対象URL、HTTPメソッド、送信元などを限定して例外を検討します。設定変更前にバックアップと戻し方を用意し、検証はWordPressのテスト環境を作る方法に沿って行います。
5．キャッシュが要求条件と異なる応答を返している
言語や圧縮形式で応答が変わるのに、CDNやキャッシュが変動条件を適切に区別できていないと、特定の利用者だけ誤った応答や406を受け取ることがあります。応答のVary、キャッシュ状態、CDNキャッシュキーを確認し、対象URLだけを安全にパージして再確認します。
サイト全体のキャッシュ削除を繰り返す前に、WordPressのキャッシュ設定を安全に確認する手順で、ブラウザ、WordPress、サーバー、CDNの層を分けてください。
最初の10分で行う安全な初動
1．入力内容と発生条件を保存する
保存やフォーム送信で失敗したら、まず本文や入力値を別の安全な場所へ退避します。次に、完全なURL、画面上の操作、HTTPメソッド、発生時刻、端末、ブラウザ、ログイン状態、406の応答本文を記録します。秘密情報や個人情報は共有用メモから除きます。
2．症状の範囲を一度だけ比較する
- 公開ページと管理画面の両方か
- 通常ブラウザと外部APIクライアントの両方か
- ログイン中とログアウト状態の両方か
- 特定URL、特定言語、特定ファイル形式だけか
- CDN経由とオリジンサーバーで差があるか
- 直前のプラグイン、テーマ、WAF、サーバー変更があるか
公開ページは正常で、独自APIクライアントだけ失敗するなら要求ヘッダーが有力です。すべての利用者が同じURLで失敗するなら、サーバー側の表現設定や防御層を優先します。何度も送信するとWAF制限や重複処理を増やすため、比較は必要最小限にします。
3．要求と応答を一組で記録する
ブラウザの開発者ツールやAPIクライアントで、Request HeadersのAccept系、Response Headers、HTTPステータス、応答本文を保存します。Authorization、Cookie、APIキー、セッショントークンは公開メモやスクリーンショットへ残しません。
ブロックエディターで同時に「返答が正しいJSONレスポンスではありません」と表示される場合は、WordPressのJSONレスポンスエラーを直す確認順で、406のHTML拒否ページがREST APIへ返っていないかを確認します。
どの層が406を返したか特定する
| 確認層 | 見るもの | 判断の手がかり |
|---|---|---|
| ブラウザ・外部クライアント | Accept系ヘッダー、拡張機能、送信ライブラリ | 通常ブラウザとの差があるか |
| CDN・WAF | 応答ヘッダー、イベント、リクエストID | オリジンへ届く前に拒否したか |
| Webサーバー | アクセスログ、エラーログ、MultiViews | Apache等が表現を選べなかったか |
| WordPress・プラグイン | RESTルート、独自応答、更新履歴 | アプリケーションが406を明示したか |
| キャッシュ | Vary、キャッシュキー、HIT・MISS | 条件の違う応答が混ざったか |
WordPress REST APIは通常JSONを使いますが、WordPressコアがすべての形式不一致で406を返すわけではありません。プラグインの独自RESTルートや外部API、中継層が返している可能性もあるため、WordPressだけを原因と決めつけないことが重要です。
原因別の安全な直し方
1．AcceptをAPIが返せる形式へ合わせる
対象APIの公式仕様で応答形式を確認し、その形式を受け取れるAcceptへ戻します。WordPress REST APIなら、WordPress REST APIリファレンスで対象ルートと応答を確認します。独自メディアタイプが必須のAPIでは、そのサービスの現行仕様を優先してください。
原因調査で一時的にAccept: */*を試す場合も、本番仕様として無条件に固定せず、クライアントが実際に処理できる形式へ絞り直します。受け取れない内容を成功扱いすると、後段で解析エラーやデータ破損につながります。
2．言語と圧縮の条件を標準値へ戻す
特定端末や自動処理だけで失敗するなら、Accept-LanguageやAccept-Encodingへ不自然に狭い値、q=0、未対応の符号化だけが設定されていないか確認します。ブラウザやライブラリの既定値と比較し、独自設定を一つずつ外します。
3．Apacheの表現候補とMultiViewsを見直す
Apache環境で拡張子なしURLや多言語ファイルだけ失敗する場合は、候補ファイル、Content-Type、Content-Language、Content-Encoding、type-map、MultiViewsの範囲を確認します。WordPressで必要のないMultiViewsが有効なら、影響を検証したうえで対象ディレクトリだけ無効化を検討します。
4．WAFの誤検知は対象限定で調整する
WAFイベントと406の時刻・URL・リクエストIDが一致したら、ホスティング会社または管理者へ、再現手順とルール情報を添えて相談します。正当な操作であることを確認したうえで、該当ルールやパスだけを調整します。サイト全体のWAF停止は、攻撃も同時に通すため避けてください。
5．キャッシュの変動条件をそろえる
言語や圧縮で応答が変わるなら、オリジンのVaryとCDNキャッシュキーが一致しているか確認します。変更後は対象URLのキャッシュだけを削除し、異なる言語設定と通常ブラウザで再テストします。古いキャッシュが残ると、修正済みでも特定利用者だけ失敗が続きます。
やってはいけない対処
- 原因確認前にWAFやセキュリティプラグインを全面停止する
- AcceptとContent-Typeを同じ役割だと思って書き換える
- すべての形式や言語を無条件で成功扱いにする
- .htaccessをバックアップせず全面置換する
- CDN、WordPress、サーバーの全キャッシュを同時に消して原因を分からなくする
- AuthorizationやCookieを含む要求情報を公開場所へ貼る
- 406が続く公開URLを放置する
Googleは、429を除く4xxを返すURLの内容を検索処理に使用せず、すでにインデックス済みのURLも継続すれば除外され得ると説明しています。公開ページが406なら、管理画面だけの症状より優先して、通常のGooglebotや未ログイン利用者へ200が返る状態を確認してください。
復旧後の確認チェックリスト
- 問題のURLが通常ブラウザで200を返す
- WordPressの投稿・固定ページを保存できる
- フォームが一度だけ送信され、通知と保存結果が正しい
- REST APIが想定したJSONまたは指定形式を返す
- 言語切り替えと圧縮配信が必要な端末で動く
- 非対応形式を要求した場合に安全なエラーまたは既定応答になる
- WAFが他の不正要求を引き続き遮断する
- CDNキャッシュ更新後も再発しない
- アクセスログに406が増え続けていない
変更点、発生日、原因、修正箇所、確認結果を運用メモへ残します。再発時に同じ切り分けを繰り返さずに済み、プラグインやサーバー更新との関連も追いやすくなります。
自力で直せないときにサーバー会社へ伝える情報
- 406が出た完全なURLと発生日時・タイムゾーン
- 閲覧、保存、フォーム、REST APIなどの操作
- HTTPメソッドとAccept系ヘッダーの種類
- 応答ヘッダー、応答本文、リクエストID
- 影響する端末、言語、ログイン状態、URLの範囲
- 直前のプラグイン、WAF、CDN、.htaccess変更
- WAFイベントやWebサーバーログとの一致
- すでに試したことと、その結果
秘密情報は伏せたうえで、「406を解除してほしい」だけでなく、「どの層が返しているか」「どのAccept条件または防御ルールが一致しないか」を確認したいと伝えると、必要以上に防御を弱めずに調査できます。
よくある質問
ブラウザのキャッシュ削除だけで直りますか？
古い変動応答が残っている場合は改善する可能性がありますが、Acceptの不一致、WAF、MultiViewsの設定は直りません。シークレットウィンドウで一度比較し、応答ヘッダーとサーバー側ログを確認してください。
406はWordPressの不具合ですか？
WordPressコアに限りません。ブラウザ・外部クライアント、CDN・WAF、Apache、プラグイン、外部APIのどこでも返され得ます。発行元を特定してから、その層だけを直します。
AcceptとContent-Typeは両方application/jsonにすればよいですか？
必ずしもそうではありません。Acceptは受け取りたい応答、Content-Typeは今回送る本文の形式です。GETで本文を送らない場合でもAcceptは使えます。対象APIの仕様に従い、それぞれを独立して設定します。
まとめ
WordPressの406 Not Acceptableは、要求した応答形式・言語・圧縮条件と、サーバーが提供できる表現が合わないときに起こるエラーです。ただし、防御製品が拒否応答として406を使う場合もあるため、番号だけで原因を断定できません。
安全な順番は、入力退避、発生条件の記録、Accept系ヘッダー確認、発行元の特定、対象一か所の修正、復旧後の防御確認です。403・405・415と役割を分け、WAFやサーバー設定を必要以上に緩めないことが、再発しにくい復旧につながります。