WordPressの__GA_INJ_START__マルウェア感染を完全駆除する手順
WordPress のテーマファイル functions.php に「__GA_INJ_START__」というコメント記述を見つけたら、Google Analytics を装ったマルウェア感染の可能性が高い。完全に駆除するには、functions.php を元に戻すだけでは不十分で、データベースに潜む隠し管理者アカウントの削除と侵入経路の遮断まで行う必要がある。
__GA_INJ_START__マルウェアとは何か
このマルウェアは、テーマの functions.php 内に不正なコードを注入する際、開始位置の目印としてコメント文「__GA_INJ_START__」を書き込む。Google Analytics の計測タグに似せた外見のため、コードをざっと見ただけでは正規のトラッキングコードと勘違いしやすい。
実際に注入されるコードは、Google Analytics とは無関係の永続的なバックドアとして働く。具体的には、不正な管理者アカウントを定期的に生成したり、攻撃者が自由にサイトへ再侵入するための隠し経路を維持する機能を持つ。コード自体が自己修復的に動くこともあり、単に該当部分を削除しても再び書き戻されるケースがある。
感染の典型的な流れは、まず正規の WordPress 管理者アカウントへ何らかの方法でログインし、管理画面内のファイル編集機能やコードスニペット系プラグインを経由して functions.php に到達する。その段階で不正な管理者アカウントを追加し、数日から数週間かけて隠しアカウントを増やした後、最終段階として __GA_INJ_START__ 付きのコードがテーマに注入される。
このデモは侵入から感染完了までの典型的な進行パターンを示している。攻撃者は一度管理者権限を得ると、すぐに目立つ改ざんを行うのではなく、まず隠しアカウントを作って持続的なアクセスを確保するのが特徴だ。
隠し管理者アカウントをどうやって見つけるか
このマルウェアに感染したサイトでは、データベース内に通常では一覧に表示されない形で不正な管理者アカウントが追加されている。管理画面のユーザー一覧に表示されない場合もあるため、phpMyAdmin などでデータベースを直接確認するのが確実だ。
まず wp_users テーブルを開き、ユーザー名に不審な接頭辞が付いていないかを確認する。具体的には sync_agent、cdn_worker、seo_service の後にランダムな英数字が続く形式のアカウントが典型的だ。テーブルプレフィックスが wp_ 以外の場合は、その文字列に読み替えて探す。
次に wp_usermeta テーブルで、該当ユーザー ID に administrator 権限を付与するエントリが存在するかを調べる。さらに wp_options テーブルには __ga_hidden_users、_theme_inject_status、__ga_r_cache という見慣れないキーが保存されていることがある。これらのキーはマルウェアが隠し管理者の一覧を管理するために使う。
サーバーに SSH でログインできる環境なら、ファイルシステム全体を横断検索するのが最も早い。以下のコマンドでマルウェア特有の文字列を探せる。
grep -RniE '__GA_INJ|__ga_hidden_users|__ga_r_cache|_theme_inject_status|sync_agent|cdn_worker|seo_service' .SSH が使えない場合は、FTP でファイルをダウンロードしてエディタの検索機能を使うか、運営中のレンタルサーバーが提供するファイルマネージャの検索機能を活用する。また、WordPress 管理画面から有効化されているプラグイン一覧を確認し、心当たりのないプラグインが増えていないかも必ず調べる。
マルウェアを完全に駆除するにはどうすればいいか
重要なのは、functions.php を置き換えるだけでは駆除できないという点だ。隠し管理者アカウントとバックドアをすべて取り除くまで、攻撃者は何度でも再侵入できる。以下に駆除の全体フローを示す。
このデモは駆除作業の全体像を示している。以下、各ステップの具体的な進め方を詳しく解説する。
バックアップを必ず先に取得する
駆除作業ではデータベースのレコード削除やファイルの書き換えを行うため、操作を誤るとサイトが壊れる恐れがある。作業前にデータベースとファイルの両方を丸ごとバックアップしておく。レンタルサーバーにバックアップ機能が付属している場合も、念のため別の場所にもコピーを保存する。
隠し管理者アカウントをデータベースから削除する
phpMyAdmin などで wp_users テーブルを開き、不審なユーザー名のレコードを特定する。sync_agent、cdn_worker、seo_service にランダムな英数字が付いた形式が典型だが、まったく別の名前で偽装している可能性もある。新規登録した覚えのない管理者権限ユーザーはすべて削除対象だ。
ユーザーを削除する際、wp_usermeta テーブルに残った関連エントリも忘れずに削除する。SQL を直接実行する場合は、該当ユーザー ID を指定して両テーブルからレコードを消す。操作前に必ずバックアップを取り、プレビュー画面で対象レコードを確認してから実行する。
functions.php の不正コードを除去する
テーマの functions.php をエディタで開き、__GA_INJ_START__ から始まるコメントと、それに続くコードブロックを特定する。__GA_INJ_END__ または類似の終了マーカーがある場合は、その範囲全体を削除する。マーカーが無い場合は、不審な関数定義や管理者アカウントを操作するコードを丁寧に確認しながら取り除く。
該当テーマが親テーマなら、修正がテーマ更新で失われないよう子テーマ化を検討する。また、他のテーマファイルや wp-content 直下の PHP ファイルにも同じマーカーが仕込まれている可能性があるため、前述の grep コマンドで全ファイルを横断検索してから作業するのが安全だ。
セッションとパスワードをリセットする
攻撃者が既存のセッションを保持していると、アカウントを消してもアクセスが続く。WordPress の管理画面からユーザー一覧を開き、すべての管理者ユーザーに対して「全てのセッションを破棄」を実行する。さらに全管理者のパスワードを新しいものへ変更する。可能ならメールアドレスも再確認し、見覚えのない転送設定が無いか調べる。
アクセスログから感染時期を特定するにはどうするか
__GA_INJ_START__ が functions.php に現れた日が感染開始日とは限らない。実際には、その数日前から数週間前にかけて攻撃者が隠し管理者アカウントを作り、段階的に足場を固めていたケースが多い。駆除後に再発を防ぐには、感染の起点となった脆弱性や認証情報を特定することが欠かせない。
まずデータベースの wp_users テーブルで、不正な管理者の登録日時を確認する。WordPress はユーザー作成日時を user_registered カラムに記録している。次にサーバーのアクセスログを同じ期間分さかのぼり、wp-login.php へのログイン試行や、admin-ajax.php、theme-editor.php などへの不審なアクセスが無いかを照合する。
攻撃者が最初に正規の管理者アカウントでログインしていた場合、ログには正常なログインとして記録されているため見落としやすい。ログイン元 IP アドレスの突発的な変化、深夜帯のログイン、短時間での連続したファイル編集操作などを手がかりにする。ログの保存期間が短いレンタルサーバーでは、可能な範囲でログ保管期間を延ばしておくと今後の調査に役立つ。
再感染を防ぐには何をすればいいか
駆除が完了しても、侵入経路が残っていれば同じ手口で再び感染する。再発防止には、まず WordPress 本体、テーマ、プラグインを最新版へ更新する。侵入経路として悪用された可能性のあるファイル編集系プラグインやコードスニペット系プラグインは、使用していないなら削除する。
管理者アカウントに対しては二段階認証を有効にし、パスワードは推測されにくい長いものへ変える。管理画面へのアクセスを IP アドレス制限で絞るのも効果的だ。さらに wp-config.php にファイル編集機能を無効化する定数 DISALLOW_FILE_EDIT を追加すると、管理画面からテーマやプラグインのコードを書き換えられる経路を塞げる。
定期的な点検も重要になる。ユーザー一覧に知らない管理者が増えていないか、wp_options に見覚えのないキーが無いか、functions.php などのテーマファイルに不審なコメントが追加されていないかを毎月確認する。可能ならセキュリティプラグインによる定期スキャンを導入し、変更検知の通知を受け取れるようにしておく。
functions.php に __GA_INJ_START__ が注入され、データベースには sync_agent や cdn_worker などの隠し管理者が存在する。攻撃者はいつでも再侵入できる状態。
不正コードが除去され、隠し管理者はデータベースから完全に削除済み。パスワードとセッションもリセットされ、更新も適用されている。
このデモは駆除前後の状態を対比したものだ。感染状態ではマルウェアの目印と隠し管理者が残っているが、駆除後は不正な要素がすべて取り除かれている。
よくある質問
__GA_INJ_START__はGoogle Analyticsの正規コードではないのか
正規の Google Analytics 計測コードにこのようなマーカーは存在しない。__GA_INJ_START__ は不正なコードの開始位置を示す目印で、マルウェアが後からコードを書き戻す際の識別子として使われる。テーマファイルにこの文字列を見つけたら感染を強く疑うべきだ。
隠し管理者アカウントはデータベースのどこを確認すれば見つかるか
wp_users テーブルと wp_usermeta テーブルの両方を確認する。ユーザー名が sync_agent、cdn_worker、seo_service にランダムな英数字が付いた形式なら要注意だ。さらに wp_options テーブルに __ga_hidden_users や _theme_inject_status などの見慣れないキーが無いかも調べる。
セキュリティプラグインを導入しているのに感染したのはなぜか
プラグインが検出できるシグネチャを持たない新種や変種だった、定義が古かった、正規の管理者としてログインしてから活動したため不正ログインと判定されなかった、などの理由が考えられる。プラグインに頼るだけでなく、定期的なユーザー一覧やファイルの目視確認も併用する。
感染後、サイトを公開したまま駆除作業はできるか
推奨されない。攻撃者がバックドアを持っている間、サイトを公開し続けると訪問者の情報が窃取されたり、別の攻撃の踏み台にされたりする恐れがある。可能ならメンテナンスモードに切り替え、バックアップを取ってから作業するのが安全だ。
駆除後にサイトが真っ白になった場合の対処方法は？
デバッグモードを有効にしてエラー内容を特定し、テーマやプラグインを一つずつ有効化して切り分ける。テーマの functions.php を編集した際に記述ミスがあると画面が真っ白になることが多い。感染前のバックアップがあれば、その時点から修復する方が確実な場合もある。
この記事のポイント
- __GA_INJ_START__はGoogle Analyticsを装ったマルウェアの目印
- 隠し管理者アカウントはデータベースを直接確認しないと見落とす
- functions.phpの置き換えだけでは再感染する
- アクセスログを数日〜数週間さかのぼって感染起点を探す
- 駆除後は全パスワード変更とセッションリセットが必須
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
GA4にAI Assistantチャネル追加、ChatGPT流入を可視化
Google Analytics 4（GA4）に2026年5月、生成AIプラットフォームからの流入を可視化する「AI Assistant」チャネルが追加された。ECサイト運営者にとって、ChatGPTやClaudeが商品情報を紹介した結果のトラフィックを正確に把握できる初めての標準機能だ。
この記事ではAI Assistantチャネルの基本的な仕組みと、ECサイトでの具体的な活用法を解説する。設定不要でデータが自動収集される一方、AI Overviewsは含まれないといった注意点もあるため、正しい読み方を押さえておく必要がある。
WooCommerceサイトを運営する中小企業の担当者や、ECのアクセス解析を担当するWeb担にとって、これまで「参照元不明」だったAI経由の流入を可視化できる意味は大きい。
AI Assistantチャネルとは何か
AI Assistantチャネルは、GA4のデフォルトチャネルグループに追加された新しい分類項目だ。ChatGPTやGemini、Claudeといった主要な生成AIプラットフォームからのトラフィックを自動的に判別し、ひとつのチャネルとして集計する。
計測対象となるプラットフォーム
Googleの公式ヘルプドキュメントによると、AI Assistantチャネルに含まれるのは「ChatGPT、Gemini、Claudeといったチャットボット」からのトラフィックだ。具体的な全リストは公開されていないが、主要な生成AIサービスはおおむねカバーされていると見てよい。
ここで重要な注意点がある。Google検索のAI Overviews（旧SGE）やAI Modeは、このチャネルには含まれない。これらは引き続き「Organic Search（オーガニック検索）」チャネルとして報告される。同じAI由来の流入でも、検索エンジン経由かチャットボット経由かで扱いが異なるわけだ。
ECサイトにとっての意味
ECサイト運営者にとって、AIチャットボット経由の流入は従来のSEOとは異なる文脈で発生する。たとえば「予算3万円で買えるおすすめのワイヤレスイヤホン」といった自然言語の質問に対し、ChatGPTが具体的な製品名とURLを提示するケースだ。この流入経路を正確に把握できれば、AIに自社商品がどのような文脈で言及されているかを分析できる。
AIトラフィックの確認手順
GA4でAI Assistantチャネルのデータを見るための手順を解説する。初期設定は不要で、GA4が自動的に分類を開始しているため、すぐに確認できる。WooCommerceサイトでGA4を導入済みであれば、追加のコード実装も必要ない。
トラフィック全体像の把握
まずはECサイト全体で、AI経由の流入がどの程度あるのかを確認する。GA4管理画面で「レポート」→「集客」→「トラフィック獲得」の順に開き、「セッションのデフォルトチャネルグループ」ディメンションを選択する。ここで「AI Assistant」という行が表示されていれば、すでにAI経由のトラフィックが発生している。
表示される指標はエンゲージメント率、セッションあたりのイベント数、平均セッション時間などだ。これらの数字をOrganic Searchチャネルと比較することで、AI経由ユーザーの行動特性が見えてくる。
ランディングページの特定
AIがどの商品ページを参照しているのかを特定するには、「レポート」→「エンゲージメント」→「ページとスクリーン」を開く。画面上部の「フィルタを追加」から、以下の条件で絞り込む。
- ディメンション：セッションのデフォルトチャネルグループ
- マッチタイプ：完全一致
- 値：AI Assistant
このフィルタを適用すると、AIプラットフォームからのクリックが多いページが上位に表示される。WooCommerceの商品ページやカテゴリページのうち、どのURLがAIに評価されているかを把握できるはずだ。
AIトラフィックと他チャネルの比較
同じ「ページとスクリーン」レポートで「比較を追加」ボタンを使うと、AI経由とオーガニック検索経由のトラフィックを横並びで比較できる。Practical Ecommerceの記事著者Carlo Daniele氏の検証によれば、オーガニック検索で上位のページとAI Assistant経由で上位のページは重複しなかったという。
これはEC担当者にとって示唆が大きい。Google検索で上位表示されている商品と、AIがユーザーに推薦する商品が異なる可能性があるためだ。AI経由の流入を伸ばすには、従来のSEO対策とは別のアプローチが必要になるかもしれない。
正規表現を使った詳細なソース分析
AI Assistantチャネルは便利だが、どのAIプラットフォームからの流入なのかまでは分解できない。ChatGPT経由なのかClaude経由なのかを個別に知りたい場合は、正規表現（regex）を使ったフィルタリングが有効だ。
設定手順
「レポート」→「集客」→「トラフィック獲得」で、グラフ上部の「フィルタを追加」をクリックする。ディメンションに「セッションの参照元/メディア」、マッチタイプに「matches regex」を選択し、以下の正規表現を値欄に貼り付ける。
.*chatgpt.com.*|.*perplexity.*|.*edgepilot.*|.*copilot.microsoft.com.*|.*openai.com.*|.*gemini.google.com.*|.*claude.ai.*|.*grok.x.ai.*このフィルタを適用すると、AIプラットフォームごとのセッション数やエンゲージメント指標を一覧できる。ただしPractical Ecommerceの記事でも指摘されているように、AI Assistantチャネルとの間にわずかなデータの不一致が生じる場合がある。これは「Organic」や「(not set)」と分類される一部のAIトラフィックが正規表現では拾えていないためだ。
WooCommerceサイトでの活用ポイント
正規表現フィルタを使えば、たとえば「ChatGPT経由では商品Aへの流入が多いが、Claude経由では商品Bが多い」といったプラットフォーム別の傾向を把握できる。AIによって得意とする商品カテゴリや、参照する情報ソースが異なる可能性があるためだ。
このデータをもとに、特定のAIプラットフォームで自社商品が言及されやすいコンテンツを強化するといった戦略が考えられる。Semrushなどの外部ツールで、どのようなプロンプトがAIの引用を生んでいるのかを調査するのも有効だ。
EC担当者が今すぐやるべき3つのアクション
AI Assistantチャネルの登場を受けて、ECサイトのアクセス解析にすぐに組み込むべき施策を整理する。いずれも追加コストなしで今すぐ始められるものばかりだ。
特にアクション2は重要だ。AIは商品スペックや口コミ、価格情報を総合的に評価して回答を生成する。商品ページの情報が不十分だとAIに引用されにくくなるため、商品説明の充実や構造化データの実装はAI時代のECに不可欠な施策といえる。
AIトラフィックとECの未来
GA4のAI Assistantチャネルは、ECにとって「AI経由の流入」という新たな指標を提供し始めた。現時点ではまだAIトラフィックの絶対量は小さいかもしれないが、ChatGPTやClaudeがデフォルトでWeb検索を行うようになり、AIを経由した商品発見は確実に増えていく。
AI OverviewsがOrganic Searchに含まれるという設計からもわかるように、GoogleはAIを「検索の拡張」と位置づけている。EC担当者はSEOとAI最適化を別物ではなく、同じ「検索体験」の両輪として捉えるべきフェーズに入ったといえる。
WooCommerceサイトであれば、GA4の標準機能だけでAIトラフィックの可視化は十分に可能だ。まずはデータを取得し、AIが自社商品をどう評価しているのかを把握することから始めてほしい。
この記事のポイント
- GA4に2026年5月追加のAI Assistantチャネルで、ChatGPTやClaudeなど生成AIからの流入が自動分類される
- AI OverviewsやAI Modeは含まれず、これらはOrganic Searchとして報告される点に注意が必要
- ページとスクリーンレポートでAI経由ランディングページを特定し、商品情報の最適化に活かせる
- 正規表現フィルタでAIプラットフォーム別の傾向を把握し、より細かな流入分析が可能
- AIトラフィックはSEOと地続きの指標であり、商品ページの情報充実がAIからの引用を増やす鍵になる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Bricks Builderのカスタムコードで同意管理プラグインが効かない時の直し方
Kanslieri Cookie ConsentでGoogle AnalyticsやMicrosoft Clarityを自動ブロックする設定にしているのに、シークレットウィンドウで計測タグが動いてしまう原因は、Bricks Builderのカスタムコード欄に直書きしたスクリプトを、同意管理プラグインが認識できない仕組みにある。スクリプトを手動ブロック用の属性に書き換えるか、WordPress標準のエンキュー方式に差し替えれば、同意前の計測を確実に止められる。
なぜBricksカスタムコードの計測タグがブロックされないのか
Kanslieri Cookie Consentをはじめ、多くのCookie同意管理プラグインは、WordPressの標準機能であるwp_enqueue_scriptで読み込まれたスクリプトをフックして制御する設計になっている。スクリプトのハンドル名を解析し、同意が得られるまで実行を自動的に保留する仕組みだ。
一方、Bricks Builderの「Settings → Custom Code → Header Scripts」に貼り付けたコードは、テーマがwp_headアクションを通じてページのソースにそのまま埋め込む。プラグイン側からは「PHPで読み込まれたスクリプト」として認識されず、単なるインラインHTML扱いになる。その結果、管理画面のScript Blockingページに「Google Analyticsは自動ブロック対象」と表示されていても、実際にはブロックが効かない。
Google Analyticsの_gaや_gidといったCookieがシークレットウィンドウで生成され、/g/collectへのリクエストが送信され、page_viewやscrollイベントが記録されるのはこのためだ。Microsoft Clarityも同様に、カスタムコード欄経由では自動ブロックの対象外になる。
同意前のトラッキングを防ぐ具体的な修正手順
Kanslieri Cookie Consentの自動ブロックが効かない場合でも、手動ブロックの仕組みを利用すれば計測を止められる。修正方法は大きく2つある。すでにカスタムコードを使っているなら、スクリプトタグに手動ブロック用の属性を追加するのが最も手早い。
手動ブロック用のtype属性に書き換える方法
Kanslieri Cookie Consentは、スクリプトタグのtype属性をtext/plainに書き換えることで、同意があるまでスクリプトの実行を止める仕組みを持っている。同意が得られた時点で、プラグインがtypeをtext/javascriptに戻して実行する。Bricksのカスタムコード欄に貼ってあるGoogle AnalyticsとMicrosoft Clarityのコードを、次のように修正する。
<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'G-XXXXXXXXXX');
</script><script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX" type="text/plain" data-cookiecategory="analytics"></script>
<script type="text/plain" data-cookiecategory="analytics">
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'G-XXXXXXXXXX');
</script>ポイントは各<script>タグにtype="text/plain"とdata-cookiecategory="analytics"を追加することだ。data-cookiecategoryの値は、Kanslieri Cookie Consentの設定で該当スクリプトを割り当てたいカテゴリ名と一致させる。Google Analyticsならanalytics、Microsoft Clarityも同じ分析カテゴリで構わない。複数カテゴリにまたがる場合はdata-cookiecategory="analytics, marketing"のようにカンマ区切りで指定できる。
WordPressのエンキュー方式に切り替える方法
より根本的な解決策として、カスタムコード欄ではなく子テーマのfunctions.phpからwp_enqueue_scriptでスクリプトを読み込む方法もある。この方法なら、Kanslieri Cookie Consentの自動ブロック機能が確実に働く。
function my_google_analytics_script() {
wp_enqueue_script(
'google-analytics',
'https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX',
array(),
null,
false
);
wp_add_inline_script(
'google-analytics',
"window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'G-XXXXXXXXXX');"
);
}
add_action('wp_enqueue_scripts', 'my_google_analytics_script');このコードを子テーマのfunctions.phpに追加したら、Bricksのカスタムコード欄から該当のコードを削除する。Kanslieri Cookie ConsentのScript BlockingページでGoogle Analyticsが認識されるようになり、同意前のトラッキングが自動的にブロックされる。
手動ブロックが正しく動くか確認する手順
DevToolsのNetworkタブでは、フィルタにcollectやclarityと入力すると該当リクエストを素早く見つけられる。同意前にこれらのリクエストが記録されていなければ、ブロックは正しく機能している。その状態でCookieバナーの「同意する」をクリックし、直後にリクエストが走り始めれば、同意後の計測も正常に動作していることになる。
Bricks Builderのキャッシュが有効になっている場合は、修正後にかならずキャッシュをクリアする。Bricksの管理画面から「Bricks → Settings → Performance」でキャッシュを削除したうえで、サーバー側のキャッシュやCDNがある場合も同時にパージする。キャッシュが残っていると修正前のスクリプトが配信され続けてしまうため、確認作業の前に忘れずに行う必要がある。
よくある質問
他のページビルダー（ElementorやDivi）でも同じ問題は起きるのか
起きる可能性が高い。Elementorのカスタムコード機能やDiviの統合設定から追加したスクリプトも、テーマ側で直接HTMLに出力されるため、同意管理プラグインの自動ブロック対象外になりやすい。同じ手動ブロックの手法が適用できる。ただし、Elementorの場合はwp_enqueue_script方式に切り替える方が推奨される場面が多い。カスタムコード欄にスクリプトを置く運用は、同意管理の観点からは避けるのが無難だ。
Kanslieri Cookie Consentの自動ブロックが効かないスクリプトを見分ける方法はあるか
管理画面の「Script Blocking」ページに一覧表示されるスクリプトは、プラグインが自動検出できたものだけだ。ここに表示されていないGoogle AnalyticsやClarityのスクリプトは自動ブロック対象外と判断してよい。また、シークレットウィンドウで実際にCookieが生成されるか、DevToolsでネットワークリクエストが発生するかを確認すれば、ブロックの可否を実動作で検証できる。
手動ブロックに書き換えたスクリプトが、同意後も動かない場合はどうするのか
Kanslieri Cookie Consentの設定で、data-cookiecategoryに指定したカテゴリが有効になっているか確認する。「Cookie Settings」画面で該当カテゴリのトグルがオンになっていること、同意バナーでユーザーがそのカテゴリを許可できる選択肢が表示されていることをチェックする。カテゴリ名にタイプミスがあると、プラグインがスクリプトをどのカテゴリに紐づけてよいか判断できず、同意後も実行されない。
Bricksのカスタムコードは使わず、Google Site KitプラグインでGA4を入れるとどうなるか
Site Kitはwp_enqueue_scriptを使ってGoogle Analyticsタグを読み込むため、Kanslieri Cookie Consentの自動ブロック機能が正常に働く。手動ブロックの書き換えは不要になる。すでにカスタムコードでGA4を入れている場合は、そのコードを削除してSite Kitに移行するだけで、同意管理の課題が解決する。Clarityも公式プラグインを使えば同様だ。
この記事のポイント
- Bricks Builderのカスタムコード欄は同意管理プラグインの自動ブロック対象外になる
- スクリプトタグにtype="text/plain"とdata-cookiecategoryを追加して手動ブロックに対応させる
- wp_enqueue_scriptで読み込めば自動ブロックが有効になり修正不要
- 修正後はシークレットウィンドウとDevToolsでCookieとリクエストを検証する
- キャッシュクリアを忘れると修正が反映されない
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている