WEBサイト
自社で運用している別サイトのアクセス解析ダッシュボードを、朝いちばんで開いた。前日のページビューの欄に「0」と並んでいた。もともと数字は一桁二桁で動いているだけの、まだ育っている途中のサイトなのだが、それでも「0」という数字は見たことがなかった。担当から「アクセスが0になっているんですが、これは何か壊れているんでしょうか」と聞かれて、その日の最初の仕事は、記事のことでもコンテンツのことでもなく、「本当に0なのか、それとも計測のどこかが壊れているのか」を確かめることになった。
朝、管理画面に並んだ「0」
「本当に0なのか、何かが壊れているのか」を先に切り分ける
「0」という数字には、大きく分けて二つの可能性がある。一つは、本当にその日 誰も来なかったという可能性。もう一つは、来てはいたのに、それを数える仕組みのどこかが途中で止まっていて、正しく記録されなかったという可能性。後者だとしたら、直すべきなのは記事の内容でもコンテンツの質でもなく、計測の配線そのものだ。だからまず、疑うべき場所を一つずつ確かめていくところから始めることにした。焦って「アクセスが減った理由」を考え始める前に、そもそも「本当に減っているのか」を確認するのが先だ。ここの順番を間違えると、存在しない原因を探して丸一日を溶かすことになる。
正直に言うと、担当から聞かれた瞬間は「たまたまサーバーの調子が悪かっただけだろう」と、根拠もなく決めつけそうになった。だが、それだと「なぜ今日だけ」の説明がつかない。何かの障害でサーバーが止まっていたのなら、他のサイトや他の機能にも影響が出ているはずだが、そういう報告は他に一つも上がっていなかった。だから「サーバー全体の障害」という仮説も、早い段階で候補から外した。
ちなみにこれは、以前 archives/122「『順位が落ちた』と騒がれた週、Googleの公式は何も言っていなかった ── 変動と、自分に起きたことを切り分ける」で書いたのと同じ考え方だ。「何かがおかしい」と感じたときにまずやるべきなのは、原因を推測することではなく、事実そのものを段階ごとに切り分けることだと思っている。今回の「0」も、原因を決めつけてから調べ始めるのではなく、まず「どの段階までは正しく動いているか」を一つずつ確かめる順番で進めることにした。
もう一つ、この段階で意識していたことがある。それは「壊れている」と「壊れていない」のどちらの結論が先に見つかっても、それを最終結論にしないということだ。もし最初の1つ目の層でエラーが見つかっていたら、そこで安心して調査を打ち切っていたかもしれない。だが、もし他にも壊れている層があったとしたら、1つ直しただけで「解決した」と勘違いして終わっていたはずだ。だから今回は、途中で1つ見つかった時点で止めず、5つの層を最後まで通して確認する、という進め方にした。
計測の仕組みを5層に分けて、順番に確認した
アクセス解析の数字は、1つの箱の中だけで完結しているわけではない。ページに埋め込んだタグから、それを定期的に取りに行く処理、値が0で返ってきたときの扱い、過去分をあとから取り直す仕組みまで、いくつもの層が縦に積み重なって、最終的に画面に表示される「0」という数字になる。だから「0」の原因を探すときは、この層を上から下へ、1つずつ確かめていく必要がある。どこか1層だけを見て「大丈夫だった」と判断してしまうと、実はその下の層が止まっていた、ということに気づけない。
5つの層を、1つずつ確かめていく
今回は、次の5つに分けて見ていった。それぞれの層は役割が違っていて、どれか一つでも欠けると、正しい数字にたどり着けなくなる。
| 層 | 確認したこと | 結果 |
|---|---|---|
| ① サーバーのアクセスログ | その日のリクエストが記録されているか | 記録されていた |
| ② 計測タグ | ページに正しく埋め込まれているか、データストリームの設定が合っているか | 正常だった |
| ③ 定期取得の処理（cron） | 実行されているか、エラーが出ていないか | 実行されていた |
| ④ ゼロ上書き防止の仕組み | 集計値が0で返ってきたとき、既存の値を上書きしないか | 正しく機能していた |
| ⑤ 過去日の取り直し（backfill） | 直近6日分を取り直す設定があるか | 有効だった |
結果としては、5つとも「正常」だった。サーバーには前日のリクエストがちゃんと記録されていたし、ページのソースを見てもタグは正しい形で埋め込まれていた。定期的にデータを取りに行く処理もエラーを吐かずに動いていたし、集計値が0で返ってきたときに前の値を上書きしない仕組みも、実際にログを見ると想定どおりに発動していた。直近数日分を取り直す設定も、有効になっていた。特に④のゼロ上書き防止と⑤の取り直しは、「一時的に0が返ってきても、正しいデータが来たときに自動で埋め直す」ための保険のような仕組みだが、この保険が正しく動いていたということは、少なくとも「一度 壊れて、そのまま放置された」わけではないことを意味する。
この5つの層は、それぞれ確認する場所も方法もまったく違う。サーバーのログはサーバーに直接入って見るしかないし、計測タグはページのソースコードを開いて目で確認する。定期取得の処理は実行記録を追い、ゼロ上書き防止と取り直しの仕組みは、それぞれの設定と、実際に過去のデータがどう埋まっているかを突き合わせて確認する。この5つを全部 確認し終えるまでには、それなりの時間がかかった。だが、ここを飛ばして「たぶんタグの設定だろう」と当たりをつけて1箇所だけ見て終わらせていたら、5つのうち4つが正常であることに満足して、本当の原因である「誰も来ていなかった」という可能性には、たどり着けなかったと思う。
5層とも正常。それでも数字は0のままだった
「壊れている」という前提が外れた瞬間
ここまで確認して、正直 少し困った。てっきりどこかの層で処理が止まっていて、それを直せば数字が戻るはずだと思っていたのに、確認した5つの層は、どれも「正しく動いている」という結果しか出てこない。動いているのに0が出る、というのはどういうことなのか。
ここで、「壊れているはずだ」という最初の前提を一度 脇に置いて、別の可能性を考える必要が出てきた。仕組みが正しく動いているのに0が出るのだとしたら、残っている説明は一つしかない。「本当にその日は、誰も来なかった」という可能性だ。これは受け入れるのに少し時間がかかった。5つの層を確認するのに使った時間より、「壊れていない」という結論を受け入れるほうに、正直もう少し時間を使った気がする。人はどうしても「原因が見つかった」という達成感を求めてしまうもので、「調べたけど、全部 正常でした」という結論は、拍子抜けするぶん、素直に受け止めにくい。
仕組みを疑うのをやめて、その日に実際に何が起きていたのかを、もう一段 手前から見直すことにした。仕組みの中を探すのではなく、仕組みが受け取っていた「入力そのもの」を見に行く、という向きの転換だった。
そこで「誰が来ていたのか」を、日付ごとに数え直した
bot以外のアクセスは、たった2件だった
サーバーのアクセスログから、その日 実際に誰が来ていたのかを、自動巡回プログラム（bot）を除いて数え直してみた。検索エンジンのクローラーや、各種の巡回プログラムからのアクセスは、人間の訪問とは性質が違うので、いったん脇に置く。残ったのは、たった2件だった。仕組みは正しく「0件」ではなく、正しく「ほぼ0件だった」を伝えていた、ということになる。
その2件は、サーバー自身の死活監視だった
その2件の中身を見ると、どちらも同じ場所からのアクセスだった。サーバー自身が「自分は正常に動いているか」を確認するために、定期的に自分自身へアクセスする仕組み（死活監視）からのものだった。これは人が読むためのアクセスではなく、システムが自分の健康状態を確認するための、いわば独り言のようなアクセスだ。つまりその日、社内外を問わず、人がそのサイトを見に来た記録は1件も残っていなかった。数字が「0」だったのではなく、実質「0」に限りなく近い日だった、ということだ。
前日の218件を、もう一度 数えてみた
218件、全部が同じ場所から
気になったので、その前日についても、同じやり方で数え直してみた。前日はbot以外のアクセスが218件あった。この数字だけを見ると、「ああ、前日は普通にアクセスがあったんだな」と思ってしまう。ところが内訳を見ると、この218件は全部、同一の回線からのアクセスだった。社内の誰かが、その日ずっとそのサイトのページを開いたり閉じたりしていた、という形の数字だった。
「見えていた数字」の正体
ここでようやく、話の輪郭がはっきりした。「その日だけ0だった」のではない。「その日は、社内の誰も見に来なかった日」だったのだ。そして逆に言えば、それまで管理画面に表示されていたページビューの数字は、ほとんどが自分たち自身のアクセスだった、ということになる。読者が来ていたわけではなく、自分たちが自分たちの数字を見て、それを「アクセス」だと思い込んでいたことになる。
これは archives/136「『AIからの流入60件』を数え直したら、60件ともAIが自分の名前を名乗った文字列だった」で書いた形と、根っこの部分がよく似ている。あの記事では、「流入元」の欄に入っていた文字列が、実は外部からの紹介ではなく、AIの巡回プログラムが自分の名前を自己紹介として残した記録だった。見えている数字の「中身」を確かめずに、数字そのものを信じてしまうと、同じ落とし穴に落ちる。今回は流入元ではなく訪問者そのものが、自分たち自身だったという違いはあるが、「見えている数字＝読者の数」だと決めつけてはいけない、という点は同じだった。
そして、これは今回に限った話でもない。数字が小さいサイトほど、この落とし穴にはまりやすい。読者の数が少ないぶん、社内の確認作業や、担当者自身の閲覧が、全体に占める割合として大きく出てしまうからだ。1日1,000件の訪問があるサイトなら、社内の2〜3件のアクセスは誤差に埋もれる。だが1日の訪問がもともと数十件しかないサイトでは、その数件が全体の数字を大きく動かしてしまう。
Google アナリティクス4の「内部トラフィックの除外」は、2段階に分かれている
ここまでで、原因ははっきりした。数字がおかしかったのではなく、数字の中身がずっと自分たち自身だった。ならば次にやることは一つで、自分たち自身のアクセスを、計測結果から除外する設定を入れることだ。Google アナリティクス4（GA4）には、自社のアクセスを除外するための仕組みが用意されている。ただし今回 手を動かしてみて分かったのだが、この設定は2つの独立した操作に分かれている。
1段階目：内部トラフィックの定義
まず、管理画面の「データストリーム」→「タグ設定」→「内部トラフィックの定義」で、どのIPアドレスを「内部」とみなすかを登録する。ここではIPアドレス、またはIPアドレスの範囲を指定し、それに一致するアクセスに「internal」（または任意の値）という印を付けてもらう設定を作る。この時点では、まだ何も除外されていない。あくまで「これは内部です」という印を付ける準備をしただけだ。この段階だけを見ると、いかにも「これで除外できた」ように感じてしまうのが、今回いちばんの落とし穴だった。
2段階目：データフィルタ
次に、管理画面の「データ設定」→「データフィルタ」で、実際にその印が付いたデータを除外するかどうかのスイッチを作る。ここが今回いちばん見落としやすかった部分だ。新しく作られたデータフィルタの状態は、最初「テスト」になっている。そして「テスト」の状態では、データは実際には除外されない。除外したとしたらどう見えるかを、レポート上で確認できるだけで、通常のレポートにはまだ反映されない仕組みになっている。
| 段階 | やること | この時点での効果 |
|---|---|---|
| 1. 内部トラフィックの定義 | 除外したいIPアドレス（範囲）を登録する | まだ何も除外されない（印を付ける準備だけ） |
| 2. データフィルタ（テスト） | フィルタを作成する。初期状態は「テスト」 | 除外された場合の見え方を確認できるだけ。通常のレポートには反映されない |
| 2. データフィルタ（有効） | 状態を「有効」に切り替える | 実際にデータが除外され、通常のレポートに反映される |
実際、今回 自分で新しく作ったフィルタも、最初は「テスト」の状態で作られていた。公式のヘルプページを見ると、フィルタの状態には「テスト」「有効」「無効」の3つがあり、テストの状態で内容を確認してから有効にする、という流れで使うことが前提の作りになっている（GA4データフィルタについて（Google公式ヘルプ））。内部トラフィックの定義そのものの手順は、内部トラフィックの除外（Google公式ヘルプ）にまとまっている。似た仕組みとして、社内の開発担当者からのアクセスだけを別に除外したいときのためのデベロッパートラフィックの除外という設定も用意されている。「内部の人」と「開発中に自分でテストしているだけの人」を分けて考えられるようになっている点からも、この仕組みが最初から「除外は慎重に、段階を踏んで行う」という考え方で設計されていることがうかがえる。
ちなみに、今回の「内部トラフィックの除外」は、検索エンジンにページを見せないようにする設定（noindexやrobots.txt）とはまったく別の話だ。前者は「自分たちのアクセスを、集計結果から除く」設定で、後者は「検索結果に、そのページを出さない」設定になる。この二つを混同すると余計にややこしくなるので、noindex・nofollow・robots.txtの違いは、別記事の「noindex・nofollow・robots.txtは、それぞれ何を止めているのか ── 混同しやすい3つの設定を確認する15項目」に整理してある。
新しく作ったフィルタは、既定で「テスト」のまま止まっている
「テスト」の状態では、除外されていないことに気づけない
ここがいちばん厄介なところだと思う。フィルタを「テスト」の状態のまま1ヶ月放置しても、エラーは一切出ない。管理画面のどこにも赤い警告は出ないし、レポートの見た目もいつもどおりだ。除外されていないことは、通知にもならなければ、他のどの数字にも波及しない。気づく手がかりは、フィルタの一覧を開いて「状態」の欄を自分の目で確認すること、それしかない。多くのシステムは「設定が中途半端だと警告を出す」という作りになっているが、この設定に関しては、中途半端な状態のままでも、システムとしては「正しく動いている」ことになる。「テスト」は正式な状態の一つであって、エラー状態ではないからだ。
これは以前 archives/121「『守る側』が動けなくなった週 ── 大手メディアのGoogle遮断検討と、同じクローラーという壁」で書いた話にも通じる。あの記事では、過去30日のアクセスのうち日本からの実ユーザーが1,348人中87人（6.5%）しかいなかった、という数字を出したことがある。あのときも、見えている数字の大部分が、想定していたのとは違う相手からのアクセスだった。規模も種類もまったく違う話だが、「見えている数字を、そのまま鵜呑みにしない」という点では同じ形をしている。
今日、実際に「有効」に切り替えた
今回は、その「テスト」の状態を確認したうえで、今日 実際に「有効」へ切り替えた。✅ 当サイト実施済 内部トラフィックの定義、データフィルタの作成、状態を「有効」への切り替えまで、当サイトでも同じ手順を今日 実行した。
ただし、正直に書いておきたいことがある。フィルタが除外の対象にするのは、「有効」に切り替えたあとに届いたデータだけだ。今日 有効にしたからといって、今日 これまでに集まったデータや、過去のデータが遡って除外されるわけではない。だから、この設定が本当に効いているかどうかを確認できるのは、丸1日 経った明日以降、正確には「有効にした日の翌日以降」の数字を見てからになる。今日の時点では「設定した」というところまでしか言えない。効果を確認する前に「対応済みです」と報告してしまうと、翌日の数字が思ったほど変わらなかったときに、また一から仕組みを疑い直すことになる。今回それを一度やりかけたので、あえてここに書いておく。
数える側でも、同じ日に3回 間違えた
ここまでの調べ物の途中で、自分の数え方のほうでも、3回 同じ形の間違いをした。同じ対象を、違う測り方で測ると、違う数字が出た。3つとも、どちらの数字も「嘘」ではなく、何を数えているかが違っていただけだった。仕組みを疑う前に自分の数え方を疑う、という話を上のほうで書いたが、実際には自分自身が、その日のうちに3回も同じ形でつまずいている。
IPアドレスのつもりが、ブラウザのバージョン番号だった
アクセスログから訪問者のIPアドレスを取り出そうとして、ログの行全体から「数字.数字.数字.数字」という形の文字列を探した。ところがこれをやると、ブラウザ情報の中に含まれるバージョン番号（たとえば「Chrome/152.0.0.0」のような表記）まで、IPアドレスとして拾ってしまった。見た目はどちらも「数字がピリオドで区切られた形」なので、機械的に探すと区別がつかない。実際に出てきた値を見て、「152.0.0.0」のように末尾が「.0.0.0」で終わる値がいくつも並んでいたので、これはおかしいと気づけた。もしブラウザのバージョンがもう少し不規則な数字だったら、気づくのがもっと遅れていたかもしれない。
本来やるべきだったのは、行全体から探すのではなく、ログの書式で決められた「決まった位置の列」を指定して取り出すことだ。アクセスログのどの位置に何の情報が入るかは、サーバー側の書式設定によって決まっている。Apacheの公式ドキュメントにも、次のように書かれている。
"The second argument specifies what will be written to the log file. It can specify either a nickname defined by a previous LogFormat directive, or it can be an explicit format string as described in the log formats section."
（日本語訳：第二引数は、ログファイルに何を書き込むかを指定する。これは、直前のLogFormatディレクティブで定義されたニックネームを指定することもできるし、ログフォーマットの節で説明されている明示的な書式文字列を指定することもできる）
つまり、ログの各列が何を意味するかは書式の定義そのもので決まっていて（mod_log_config（Apache公式ドキュメント））、「それらしい形の文字列を行全体から探す」というやり方は、そもそも列の意味を無視したやり方だった。列を指定して取り出すように直したら、正しい数字に戻った。
ちなみに、来ているのが本当に検索エンジンの正規のクローラーかどうかを厳密に確認したいときは、IPアドレスを一つ拾って終わりにするのではなく、逆引きと正引きの両方を突き合わせて確認する方法が、Google自身の公式ドキュメントで案内されている（Googlebotの確認方法（Google Search Central））。今回のような「自社のアクセスかどうか」の切り分けとは目的が違うが、「名乗っている名前をそのまま信じない」という考え方は共通している。
圧縮済みログの1世代が、集計から漏れていた
アクセスログは、日が経つと自動的に圧縮されて保存される仕組みになっている。集計するときに、圧縮済みのファイルだけをまとめて数えたところ、直近の1日分だけが集計から漏れていた。理由は単純で、圧縮の仕組み自体が「一番新しい1世代分は、まだ圧縮しない」という設定になっていたからだ。ログを圧縮したその日のうちに、また新しいアクセスが書き込まれる可能性があるので、直近の1本だけはしばらく生のまま残しておく、という設計になっている。圧縮ファイルだけを対象にすると、この「まだ圧縮されていない直近の1本」が、対象の外に置き去りになる。
実際に数えてみたところ、この漏れは全体の20.1%（5,554行）にあたった。件数としては小さくないのに、圧縮の仕組みそのものは正しく動いているので、これも「壊れている」わけではない。集計する側が、圧縮ファイルと生のファイルの両方を見ていなかっただけだ。圧縮済みのファイルと、まだ圧縮されていない生のファイルの両方を対象に含めて数え直したら、正しい件数に戻った。
バイト数とディスク占有量は別の数字だった
ログの容量を確認するときに、「実際のバイト数」で見た数字と、「ディスク上の占有量」で見た数字が、約2倍 違っていた。小さいファイルがたくさんある場合、ファイルシステムの最小割り当て単位（ブロックサイズ）の関係で、実際の中身より大きい容量をディスク上で占有することがある。1バイトのファイルでも、ディスク上では最小単位ぶんの容量を使う、というのはよくある話で、これは壊れているのではなく、そういう仕組みだ。GNU coreutilsの公式マニュアルにも、「見かけのサイズ」とディスク上の実際の使用量は別の概念であることが明記されている（du コマンドの公式マニュアル（GNU Coreutils））。どちらの数字も間違いではなく、「何を測っているか」を確認せずに片方だけを見て判断すると、実態を見誤る。
この3つに共通しているのは、「同じものを測っているつもりで、単位や範囲が違っていた」ということだ。数字がおかしいと感じたときは、数字そのものを疑う前に、自分がその数字を「どうやって取り出したか」を先に疑ったほうがいい。今回の3つは、どれも一度 気づいてしまえば単純な話だが、気づく前は「なぜこんな数字になるのか」がまったく分からず、それぞれ小さくない時間を使ってしまった。
そして気づいた3つとも、共通して助けになったのは「2つの数え方で測り直す」というやり方だった。IPアドレスの件は、行全体から探す方法と、列を指定する方法の2通りで数を比べたら、数字が食い違ったので気づけた。圧縮ログの件も、圧縮ファイルだけの件数と、生ファイルを含めた件数を比べて気づいた。バイト数の件も同じで、1つの測り方だけを信じていたら、どれも気づけないままだったと思う。1回だけ測って終わりにせず、できれば別の角度からもう一度 測ってみる。手間はかかるが、今回のような小さな見落としは、そうしないと表に出てこない。
当サイトが、今日ここまでやったこと
今回の件を通して、当サイト自身の設定も見直した。今の状態を、正直に書いておく。
✅ 当サイト実施済 内部トラフィックの定義（自社の回線を「internal」として登録）
✅ 当サイト実施済 データフィルタの作成と、状態を「テスト」から「有効」への切り替え
🔧 当サイト着手中 効果の確認。有効にしたのは今日なので、実際に除外されたデータで数字を見られるのは、早くても明後日以降になる
📋 予告 定期的にフィルタの状態を見直す運用（テストのまま放置されていないかを、月に一度チェックする形にする予定）
今まで見ていた数字がほぼ自分たちのアクセスだった、というのは、正直あまり気持ちの良い発見ではない。ただ、隠しても仕方のないことなので、そのまま書いておく。数字を除外した後の当サイトの本当の姿は、まだ自分でも見えていない。除外を有効にした直後は、これまでより数字が大きく下がって見えるはずだが、それは数字が悪化したのではなく、初めて本当の数字が見え始めた、ということだと理解しておきたい。
明日から、自分のサイトで確認できること
同じことをこれから確認する人のために、今回やったことをチェックリストにしておく。
| 確認項目 | 確認する場所 | 注意点 |
|---|---|---|
| 内部トラフィックの定義が登録されているか | 管理 → データストリーム → タグ設定 → 内部トラフィックの定義 | 登録しただけでは、まだ何も除外されない |
| データフィルタの状態 | 管理 → データ設定 → データフィルタ | 「テスト」のままでは除外は実行されない。エラーも警告も出ない |
| bot以外の実際のアクセス件数 | サーバーのアクセスログ | 行全体からIPらしき文字列を探さず、決まった列だけを取り出す |
| 圧縮済みログの取りこぼし | ログの保存ディレクトリ | 圧縮ファイルだけでなく、まだ圧縮されていない直近分も対象に含める |
サイト全体を一度に確認したいときは、当サイトの🔧 URLを入力するだけでSEO・パフォーマンス・セキュリティを一括チェックできる「WEBサイト総合分析・レポートツール」を使うと、アクセス解析以外の設定も含めて見直すきっかけになる。検索まわりの設定を合わせて確認したい場合は、🔧 「Google Search Console お助けツール」も併せて使うと、内部トラフィックの話とは別の「検索結果への出方」の状態まで一度に見られる。どちらも無料で使えるので、今回のような「数字が急に0になった」という場面に限らず、月に一度くらいのペースで開いておくと、変化に早く気づける。
まとめ ── 「0」は「壊れている」の証拠ではなかった
今回、いちばん時間をかけたのは「壊れている場所を直す」ことではなく、「壊れていない」ことを確かめることだった。サーバーのログ、計測タグ、定期取得の処理、ゼロ上書き防止、過去日の取り直し。5つの層は、最初から最後まで正常に動いていた。動いていなかったのは仕組みではなく、「見えている数字が、誰のものか」という前提のほうだった。
そしてもう一つ、今回はっきりしたことがある。GA4の内部トラフィック除外は、「登録した」だけでは終わらない、2段階の設定だということだ。1段階目（内部トラフィックの定義）だけをやって満足してしまうと、2段階目（データフィルタを「有効」にする）が抜けたまま、何も除外されていない状態がずっと続く。そしてその状態は、誰にも知らされない。気づくのは、自分でフィルタの一覧を開いて「状態」の欄を見たときだけだ。
アクセスが「0」だったこと自体は、悪いニュースではなかった。むしろ、それまで見えていた数字の中身に、初めて気づけたきっかけだった。数字が減ったように見えたら、まず疑うべきは仕組みではなく、その数字が「誰のものだったか」なのかもしれない。仕組みを疑って5層すべてが「正常」だったときこそ、次に見る場所は仕組みの中ではなく、仕組みが受け取っていた入力そのものだ、ということを、今回はあらためて覚えておきたい。
関連記事と出典
関連 archives（同じ考え方で書いた記事）
- archives/140『0件には三つの顔がある』と書いた記事が、三つ目の顔を踏んでいた ── サイトへのアクセスの94%を、52日間 見ていなかった ── 「見ている場所そのものが違っていた」という、今回とは別の角度からの0件の話
- archives/136「AIからの流入60件」を数え直したら、60件ともAIが自分の名前を名乗った文字列だった ── 見えている数字の「中身」を確かめなかった実例
- archives/135「測定中」と書いてあると、誰も測らなくなる ── llms.txtの52日分のログを、宣言から15日後に初めて開いた ── 「あとで確認する」と書いたまま放置していた話
- archives/122「順位が落ちた」と騒がれた週、Googleの公式は何も言っていなかった ── 変動と、自分に起きたことを切り分ける ── 推測より先に事実を切り分ける、という考え方
- archives/121「守る側」が動けなくなった週 ── 大手メディアのGoogle遮断検討と、同じクローラーという壁 ── 見えている数字の大部分が想定と違う相手だった、別の実例
