OptinMonsterなど4プラグインのサプライチェーン攻撃、不正管理者を確認する手順
OptinMonster、TrustPulse、PushEngage、Uncanny Automator のいずれかのプラグインを導入している場合、ただちに管理画面の全ユーザー一覧を確認し、身に覚えのない管理者アカウントが作成されていないか点検する必要がある。これらのプラグインに使用されている CDN スクリプトが改ざんされ、悪意ある管理者を自動生成するサプライチェーン攻撃が 2026 年 6 月に確認された。
何が起きたのか 今回のサプライチェーン攻撃の仕組み
攻撃者はプラグインのソースコードそのものを改変したわけではなく、各プラグインが配信に利用している外部 CDN 上のスクリプトファイルに細工を施した。このため、プラグイン自体のバージョンアップや通常のマルウェアスキャンでは異常を検知しにくいのが特徴だ。
改ざんされたスクリプトは、サイトのフロントエンドに読み込まれる形で実行され、裏側で WordPress のユーザー登録 API を突いて新規の管理者アカウントを作成する。攻撃者がすでに管理者権限を取得している場合、サイトの改ざんや情報の窃取が自由に行える極めて危険な状態となる。
国内の WordPress サイトでも、マーケティングツールとして該当プラグインを導入しているケースは少なくない。攻撃が表面化した時点で、該当プラグインの開発元はすでに CDN 側の改ざんを修正し、侵害された可能性のある顧客への通知を進めているが、すべてのサイト運営者が自らチェックを行うことが被害の深刻化を防ぐうえで決定的に重要だ。
サイトに悪意ある管理者は存在しない。
サイト訪問時に不正スクリプトが実行され、未知の管理者アカウントが自動生成される。
自分は対象か 影響を受けるプラグインを導入していないか確認する
今回のサプライチェーン攻撃の対象として報告されたのは次の 4 製品だ。いずれか 1 つでも導入している場合は、影響を受けた可能性を前提に全手順を実行する必要がある。
- OptinMonster（オプティンモンスター）
- TrustPulse（トラストパルス）
- PushEngage（プッシュエンゲージ）
- Uncanny Automator（アンキャニーオートメーター）
プラグイン一覧ページでこれらの名称を検索すれば、導入の有無はすぐに判別できる。ただし、テーマの functions.php に直接コードを埋め込んでいる場合や、カスタム実装で CDN スクリプトを読み込んでいる場合はプラグイン管理画面では発見できないため、サイトのソースコードやタグマネージャーの設定も併せて確認するとより確実だ。
不正な管理者アカウントを特定して削除する手順
まず管理画面の「ユーザー」→「ユーザー一覧」を開き、管理者権限を持つアカウントをすべて確認する。身に覚えのない管理者アカウントが存在する場合は、そのアカウントが攻撃によって作成された可能性が極めて高い。
削除時に「投稿の所有権」をどうするか
不正な管理者を削除する際、WordPress はそのユーザーが作成した投稿の帰属先を尋ねてくる。該当ユーザーが攻撃者である場合、そのアカウントが作成した投稿そのものも悪意あるコンテンツであることが多いため、すべて「削除」を選択して問題ない。もし誤って残す必要がある場合のみ、正当な管理者に帰属を変更する。
不正な管理者アカウントがゼロでも油断できない理由
攻撃スクリプトは任意のタイミングで管理者を作成する仕組みになっている。現在のユーザー一覧に不審点がなくても、改ざんされた CDN スクリプトが過去に読み込まれたことがあれば、攻撃者がすでにアクセストークンや認証情報を窃取している可能性を排除できない。必ず後述の予防措置まで実行する必要がある。
感染後のサイトを安全な状態に戻すために今すぐやるべきこと
該当プラグインを完全に削除して再インストールする
単なる無効化では不十分だ。該当プラグインを一度完全に削除し、公式リポジトリまたは開発元から最新版をダウンロードして再インストールする。これにより、仮に攻撃者がプラグインの管理画面内に保存していた設定値や隠しコードを仕込んでいたとしても、完全に除去できる。
全ユーザーのパスワードをリセットし多要素認証を有効にする
攻撃者がすでに正当なユーザーのログイン情報を盗んでいる可能性を想定し、サイトの全ユーザー（特に管理者・編集者権限）のパスワードを変更する。加えて多要素認証（二段階認証）をただちに有効にし、パスワード単体ではログインできない設定に切り替えることが再侵入の防止に直結する。
WP ソルトキーを強制的に無効化する
wp-config.php に定義されている認証用のソルトキー（AUTH_KEY、SECURE_AUTH_KEY、LOGGED_IN_KEY、NONCE_KEY とそれぞれの SALT）をすべて新しい値に置き換える。これで既存のすべてのログインセッションが即座に無効になり、攻撃者が盗んだクッキーではアクセスできなくなる。WordPress の公式ソルト生成ツールを使えば、ランダムな値がすぐに発行できる。
.htaccess や wp-config.php に仕込まれたバックドアを点検する
管理者権限を取得した攻撃者は、テーマファイルやプラグインファイルを編集してバックドアを仕込むことが多い。特に functions.php や wp-config.php、.htaccess に不自然なコードが追記されていないかを FTP またはサーバー管理画面のファイルマネージャーで直接確認する。見慣れない base64 デコード処理や eval 関数を含むコード、不明な外部 URL へのリクエストがあれば攻撃の痕跡だ。
なぜ通常のウイルススキャンでは検知されなかったのか
一般的なセキュリティプラグインは、サーバー上の PHP ファイルやデータベースの不審なパターンをスキャンする。しかし今回の攻撃は、問題のあるコードがサイト外部の CDN 上にあり、ブラウザの JavaScript 実行を通じて攻撃が成立する仕組みだった。サーバー側のファイルに痕跡が残らないため、従来型のマルウェアスキャンでは検出が困難だった。
この手口が示しているのは、外部リソースに依存するプラグインは、その配信網が侵害された場合にプラグイン本体の安全性とは無関係に危険になりうるという現実だ。CDN から読み込まれるスクリプトに対しては、Subresource Integrity（SRI）属性による改ざん検知が有効だが、これを実装しているプラグインは現状ほとんど存在しないことも今回の問題を深刻にした。
再発を防ぐために導入すべき具体的な対策
外部 CDN スクリプトを監視する仕組みを整える
すべての外部スクリプトをやみくもに拒否するのは現実的ではないが、コンテンツセキュリティポリシー（CSP）ヘッダーを適切に設定することで、どの CDN からのスクリプト実行を許可するかを明示的に制御できる。許可リストにないドメインからのスクリプトはブラウザ側でブロックされるため、未知の改ざんが発生した場合の被害を抑える障壁になる。
管理者ユーザーの監査ログを定期的に確認する
新しい管理者の追加や権限変更を記録する監査ログプラグインを導入しておけば、今回のように見知らぬアカウントが作成されたときに即座に気づける。攻撃が CDN 経由で行われたとしても、サーバー側でユーザーが作成される瞬間をログに残すことができるため、異常検知の有効な補助線になる。
利用プラグインの外部依存関係を定期的に見直す
導入済みのすべてのプラグインが、どの外部ドメインに対してリクエストを送っているかを定期的に棚卸しする習慣をつけると、今回のようなサプライチェーンリスクの芽を早期に見つけやすくなる。プラグインがバックグラウンドで読み込んでいる CDN スクリプトや API エンドポイントを把握していれば、問題発生時に影響範囲を素早く特定できる。
よくある質問
該当プラグインを無効にしただけで安全といえるか
安全とはいえない。改ざんされたスクリプトが過去に読み込まれた時点ですでに不正な管理者が作成されている可能性がある。無効化では既存の被害は解消されず、削除と再インストール、およびユーザー一覧の精査が必須になる。
不正な管理者が見つからなかった場合でも何かすべきことはあるか
全ユーザーのパスワードリセットとソルトキーの変更は必ず実行する。改ざんスクリプトが認証クッキーやアクセストークンを窃取していた場合、攻撃者は管理者アカウントを作らずとも正当なユーザーとしてログインできる可能性があるためだ。
これらのプラグインは今後も使い続けても大丈夫か
各開発元はすでに CDN の改ざんを修正し、再発防止策を強化している。しかしどのプラグインでも外部依存がある以上、同様のリスクをゼロにすることは不可能だ。使用を継続する場合は、この記事で述べた監視と予防の仕組みを併せて導入することが前提になる。
WordPress 本体や他の無関係なプラグインまで影響を受けるのか
今回の攻撃は対象プラグインの CDN スクリプト経由でのみ実行された。ただし管理者権限を奪取された後は、WordPress 本体や他のプラグインを含め、サイト全体が改ざん対象になりうる。該当プラグインを使用していた場合は、サイト全体のファイル整合性チェックを併せて行うとよい。
この記事のポイント
- OptinMonster、TrustPulse、PushEngage、Uncanny Automator 利用者は要緊急対応
- 不正な管理者アカウントの有無を「ユーザー一覧」で即座に確認する
- 該当プラグインの完全削除と再インストールで痕跡を除去する
- 全ユーザーパスワードのリセットとソルトキー変更が防御の基本線
- CSP 設定と管理者監査ログで将来の類似攻撃に備える
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
JavaScriptがログアウト時に動かない原因と直し方
管理画面にログインしているときだけ JavaScript が動き、ログアウトすると止まる。この現象の原因は、ほぼ「スクリプトの読み込み順序」と「キャッシュ・最適化プラグインの挙動」のどちらか、あるいは両方の組み合わせだ。ログイン時は管理バー用のスクリプト等が読み込まれるため依存関係が偶然成立し、ログアウト時にそれが外れてエラーになるケースが多い。
ログアウト時だけ JavaScript が動かなくなる仕組み
このデモは典型的な依存関係の崩れを示している。ログイン中は WordPress が管理バーやフッターに jQuery を読み込むため、その後に記述されたスクリプトが偶然動く。ログアウトすると jQuery が存在せず、$ is not defined や jQuery is not defined といったエラーで止まる。
HTML ブロックに直接書いた JavaScript が招く問題
WordPress の「カスタム HTML」ブロックに <script> タグを直書きする方法は、一見手軽だが制御が難しい。出力される位置がテーマやブロック配置に依存し、jQuery などのライブラリより前に実行されれば必ず失敗する。さらにインラインスクリプトは多くのキャッシュプラグインで最適化対象から外されたり、結合・遅延読み込みの対象にならず、ログアウト時だけ二重に不利な状況を生む。
HTML ブロック直書きスクリプトの3つの弱点
- 読み込み順序を制御できない（テーマの render 順に依存する）
- jQuery の依存関係を WordPress に伝えられない
- キャッシュ・圧縮プラグインがスクリプトとして認識しない場合がある
ログアウト時でも動くようにする正しい組み込み手順
原則は「JavaScript は HTML ブロックに直書きせず、WordPress の仕組み（wp_enqueue_script）で読み込む」ことだ。すでに直書きで動いているものを移行するには、以下の手順で進める。
STEP 1 既存の script タグを外部ファイルに移す
HTML ブロック内の <script>〜</script> 部分だけを抜き出し、子テーマのフォルダ内に testimonial-slider.js のような名前で保存する。<script> タグそのものは不要で、中身のコードだけを移す。HTML ブロックにはスライダーの構造（ul や div のマークアップ）だけを残す。
STEP 2 functions.php で安全に読み込む
子テーマの functions.php に以下のコードを追加する。管理画面ではなくフロントエンドだけに読み込ませるために wp_enqueue_scripts フックを使う。依存関係として jquery を指定すれば、WordPress 本体の jQuery が先に読み込まれてから実行される。
function my_testimonial_slider_script() {
wp_enqueue_script(
'testimonial-slider',
get_stylesheet_directory_uri() . '/testimonial-slider.js',
array('jquery'),
'1.0.0',
true
);
}
add_action('wp_enqueue_scripts', 'my_testimonial_slider_script');最後の引数 true はフッターで読み込む指定だ。スライダーの DOM 要素が本文中に存在する場合はフッター読み込みで問題ない。もしスライダーを本文より前に実行する必要があるなら false にしてヘッダーで読ませるが、多くのケースではフッターで十分だ。
STEP 3 $ の衝突を防ぐ
WordPress の jQuery は noConflict モードで動作しているため、$ がそのまま使えない環境がある。古いコードを流用している場合は $ is not a function エラーが起きやすい。回避策として、外部ファイル全体を即時実行関数で囲み、引数で $ を受け取る記法が安全だ。
(function($) {
$(document).ready(function() {
// ここにスライダーのコード
});
})(jQuery);STEP 4 キャッシュプラグインでスクリプトを除外する
ここまで対応しても直らない場合、キャッシュや最適化プラグインが原因の可能性が高い。ログアウト時はページキャッシュが有効になり、スクリプトの遅延読み込みや結合が適用される。自前の testimonial-slider.js をこれらの処理から除外する必要がある。
プラグインの設定画面で「スクリプトの除外」「遅延読み込みの除外」といった項目を探し、testimonial-slider（ハンドル名）または testimonial-slider.js（ファイル名の一部）を指定する。除外後は必ずキャッシュを全削除してからログアウト状態で確認する。
Elementor のフックやテーマのアクションフックを使った場合の注意点
テーマ付属のフック（GeneratePress の Element など）に HTML ブロックごと差し込む方法も考えられるが、根本的にはスクリプトの読み込み順序問題は同じだ。フックで出力する位置を変えても、jQuery より前に呼ばれるリスクは残る。フックを使う場合でも、スクリプト部分は wp_enqueue_script に任せ、フックにはマークアップだけを出力する形が堅実だ。
Elementor Pro の「カスタムコード」機能を使っているなら、その中に script タグを書くのではなく、同様に子テーマのファイルとして切り出してハンドル登録するほうが制御できる。どうしても直書きが必要なら、カスタムコードの「場所」設定を「本文の終了タグ直前」にし、さらにコード内で jQuery を明示的に使う（$ を使わない）ことでエラーを減らせる。
よくある質問
コンソールに「$ is not defined」と出るがどう直せばいいか
jQuery が読み込まれる前に $ を使っているか、noConflict モードで $ が無効になっている。即時関数で (function($) { ... })(jQuery); とラップし、すべての $ をこのスコープ内に収めれば解決する。
functions.php を編集せずに直す方法はあるか
「WPCode」などのコードスニペット管理プラグインを使えば、管理画面から wp_enqueue_script のコードを登録できる。functions.php を直接触りたくない場合の現実的な代替手段だ。スニペットの実行場所を「フロントエンドのみ」に設定するのを忘れないようにする。
キャッシュを削除しても直らないのはなぜか
ブラウザキャッシュだけを消していて、サーバー側のページキャッシュや CDN キャッシュが残っているケースが多い。WordPress のキャッシュプラグインの「すべてのキャッシュを削除」を実行し、さらに CDN を使っている場合はその管理画面からもパージする。シークレットウィンドウで確認するとブラウザキャッシュの影響を除外できる。
スライダーのマークアップだけ残して script を外したら表示が消えた
新しく作った JS ファイルが正しく読み込まれていない。ブラウザの開発者ツールの「ネットワーク」タブで testimonial-slider.js が 200 番で返っているか確認する。404 ならパスが間違っている。読み込まれているのに動かない場合は、コンソールに別のエラーが出ていないか調べる。
この記事のポイント
- ログアウト時だけ JavaScript が動かない原因は、jQuery の依存切れとキャッシュ最適化の複合
- HTML ブロックへの script 直書きは読み込み順序を制御できず、根本対策にならない
- wp_enqueue_script で jQuery 依存を明示し、外部ファイルとして切り出すのが正攻法
- 即時関数で $ の衝突を防ぎ、キャッシュプラグインでは独自スクリプトを除外対象に追加する
- Elementor やテーマフックを使う場合も、スクリプトだけは enqueue に任せる設計が堅実
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
特定商品ブロックを設置した固定ページでfatal errorが発生する問題の直し方
特定商品ブロックを固定ページに配置したときに「Uncaught Error Call to a member function get_id() on null」というfatal errorが表示されるのは、PreCart for WooCommerce のバグが原因だ。プラグインを最新バージョンへ更新するか、functions.php へ一時的な修正コードを追加すれば直る。
なぜ固定ページ上の商品ブロックで fatal error が起こるのか
PreCart は WooCommerce の商品情報を扱うフィルターフック（woocommerce_product_add_to_cart_text など）にコールバック関数を登録し、その中で global $product から商品オブジェクトを取得して $product->get_id() を呼び出している。しかし、ブロックエディタで「特定商品」ブロックを通常の固定ページに配置すると、WooCommerce のブロック表示パイプラインではグローバル変数 $product が null のままフィルターが走るケースがある。PreCart のコードには null チェックがないため、null に対して get_id() を呼び出してしまい、致命的なエラーでページ全体が落ちる。
$product が null のままコールバックが実行される$product->get_id() で致命的エラー発生（画面が真っ白になる）影響を受けるメソッドは change_add_to_cart_text()、display_pre_order_messgae()、display_pre_order_badge() など、いずれも保護コードがない。WooCommerce の商品ブロックを店舗ページ以外で使っているサイトはすべてこの問題に遭遇し得る。
PreCart を更新してエラーを解消する手順
開発元はこの問題を認識しており、すでに修正アップデートがリリースされている。まずは管理画面からプラグインを最新版に上げるのが最も安全で確実な対処法だ。
更新通知が表示されない場合
「ダッシュボード」→「更新」から更新の再確認を行うか、PreCart のプラグインページで一度「プラグインを削除」→ 公式リポジトリから再インストールする方法もある。ただしこの場合、設定がリセットされる可能性があるため、事前に PreCart の設定をメモしておくかエクスポート機能があれば使っておくと安心だ。
functions.php で null チェックを追加して一時的に対処する方法
どうしてもすぐにプラグインを更新できない場合や、何らかの理由で更新後に問題が残る場合は、テーマの functions.php にフックを追加して一時的にエラーを回避できる。
/**
* PreCart の null チェック不足による fatal error を回避（一時的対応）
*/
add_filter( 'woocommerce_product_add_to_cart_text', function( $text, $product ) {
if ( ! $product || ! is_a( $product, 'WC_Product' ) ) {
return $text;
}
// 以下は原本の処理が走るが、早期リターンで保護
return $text;
}, 1, 2 );
add_filter( 'woocommerce_single_product_summary', function() {
global $product;
if ( ! $product || ! is_a( $product, 'WC_Product' ) ) {
return;
}
// 同様に早期リターン
}, 1 );上記のコードは PreCart が使っているのと同じフックに、より優先度の高いコールバック（優先度 1）で null チェックを追加し、商品オブジェクトが存在しないときは処理を打ち切る仕組みだ。PreCart のフィルターよりも先に実行されるため、致命的エラーに至る前に関数を抜けられる。
$product->get_id();
$product->get_id();
functions.php 編集時の注意点
子テーマを使っていない場合、テーマ更新で修正が上書きされるリスクがある。必ず子テーマの functions.php にコードを追加するか、Code Snippets プラグインでコードを管理するのが望ましい。また、この一時対応はあくまで応急処置であり、PreCart の他の機能が正常に動作しない可能性もゼロではない。早めに公式アップデートを適用して、追加コードは削除する。
手動修正後に確認しておきたいポイント
- 一時的なコードを追加した後、サイトの表示速度やエラーログに変化がないか定期的にチェックする
- PreCart の機能（カート追加テキストの変更や予約注文バッジなど）が期待どおり動作しているかテストする
- PHP のエラーログを確認し、別の箇所で同様の null 参照エラーが隠れていないか調べる
- サイト全体のキャッシュをクリアし、CDN を利用している場合は CDN キャッシュも破棄する
- PreCart の更新が確認できたら必ずプラグインを最新版に上げ、追加コードを削除する
よくある質問
PreCart 以外のプラグインでも同じように商品ブロックでエラーが出ることはありますか
ある。WooCommerce のブロックを通常ページで使うと、$product グローバルを正しく取り扱っていない他の拡張プラグインでも同様の null 参照エラーが起きるケースが報告されている。エラーの文面に別のプラグイン名が含まれている場合は、そちらの開発元へ報告しつつ、同じように functions.php で早期リターンを追加すれば応急回避できることが多い。
WooCommerce の商品ブロックを固定ページで使うこと自体は問題ないのでしょうか
WooCommerce のブロックは基本的に店舗ページや商品ページで使うことを想定しているが、WordPress の標準ブロックとして技術的にはどの投稿タイプでも利用できる。プラグインがグローバル変数の有無を適切にハンドリングしていれば固定ページで使っても問題は起きない。ただ、テーマやプラグインが認めるまで、動作確認は入念に行ったほうがよい。
エラーメッセージが表示されずに画面が真っ白になる場合はどうすればよいですか
WordPress が致命的エラーを表示しない設定（WP_DEBUG が false）のときは、管理画面のメールに送られる復旧モード用のリンクを探すか、サーバーの PHP エラーログを確認する。wp-config.php で define('WP_DEBUG', true); を一時的に有効にすれば、画面上にエラー詳細が表示され、原因を特定しやすくなる。なお、本番環境ではデバッグモードをすぐに無効に戻すこと。
管理画面にも入れなくなってしまった場合はどうすれば直りますか
FTP またはレンタルサーバーのファイルマネージャーで /wp-content/plugins/precart/ ディレクトリの名前を一時的に変更（例：precart_deactivated）すれば、プラグインが無効化されて管理画面に再ログインできる。その後、前述の更新や一時コードで対処し、ディレクトリ名を元に戻す。
この記事のポイント
- 固定ページに WooCommerce 商品ブロックを配置したときの fatal error は PreCart の null チェック不足が原因
- 解決策は PreCart プラグインの最新版への更新が最も安全で確実
- すぐに更新できない場合は、functions.php にフックで早期リターンを追加すれば応急回避できる
- functions.php 編集は子テーマで行い、アップデート後は必ず追加コードを削除する
- 管理画面に入れなくなったら FTP でプラグインフォルダ名を変更し無効化する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
AI EngineとJetpackが衝突してGeminiが使えない時の解決策
AI Engine プラグインをバージョン 3.5.5 以降にアップデートすれば、この問題は即座に解決する。根本原因は Jetpack が REST API に追加する整数型 enum フィールドを、Google Gemini がツール定義で拒否していたことにある。AI Engine の開発者がこのスキーマ生成ロジックを修正し、文字列型以外の enum を自動除去するようになった。
どのようなエラーが発生するのか
Desktop Commander で AI Engine を MCP サーバーとして管理モードで接続し、AI モデルに Google Gemini を指定すると、次のようなエラーで通信が失敗する。
「GenerateContentRequest.tools[0].function_declarations[30].parameters.properties[jetpack_publicize_connections].items.properties[status].enum: only allowed for STRING type」という趣旨のエラーが返る。翻訳すると「enum は STRING 型にしか使えない」という厳格な制約に違反した形だ。
管理画面では具体的に「AI Engine が Gemini API からの応答に失敗しました」といった形で表示され、チャットが開始できないか、途中で止まる。管理モードでなければ発生しないエラーだ。
なぜ Jetpack と AI Engine が衝突するのか
核心は Google Gemini API の「ツール定義」に対する極めて厳格なバリデーションにある。Gemini は利用可能な関数のパラメータをスキーマで受け取るが、enum（許容値の固定リスト）を使う場合、そのデータ型を必ず文字列にしなければならない。
一方 Jetpack は、WordPress の投稿作成や更新時に使われる REST API エンドポイントへ、ソーシャルメディア連携用のフィールドを動的に追加している。その中の jetpack_publicize_connections フィールドには status というパラメータがあり、Jetpack はこれを整数型の enum（[0, 1]）として定義している。
AI Engine が WordPress のスキーマ全体を走査して Gemini 向けのツールリストを組み立てる際、この整数型 enum をそのまま継承してしまう。その結果、Gemini API がリクエスト全体を「400 Bad Request」ではねつける流れだ。
読み取り専用モードならば投稿作成系のツールが含まれないため、このエラーは発生しない。管理モードで書き込み権限を付与する場合に限って表面化する。
AI Engine 3.5.5 以降へのアップデートで恒久修正する
AI Engine の開発者によって、バージョン 3.5.5 で根本的な修正が加えられた。ツールスキーマを作成する際、文字列型以外の enum 定義を自動的に除去する処理が追加されている。
スキーマキャッシュのバージョンも同時に引き上げられているため、更新後に手動でキャッシュをクリアする必要はない。自動的に再生成され、Jetpack の整数型 enum は除去された状態でツールリストが構築される。
どうしてもアップデートできない場合の手動修正
何らかの理由で AI Engine を最新版にできない場合、子テーマの functions.php または Code Snippets プラグインに以下のコードを追加し、Jetpack の整数型 enum フィールドを強制的に文字列型へ変換できる。
<?php
/**
* Jetpack と AI Engine、Google Gemini の競合を修正する。
* Jetpack の status enum フィールドを文字列型に変換する。
*/
add_action( 'wp_enqueue_scripts', 'enqueue_parent_styles' );
function enqueue_parent_styles() {
wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );
}
add_action( 'rest_api_init', 'fix_jetpack_enum_for_gemini', 9999 );
function fix_jetpack_enum_for_gemini() {
global $wp_rest_additional_fields;
if ( ! empty( $wp_rest_additional_fields ) ) {
foreach ( $wp_rest_additional_fields as $post_type => $fields ) {
if ( isset( $wp_rest_additional_fields[$post_type]['jetpack_publicize_connections'] ) ) {
if ( isset( $wp_rest_additional_fields[$post_type]['jetpack_publicize_connections']['schema']['items']['properties']['status'] ) ) {
// 問題を起こす整数 enum を除去
unset( $wp_rest_additional_fields[$post_type]['jetpack_publicize_connections']['schema']['items']['properties']['status']['enum'] );
// データ型を文字列に明示
$wp_rest_additional_fields[$post_type]['jetpack_publicize_connections']['schema']['items']['properties']['status']['type'] = 'string';
}
}
}
}
}
?>コード追加だけでは修正されないケースがある。AI Engine はツールリストをデータベースに強力にキャッシュしているため、キャッシュを強制的に再生成させる必要がある。
Jetpack を無効化した状態でチャットを実行することで、AI Engine は Jetpack 関連フィールドのないスキーマを新規に作成する。Jetpack を再有効化した後は上記のフィルタが働き、問題の enum がスキーマに混入することはなくなる。
よくある質問
Jetpack を使っていなければこの問題は起こらないのか
Jetpack の jetpack_publicize_connections フィールドが原因であるため、Jetpack を導入していなければ発生しない。ただし、他のプラグインも整数型 enum を REST API に追加している場合は似たエラーが出る可能性がある。その場合も AI Engine 3.5.5 以降であれば同様に自動除去される。
読み取り専用モードではなぜ問題ないのか
読み取り専用モードでは、投稿の作成や更新といった書き込み系のツールが Gemini に送信されない。問題の jetpack_publicize_connections フィールドは投稿作成時に登場するため、ツールリストから除外される。管理モードだけが影響を受ける。
AI モデルが Gemini 以外でも同じエラーは出るか
このエラーは Gemini のツール定義バリデーションが特に厳格なために発生する。OpenAI の GPT シリーズなど、他の AI モデルでは整数型 enum を許容するものもあるが、根本原因はスキーマにあるため、どのモデルでも潜在的な問題になりうる。AI Engine 3.5.5 の修正で全モデルに対応できる。
AI Engine 3.5.5 にアップデートした後、スキーマキャッシュは本当に自動クリアされるのか
開発者によれば、スキーマキャッシュのバージョンナンバーが引き上げられているため、更新後の初回リクエスト時に自動的に再生成される。手動でキャッシュを削除する操作は不要。もし不安があれば、AI Engine の設定画面からキャッシュを手動クリアしても問題ない。
この記事のポイント
- AI Engine 3.5.5 以降のアップデートで根本解決する
- 原因は Jetpack の整数型 enum を Gemini が拒否するため
- 読み取り専用モードでは書き込み系ツールが送信されず問題は出ない
- 手動修正する場合は Jetpack 一時無効化によるキャッシュ再生成が必須
- 修正後は文字列型以外の enum が自動除去され、あらゆる AI モデルで安定する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
PHP 8.4にしたらmodern-events-calendar-liteで翻訳読み込みエラーが出た時の対処法
PHP 8.4への移行直後にデバッグログへ記録された「_load_textdomain_just_in_time」の通知は、PHPのバージョンが原因ではない。WordPress 6.7で追加された新しい翻訳読み込み機構が、modern-events-calendar-liteプラグインの不適切な翻訳呼び出しを検出し、注意喚起しているだけだ。サイトの動作には影響しないが、デバッグモードを有効にしているとログを埋め尽くす。根本的な解決はプラグインのバージョンアップだが、更新が提供されていなければ数行のコードで通知を抑制できる。
なぜPHP 8.4への切り替え後にこの通知が現れたのか
実際のところ、PHP 8.4と翻訳読み込みの仕組みには直接の関係はない。今回の通知が突然ログに現れたのは、ふたつのタイミングが重なったためだ。ひとつは WordPress 6.7 で導入された「just-in-time翻訳読み込み」機能が、従来よりも厳密にプラグインのコードをチェックするようになったこと。もうひとつは、PHPのバージョンを上げるタイミングでデバッグモード（WP_DEBUG）を有効にした、もしくはデバッグログの出力先を確認したことだ。
つまり、PHP 7.4 の環境でも WordPress 6.7 以降であれば同じ通知は発生していた可能性が高い。PHP 8.4 にしたからといって、追加のエラーが生じたわけではないと捉える必要がある。デバッグログを初めて見たことで、以前から存在していた通知に気づいたという構図になる。
_load_textdomain_just_in_time通知の正体
WordPress 6.7 では、翻訳ファイルの読み込みをできるだけ遅延させる「just-in-time翻訳」の仕組みが強化された。その中核を担うのが _load_textdomain_just_in_time という内部関数だ。この関数は、プラグインやテーマが本来「init」アクション以降に行うべき翻訳ファイルの読み込み（textdomainのロード）を、それより早い段階で実行しようとした場合に検知し、開発者向けの通知を発生させる。
表示されるエラーメッセージの日本語訳は「_load_textdomain_just_in_time 関数が正しく呼び出されませんでした。modern-events-calendar-lite ドメインの翻訳の読み込みが早すぎるタイミングで開始されました。」といった趣旨になる。これは「重大なエラー」ではなく「注意（Notice）」であるため、サイトの表示が崩れたり、機能が停止したりすることはない。
PHP Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the modern-events-calendar-lite domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later.
-- デバッグログから当該通知がなくなり、本来のエラーだけが記録される --
上記のBefore/Afterのように、この通知を抑制すればデバッグログがすっきりし、本当に注意すべきエラーを見落としにくくなる。通知の表示自体はWordPress側の仕様変更によるものなので、PHP 8.4にしたからといって新たな不具合が混入したわけではないと理解しておこう。
翻訳読み込み通知を解消する手順
プラグインの更新状況を確認する
まずは、modern-events-calendar-liteプラグインが最新版になっているか管理画面の「プラグイン」一覧から確認する。WordPress 6.7への対応が完了していれば、アップデートを適用するだけで通知は自然に消える。ただし、このプラグインはしばらく大きな更新がないケースもあり、執筆時点では修正が提供されていない可能性が高い。
更新が見つからない場合は次の手順に進む。開発元が対応しないあいだは、ユーザー側で通知を抑える方法を取らざるを得ない。
コードを追加して通知を抑制する
更新が提供されていない場合でも、WordPressのフィルターフックを使って、modern-events-calendar-liteに限って「_load_textdomain_just_in_time」の通知を発生させないようにできる。具体的には、以下のコードをMUプラグイン（Must-Use Plugin）として配置する。
<?php
/**
* Plugin Name: Suppress MEC Translation Notice
* Description: modern-events-calendar-lite の翻訳読み込み通知を抑制する
*/
add_filter( 'doing_it_wrong_trigger_error', function( $trigger, $function_name, $message, $version ) {
if ( '_load_textdomain_just_in_time' === $function_name && false !== strpos( $message, 'modern-events-calendar-lite' ) ) {
return false;
}
return $trigger;
}, 10, 4 );このコードは「doing_it_wrong_trigger_error」フィルターを利用し、問題の関数名とメッセージ内に当該プラグインのテキストドメインが含まれている場合のみ、通知のトリガーを無効にする。他のプラグインやコアの重要なお知らせには影響を与えないため、安全に使える。
設置方法は、wp-content/mu-plugins/ ディレクトリに任意の名前のPHPファイル（例: mec-translation-suppress.php）を作成し、上記コードを貼り付けるだけ。mu-plugins フォルダが存在しない場合は手動で作成する。MUプラグインを使うと、テーマの切り替えや通常のプラグイン管理の影響を受けず、恒久的にフィルターが適用される。
デバッグログを確認する
コードを追加したあと、再度サイトを表示したり、管理画面にログインし直したりすると、それ以降のデバッグログ（wp-content/debug.log）に当該通知が記録されなくなる。念のため、一度プラグインを無効化・再有効化するか、任意のページを表示してからログを確認すると確実だ。通知が消えていれば対処は完了。もし引き続き同じ通知が残っている場合は、ファイルの設置場所やコードの記述ミスを確認する。
よくある質問
この通知はサイトを停止させるのか
停止しない。WordPressの「Notice」レベルの出力であり、サイトの表示やプラグインの動作そのものにはまったく影響を与えない。デバッグモードが有効な環境でのみログに出力されるものなので、訪問者が目にすることもない。
PHP 8.4に戻したほうがいいのか
戻す必要はない。通知はPHPのバージョンに依存せず、WordPress 6.7の仕様に起因する。PHP 7.4はすでにセキュリティサポートが終了しているため、PHP 8.4を使い続けるほうが望ましい。今回の通知を理由にPHPのバージョンを下げるのは誤った判断だ。
他のプラグインでも同じ通知が出る可能性はあるか
十分にある。WordPress 6.7以降、翻訳の読み込みを「init」より前に行っている多くの古いプラグインやテーマで同様の通知が発生する。同じ仕組みで対処したい場合は、上記のコード内の「modern-events-calendar-lite」の部分を該当するテキストドメインに置き換えればよい。
通知を消すコードを使うとほかのエラーも隠れてしまうのか
今回紹介したフィルターは、関数名とメッセージ内容の両方で限定しているため、ほかの「doing_it_wrong」通知には影響しない。別のプラグインやWordPressコアが発する重要な警告は、従来どおりデバッグログに記録される。ただし、全体的な検証のために、テスト環境でコードの動作を確認してから本番に適用するのが安心だ。
この記事のポイント
- PHP 8.4への切り替え後に出た翻訳通知は、PHPのバージョンが原因ではない
- WordPress 6.7のjust-in-time翻訳機能が古いプラグインの不備を検出したもの
- サイトの動作には影響せず、デバッグログに記録されるだけのNotice
- プラグインの更新がなければ、フィルターコードで通知だけを抑制できる
- 通知を抑制しても他の重要なエラーは引き続きログに残る
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
会員制サイトSEOの7つの戦略、ティーザーで制限コンテンツを検索上位に
会員制サイトを運営していると、せっかく質の高いコンテンツを制作しても、Google検索にまったく表示されないという問題に直面しやすい。原因の多くは、価値のある記事やコースがログインページやペイウォールの奥に隠れていることにある。検索エンジンは会員専用エリアをクロールできず、サイト全体のテーマを正しく把握できないのだ。
しかし、コンテンツ保護とSEOはトレードオフではない。適切な設計を施せば、プレビュー部分を検索エンジンに読み取らせつつ、中核の有料コンテンツはしっかり守れる。WPBeginnerがまとめた「会員制サイトSEOの7つの戦略」をもとに、具体的な実装方法を解説する。
会員制サイトのSEO課題と「ティーザーコンテンツ」の考え方
会員制サイトには特有のSEOの壁がある。Googleは公開されている情報だけをインデックスするため、ログイン必須のレッスンやダウンロード資料、会員ダッシュボードの中身は一切読み取れない。一方で、完全に閉ざしてしまうと検索流入を失い、新規会員の獲得機会が減ってしまう。
検索エンジンはゲート付きコンテンツをどう扱うか
Googleは、ログイン前の訪問者にも表示される「公開プレビュー」部分をインデックス可能だ。一方、認証画面の奥にある会員専用ページはクローラーのアクセス対象外となる。この仕組みを逆手に取り、ティーザーコンテンツ（Teaser Content）と呼ばれる一部公開方式を採用するサイトが多い。WPBeginnerの著者も、これが会員制サイトのSEOにおいて最も効果的で安全な手法だと述べている。
ティーザーコンテンツが有効な理由
ティーザーとは、記事の導入部やレッスンの要約、キーポイントなどを会員以外にも公開し、続きはログイン後に読めるようにする仕組みだ。Googleはこの公開部分をもとにページの主題を理解し、検索結果に表示できるようになる。訪問者にとっては内容の魅力を事前に感じられるため、会員登録へのコンバージョン率も向上しやすい。WPBeginnerの実践では、無料の動画コース一覧を誰でも閲覧可能にし、レッスン本体は会員登録後に開放する形で、SEOと会員獲得を両立している。
このデモのように、Googleは公開部分のテキストからページの内容を把握し、ランキング評価に活用する。訪問者にとっては「続きも見たい」というモチベーションが生まれ、会員獲得の導線としても機能する。
ティーザーとコンテンツドリッピングを安全に運用する
ティーザー表示の設定ができたら、次は会員にコンテンツを段階的に提供する「コンテンツドリッピング」について理解しておきたい。これはオンラインコースなどでよく使われる手法で、SEOに悪影響を及ぼさないためにはいくつかの注意点がある。
MemberPressを使ったティーザー公開の設定手順
WordPressで会員制サイトを構築する場合、高い機能を持つプラグインとしてMemberPressが広く使われている。管理画面の「MemberPress」→「ルール」から新規ルールを追加し、保護したい投稿やカテゴリを選択する。その後「アクセス条件」で特定の会員レベルを指定し、「未認証時のアクション」で抜粋の表示を有効にすれば、公開ティーザーが実装できる。
抜粋の長さは200〜300語程度を目安に設定すると、検索エンジンがページ主題を理解するのに十分な情報量を提供できる。WPBeginnerのガイドでは、未認証時に表示されるメッセージに料金ページや登録ページへのリンクを埋め込むことで、コンバージョン向上を図る方法も推奨されている。
コンテンツドリッピングがSEOに与える影響と事前対策
ドリッピングとは、会員登録後の日数経過や特定の日付に合わせて、レッスンを少しずつ開放していく仕組みだ。未解放のコンテンツは検索エンジンからも見えないため、その期間はインデックスされない。しかし、事前にティーザーページやレッスン概要を用意しておけば、後日開放されたときにスムーズにクロールされる。
動画コースの場合は、各レッスンに短いプレビュー動画や書き起こしテキスト、キーポイントをまとめた公開ランディングページを設ける方法が有効だ。WPBeginnerの著者は、これによって開放前から検索エンジンに内容を認識させられると指摘している。
無料コンテンツを拡充して検索トラフィックを底上げする
会員制サイトの運営者の中には、コンテンツの大半をペイウォールの内側に置いてしまうケースがある。だが、それではGoogleがサイト全体の専門性を評価する材料が不足し、オーガニック流入が伸び悩む。実際に成果を上げているサイトは、無料コンテンツを充実させ、そこから有料会員プログラムへと誘導する設計をとっている。
無料と有料の境界線の引き方
無料コンテンツは、幅広い検索キーワードでアクセスを集める役割を担う。一方、有料コンテンツにはテンプレートやワークシート、詳細な実装ガイドなど、より深い価値を置く。WPBeginnerが提示する枠組みでは、初心者向けチュートリアルや統計レポート、業界の基礎知識は無料とし、高度なノウハウや会員限定のツールキットは有料会員向けに保護する。
- 無料コンテンツ：検索ボリュームの大きいキーワードを狙うブログ記事、初心者向け解説、バックリンクを獲得しやすいリソース
- 有料コンテンツ：テンプレート、ワークシート、オンラインコース、会員限定の実装ガイド
このように切り分けると、無料記事で集めた訪問者に「より深い学びを得たければ会員登録を」と自然に促せる。
E-E-A-Tシグナルとキーワード戦略で信頼を構築する
会員制サイトは、専門知識やトレーニングを販売する性質上、訪問者からの信頼獲得が欠かせない。Googleが評価するE-E-A-T（経験、専門性、権威性、信頼性）の観点からも、無料コンテンツを使って実績や実例を示すことが有効だ。WPBeginnerの著者は、実際に自分たちでツールを使い、結果やケーススタディを共有することで、サイトの専門性を高めている。
具体的には、著者プロフィールの充実、会員の声や成功事例の掲載、実際の運用画面の紹介などが信頼構築に役立つ。無料記事にこうしたシグナルを埋め込んでおくと、検索エンジンだけでなく、人間の読者にも「このサイトは信用できる」と感じてもらいやすい。
テクニカルSEOとnoindex設定でクローラーの集中力を高める
どれだけ優れたコンテンツ戦略を立てても、サイトの技術的な土台が整っていなければ、検索順位は伸びにくい。会員制サイトでは特に、ログインページやアカウントページといった「低価値ページ」が検索結果に紛れ込むのを防ぐことも重要になる。
サイトスピードやHTTPSなど基盤のチェックリスト
- HTTPSによるセキュリティ保護とランキングシグナルの確保
- キャッシュプラグインの導入と画像最適化によるサイトスピード改善
- モバイルフレンドリーなデザインの採用
- XMLサイトマップを生成し、検索エンジンにサイト構造を伝える
- リンク切れや404エラーを定期的に検出し修正する
これらの対策は会員制サイトに限らず重要だが、ペイウォールがあるぶん、クローラビリティの健全性を保つ意識がより求められる。
ログインページやアカウントページをnoindexに
会員ログインページやアカウント管理画面、決済完了後のサンキューページなどは、検索結果に表示されてもユーザーにとってほとんど価値がない。むしろ、これらのページがインデックスされると、サイトの評価につながる重要なコンテンツの存在が薄れてしまう可能性がある。
そのため、All in One SEO（AIOSEO）などのSEOプラグインを使って、該当ページの編集画面から「Robots Meta」設定で「No Index」を有効にすることを推奨する。WPBeginnerの著者も、会員向け機能ページはnoindexに設定し、ブログ記事やコースランディングページなどの集客に集中させる方針をとっている。
内部リンクとコンバージョン最適化で会員化を加速する
無料コンテンツで訪れたユーザーを会員登録へと導くためには、サイト内の動線設計が欠かせない。内部リンクを活用して無料記事から有料プランへつなぎ、さらにポップアップやスライドインなどの施策で後押しすれば、SEOで獲得したトラフィックを収益に結びつけられる。
無料記事から有料コンテンツへの自然な導線
ブログ記事で「会員制サイトの始め方」を解説しているなら、記事の途中や末尾に「さらに詳しいテンプレートは会員プログラムでダウンロード可能」といったリンクを設置する。リンクのアンカーテキストは「こちらをクリック」ではなく「会員限定テンプレートを入手する」のように具体的に書くと、クリック率とSEO評価の両面で効果が高い。
- ブログ記事 → 関連する有料コースのランディングページ
- 無料のチュートリアル → 会員限定の上級編トレーニング
- リソースガイド → プレミアムテンプレートのダウンロードページ
内部リンクを張り巡らせると、Googleがサイト構造を理解しやすくなるのに加え、訪問者を収益化ページへ自然に誘導できる。
OptinMonsterによるExit-Intentやスライドインの活用
WPBeginnerの著者が特に効果的だと評価しているのが、OptinMonsterを使った出口検知ポップアップやスクロール連動スライドインだ。MemberPressとの連携機能により、未会員の訪問者だけを対象にキャンペーンを表示できるため、無料トライアルや割引オファーを最適なタイミングで提示できる。
たとえば、記事を最後まで読んだユーザーに対して「続きは会員限定です。今なら初月無料」と表示するスライドインは、押しつけがましくなく自然に感じられる。実際に、WPBeginnerの運営する複数のサイトでも、こうした導線によってメールリストの拡大や会員登録数の増加を実現している。
効果測定の指標とMonsterInsightsでの追跡
会員制サイトのSEO施策が成果を上げているかは、アクセス数だけでなく会員登録数やコンバージョン率で判断する必要がある。MonsterInsightsを使えば、GoogleアナリティクスのデータをWordPress管理画面に取り込み、どの記事が最も会員登録につながっているかを直感的に把握できる。
- オーガニックトラフィックの推移
- ティーザーページへの流入と直帰率
- 会員登録完了ページへの到達数
- バックリンク獲得状況
定期的にこれらの指標を確認し、特に会員登録につながっているコンテンツを強化していくと、施策の費用対効果を最大化しやすい。
この記事のポイント
- 会員制サイトのSEOには、公開ティーザーで検索エンジンに内容を伝える手法が欠かせない
- MemberPressで抜粋表示を設定し、一部のコンテンツを誰でも見られるようにする
- コンテンツドリッピングは事前にティーザーページを用意すればSEO上のデメリットは最小限
- 無料コンテンツで集客し、内部リンクとコンバージョン施策で有料会員へ誘導する
- 会員向け機能ページはnoindexにして、クロールのリソースを重要なページに集中させる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WP Rocketのキャッシュ後にモバイルレイアウトが崩れる原因と直し方
WP Rocket のキャッシュ生成後にモバイルレイアウトだけが崩れる場合、Remove Unused CSS（未使用 CSS の削除）や CSS の縮小化（Minify）がレスポンシブ用のメディアクエリや動的クラスを誤って処理している可能性が高い。最初に「未使用 CSS の削除」を無効化するか、モバイル用 CSS を除外設定すれば多くのケースで即座に解決する。
なぜ WP Rocket のキャッシュ後だけモバイル表示が崩れるのか
WP Rocket はサイトの表示速度を上げるため、CSS や JavaScript ファイルを結合・縮小・遅延読み込みする。この最適化処理は強力だが、画面幅に応じてスタイルを切り替えるメディアクエリ（@media）を含むファイルを処理する際に、意図しない形でルールを並べ替えたり削除したりすることがある。
特に問題を起こしやすいのは「未使用 CSS の削除（Remove Unused CSS）」機能だ。この機能はページで実際に使われている CSS だけを抽出して配信する仕組みだが、JavaScript で動的に追加されるクラスや、スクロール位置・タップ操作などユーザーのアクション後に初めて適用されるスタイルを「未使用」と判断して除去してしまう。モバイル表示の崩れは、ほぼこの機能か Critical CSS の生成に起因する。
Cloudflare のキャッシュや Auto Minify が WP Rocket と二重に最適化をかけている場合も、CSS の破損リスクが高まる。キャッシュを両方でクリアしても、最適化処理そのものが走るたびに同じ崩れが再発するのはそのためだ。
■ カラムが重なって文字が読めない
■ ボタンや画像が画面幅をはみ出す
■ WP Rocket の「未使用 CSS 削除」が
@media ルールを除去している■ Critical CSS の再生成と検証
■ Cloudflare 側の二重最適化を停止
■ すべてのデバイスで同一レイアウトを維持
WP Rocket が CSS を処理する流れは、ファイルの読み込み・解析・不要ルールの除去・結合・縮小という順序で進む。このデモは、どの段階でモバイル用のスタイルが失われるかを概念的に示したものだ。
最初に試すべき設定変更と確認手順
未使用 CSS の削除を一時的に無効化する
WordPress 管理画面の「設定」→「WP Rocket」→「ファイル最適化」タブを開き、「CSS ファイル」セクションにある「未使用の CSS を削除（Remove Unused CSS）」のチェックを外す。変更を保存したら、WP Rocket のキャッシュを完全に削除し、Cloudflare を使っている場合は Cloudflare 側のキャッシュもパージする。
シークレットウィンドウまたはキャッシュの残っていない別ブラウザでモバイル表示を確認し、問題が解消したかどうかを判断する。もしこれで直った場合、原因は未使用 CSS の削除処理だと特定できる。
Critical CSS の生成状況を確認する
「未使用 CSS の削除」を有効にしたまま使いたい場合は、Critical CSS（ファーストビュー表示に必要な最小限の CSS）の生成がモバイル用に正しく行われているかを検証する。「WP Rocket」→「ファイル最適化」→「CSS ファイル」セクションにある「クリティカル CSS の最適化（Optimize Critical CSS）」の設定を開き、モバイル向けの Critical CSS が生成されているか確認する。
生成された Critical CSS が不完全な場合、モバイルでのレイアウトが崩れる。一度「クリティカル CSS を再生成」ボタンで再生成し、それでも改善しない場合は、この機能自体をいったん無効化して様子を見る。
CSS 縮小化（Minify）と結合の影響を切り分ける
「未使用 CSS の削除」を無効にしても問題が続く場合、CSS 縮小化（Minify CSS）または CSS 結合（Combine CSS）が原因である可能性を調べる。どちらか一方だけを有効にしてキャッシュを削除し、崩れの有無を確認する。縮小化と結合を両方有効にしていると切り分けができないため、必ず一方ずつ試す。
原因となる機能を特定できたら、その機能だけを無効化するか、次項で説明する除外設定を使って該当 CSS だけを最適化対象から外す方法に進む。
モバイル用 CSS を WP Rocket の最適化から除外する方法
テーマやプラグインが読み込むモバイル用 CSS ファイルを特定し、WP Rocket の除外リストに追加すれば、最適化によるレイアウト崩れを防ぎつつ、他のファイルの高速化は維持できる。
どの CSS ファイルが除外対象かを特定する
ブラウザのデベロッパーツール（F12）でモバイル表示を開き、「ネットワーク」タブで読み込まれている CSS ファイルを確認する。レスポンシブ用のスタイルを含むファイル名には responsive mobile tablet などの文字列が含まれていることが多い。また、テーマのメインのスタイルシート（style.css）の後半に @media ルールが集中している場合は、ファイル全体を除外候補として扱う必要がある。
WP Rocket の除外設定に CSS を追加する
「WP Rocket」→「ファイル最適化」→「CSS ファイル」セクションを開き、「除外する CSS ファイル（Excluded CSS Files）」のテキストエリアに、先ほど特定したファイル名（例: responsive.css mobile.css theme-responsive-min.css）を行単位で入力する。ファイルの URL の一部（例: /themes/my-theme/css/responsive）でも指定できる。
特定の CSS の塊（インラインの @media ブロックなど）だけを除外したい場合は、「未使用 CSS の削除」の設定内にある「セーフリスト（Safe list）」にクラス名や ID を追加する方法も有効だ。たとえば .mobile-menu #responsive-nav .hamburger など、モバイル表示でのみ使われるセレクタをカンマ区切りで指定すれば、そのルールは削除されずに残る。
Cloudflare 側の設定との競合を防ぐ
Cloudflare の「速度」→「最適化」→「Auto Minify」で CSS と JS の縮小化が有効になっている場合、WP Rocket の縮小化と二重がけになって CSS が破損することがある。Cloudflare 側の CSS 縮小化は無効にし、WP Rocket に一本化する。また Cloudflare の「Rocket Loader」も JavaScript の実行順序を変更するため、モバイルでの動的なスタイル適用に悪影響を及ぼす可能性がある。問題が解消しない場合は Rocket Loader も一時的に停止して検証する。
よくある質問
WP Rocket の「モバイルキャッシュ」機能は有効にすべきか
レスポンシブテーマを使っている場合は「モバイルキャッシュを有効にする（Enable caching for mobile devices）」はオフのままで問題ない。この機能はモバイル専用の別テーマ（例：Jetpack のモバイルテーマ）を使っている場合に必要になる設定で、通常のレスポンシブサイトでは有効化するとキャッシュが二重管理されて意図しない表示になることがある。
CSS 縮小化で改行が消えてレイアウトが崩れることはあるか
改行や空白の除去自体が CSS の意味を変えることはほとんどない。ただし、コメント行に書かれた条件付きブラウザ指定（/*! normalize.css */ のような特殊構文）や、不適切に記述された @import 文が縮小化で破損することがある。その場合は該当ファイルを縮小化の除外リストに追加する。
Remove Unused CSS をオフにするとサイト速度は大幅に落ちるか
ページ全体の CSS サイズが極端に大きい場合を除き、体感速度が大きく落ちることは少ない。むしろレイアウト崩れによるユーザー離脱のリスクのほうが深刻だ。未使用 CSS の削除を無効化したうえで、Critical CSS の生成だけを有効にすると、ファーストビューの表示速度を保ちつつ安定したレイアウトを維持できる。
モバイルキャッシュを削除しても直らないのはなぜか
WP Rocket のキャッシュ削除に加えて、Cloudflare のキャッシュ、ブラウザキャッシュ、サーバー側のページキャッシュ（Nginx FastCGI や LiteSpeed Cache など）のいずれかに古いデータが残っている可能性がある。すべてのキャッシュ層を順にクリアしてからシークレットモードで確認する。また、CDN のエッジサーバーにキャッシュが残っている場合もあるため、Cloudflare の「キャッシュ」→「すべてをパージ」を実行したあと最低5分は待ってから検証する。
この記事のポイント
- モバイルレイアウト崩れの主因は「未使用 CSS の削除」と Critical CSS の不完全な生成
- 問題の CSS を特定し WP Rocket の除外リストに登録すれば最適化と両立できる
- Cloudflare の Auto Minify や Rocket Loader との二重がけに注意する
- キャッシュの検証は全キャッシュ層をクリアしたうえでシークレットモードで行う
- モバイルキャッシュ機能はレスポンシブテーマではオフでよい
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
MonsterInsights公式サイトが攻撃、フィッシングメールに警戒を
WordPress向けGoogle Analytics連携プラグイン「MonsterInsights」の公式サイトがサイバー攻撃を受け、一時的にオフラインとなった。さらに深刻なのは、同プラグインを装ったフィッシングメールがユーザーに送信されている点だ。無料版だけでも200万サイト以上にインストールされており、影響は広範囲に及ぶ。
この記事では、MonsterInsightsが直面している攻撃の実態と、ユーザー側が直ちに取るべき対策を整理する。サイトに同プラグインを導入している運営者は、偽の更新通知やダウンロードリンクに十分な警戒が必要だ。
MonsterInsightsとは何か、なぜ影響が大きいのか
MonsterInsightsは、WordPressサイトにGoogle Analytics（GA）のデータを直感的に表示するプラグインだ。管理画面内のダッシュボードでアクセス解析を完結できる点が評価され、広く普及している。無料版のインストール数は200万サイトを超え、有料版を含めると約300万サイトに導入されているとされる。
上図のように、MonsterInsightsは本来、GAデータをWordPress管理画面に橋渡しする安全なツールだ。しかし今回、攻撃者がその信頼性を逆手に取り、ユーザーを偽サイトへ誘導する手口が確認されている。
インストールベースが極めて大きいため、被害が連鎖的に広がるリスクがある。攻撃者がMonsterInsightsの顧客リストにアクセスした場合、正規のユーザー情報を使って説得力のあるフィッシングメールを送信できるからだ。
公式サイトのダウンと攻撃の兆候
Search Engine Journalの記事によれば、MonsterInsightsの公式サイトは2026年6月12日時点でオフラインとなり、トップページには以下のような告知が表示されている。
Our website is offline as we’re mitigating an attack. Your analytics and tracking aren’t affected. Please DO NOT download MonsterInsights from any 3rd party website as there is a known phishing attempt happening right now.
この告知から読み取れるのは、攻撃がWebサイトそのものを標的にしている一方で、既存ユーザーのアナリティクス機能やトラッキングには影響が出ていないという点だ。MonsterInsightsはプラグインとして各サイトにローカルインストールされているため、公式サイトが落ちても、すでに導入済みのサイトでGAデータの取得が止まることはない。
ただし、公式サイトにアクセスできない状態が続くと、正規のアップデートを受け取れなくなるリスクがある。攻撃者はその隙を突き、「MonsterInsightsの緊急アップデート」を装ったメールを流している。
攻撃の種類とフィッシングの手口
現時点で攻撃の詳細な手法は明らかにされていない。しかし、公式サイトの差し替えと顧客へのフィッシングメール送信が同時に発生していることから、次のようなシナリオが推測される。
- 攻撃者が何らかの方法でMonsterInsightsの顧客データベースまたはメール配信システムにアクセスした
- 入手したメールアドレスに対して、MonsterInsightsを装ったフィッシングメールを一斉送信している
- メールには偽のダウンロードリンクが含まれ、サードパーティサイトから不正なプラグインをインストールさせる狙いがある
フィッシングメールを受け取ったユーザーがリンクをクリックし、指示に従って「更新」を実行すると、マルウェアを含む偽のプラグインがWordPressサイトにインストールされる可能性がある。これにより、サイトの乗っ取りや情報漏洩といった二次被害が発生するリスクが高まる。
✅ 公式サイト（復旧後）またはWordPress管理画面からのみ更新する
✅ 不審なメールは support@monsterinsights.com に報告する
上記のような緊急性を煽る文言が使われている場合、特に注意が必要だ。MonsterInsightsの公式Xアカウントも、サードパーティサイトからのダウンロードをしないよう強く呼びかけている。
ユーザーからの報告とSNS上の反応
X（旧Twitter）上では、実際にフィッシングメールを受け取ったユーザーが複数報告している。
ユーザーの @alliemims 氏は、フィッシングメールを受け取ったがリンクには触れず、公式サイトの問い合わせフォームから報告しようとしたところ、403エラーでアクセスできなかったと投稿している。別のユーザー @biancavandepoel 氏は、攻撃者がすでに顧客リストを入手している可能性を指摘し、MonsterInsights側から全顧客への迅速な警告メール送信を求めている。
これらの投稿からは、ユーザーが混乱しつつも冷静に対処しようとしている様子がうかがえる。報告しようとしても公式サイトにアクセスできないという状況が、事態をより複雑にしている。
MonsterInsightsの公式対応と今後の展望
MonsterInsightsは公式Xアカウントで、攻撃を緩和するための対応を進めていると発表している。また、サードパーティサイトからのダウンロード禁止を改めて警告し、ユーザーに対しては support@monsterinsights.com への問い合わせを案内している。
現時点では、公式サイトの復旧時期や攻撃の全容については明らかにされていない。しかし、過去のWordPressプラグインに対するサプライチェーン攻撃の事例から見ると、今回のインシデントは以下のような段階を経て収束に向かうと予想される。
- 攻撃経路の特定と遮断
- 流出した可能性のある顧客データの範囲特定
- 公式サイトの復旧とセキュリティ強化
- 影響を受けたユーザーへの個別通知
重要なのは、MonsterInsightsのプラグインそのものに脆弱性が見つかったわけではないという点だ。今回の問題は公式サイトと顧客コミュニケーション経路への攻撃であり、既存のインストール済みプラグインが直接危険にさらされているわけではない。ただし、フィッシングによって偽のプラグインをインストールさせられるリスクは現実に存在する。
サイト運営者が直ちに取るべき5つの対策
MonsterInsightsを導入している、または同プラグインの利用を検討しているサイト運営者は、以下の対策を即座に実行することを推奨する。
特に重要なのは、落ち着いて公式情報を待つことだ。攻撃者は混乱に乗じてユーザーを騙そうとする。MonsterInsightsのプラグイン自体が危険になったわけではないため、慌ててプラグインを削除したり、非公式の「修正版」をインストールしたりする必要はない。
WordPressプラグインのエコシステム全体を見渡すと、今回のようなサプライチェーン攻撃は増加傾向にある。2024年にも複数の人気プラグインが同様の手口で攻撃を受けた事例がある。自社サイトのセキュリティ対策として、以下の日常的な施策も合わせて見直すことを推奨する。
- プラグインの自動更新を有効にし、公式リポジトリからの更新のみを許可する
- 管理画面へのアクセスに二要素認証を導入する
- 定期的にサイトのプラグイン一覧を監査し、不要なものは削除する
- セキュリティプラグインでファイル変更の監視を行う
この記事のポイント
- MonsterInsights公式サイトが攻撃を受け、フィッシングメールが顧客に送信されている
- 既存のプラグイン機能（アナリティクス・トラッキング）には影響なし
- メール内のリンクからサードパーティサイトでプラグインをダウンロードしないこと
- プラグイン更新はWordPress管理画面または公式サイトからのみ行う
- 不審なメールは公式サポートに報告し、自社サイトのプラグイン一覧も確認する
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
QSMプラグイン更新後にメディア画面のレイアウトが崩れた時の直し方
特定のプラグインを更新した直後にメディアアップロード画面のレイアウトが崩れた場合、まず該当プラグインのバージョンを更新前の状態に巻き戻すまたは一時的に無効化し、公式サポートへ報告するのが最も早い解決策だ。根本原因はプラグインが管理画面に読み込む CSS や JavaScript の競合にあり、プラグイン側の修正を待つ必要がある。
なぜ QSM プラグインの更新後にレイアウトが崩れるのか
プラグインのバージョンアップでメディアアップロード画面に限って表示が崩れる現象は、Quiz And Survey Master（QSM）v11.1.1 で報告されている。このバージョンで管理画面の他ページ向けに追加された CSS や JavaScript が、メディアライブラリのモーダルやグリッドレイアウトと競合するケースが主な原因だ。
WordPress の管理画面では複数のプラグインが同じ画面にスタイルを適用できる。あるプラグインが独自のフォーム用スタイルをグローバルに出力した場合、メディアアップローダーのドラッグ＆ドロップ領域やサムネイル一覧の幅計算が崩れ、ボタンが画面外に飛び出したり画像が縦一列に並んだりする。
この問題は QSM 側が読み込む管理画面用 CSS のセレクタ範囲が広すぎることに起因する。プラグイン開発者が自プラグインの設定画面だけに限定してスタイルを当てるつもりが、WordPress 全体の管理画面に影響するセレクタを使ってしまうことで発生する。
QSM を最新にしたままレイアウト崩れを直す方法
QSM プラグインに依存しているサイトでは単純な無効化が難しいため、まずはプラグイン公式の修正を待ちつつ、以下のいずれかの方法で一時的にレイアウトを正常化できる。
過去の安定バージョンに巻き戻す
WordPress ではプラグインのバージョンを手動でダウングレードできる。まず管理画面の「プラグイン」から QSM を一度削除する。削除してもアンケートデータや設問はデータベースに残る。
次に QSM の公式プラグインページ下部にある「以前のバージョン」 から v11.1.0 以前の安定版 ZIP を入手し、「プラグイン」→「新規追加」→「プラグインのアップロード」でインストールする。有効化後、メディアアップロード画面を再読込すればレイアウトは戻る。
このデモはレイアウト崩れが発生した際の切り分けとバージョン巻き戻しの流れを示している。プラグイン削除で既存データが消える心配はなく、過去バージョンの再適用で一時的に運用を継続できる。
管理画面の特定ページだけで無効化するコードを使う
QSM を有効にしたまま管理画面のメディアページだけでプラグインのスタイルを外したい場合、functions.php にフィルターフックを追加する方法がある。テーマの functions.php や Code Snippets プラグインを用いて以下のコードを追加する。
add_action('admin_enqueue_scripts', function($hook) {
if ('upload.php' === $hook || 'media-new.php' === $hook) {
wp_dequeue_style('qsm-admin-style'); // 実際のハンドル名に応じて変更
}
}, 100);上記の qsm-admin-style は実際に登録されているスタイルシートのハンドル名に置き換える必要がある。ハンドル名は QSM のプラグインソースコードを確認するか、ブラウザの開発者ツールで読み込まれている CSS ファイルの ID 属性から特定できる。
この方法はプラグインのアップデートでハンドル名が変わると再設定が必要になるため、あくまで暫定対応として位置づけるのが現実的だ。
自動更新を一時停止して様子を見る
プラグインの自動更新が有効になっている環境では、意図しないバージョンアップで管理画面が壊れるリスクが常にある。QSM を v11.1.0 に戻したら、プラグイン一覧で QSM の「自動更新を有効化」のチェックを外しておく。WordPress 本体の「更新」画面からも状況を監視し、次期バージョン v11.1.2 以降で修正パッチがリリースされたタイミングで手動更新する方が安全だ。
根本解決のためにすべきこと
レイアウト崩れが特定のプラグインに起因することが分かったら、積極的にプラグイン開発者へ報告するのが最も建設的な対応だ。QSM の公式サポートフォーラムや GitHub リポジトリで、以下の情報を添えて報告すれば修正が加速する。
- 現象が起きた WordPress のバージョンと PHP バージョン
- QSM のバージョン（v11.1.1）
- メディアアップロード画面のスクリーンショット
- ブラウザの開発者コンソールに表示された JavaScript エラー
開発者コンソールの確認方法は、Google Chrome の場合、Windows では F12 キー、Mac では Cmd + Option + I で「Console」タブに切り替え、赤字で表示されたエラーをキャプチャする。
開発者にとってコンソールエラーと発生条件の詳細は修正箇所を特定する決定的な手がかりになる。報告するときは感情的な内容を避け、「メディアページを開いたときだけレイアウトが崩れる。コンソールには ○○ というエラーが出ている」と具体的に伝えるとよい。
よくある質問
プラグインを無効化せずにメディアアップロードだけ使う方法はあるか
投稿画面の「メディアを追加」ボタンからもファイルをアップロードできる。メディアライブラリのグリッド表示が崩れていても、このモーダル画面では正常に動作するケースが多い。
QSM が原因かどうかを確実に特定するにはどうすればいいか
最も確実なのは Health Check & Troubleshooting プラグインを使ったトラブルシューティングモードだ。このモードではログイン中の自分だけにプラグインの無効化が適用されるため、サイト訪問者には影響を与えずに QSM のオンオフを切り替えられる。
バージョンを戻すとアンケートのデータは消えるのか
消えない。QSM の設問や回答データはデータベースの専用テーブルに保存されている。プラグインを削除しても WordPress の標準動作ではテーブルが削除されないため、再インストール後にすべてのデータが復元される。
子テーマの functions.php を編集するのが不安だ
Code Snippets プラグインを使えば管理画面から安全に PHP コードを追加できる。文法エラーがあるとスニペットが自動で無効化されるため、サイト全体が真っ白になるリスクを回避しやすい。
今回の問題は WordPress 本体のせいか
違う。WordPress 本体の更新ではなく、QSM プラグインの特定バージョン（v11.1.1）が原因だ。WordPress コアにはメディア画面のレイアウトに関する既知の不具合は報告されていない。
この記事のポイント
- QSM v11.1.1 への更新が原因でメディアアップロード画面のレイアウトが崩れる
- 即効対策は v11.1.0 以前の安定版に巻き戻すこと
- 暫定対策として functions.php で特定ページだけスタイルを停止できる
- 恒久解決にはプラグイン開発者への詳細なエラー報告が不可欠
- 自動更新を停止して次期バージョンでの修正を待つのが安全
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Diviポップアップを時間指定で自動表示するトリガー設定方法
Divi のポップアップを「ページを開いてから数秒後」や「一定のスクロール後」に自動表示するには、ポップアップ編集画面のトリガー設定を使う。Divi ビルダーで作成したポップアップであれば、標準機能だけで時間遅延やスクロール位置を細かく制御できる。プラグイン版のポップアップ機能を使っている場合でも、設定タブの名称こそ異なるが考え方は同じだ。
Divi ポップアップのトリガー設定を開く手順
まずは、すでに作成済みのポップアップの編集画面にアクセスする。WordPress 管理画面の「Divi」メニューから「Theme Builder」を開き、登録されているポップアップの一覧を表示する。該当のポップアップをクリックすれば、Divi ビルダーの編集画面が立ち上がる。
ポップアップの編集画面では、画面下部にある「設定」パネルの中に「トリガー」タブが存在する。ここが表示タイミングを決める中核部分だ。もし「トリガー」タブが見当たらない場合は、ポップアップを新規作成したときに「ポップアップの種類」を誤って選択した可能性がある。再度ポップアップの種類を確認し、「自動ポップアップ」など時間経過に対応した種類を選び直す必要がある。
ページ表示後の時間でポップアップを表示する手順
トリガー設定内で「時間遅延」を選択し、秒数を指定するのが最もシンプルな方法だ。ここでは具体的な操作の流れと、設定値の意味を明確にする。
時間遅延のトリガーを正確に設定するコツ
時間遅延のプルダウンを選ぶと、すぐ下に「遅延時間（秒）」という入力欄が現れる。ここに数字（半角）を入れるだけで、ページが完全に読み込まれてからその秒数が経過した時点でポップアップが出現する。
たとえば「5」と入力すれば、ユーザーがページにアクセスして5秒後に表示される。なお、この秒数は外部スクリプトや画像の読み込み完了を基準にするため、重いページでは体感より若干遅れることがある。3〜8秒程度の短めの数字にしておくと、ユーザーがページを離れる前に目に留まりやすい。
複数のトリガーを同時に有効化できることも覚えておきたい。時間遅延とスクロールを併用すれば「5秒経過、かつ 30% スクロールしたら表示」といったより複雑な条件も作れる。
スクロール量でポップアップを表示する手順
スクロールをトリガーにする場合は、同じ「トリガー」タブ内で「スクロール」を選択する。ページの何パーセントがスクロールされた時点で表示するかを、スライダーまたは数値入力で指定できる。
スクロールトリガーのパーセント設定の考え方
スクロール量の入力値は「ページ全体の高さに対する比率」を示す。たとえば 25% と設定すれば、ユーザーがページの4分の1までスクロールしたタイミングでポップアップが出現する。記事ページなど長いコンテンツでは 40〜60% に設定すると、読み進めたユーザーにだけ訴求でき、直帰率の高いユーザーを無駄に邪魔しない。
注意点として、ページの高さが極端に短い場合（例えばランディングページなど）、設定したパーセントに到達する前に画面外に出てしまい、ポップアップが表示されないことがある。そうしたページではパーセントを低めに調整するか、時間遅延との併用を検討するとよい。
設定したポップアップが表示されないときのチェックポイント
トリガーを正しく設定しているのに実際のページでポップアップが出てこない場合は、いくつかの典型的な原因を順に潰していく。
- キャッシュの影響を受けている。Divi の設定を変更したら、サーバー側キャッシュやブラウザキャッシュをクリアする。
- 表示条件（ポップアップが表示されるページのルール）が合っていない。特定のページのみに制限していないか確認する。
- ブラウザのポップアップブロッカーが反応している。Divi のポップアップは HTML/CSS ベースなので通常は影響を受けないが、拡張機能の干渉を疑う。
- JavaScript の競合が起きている。他のプラグインやテーマのスクリプトと衝突し、トリガーが発火していない可能性がある。全プラグインを一時停止して切り分ける。
特にキャッシュ系プラグインを使用している場合は、Divi の JavaScript ファイルが古いまま配信されているケースが多い。キャッシュを削除したうえでシークレットウィンドウからアクセスすれば、新鮮な状態で動作確認ができる。
よくある質問
時間遅延とスクロールの両方を同時に使えるか
Divi のポップアップ設定では、トリガータイプを複数組み合わせることができる。時間遅延とスクロールの両方をアクティブにすると「指定秒数が経過した、かつ指定のパーセントまでスクロールした」時にのみポップアップが表示される AND 条件になる。どちらか一方だけで十分なケースが多いが、コンバージョンを高めたいランディングページでは組み合わせも有効だ。
モバイル端末ではポップアップを非表示にできるか
「トリガー」タブの下にある「表示設定」セクションで、デバイスごとの表示オンオフを切り替えられる。モバイルのチェックを外せば、スマートフォンやタブレットでは一切ポップアップが表示されなくなる。画面サイズが小さい端末でポップアップが邪魔にならないようにするために、多くのサイトでこの設定が使われている。
ポップアップが何度も出るのを防ぐには
一度表示したポップアップを同じユーザーに再度表示しないようにするには、「表示設定」の「頻度」オプションを使う。「セッションごとに1回」や「日ごとに1回」などを選べば、Cookie によって表示回数を制限できる。時間遅延で表示するポップアップであっても、この設定を併用すればユーザー体験を損ねにくい。
ポップアップにカウントダウンタイマーを表示したい
Divi には標準でカウントダウンタイマーモジュールが用意されている。ポップアップのレイアウト内にそのモジュールを配置すれば、表示と同時にタイマーが動き始める。時間遅延のトリガーと組み合わせると「あと○秒で閉じます」といった演出も可能だ。なお、タイマーはサーバー時刻ではなくブラウザ側で動作するため、正確な時刻に基づくキャンペーンには向かない。
この記事のポイント
- Divi ポップアップの表示タイミングは「トリガー」タブで設定する
- 時間遅延は秒数、スクロールはパーセントで指定できる
- キャッシュや表示条件が原因で動作しないことが多いのでまず確認する
- モバイル非表示や表示頻度制限を併用するとユーザーに優しい
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている