自分の site: 検索が Search Console を汚染していた｜平均26.5位は、汚染ゼロの日には62.2位だった

インデックスされているかを確かめたくて、site: に自分のドメインを付けた検索を何度も打っていました。定番の確認手順として、あちこちに書いてあるやり方です。

その検索が、Search Console のページ別データに残っていました。 そして残ったせいで、このサイトの最優先KPIである「掲載順位11〜30位の記事を探す」という判定が、成立しなくなっていました。

結論：site: は「インデックス確認」の代わりに「順位データ」を差し出している

以下の数字はすべて、2026年8月22日に Search Console（zaitaku-labo.com プロパティ）を実査した記録です（出典: state/metrics/daily/2026-08-22.md）。

気づいた入口：表示34回なのに、ページ別テーブルが53行あった

最初におかしいと思ったのはここです。3か月窓（実データは8/16〜8/19）で、サマリは次のようになっていました。

表示が34回しかないのに、ページ別のテーブルは53行ありました。 1ページあたり1回未満の表示で53ページが並ぶのは、通常の検索では起こりません。

行の中身を見ると、理由は1つしかありませんでした。表示1回のページの掲載順位が、ほぼ完全な連番になっていたのです。

3, 5, 6, 7, 10, 12, 13, 15, 16, 18, 19, 20, 21, 22, 23, 24, 25, 26,
28, 29, 30, 31, 32, 34, 35, 36, 38, 39, 40, 41, 44, 45, 46, 47, 48, 49, 50, 51

53行のうち 38行がこの連番ラダーでした。順位の3番目・5番目・6番目……に、それぞれ別のページが1回ずつ表示されている。これは検索結果の1ページ目から順にサイト内の全URLが並んだときの形そのものです。

なお、この連番が site: 由来であるという因果は、観測された形からの解釈です（推測）。断定できるのは「38行が連番だった」ところまでです。ただし後述のとおり、site: を打つのをやめた翌日に連番が消えたので、解釈としては強いと考えています。

クリック5件も、読者ではなかった可能性が高い（推測）

同じ期間のクリックは5件で、CTRは14.7%でした。立ち上げ期のサイトとしては良すぎる数字です。ページ別に割るとこうなります。

CTR 50% / 25% / 100% は、自然な検索行動から出る値ではありません。 site: の検索結果を自分でクリックしたものとみられます（推測）。運営者はイギリス在住で、日本語クエリからの流入とは考えにくい、という状況証拠も同じ方向を指しています。

ここは断定しません。断定できるのは実測されたCTRの値までで、「自分のクリックである」は解釈です。 観測と解釈を混ぜて重大な結論に使い、後で誤診だったと判明した経験があるので、この線は毎回引くようにしています（AIの成果物は目視で検証しない）。

判別ルールを2日で3回作った。最初の2回は実データで壊れた

汚染が分かった以上、毎朝の分析スクリプトが自動でこれを弾けないと意味がありません。 分析は毎朝8時に自動実行しているので、人が毎回目で見て判断する運用は成立しません（AIエージェントの定時実行）。

そこでルールを書いたのですが、2日で3案出して、最初の2案が実データで壊れました。

① 表示5回未満は順位として読まない（2026-08-21）

最初に入れたのは件数のしきい値です。MIN_IMPRESSIONS_FOR_RANK = 5 として、「表示が5回に満たないページの掲載順位は採用しない」としました。連番ラダーの行がすべて表示1回だったので、これで落ちるはずでした。

翌日の実データで素通りしました。

表示10回はしきい値の倍です。しきい値は「1回しか表示されていない行」しか落とせません。 同じ日に別のセッションで打った site: が積み上がれば、1ページの表示は簡単に2桁になります。

前日のテストは、8/20の実データ51行を fixture にして全項目パスしていました。回帰テストは既知の失敗しか守りません。 穴は fixture の外にありました。

② 整数ちょうどの順位を疑う（2026-08-22 未明）

次に考えたのが「順位が整数ちょうどなら怪しい」でした。site: は毎回同じ並びを返すので、複数回表示されても順位が動かず、平均が割り切れた値になるはずだ、という理屈です。実際 desk-takasa-tekisei の 24.0 はぴったり整数でした。

同じ日の朝、7時間後に反証されました。

日別に割ると、24.0 は4日ぶんの加重平均でした。

(3 × 10.7 + 1 × 11.0 + 4 × 9.0 + 2 × 80.5) ÷ 10 = 24.01

小数第2位まで出すと 24.01 で、表示上 24.0 に丸められていただけでした。整数だったのは偶然です。 そして同じルールは逆側でも外します。

zaitaku-hirune-kamin は 13.5 で非整数ですが、後述のとおりクエリが1件も紐づいていません。②は偽陽性と偽陰性を同時に出します。 提案から反証まで7時間でした。

③ そのページに紐づくクエリが0件なら、順位を読まない（2026-08-22）

3案目で、相関ではなくデータの出どころを見るようにしました。

Search Console でページ別に表示がある3本について、そのページに絞ってクエリを見ると、こうなりました。

該当3本すべてを、確定的に判別できました。 ①も②も取りこぼした2本が、この軸では一発で落ちます。

理由は単純で、site: 検索の表示はクエリ次元に記録されないからです。ページ別には表示が立つのに、クエリ側には何も出ない。この食い違い自体が指紋になります。

