はじめに
ある日、自分のブログのGoogle Analytics(以下、GA4)を眺めていたら、ある時期から急にアクセスが0になっていた。「ついにブログが完全にオワコンになったか…」と一瞬絶望しかけたが、よく見ると計測自体が止まっているっぽい挙動だった。
たまたま同時期にPHP 7→8の移行作業をやっていたので「PHP移行のせいでアナリティクスが死んだ」と思い込んで調査を始めたのだが、実際の犯人は全く別のところに潜んでいた。
同じような状況でハマる人もいるかもしれないので、調査の過程と最終的な原因をまとめておく。
環境
- WordPress + Cocoonテーマ
- Site Kit by Google(GA4連携プラグイン)
- LiteSpeed Cache(これが今回の犯人)
- PHP 8系(直前にPHP 7から移行済み)
事象
GA4ホーム画面のグラフを見ると、ある日を境にアクティブユーザー・イベント数・表示回数が一気に落ち込んで、ほぼ平坦な線に張り付いていた。明らかに「アクセスが減った」ではなく「計測が止まっている」ような落ち方。
同じ時期にPHP 7→8の移行作業をしていたため、当然これを疑った。
仮説1: PHP 8移行でエラーが出ている? → 外れ
PHP 8では非推奨機能の削除や警告のエラー昇格があるので、GAタグの出力箇所より前でFatal Errorが出ていれば、その時点で出力が止まる可能性がある。
そう思ってブラウザの「ページのソースを表示」(Ctrl+U)で確認したところ、GAタグ自体はちゃんと出力されていた。ということは、PHPエラーで出力が止まっているわけではなさそう。
仮説2: Site Kitの認証切れ? → 半分正解
WordPress管理画面でSite Kitを開いたら「再ログインしてください」のメッセージが表示されていた。再ログインしたところ Connected 状態に復旧。
「これで解決か!」と思ったが、GA4のリアルタイムレポートを開いても、自分でブログにアクセスしてもユーザー数は0のまま反映されない。
検証中の罠: ブラウザのトラッキング防止機能
「ちゃんと計測されているか」を自分のブラウザで確認しようとしたのだが、ここで2つの罠にハマった。
罠1: Vivaldi(シークレットウィンドウ)の広告ブロッカー
シークレットウィンドウなら拡張機能オフだしクリーンだろうと思ってVivaldiで開いたが、Vivaldiは内蔵で広告ブロッカーを持っており、これが googletagmanager.com へのリクエストもブロックしていた。
罠2: Microsoft Edgeのトラッキング防止
EdgeのDevTools(F12)でConsoleタブを開いてリロードすると、こんなエラーが大量に出ていた。
Tracking Prevention blocked access to storage for <URL>これはEdge標準の「トラッキング防止」機能がGoogle Analyticsをブロックしている証拠。設定 → プライバシー/検索/サービス → 「トラッキング防止を有効にする」をオフにして検証することにした。
検証時の注意点
自分のブラウザがGAをブロックしていると、いくらサーバー側を直しても「計測されない」と勘違いしてしまう。検証用にはスマホの4G/5G回線+標準ブラウザが最もクリーンな環境。
真犯人の発見: ページソースからgtagが消えていた
ブラウザのブロックを全部解除した状態でNetworkタブを見ても、 googletagmanager・google-analytics・collect のいずれのリクエストも飛んでいない。
「あれ?」と思って view-source:https://k1persia.com/ でソースを直接確認したところ、先ほどあったはずの gtag の文字列が、1件も含まれていなかった。
最初にソース確認した時はGAタグが見えていたのに、今は消えている。これはキャッシュの仕業しかありえない。
Cocoonキャッシュをクリア → 復活せず
Cocoon設定 → キャッシュ から「全てのキャッシュの削除」を実行したが、ソースに gtag は戻ってこなかった。
LiteSpeed Cacheが本命だった
WordPressのプラグイン一覧を見直したら、LiteSpeed Cache がしっかり有効化されていた。これが古いHTML(GAタグなし版)をキャッシュして配信し続けていたのが真の原因。
LiteSpeed Cacheの管理画面 → ツールボックス → パージ →「すべてをパージ」を実行。
その後、 view-source: で確認すると、見事に gtag/js?id=GT-XXXXXXX が復活。GA4のリアルタイムレポートでもアクセスがカウントされるようになり、無事に計測復旧となった。
WordPressでGA計測が止まった時のチェック順序
今回の経験から、同じ事象が起きた時のチェックリストをまとめる。上から順番に確認していくのが効率的だと思う。
- Site Kitの
Connected状態を確認。認証切れなら再ログイン。 view-source:サイトURLでgtagを検索。出力されているか確認。- ↑で見つからない場合、キャッシュ系プラグインを全パージ。LiteSpeed Cache、WP Super Cache、W3 Total Cache、Cocoonキャッシュ等を全部。
- 検証時のブラウザ環境に注意。広告ブロッカー、Edgeのトラッキング防止、Vivaldi/Braveの内蔵シールドはオフに。
- WordPressログイン状態の影響を考慮。Site Kitの「Excluded from Analytics: All logged-in users」設定が有効だと、ログイン中ユーザーは計測対象外。
運用上の注意点(自分用メモ)
LiteSpeed Cache関連
- Site Kitの設定変更後、テーマ・プラグイン更新後はLiteSpeed Cacheのキャッシュをパージする習慣をつける
- 管理バー(画面上部)の「LiteSpeed Cache」メニューから「全てパージ」が一発で実行可能
- 「ページ最適化」でJS結合・遅延ロードを有効にしている場合、GAタグが正しく動かないリスクあり。問題発生時はこれもオフにして切り分け
検証用ブラウザ環境
- 自分の検証アクセスがブロックされる可能性を常に念頭に置く
- DevToolsのConsoleタブで
Tracking Prevention blockedやnet::ERR_BLOCKED_BY_CLIENTが出ていないか必ず確認 - リアルタイムで反映されない時の切り分けには、スマホ4G回線が最強のクリーン環境
まとめ
PHP 7→8移行という大きな作業の直後だったため、当初はPHP移行を強く疑った。しかし実際の原因はそれとほぼ独立したキャッシュ問題だった。
時系列で関連していそうに見えても、実際の処理フロー(HTML出力 → ブラウザ取得 → JS実行 → GA送信)のどこで止まっているかを一段一段切り分けることが、結果的に最短ルートになる。
特に「ソースに gtag があるか」を view-source: で確認するのは、キャッシュ問題発見の決定打になった。WordPress + GA計測トラブルでは、最初にここを見るのがおすすめ。
あと、自分のブラウザ環境がGAをブロックしている可能性、これは想像以上に検証を混乱させるので、スマホ4G回線で確認するクセをつけたほうがいいなと痛感した一件だった。
