SWELLの swell-ct-pv へのPOSTが401になると、PV計測に失敗している可能性があります。ただし401だけでは原因のプラグインを特定できません。リクエスト先、送信方法、レスポンス本文を順に確認します。
最初にNetworkで失敗した通信を確認する
ブラウザの開発者ツールでNetworkを開き、公開記事を再読み込みします。swell-ct-pvで絞り込み、Request URL、Request Method、Status、Responseのcodeとmessageを控えます。Cookieや認証ヘッダーを含む通信全体を公開しないでください。
POST /wp-json/wp/v2/swell-ct-pv
確認するもの：
・実際のRequest URL（サブディレクトリを含む）
・Request MethodがPOSTか
・HTTPステータス
・ResponseのcodeとmessageSWELL 2.19.0のlib/rest_api.phpでは、このルートはPOST用で、テーマ側のpermission_callbackは__return_trueです。WordPress全体の認証フィルター、プラグイン、サーバーの制限は別に適用されます。管理者でログインした場合だけ成功するなら、ログアウト時の制限を優先して調べます。
エラーの返答から調べる場所を分ける
JSONのcodeやmessageにプラグイン由来の文言がある場合は、その設定とログを確認します。rest_cookie_invalid_nonceなどnonceに関する返答なら、ログイン状態とキャッシュされたページの認証情報を調べます。HTMLの拒否ページならWAFやサーバーログも確認します。ルートが無い場合の404や、GETで開いた結果をPOSTの401と混同しないでください。
POST・認証拒否・nonceエラーを比較する
| 通信条件 | 隔離環境で確認した応答 | 切り分ける点 |
|---|---|---|
| 対象ルートへのGET | 404 / rest_no_route | POST専用ルートをブラウザのアドレス欄だけで検査しない |
| 匿名の正常なPOST | 200。対象投稿IDが返り、試験投稿のPVが1増加 | 公開ルートの通信と計測の両方を確認 |
| 認証フィルターで拒否したPOST | 401。拒否理由のcodeが返る | SWELLのpermission_callback以外の制限を調べる |
| 不正なX-WP-Nonce付きPOST | 403 / rest_cookie_invalid_nonce | キャッシュとログイン状態を確認 |
WordPress 7.1.2 / SWELL 2.19.0の隔離環境で、試験投稿に対する実HTTP通信を比較しました。
401は試験用の認証フィルターによる再現であり、XO SecurityやPerfmattersの全設定を再現した結果ではありません。
成功したPOSTだけがPVを増やし、401・403の拒否時には増えませんでした。
このSWELLバージョンの成功応答は、投稿IDを含むJSONを文字列として返します。
外側に引用符が付いた表示だけで失敗と判断せず、Statusと対象投稿IDを確認してください。
XO Securityの設定方向に注意する
XO Security 3.11.0のrest_endpoints処理では、rest_disable_endpointsに登録されたルートをログアウト時の一覧から除外します。「無効化するエンドポイント」の選択は許可リストではありません。以前の記事にあった「許可するためにチェックを入れる」という案内は逆でした。対象ルートが無効化対象になっている場合は、その指定だけを見直します。
PV計測の問題を直すために、swell-block-settingsなど管理用ルートまで一括で許可する必要はありません。インストール中のバージョンの項目名とヘルプを確認し、変更前の選択内容を保存してください。XO Securityの公式説明も参照してください。
Perfmatters・独自コード・WAFを切り分ける
PerfmattersのREST API制限には、ログアウト時や管理者以外を制限する設定があります。導入されている場合に確認する候補であり、401だけで原因とは断定できません。設定を一度に変えず、ステージング環境で一項目ずつ比較します。
子テーマやCode Snippetsにrest_authentication_errorsの独自処理がある場合は、その条件が匿名ユーザーの全REST通信を拒否していないか確認します。.htaccessやWAFも同様に、該当リクエストの記録と設定を照合します。原因確認のために本番のWAFや認証制限をまとめて解除する手順は取りません。SiteGuardなどに未確認の設定画面があると決めつけず、利用中の製品の説明を確認してください。
修正後の確認と戻し方
原因となる設定を限定して変更したら、該当ページのキャッシュを更新し、ログアウト状態で同じ公開記事を一度開きます。Networkで対象POSTの成功とResponseを確認し、必要ならSWELL側のPV表示も確認します。ページを大量に再読み込みしたり、POSTを連続送信したりすると計測値を増やしてしまいます。
REST APIの一覧URLにJSONが表示されても、PV計測のPOST成功は証明できません。記事編集・保存など通常の機能も確認してください。改善しない場合は、保存しておいた選択内容へ戻し、変更した独自コードだけをバックアップから復元します。WAFの判断が必要な場合は、発生時刻・ルート・応答コードを添えてサーバー担当へ調査を依頼します。
設定を戻すときの基本の並びはSWELLの初期設定ガイド、導入中の製品名とバージョンの調べ方はテーマ・プラグインを調べる方法にまとめています。
投稿IDのないPOSTによる500と401を区別する
独立したWordPress 7.1.2 / SWELL 2.19.0で、swell-ct-pvへ投稿IDのないPOSTを送ると、HTTP 500、codeがwp_die、messageが[]という応答になりました。
投稿IDを含む検証用のPOSTでは200で対象IDが返り、その検証用投稿の保存値が1だけ増えました。
投稿IDの欠落による500を、認証拒否による401と同じ設定問題として扱いません。
Networkで実際にテーマが送ったリクエストのStatus・Response・送信データを照合し、postidが含まれているかを確認してください。
このために本番へ手動のPOSTを繰り返す必要はありません。
500の原因をこの1例へ限定せず、異なる応答やPHPのエラーがある場合はその記録を確認します。
確認した環境と範囲
WordPress 7.1.2 / SWELL 2.19.0の隔離環境で、所有する検証用投稿に対して実HTTP通信を比較しました。SWELL 2.19.0とXO Security 3.11.0のソースも確認しています。
サーバー側の制限を見直す場合はセキュリティヘッダーの設定方法も合わせて確認してください。
よくある質問：SWELLのREST API 401エラー（swell-ct-pv）
SWELLのPV計測で、REST APIが401になったときは、まず何を確認しますか？
記事では、ブラウザの開発者ツールでNetworkを開き、公開記事を再読み込みして、swell-ct-pvで絞り込み、Request URL、Request Method、Status、Responseのcodeとmessageを控えます。401だけでは原因のプラグインを特定できません。Cookieや認証ヘッダーを含む通信全体を公開しないでください。
管理者でログインしたときだけ成功する場合は？
記事によると、SWELL 2.19.0のlib/rest_api.phpでは、このルートはPOST用で、テーマ側のpermission_callbackは__return_trueです。WordPress全体の認証フィルター、プラグイン、サーバーの制限は別に適用されます。管理者でログインした場合だけ成功するなら、ログアウト時の制限を優先して調べます。
レスポンスの内容から、どこを調べますか？
記事では、JSONのcodeやmessageにプラグイン由来の文言がある場合は、その設定とログを確認します。rest_cookie_invalid_nonceなどnonceに関する返答なら、ログイン状態とキャッシュされたページの認証情報を調べます。HTMLの拒否ページならWAFやサーバーログも確認します。ルートが無い場合の404や、GETで開いた結果をPOSTの401と混同しないでください。
XO Securityの設定は、どう見直しますか？
記事では、XO Security 3.11.0のrest_endpoints処理では、rest_disable_endpointsに登録されたルートをログアウト時の一覧から除外します。「無効化するエンドポイント」の選択は許可リストではありません。以前の記事にあった「許可するためにチェックを入れる」という案内は逆でした。対象ルートが無効化対象になっている場合は、その指定だけを見直し、変更前の選択内容を保存してください。管理用ルートまで一括で許可する必要はありません。
Perfmattersや独自コード、WAFが原因のときは？
記事では、PerfmattersのREST API制限にはログアウト時や管理者以外を制限する設定があり、導入されている場合に確認する候補ですが、401だけで原因とは断定できません。設定を一度に変えず、ステージング環境で一項目ずつ比較します。子テーマやCode Snippetsにrest_authentication_errorsの独自処理がある場合は、匿名ユーザーの全REST通信を拒否していないか確認します。原因確認のために本番のWAFや認証制限をまとめて解除する手順は取りません。
500エラーと401エラーは、同じ問題ですか？
記事では、独立したWordPress 7.1.2／SWELL 2.19.0で、swell-ct-pvへ投稿IDのないPOSTを送ると、HTTP 500、codeがwp_die、messageが[]という応答になりました。投稿IDの欠落による500を、認証拒否による401と同じ設定問題として扱いません。Networkで実際にテーマが送ったリクエストのStatus・Response・送信データを照合し、postidが含まれているかを確認してください。
修正後は、どう確認して、戻しますか？ 確認の範囲は？
原因となる設定を限定して変更したら、該当ページのキャッシュを更新し、ログアウト状態で同じ公開記事を一度開いて、Networkで対象POSTの成功とResponseを確認します。ページを大量に再読み込みしたり、POSTを連続送信したりすると計測値を増やしてしまいます。改善しない場合は、保存しておいた選択内容へ戻し、変更した独自コードだけをバックアップから復元します。記事の確認はWordPress 7.1.2／SWELL 2.19.0の隔離環境で、すべてのプラグイン構成で401の再現・解消を確認したものではありません。最新は公式で確認してください。