「①件数 → ②整数 → ③クエリの紐づき」という3手の違いは、相関を見ていたか、出どころを見ていたかです。①と②は「汚染されたデータはこう見えるはずだ」という予想でした。③は「site: の表示はクエリとして記録されない」というデータの作られ方を使っています。

汚染をやめた翌日、初めて素の数字が読めた

site: を打つのをやめました。その翌日の 8/20 が、新ドメインで初めて汚染ゼロの1日になりました。

同じ期間を28日窓の平均で見ると、クリック5・表示40・平均26.5位です。日別で見ると 62.2位。

同じデータが、読み方だけで2倍以上ちがって見えていました。

内訳はこうなります。

• 28日合計 表示40・クリック5
• うち実オーガニックは 8/20 の 6表示（15%）だけ
• クリックは 8/20 が 0。つまり クリックの100%が自分の site: 由来

表示の85%とクリックの全部が、自分の確認行動でした。

実オーガニックのクエリは、4語しかなかった

汚染を除いた 8/20 の6表示に紐づいていたクエリの全量です。

4語すべて34位以下です。 平均20.1位・26.5位という数字を見ていたときに立てていた計画（あと一押しで1ページ目に入る記事を探してリライトする）は、そもそも対象が存在していませんでした。

この「11〜30位のリライト対象が0本」という状態自体は、キーワードの選び方が原因で以前から続いていました（AIに74本書かせたら、検索に出ていたのは3ページだけだった）。今回分かったのは、汚染された数字がその0本を「3本ある」ように見せていたことです。原因が2つ重なっていて、片方が片方を隠していました。

実装：page と query を同時に取れば判定できる

Search Console API では、dimensions に page と query を両方指定した問い合わせを1回足すだけで済みます。ページ別の表示合計と、クエリ付きの表示合計を突き合わせる形です。

// `site:` 検索の表示はクエリ次元に記録されない。よって
// 「ページ別に表示があるのに、そのページに紐づくクエリの表示が0」なら通常の検索ではない。
const attributed = new Map();
for (const r of (p.pageQueries || [])) {
  const url = r.keys[0];
  const cur = attributed.get(url) || { impressions: 0, queries: [] };
  cur.impressions += r.impressions;
  cur.queries.push({ query: r.keys[1], impressions: r.impressions, position: r.position });
  attributed.set(url, cur);
}
const attrImp = (url) => (attributed.get(url) || { impressions: 0 }).impressions;
const real = p.pages.filter((r) => attrImp(r.keys[0]) > 0);

①のしきい値は消していません。残しても害はありませんが、単独では効きません。 実オーガニックの表示を数えた後の母数に対して掛けるようにしました。

回帰テストには、この日に自分を騙した3本をそのまま fixture として入れました。

desk-takasa-tekisei     10表示・24.0位  → 候補に出ないこと
zaitaku-hirune-kamin     6表示・13.5位  → 候補に出ないこと
zaitaku-heya-layout-semai 4表示・26.0位 → 実オーガニック1表示だけを採用すること

テストは12件全通過しています。ただし前回も fixture では全項目パスしていました。「テストが通った」は「そのとき想像できた失敗は起きない」以上のことを言っていません。 検査スクリプト自体がバグる話はAIに記事を書かせると被リンク0の孤児が量産されるにも書きました。

代わりに何で確認するか

site: をやめても、インデックス状況は確認しなければなりません。汚染しない手段が3つあります。

3つ目は自作の health-check.js で、ログイン不要で配信・被覆率・収益経路・画像枚数を出します。ただしこれには流入・順位・CTAは原理的に出せません。 用途を取り違えると、また別の「測れているつもり」が生まれます。

置き換えの効果は翌日に出ました。site: を打つのをやめた 8/20 は、表示6回・クリック0で、連番ラダーが出ませんでした。 前日までの3日間は毎日ラダーが立っていたので、汚染が止まるまでのラグは1日でした。

そもそも主指標を Search Console に置いたのは、GA4ではクローラも読者も分離できなかったからでした（GA4だけ見るとクローラは見えない）。測る道具を変えたら、今度は測る側の行動がデータに入っていたという順番です。

やりがちな失敗

まとめ

• site: 検索の表示は Search Console のページ別テーブルに載る。実測で53行中38行が連番ラダー（3, 5, 6, 7, 10, 12, …, 51）
• 判別ルールを2日で3回作り、最初の2回が実データで壊れた。①表示5回未満を除外 → 10表示で素通り ②整数の順位を疑う → 7時間後に反証（24.0 は 24.01 の丸め）
• 残ったのは「そのページに紐づくクエリが0件なら順位を読まない」。該当3本すべてを確定判別
• ①②は相関を見ていた。③はデータの作られ方を見ている。小さい母数では、それらしい形は偶然に発生する
• 汚染をやめた翌日に、初めて素の数字が読めた。8/20は 6表示・0クリック・平均62.2位。同じ28日平均は26.5位で、実勢を2倍以上よく見せていた
• 28日合計40表示のうち実オーガニックは6表示（15%）、クリックは100%が自分由来

インデックス確認としての site: 検索は、有害だとはどこにも書かれていません。実際、流入が十分にあるサイトなら誤差に沈みます。自分の数回が全体の85%を占める規模では、確認行動そのものが観測対象を書き換えます。 測る側が測られる側に入っていないかは、道具を変えるたびに1回確かめる価値がありました。