SureCookieで同意ログが記録されない時の原因と対処法
SureCookie で同意ログが 0 件のまま増えない場合、まず疑うのは REST API の URL が 404 を返している状態だ。パーマリンク設定とキャッシュ・最適化プラグインの影響を順に確認すれば、原因を特定できる。
同意ログが記録されない原因は REST API の URL にある
訪問者が Cookie 同意バナーで「すべて同意」を選ぶと、SureCookie は WordPress の REST API に POST リクエストを送り、同意内容をログへ書き込む。この API とは、サイト内部と外部のスクリプトがデータをやり取りするための仕組みだ。
ところが、サイト側の設定やキャッシュの影響で、送信先の URL が意図した形にならないことがある。正常なら /wp-json/ から始まる URL が使われるが、設定オブジェクトが読み込まれないと /?rest_route= という形式に切り替わる。どちらも本来は動作する形式だが、後者が 404 を返す場合はリクエストが WordPress 本体に届いていない。
ブラウザの開発者ツールでネットワークタブを開き、バナー操作時の POST リクエストを確認すると、404 ステータスが返っている様子を直接確認できる。これが確認できれば、ログが記録されない直接の原因だ。
上図は URL の生成パターンを示したイメージだ。パーマリンク設定が「投稿名」などの見やすい形式にもかかわらず /?rest_route= が出る場合は、SureCookie の設定オブジェクトがページに正しく出力されていない。
パーマリンク設定を確認して URL 形式を切り分ける
この手順の全体像を踏まえて、各ステップを詳しく見ていく。
パーマリンク設定が「基本」の場合
WordPress 管理画面の「設定 → パーマリンク」を開き、現在の設定が「基本」になっている場合、/?rest_route= という URL が使われるのは正常な動作だ。この場合、URL の形式そのものは問題ではなく、404 になる原因は別にある。REST API 自体がブロックされているか、リクエストが WordPress に到達していない可能性を後述の手順で確認する。
パーマリンク設定が「投稿名」の場合
パーマリンク設定が「投稿名」などに設定されていれば、通常は /wp-json/ から始まる URL が使われる。それにもかかわらず /?rest_route= が現れるなら、SureCookie の設定オブジェクトがページ上に出力されていない。パーマリンク設定を一度保存し直し、データベース上のリライトルールを再生成するだけでも改善することがある。
キャッシュと JavaScript 最適化が設定を壊すケース
サーバー付属の最適化プラグインやキャッシュプラグインが、JavaScript の結合・遅延読み込み・圧縮を実行していると、SureCookie がページに埋め込む設定オブジェクトが壊れるか、出力されないことがある。その結果、プラグインが正しい URL を生成できず、フォールバックとして /?rest_route= を送り、404 になる。
キャッシュの全削除と最適化の停止
最初にキャッシュプラグインの管理画面からキャッシュを全削除する。続いて JavaScript の結合、遅延読み込み、圧縮の各機能を一時的に無効化する。この状態でブラウザのシークレットウィンドウを開き、同意バナーを操作してログが記録されるか確認する。直った場合は、最適化機能のどれかが原因だ。
除外設定を追加して再有効化する
原因が特定できたら、SureCookie のスクリプトを最適化の除外リストに追加する。除外対象は SureCookie の本体スクリプトと、それに付随する設定オブジェクトのインラインスクリプトだ。除外設定後、最適化機能を一つずつ再有効化し、その都度ログが記録されるかを確認する。これで各機能の影響を切り分けられる。
REST API がブロックされていないか確認する
セキュリティプラグインやサーバー側の設定で WordPress の REST API が無効化されていると、/wp-json/ も /?rest_route= も 404 や 403 を返す。同意ログの POST リクエストも同じようにブロックされるため、ログが一切記録されない。
REST API の動作確認
ブラウザのアドレスバーに、自サイトのドメインの直後に /wp-json/ を付けてアクセスする。正常なら JSON 形式のデータが表示される。404 や 403 になる場合は、REST API がサイト全体でブロックされている。セキュリティプラグインの設定画面を開き、REST API を許可するか、SureCookie のエンドポイントを除外する。
ログインユーザー限定設定を見直す
REST API へのアクセスをログインユーザーに限定する設定があると、未ログインの訪問者が送る同意 POST が拒否される。同意バナーを操作するのはログインしていない一般訪問者なので、この設定が有効だとログは永遠に記録されない。該当する設定を無効化するか、SureCookie のエンドポイントだけを許可する。
サイトスキャナーが Cookie を検出しない理由
SureCookie に内蔵されたサイトスキャナーが「成功」と表示しても Cookie を 0 件と報告するのは、同意前のスクリプトブロックが働いているためだ。Google アナリティクス 4（GA4）や Microsoft Clarity のタグは、同意が得られるまで読み込まれない。スキャナーがこのブロック状態で実行されるなら、Cookie を検出しないのは想定内といえる。
一方、外部スキャナーが検出できるのは、実際の訪問者が同意した後にタグが発火し、Cookie が設定された状態を計測しているからだ。SureCookie のスキャナーが同意後の状態を反映するかは、製品のバージョンやスキャンの実行タイミングによって異なる。同意ログと実際の Cookie の乖離が続く場合は、プラグインの仕様や設定を確認する必要がある。
よくある質問
同意ログが記録されないと法的に問題になるか
Cookie 同意の記録は、GDPR や改正電気通信事業法などの監査対応で重要な証跡になる。ログが残っていないと、同意取得の事実を証明できないため、監査や紛争時に不利になる可能性がある。運用前に必ず記録される状態へ直しておく。
/?rest_route= という URL は正常なのか
パーマリンク設定が「基本」であれば、/?rest_route= は WordPress が公式にサポートする正常な形式だ。ただし「投稿名」などに設定しているのにこの形式が出る場合は、設定オブジェクトの読み込みに失敗している可能性が高い。
パーマリンク設定が基本のままでも SureCookie は動くか
動くように設計されている。REST API のリクエストが正しく WordPress に到達すれば、/?rest_route= でも同意ログは記録される。404 になるのは URL の形式だけが原因ではなく、リクエスト経路のどこかでブロックされているケースだ。
キャッシュプラグインの除外設定はどの範囲か
SureCookie の本体スクリプトと、設定オブジェクトを含むインラインスクリプトを対象にする。多くのキャッシュプラグインにはスクリプト単位の除外欄があるため、そこに SureCookie 関連のスクリプト名を追加し、結合や遅延読み込みから外す。
同意ログが記録されたか確認する方法は
SureCookie の管理画面にある同意ログ一覧で件数が増えるかを確認する。あわせてブラウザの開発者ツールで POST リクエストが 200 を返しているかを見ると、書き込みが成功しているかがより正確にわかる。
この記事のポイント
- 同意ログが残らない直接の原因は REST API の 404 だ
- パーマリンク設定で URL 形式の正常性を切り分ける
- キャッシュと JavaScript 最適化を無効化して確認する
- REST API 自体のブロックも忘れずに点検する
- スキャナーの Cookie 0 件は同意前ブロックが原因になりやすい
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPressをサブフォルダにインストールするとREST APIが404になる原因と直し方
WordPressをサブフォルダにインストールしている環境で、REST APIのエンドポイントが404エラーを返す場合は、プラグインがサブフォルダを考慮せずにAPIのURLを生成しているバグが原因だ。該当プラグインを最新版に更新するか、パーマリンク設定のリフレッシュで解決する。
なぜサブフォルダ環境でプラグインのAPIが404になるのか
WordPressをドキュメントルート直下ではなく/blogや/siteのようなサブフォルダにインストールした場合、REST APIのベースURLはhttps://example.com/subfolder/wp-json/となる必要がある。ところが一部のプラグインは、内部でAPIのURLを組み立てる際にこのサブフォルダを考慮しておらず、https://example.com/wp-json/...のようにルート直下を指してしまう。その結果、実在しないパスへのリクエストとなり404が返る。
今回のケースでは、プラグインが独自に追加したエンドポイント/profeedwp/v1/linkedin/company-posts/smartに対して、サブフォルダを含まない不完全なURLでリクエストを発行していた。同様の問題は、テーマや他のプラグインがrest_url()関数を正しく使わずにハードコードしたパスを参照している場合にも起こる。
解決手順
まず簡単かつ即効性のある方法として、問題のプラグインを最新版へ更新する。次に、WordPressのパーマリンク設定をリセットし、REST APIのルートURLが正しく再構築されるか確認する。これで直らない場合は、手動でrest_url()が返す値を検証し、他のプラグインとの競合を調べる。
プラグインを最新版に更新する
本件ではバージョン1.6.10で修正が行われている。管理画面の「プラグイン」→「インストール済みプラグイン」から対象プラグインを確認し、更新が表示されていれば適用する。更新が出ていない場合は、一度プラグインを削除して再インストールするか、開発元の公式ページから修正版がリリースされていないか確認する。
パーマリンク設定をリセットする
プラグインの更新で直らなかった場合、パーマリンク構造の再保存でWordPress内部のルーティングをリフレッシュできる。「設定」→「パーマリンク」を開き、現在選択されている設定をそのままの状態で「変更を保存」をクリックする。これにより.htaccessの再生成と、REST APIのルート定義が再構築される。サブフォルダ環境では特に、リライトルールが正しくサブフォルダをプレフィックスとして含む必要があるため、この一手順で解決するケースが多い。
rest_url() の戻り値を検証する
根本原因がプラグイン側のURL組み立てにあるかどうかを切り分けるには、WordPressが正しいREST APIのルートURLを返しているかを確認する。テーマのfunctions.phpなどに次のようなテストコードを一時的に追加する。
add_action('wp_footer', function() {
echo '<!-- REST URL: ' . esc_url(rest_url()) . ' -->';
});サイトのフッター部分のHTMLソースに出力されたURLがhttps://example.com/subfolder/wp-json/の形式になっていれば、WordPress本体の認識は正しい。もし/subfolderが欠落している場合は、wp-config.phpでWP_HOMEとWP_SITEURLが正しくサブフォルダを含んだ値で定義されているか確認する。
全プラグインを無効化して競合を切り分ける
それでも404が解消しない場合、別のプラグインがREST APIのルーティングに干渉している可能性がある。すべてのプラグインを一括で無効化し、問題のエンドポイントにアクセスして200番台のレスポンスが返るかテストする。正常動作が確認できたら、プラグインを1つずつ有効化して原因のプラグインを特定する。キャッシュ系プラグインやセキュリティプラグインは、REST APIへのリクエストをブロックしたり、URLを書き換えたりする設定項目を持つことがあるため、該当するプラグインの設定もあわせて確認する。
よくある質問
サブフォルダにインストールする際にwp-config.phpで注意すべき点は？
WP_HOMEとWP_SITEURLの定数をhttps://example.com/subfolderのようにサブフォルダを含めて明示的に定義しておくと、サイトURLの誤認識を防げる。wp-config.phpに記述しなければならないわけではないが、マルチサーバー構成やリバースプロキシの背後で運用する場合は特に有効だ。
REST APIの404エラーはどのようにデバッグすればいいか？
ブラウザのデベロッパーツールのネットワークタブで、実際に送信されたリクエストURLを確認する。サブフォルダが欠落したURLでリクエストが発生している場合は、呼び出し元のJavaScriptファイルやPHPコードでURLの組み立て方をチェックする。rest_url()を使わずにハードコードされたパスが原因であることが多い。
プラグインを更新しても問題が再発する場合は？
修正パッチが適用されたバージョンでも、キャッシュの残存やデータベースに保存された古い設定値が原因で再発することがある。プラグインを完全に削除したあと、wp_optionsテーブルに残っている該当プラグインのオプションを手動で削除し、最新版を再インストールすると改善する場合がある。
サブフォルダ環境でなくてもAPIが404になる原因は？
パーマリンク設定が「基本」になっているとREST APIが動作しない。また、セキュリティプラグインが/wp-json/へのアクセスを制限しているケースもある。.htaccessのリライトルールが破損している場合も404になるため、パーマリンク設定の再保存でリフレッシュするのが初手として有効だ。
この記事のポイント
- サブフォルダ環境でプラグインのAPIが404になるのは、URLにサブフォルダが含まれない不完全なパスが原因
- 問題のプラグインを最新版に更新し、パーマリンク設定を再保存するのが解決の基本手順
- rest_url() の戻り値とwp-config.phpの設定を確認し、WordPress本体のURL認識が正しいか検証する
- 全プラグインの無効化で競合を切り分け、キャッシュやセキュリティ系プラグインの干渉を疑う
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Diviビルダーでカスタムパーマリンクのページが404になる原因と直し方
Diviビルダーでカスタムパーマリンクを設定した固定ページを編集しようとしたとき、編集画面が404エラーになる現象は、パーマリンク管理プラグインがビルダー専用のクエリパラメータを不正に処理しているために起こる。多くの場合、プラグインの詳細設定で特定のクエリ文字列を除外するだけで解決する。
なぜDiviビルダーがカスタムパーマリンクのページで404エラーを起こすのか
Diviのビジュアルビルダー（フロントエンド編集）は、管理画面から対象ページのURLに「?et_fb=1」といったクエリパラメータを付与し、そのページをiframe内で読み込んで動作する。このとき、パーマリンク管理プラグイン（Permalink Manager Lite など）が設定したカスタムパーマリンクのリダイレクトルールが厳しすぎると、「?et_fb」がついたURLを本来とは別の場所に転送したり、存在しないページとみなして404ステータスを返してしまう。ページ自体は正常に表示されていても、ビルダーという編集専用のアクセスだけがブロックされるかたちになる。
具体的には、パーマリンク管理プラグインの「リダイレクト設定」や「正規化」機能が、付加されたクエリ文字列を除去してしまったり、ビルダー用のパラメータを含むURLをリダイレクト対象から外す設定になっていないことが原因だ。また、一部のキャッシュ設定が影響して、ビルダーがキャッシュ済みの不完全なページを読み込んで404を返すケースもある。
Permalink Manager Lite の設定を調整して404を解消する
カスタムパーマリンクで運用している環境でDiviビルダーが使えなくなったら、まずパーマリンク管理プラグインの詳細設定を見直す。ここでは日本語環境でも多く使われている「Permalink Manager Lite」を例に手順を示すが、他のパーマリンク系プラグインでも同様の考え方で対処できる。
上記の「除外するクエリパラメータ」には「et_fb」とだけ入力すればよい。クエリキー名のみをカンマ区切りで列挙する仕様のため、値や「?」を含める必要はない。保存後にDiviビルダーでカスタムパーマリンクのページを開き直し、編集画面が正しく表示されるか確認する。
リダイレクト無効化で管理者の編集を保護する
もう一つの有効な方法は、特定のユーザーに対してリダイレクト機能を一時的に無効化する設定だ。「詳細設定」画面の「リダイレクトを無効化するユーザー」で「管理者」にチェックを入れて保存する。こうすると管理画面からビルダーを開く管理者のリクエストにはリダイレクトルールが適用されず、クエリパラメータがそのまま残るため404が発生しなくなる。ただし、この設定は公開側のパーマリンク動作には影響しない。
デバッグモードで原因を可視化する
設定を変更しても改善しない場合は、「ツール」→「Permalink Manager」→「設定」→「詳細設定」にある「デバッグモード」を有効にしてみる。デバッグモードをオンにすると、ビルダーで404になった際にプラグインがどのURLを解決しようとして失敗したか、詳細なログが記録される。これを見ることで「et_fb」以外に必要な除外パラメータが見つかったり、リダイレクトルールの競合を特定できる。
キャッシュプラグインの影響を切り分ける
パーマリンク管理プラグインの設定を見直しても直らないときは、サーバーキャッシュやWordPressのキャッシュプラグインの影響を疑う。ビルダー読み込み時の動的URLがキャッシュから誤ったレスポンスを返す場合があるため、以下の手順で一時的にキャッシュを無効化し、症状が消えるか確認する。
- 使用しているキャッシュプラグイン（WP Super CacheやW3 Total Cacheなど）を一時停止する
- サーバー側でNginxのfastcgi_cacheやApacheのmod_cacheを使っているなら、管理画面経由でキャッシュをクリアするか、一時的に無効にする
- ブラウザのキャッシュもクリアしてからビルダーを再読込する
キャッシュを切った状態で編集が成功したなら、キャッシュプラグインの「除外するURLパターン」に「?et_fb」を含む設定を追加する。たとえば、et_fb というクエリ文字列がついたリクエストはキャッシュしないように設定すれば、運用を続けながら編集機能を維持できる。
どうしても直らないときの代替手段
上記すべてを試してもビルダーが404を返す場合、根本的にプラグインの仕組みがDiviビルダーと相性が悪い可能性がある。以下の対策を順に検討する。
パーマリンクプラグインを別のものに切り替える
カスタムパーマリンク機能自体は別のプラグインでも実現できる。「Custom Permalinks」や「WP Permalink」など、Diviとの競合報告が少ないプラグインを試すことで、リダイレクトの挙動を根本から変えられる。ただし、移行時には既存のURL構造を維持できるか事前にテスト環境で確認する必要がある。
ページ編集時だけパーマリンクを一時的にデフォルトに戻す
最終手段として、編集したい固定ページのパーマリンク設定を一時的に「デフォルト（?p=123）」に変更してビルダーで作業し、公開直前にカスタムパーマリンクに戻す方法もある。ただし、編集のたびに手作業が発生するため、恒常的な運用には向かない。
よくある質問
エラーは「このサイトで重大なエラーが発生しました」ではなく「404 Not Found」と表示されるのはなぜか
Diviビルダーはページをiframeで読み込む際に、サーバーに実際のHTTPリクエストを送る。カスタムパーマリンクのルールがリクエストを処理できないと、WordPressのルーティングが失敗し「ページが見つかりません」という404ステータスが返る。これはPHPの致命的エラーではなく、あくまでもURL解決の失敗が原因だ。
特定の固定ページだけ編集できず、他のカスタムパーマリンクページは問題ないのはなぜか
スラッグの重複やリダイレクトルールの複雑さによって、一部のURLだけ誤って別のルールにマッチしてしまうことがある。全ページに同じカスタム構造を割り当てていても、個別に手動で追加したリダイレクト設定が干渉している場合もあるため、プラグインの「重複チェック」や「リダイレクトリスト」を確認する必要がある。
除外するクエリパラメータに「et_fb」を追加しても直らない場合はどうすればよいか
その場合は、ビルダーが使用する可能性のあるすべてのクエリパラメータを確認する。たとえば「et_fb」「et_pb_preview」「et_fb_iframe」「preview」「preview_id」などが考えられる。開発者ツールのネットワークタブでビルダー起動時に送信されるリクエストを調べ、404になっているURLに含まれるパラメータをすべて除外リストに追加する。
キャッシュプラグインを停止しても404が消えない
サーバーレベルのキャッシュ（VarnishやNginx FastCGI）が影響している可能性がある。レンタルサーバーの管理パネルからキャッシュを手動でクリアするか、サーバー会社のサポートに一時的なキャッシュ停止を依頼して切り分ける。WordPressのキャッシュプラグインだけでは制御できない層があるためだ。
この記事のポイント
- パーマリンク管理プラグインの除外設定に「et_fb」を追加すれば大半のケースで解決する
- 管理者向けのリダイレクト無効化も有効な回避策になる
- キャッシュプラグインやサーバーキャッシュが404を悪化させることがあるため、一時停止して切り分ける
- デバッグモードで詳細なログを確認すれば、除外すべき追加パラメータを特定できる
- 根本的に相性が悪い場合は、パーマリンクプラグインの変更も選択肢に入る
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている