AnalyticsCORE記事一覧

Article

高速化プラグインにアクセス解析タグが取り込まれ、計測が止まる

エラーは出ません。管理画面にも警告は出ません。設置確認も「正常」と表示されます。 それでも計測は止まっていました。あるサイトで、訪問の97%を数か月にわたって失っていた話です。

公開: 2026年8月9日

この記事でわかること

  • WordPressを速くするプラグインが、アクセス解析のタグを壊すことがある
  • 壊れてもエラーは出ない。数字が減っていることにしか現れない
  • 自分のサイトが大丈夫かどうかは、3分で確かめられます（確かめ方へ）

起きたこと

あるサイトで、アクセス解析の数字が実態とかけ離れていました。Google の Search Console では 28日間で1,729クリック。しかし解析タグが記録していたのは47ページビューだけでした。 しかもそのほとんどが、運営者自身がサイト内を見て回ったぶんです。

Search Console … Google が無料で提供している、検索結果での自分のサイトの成績を見る道具です。 「検索結果に何回出て、何回クリックされたか」が分かります。

原因は、サイトを速くするためのプラグインでした。悪いことは何も起きていないように見えます。 ページは正常に表示され、読者にも運営者にも異常は見えません。

自分のサイトで確かめる（3分）

特別な道具は要りません。ブラウザだけでできます。 ★必ずログアウトした状態で行ってください。理由はあとの章で説明します。

  1. シークレットウィンドウを開く
    Windows: Ctrl + Shift + N ／ Mac: ⌘ + Shift + N（Chrome の場合）
  2. 自分のサイトのトップページを開く
  3. ページのソースを表示する
    Windows: Ctrl + U ／ Mac: ⌥ + ⌘ + U。文字がびっしり並んだ画面が出れば正解です
  4. ページ内を検索する（Windows: Ctrl + F ／ Mac: ⌘ + F）。data-site と入力する
  5. 見つかった行の src= の後ろを見る

「ソース」… ブラウザがページを組み立てるために受け取っている、元の文字列のことです。 読めなくても構いません。今回見るのは1か所だけです。

判定はこれだけです。

  • src= の後ろが解析サービスのアドレスのまま → 正常
  • src= の後ろが自分のサイトのアドレス（とくに wp-content を含む）→ 取り込まれています

取り込まれたファイルの置き場所は、プラグインによって違います。 見つかったアドレスに次の文字が含まれていたら、そのプラグインが原因です。

src の後ろに含まれる文字プラグイン
/wp-content/litespeed/LiteSpeed Cache
/wp-content/cache/autoptimize/Autoptimize
/wp-content/cache/min/WP Rocket
/wp-content/cache/wpfc-minified/WP Fastest Cache
/wp-content/uploads/breeze/Breeze

defer や data-deferred が付いているだけなら問題ありません。 読み込みを後回しにしているだけで、ファイルそのものは差し替わっていないからです。 見るべきは src が変わっているかどうか、その一点です。

なぜ壊れるのか

WordPress を速くするプラグインには、たくさんのJavaScriptファイルを1本にまとめる機能があります （LiteSpeed Cache の「JS 結合」、Autoptimize の「JavaScriptコードの最適化」など）。 読み込むファイルの数が減るので、ページは速くなります。ここまでは正しい機能です。

問題は、このまとめる働きがよそから読み込んでいるファイルまで巻き込む場合です。 解析タグの1行が、こう変わります。

本来の状態（正常）

<script async src="https://example-analytics.jp/t.js" data-site="XXXX">

取り込まれた状態（壊れている）

<script src="https://あなたのサイト/wp-content/litespeed/js/880a….js" data-site="XXXX">

色を付けた部分だけが違います。ここは「このファイルをどこから読み込むか」を書く場所で、src（ソース）と呼ばれます。解析サービスのアドレスだったものが、自分のサイトのアドレスに置き換わっている——これが取り込まれた状態です。

なぜこれで記録が止まるのか。多くの解析タグは、自分がどこから読み込まれたかを見て、 データの送り先を決めています。「解析サービスから来たのだから、解析サービスへ送る」という具合です。 ところが読み込み元が自分のサイトに変わると、タグは自分のサイトへデータを送ろうとします。 そこにはデータを受け取る仕組みがないので、送られた記録は捨てられます。

たとえるなら、宛名の書かれていない封筒を「差出人の住所」を見て送り返すような仕組みです。 差出人の住所が書き換えられると、封筒は行き先を失います。

なぜ気づけないのか

この壊れ方が見つかりにくい理由は3つあります。

  • エラーが出ない。読者の画面にも管理画面にも、異常は何も表示されません。
  • 解析側にも何も届かない。「届かなかったデータ」は、受け取る側からは 「そもそも訪問が無かった」と区別がつきません。
  • 設置確認をすり抜ける。これがいちばん厄介です。

