ブログの数字を月に一度まとめて見ています。
Search Console と GA4 から取って、どのページが読まれているか、どの記事に伸びしろがあるかを確認する作業です。
取得はスクリプトに任せて、出てきた表を一緒に読む形にしています。
その日も同じように進めていたら、報告の中に一行ありました。
「Search Console にプロパティが0件登録されています」
画面を出したら4件ありました
心当たりがなかったので、ブラウザで Search Console を開いて画面を見せました。
プロパティは4件登録されていました。
このブログと、ポートフォリオのサイトと、作っているアプリの分です。
どれも前から入れてあって、消した記憶もありません。
開いていたのは新規追加を案内するページのほうでした。
プロパティをまだ持っていない人に「追加しましょう」と促す画面で、ここには登録済みの一覧が出ません。
あの画面は登録済みのプロパティを数える場所ではないので、0件と出るのが正常な動きでした。
同じ日に、同じ形がもう一度出ました
その日は記録の中のリンク切れを直していて、消えたファイルの行き先を git で追う作業もしていました。
37件が見つかりません。
削除されたファイルを探すつもりで、こう打っていました。
git show --name-status --diff-filter=D <コミット>0件でした。
git はファイル名が変わっただけのものを、リネームとして扱います。
リネームは R というステータスになるので、削除（D）だけを通すフィルタには最初から出てきません。--no-renames を付けて同じコミットを見ると、今度はまとめて削除として出てきます。
ファイルは消えていませんでした。
英語のファイル名が日本語のタイトルに変わっていただけです。
探し方の射程が、その変化に届いていませんでした。
報告そのものは、どちらも正しい
ここが厄介なところだと思っています。
新規追加のページには、確かにプロパティが0件表示されていました。--diff-filter=D も、確かに0件を返しました。
数字としては嘘がありません。
間違っていたのは、その0件を「Search Console に登録がない」「ファイルは消えていない」と読み替えたところでした。
見た場所が答えの出る場所だったかを、確かめないまま次に進んでいます。
自分も同じことをよくやります。
grep で引っかからないと、無いと思ってしまう。
引っかからなかったのは書き方のほうかもしれないのに、検索した事実のほうを根拠にしてしまうんですね。
「0件」は、見た場所とセットで意味を持つ
今回は画面を出したので気づきました。
報告の文だけを読んでいたら、そのまま確定していたと思います。
「登録されていないなら登録しよう」と進んで、二重に登録していたかもしれません。
0件は結論ではなくて、どこを見て0件なのかとセットで初めて意味を持つ。
そこが抜けると、数字は正しいまま結論だけが外れます。
