「このリンク、誰も踏んでいない」とずっと思っていました。実際には、外部リンク73本にクリック計測のコードが1行も入っていなかっただけでした。

そこから自分の計測を全部洗い直したら、「0」の読み違いが6種類出てきました。6件とも、GA4 と Search Console が表示していた数字自体は正しいです。壊れていたのは読み方のほうでした。

しかもそのうち2件は、すでに施策の No-Go を確定させる直前まで行っていました。エラーは1件も出ていません。0 はエラーにならないからです。

この記事は、その6件と、最後に見つかった「本物の 0」1件の実測記録です。

前提

対象：個人で運営している静的サイト数本（資格学習サイト takken.mainichi-lab.com と、方言の辞書サイト hogen.mainichi-lab.com ほか）
計測：GA4 3プロパティ＋ Search Console（ドメインプロパティ）
期間：2026年8月〜9月2日
収益：現時点で実質ゼロ。だから「効いた／効かなかった」の判定を間違えると、次に何を作るかを丸ごと間違える

0-1. 「測る仕掛けが無い」0

一番多かったのがこれでした。

外部リンクのクリック数がずっと 0 だったので「誰も踏んでいない」と思っていました。実際は onclick も GA4 イベントも一切実装されていなかっただけです。

リンクの張り先ごとに grep で数えました。

grep -roE 'href="https?://[^"]+"' . --include="*.html" \
  | grep -oE 'https?://[^/"]+' | sort | uniq -c | sort -rn

張り先	本数	クリック計測
記事プラットフォーム	42	なし
ASP（A8）	20	なし
楽天アフィリエイト	11	なし

合計73本。1本も計測していませんでした。

GA4 の画面には「イベント数 0」と正しく出ます。0 が出る以上、レポートは何も間違っていません。「まだ何も送っていない」と「送ったが 0 だった」は、GA4 の画面上で区別が付かないというのが本質でした。

対策として全リンクに委譲ハンドラを1本入れました。

document.addEventListener('click', (e) => {
  const a = e.target.closest('a[href^="http"]');
  if (!a) return;
  const host = new URL(a.href, location.href).host;
  if (host === location.host) return;      // 内部リンクは対象外
  if (typeof gtag !== 'function') return;  // 未ロードでも例外を投げない
  gtag('event', 'outbound_click', {
    dest_host: host,
    dest_url: a.href,
    from_page: location.pathname,
  });
}, { capture: true });

ポイントは3つです。

委譲にする。リンクは後から増えるので、個別に付けると必ず付け忘れます（実際73本のうち手作業で付いていたのは0本でした）
gtag が無くても例外を投げない。広告ブロッカーで gtag が落ちている環境で、計測コードがUIを壊すのが最悪です
dest_host を別パラメータで持つ。URL全文だけだとカーディナリティが高すぎて、GA4のレポートで束ねられません

0-2. 「まだ測れていない」0

新しく12ページ公開した翌日に Search Console を開いたら、12面中11面が表示 0 でした。

「新設ページのSEOは効かなかった」と判定しかけて、止めました。理由は2つあります。

Search Console のデータには約2日のラグがある。9月2日時点で最新のデータ日は 8月30日でした
日付境界が太平洋時間（PT）。8月31日 00:19 JST に公開したページが、Search Console 上では 8月30日に計上されていました

つまり公開後に「表示され得た日数」は最大1日。この 0 は「効かなかった 0」ではなく 「まだ露出していない 0」 です。ここで No-Go を確定させていたら、まだ何も起きていない施策を失敗として畳んでいました。

判定日を6日後にずらしました。

0-3. 「期間が違う」0

Search Console の検索パフォーマンスの URL に、期間パラメータを付けて開いていました。

.../performance/search-analytics?resource_id=sc-domain%3Aexample.com
  &start_date=2026-08-20&end_date=2026-09-02

このパラメータは無視されます。 既定の28日間にフォールバックしていて、実際に返っていたのは 8/3〜8/30 でした。指定した14日間ではなく、28日間の合計を「直近の数字」として読んでいたことになります。

確かめ方は1つだけです。

&breakdown=date

日別に落とせば、先頭行と末尾行で実際の期間が分かり、同時に最後にデータがある日も分かります。以後、期間を触ったら必ず最初に breakdown=date を見るようにしました。

0-4. 「粒度が違う」数字

コミットメッセージに「あるページのクエリが表示20・平均掲載順位6.6」と自分で書いていました。

後から breakdown=page で確認したら、そのページの28日間の表示回数は 0。ページ表に1行も出てきません。

20という数字は、そのクエリに対するサイト全体の表示回数でした。クエリ単位の数字を、ページ単位の実績として引き継いでいたわけです。

Search Console はクエリ・ページ・国・デバイスで別々に集計します。クエリの数字とページの数字を掛け合わせた行は存在しません（フィルタを掛ければ交差は取れますが、素の表を並べただけでは交差になりません）。

0-5. 「二重に数えた」数字

逆方向の間違いもありました。

同じアフィリエイトリンクのクリックで、aff_click と rakuten_click の2つのイベントが同時に飛んでいるサイトが1本ありました。片方は旧実装の残骸です。

このとき、レポートで両方を足すとクリック数がちょうど2倍になります。しかも「2倍」は一見それらしい数字なので、気づく手がかりがありません。