設置確認は、たいてい運営者が管理画面にログインした状態で自分のサイトを開いて行います。 ところが、その経路では高速化プラグインもキャッシュも効きません。 ログイン中は最適化を止める設定が一般的だからです。つまり確認するときだけ、壊れていない状態のページを見ていることになります。

この種の不具合は、匿名の読者と同じ経路でページを取得しないと見つかりません。 ログインした自分の目では、原理的に確認できません。

直し方

結合の対象から解析タグを外します。キャッシュを消すだけでは直りません。 消えるのは作られたファイルであって、次にページが作られると、また同じように取り込まれるからです。

LiteSpeed Cache の場合

  1. 管理画面 → LiteSpeed Cache → ページ最適化 → 「[8] チューニング」タブを開く
  2. 「JS 除外」の欄に、解析タグの配信元（例: example-analytics.jp/t.js）を1行追加して保存
  3. ツールボックス → 「[1] パージ」→「すべてをパージする」を押す

ここでつまずきやすい点が2つあります。

  • 結合のON/OFFと除外リストは別のタブにあります。結合の設定は「[2] JS 設定」、除外リストは「[8] チューニング」です。
  • パージは「すべてをパージする」を選びます。「CSS/JS キャッシュ」だけを消すと、結合ファイルは消えてもHTMLが古いままなので、もう存在しないファイルを読み込み続けます。直したのに直らないときは、たいていこれです。

そのほかのプラグインの場合

名前は違いますが、どれも「結合・最適化から除外するJS」を列挙する欄を持っています。 探す場所は「詳細設定」「チューニング」「上級者向け」といったタブの中です。

プラグイン除外欄の位置
Autoptimize設定 → Autoptimize →「JavaScript オプション」内の除外欄
WP Rocket「ファイルの最適化」タブ →「除外する JavaScript ファイル」
WP Fastest Cache「Excluded」タブ → ルールを追加
Breeze「Advanced Options」内の除外欄

CDNを使っている場合

サイトをCDN経由で配信している場合は、もうひと手間かかります。取り込まれたファイルは中身が変わってもファイル名が変わらないことがあり、そのときCDNは「同じファイル」と見なして古い中身を数日そのまま配り続けます。サーバー側を直したのに何も変わらないときは、 CDN側のキャッシュも削除してください。

ただし、除外の設定まで済ませればこの問題は起きなくなります。 結合ファイルの構成そのものが変わるためです。「キャッシュを消す」より「除外を入れる」ほうが根本的です。

そもそも取り込ませない

主要な高速化プラグインは、特定の属性が付いたスクリプトを最初から対象外にします。 タグの側にこれを書いておけば、利用者が設定を触らなくても結合されません。 各プラグインのソースコードを読み、実際に判定に使われていることを確認した属性は次のとおりです。

属性効くプラグイン
data-no-optimize="1"LiteSpeed Cache
data-noptimizeAutoptimize / Breeze
data-no-minifyWP Fastest Cache
data-cfasync="false"Cloudflare Rocket Loader（LiteSpeed Cache も尊重します）

なお、「読み込みを後回しにする」機能まで止める必要はありません。 解析タグはもともとページの表示を邪魔しない形で読み込まれるので、後回しにされても問題なく動きます。 止めるべきなのは「1本にまとめる」働きだけです。速度を落としてまで解析側の都合を通す理由はありません。

Analytics CORE での対応

Analytics CORE では、上記の属性と送信先をHTMLに書き込む属性を最初からタグに含めています。 送信先が書かれていれば、万一どこかで取り込まれても、記録は正しい宛先に届きます。

あわせて、登録されたサイトを週に一度クロールし、読者に配信されている実際のHTMLで タグの状態を確認しています。取り込まれていれば、その事実と直し方を管理画面に表示します。 設置確認では見つからない不具合なので、経路の外から見に行くしかありません。

この記事の内容は、Analytics CORE を使っていなくても当てはまります。 外部のJavaScriptを読み込む形の解析ツールであれば、同じことが起こり得ます。 お使いのツールが何であれ、一度ソースを確認してみることをおすすめします。

まとめ

  • 高速化プラグインのJS結合が、解析タグを自サーバーのファイルに取り込むことがある
  • エラーは出ず、設置確認も通るため、気づかないまま計測が止まる
  • 確認はログアウトした状態でソースを開き、data-site を持つ script の src を見る
  • 直し方は結合の除外リストに追加。キャッシュ削除だけでは元に戻る
  • LiteSpeed Cache は、除外欄のタブとパージの選び方でつまずきやすい
Analytics CORE を見るほかの記事