見つけ方は単純で、本番のDOMで gtag をスタブに差し替えて1回クリックするだけです。

// 本番ページの devtools で。実HITは1件も送らない
const sent = [];
window.gtag = (...args) => sent.push(args);
// …実際にリンクを1回クリック…
console.log(sent);   // 1クリックで2件出たら二重送信

「実装したから送られているはず」と「1クリックで何件送られるか」は別の問いです。後者は本番でしか確かめられません。

0-6. 「基準を知らない」0

最後は Qiita 自体の話です。この1本前に投稿した記事が、2.2日で PV 544 / LGTM 0 / ストック 0 でした。

「読まれているのに反応が1件も無い＝中身が刺さっていない」と読みかけました。

その前に、比較対象を実測しました。Qiita API は認証を付けると自分の記事の page_views_count が返ります（無認証だと null）。他人の記事のPVは非公開ですが、LGTM とフォロワー数は誰でも取れます。

# 同じタグの直近1週間の記事を200本取る
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://qiita.com/api/v2/items?query=tag:ClaudeCode+created:%3E2026-08-25&per_page=100&page=1"

結果（ClaudeCode タグ・2026/08/27〜09/02・n=200）：

指標	値
LGTM 中央値	0
LGTM が 0 の記事の割合	69.5%
LGTM 5以上の記事の割合	6.5%

LGTM 0 は例外ではなく中央値でした。

さらに、LGTM 5以上の記事（13本）と LGTM 0 の記事で著者のフォロワー数を比べると、

群	著者フォロワー数の中央値	本文長の中央値
LGTM 5以上	109	4,654字
LGTM 0	0.5	5,348字

本文長では差が付かず（LGTM 0 の群のほうがむしろ長い。14,529字で19 LGTM の記事もありました）、フォロワー数のほうにはっきり差が出ました。相関であって因果ではありませんが、少なくとも「0 だから中身が悪い」という読み方は、この分布の上では支持されません。

比較対象を取る前に自分の 0 を解釈しようとしたのが間違いでした。

本物の 0

ここまでの6件は読み違いでしたが、1件だけ本物の 0 がありました。

その 544 PV の記事から、自分のサイトへの流入は 0 です。

実測項目（2026/08/31〜09/02）	値
記事のPV	544
はてなブックマーク数（`bookmark.hatenaapis.com/count/entry`）	0
GA4：`qiita.com` からの参照セッション（自分の3プロパティ合計）	0
記事から張った先（別サービスの記事）の全期間PV	12

理由は測る前から構造で決まっていました。その記事に置いた外部リンクは1本だけで、しかも GA4 を入れていない別サービス宛てだったからです。GA4 を入れているサイトへのリンクは、記事中に1本もありませんでした。

つまり「送客が 0 だった」のではなく、送客が発生し得ない設計だった。0-1 とまったく同じ間違いを、今度はリンクの張り先でやっていたことになります。

ついでに rel も確かめました。

curl -s "https://qiita.com/<user>/items/<id>" \
  | grep -oE '<a[^>]*href="https://[^"]*"[^>]*rel="[^"]*"' | head
# => rel="nofollow noopener"

外部の記事プラットフォーム側も同じく rel="nofollow" でした。SEO評価は渡りません。 外部プラットフォームは被リンク源ではなく、referrer を運ぶ導線として見るのが正しかったです。referrer 自体は noopener では落ちません（noreferrer なら落ちる）。したがってリンク先に GA4 が入っていれば qiita.com / referral として計上されます。入れていれば、の話ですが。

判定前チェックリスト

同じことを繰り返さないように、数字を読む前に通すリストを作りました。

その指標を送るコードは実在するか（本番DOMで1回発火させて確認したか）
1アクションで何件送っているか（二重送信していないか）
データの最終日はいつか（Search Console は約2日ラグ・PT境界）
その期間指定は本当に効いているか（breakdown=date で実期間を見たか）
その数字の粒度は何か（クエリ／ページ／サイト全体を混ぜていないか）
比較対象の分布を取ったか（0 が異常値なのか中央値なのか）
測りたい経路にリンクは存在するか（0 は「踏まれなかった」ではなく「無かった」かもしれない）

6件は、それぞれ別の行に対応しています。逆に言うと、1行でも飛ばすとどれかを踏みます。

計測は、実装より読み方のほうが壊れやすいという話でした。特に 0 は「異常が無い顔をした異常」 なので、エラーにならないぶん厄介です。

なお、こうやって数字を洗い直す作業自体を自動化した記録（実装とプロンプトを全部載せています）は別途こちらにまとめてあります → https://note.com/fujiken818/n/n7f126d2e8522?utm_source=qiita&utm_medium=article&utm_campaign=note_ai_980&utm_content=qiita_002

この記事でやった「外部リンクと計測の全数チェック」は、他の方のサイトでも単発の監査として引き受けています（1サイト ¥55,000）。表示速度ではなく、可読性・タップ標的・重複・計測もれを実測して、直す順に並べるやり方です。見る項目と料金の目安 → https://mainichi-lab.com/contact?utm_source=qiita&utm_medium=article&utm_campaign=work_inquiry&utm_content=qiita_002_contact