JavaScriptなしでのボット検出：私のブログが測定したこと

JavaScriptなしでのボット検出：私のブログが測定したこと

私のブログでは、ネットワークとリクエストヘッダーのルールにより、372件のブラウザUser-Agentリクエストのうち277件（74.5%）を「ブラウザ」カテゴリから除外しました。これにより、Cloudflare Workerに届くトラフィックについて、より有用な分析が可能になりました。ただし、これによりサイトを閲覧した人の数が正確にわかったわけではありません。同じ2日間の期間で、残りの95件のブラウザHTML観測値は、14件のCloudflare Web Analyticsページロードとは依然として一致しませんでした。有用な結果は、どのリクエストがルールによって分離され、なぜ分離されたのか、そして証拠がどこまで有効かを知ることです。

• ネットワーク証拠は、ヘッダーチェックを通過したリクエストを捕捉します。 その期間中、60件のクラウド分類されたリクエストは、ブラウザルールが要求するナビゲーションヘッダーを運んでいました。
• 各分類に理由があることで、カウンターは説明可能になります。 それは間違いも露呈しました。HTML受け入れチェックが有効なヘッダーを誤って処理したり、新しい行にネットワーク出所のマーカーが欠けていたりしました。これらはすべて修正済みです。
• クライアントの識別と読者数は異なる証拠を必要とします。 9件の保存された署名検証は、クローラーや意図的なテストを含む署名者を識別します。これらは、アシスタントに読み取りを依頼する人を数えるものではありません。
• 残りの不一致は測定された問題です。 ブラウザ数の減少やスクリプトカウンターとの一致のどちらも、オーディエンスの精度を確立するものではありません。

スクリプトカウンターとのエッジページビューの比較

2つのカウンターを比較したことで、私のファーストパーティ分析の問題が明らかになりました。私はブラウザのUser-Agentを読者の証拠として扱っていました。カウンターは異なるイベントを測定するため、その不一致は調査の出発点となります。それ自体では、どのリクエストが自動化であったかを教えてくれるものではありません。

最初の警告は、9月3日に保存されたこの比較から来ました。

578対52の差は、11倍の読者数のように見えました。しかし、日次クライアント識別子は訪問ではなく、時間枠も同一ではなく、スクリプトダッシュボードには/statsが含まれていました。より比較可能な1,209対113のページ合計でも、これらの資格が必要でした。元のクエリレコードは、行われた比較を保持しています。

リクエスト内には、より強力な証拠がありました。9月2日、113の日次クライアントのうち100が1ページをロードしました。164のブラウザ-UAページ観測値のうち156にはリファラーがありませんでした。これらの事実だけでは自動化を確立できませんでした。しかし、モバイルとして分類された1つのクライアントは、同じタイムスタンプ秒で31の異なるページを取得しました。その夜の私のメモは次のとおりです。

今日、日次クライアントが113件見られますが、それは信じられないほどです。どの記事を読んでいるのか、どこから来ているのかなど... 新しい記事を公開したばかりなのに、ビュー数トップのページに表示されていません... 何が起こっているのか... 記事を公開したとき、この特定の記事にどれだけの読者が来て、どのソースから来たのかを知りたいと思うことがあります。それを知ることは不可能です。しかし、それでも最も奇妙なのは数字です。誰がこれらの記事を読んでいるのか、それは狂っているように思えますが、感謝はしていますが、自分自身をガスライティングしたくはありません。何かが合っていません。

有用な比較には、比率を計算する前に4つの決定が必要です。

1. 同じホストと、開始を含み終了を含まないUTCウィンドウを選択します。
2. ページイベントとページロードを比較します。日次識別子と訪問を別々に報告します。
3. 各システムが除外するルート、応答タイプ、ボット、所有者、テストリクエストを記録します。サンプリング情報を結果とともに保持します。
4. 不一致のリクエストを検査し、可能な収集の違いをテストします。

Cloudflareは、スクリプトブロッカーやブラウザまたはネットワークの損失を、そのビーコンがページロードを見逃す理由として文書化しています。ブラウザキャッシュと異なる適格性も、エッジカウンターに対してチェックする必要があります。スクリプトは自動化されたブラウザで実行される可能性があります。これらの原因を分離する普遍的な比率はありません。Cloudflare Web Analytics FAQ、2026年9月6日確認。

この比較は、調査できる質問を明らかにします。この記事の以前のバージョンである2未満の検証しきい値はサポートされておらず、削除しました。

Cloudflare Worker内のリクエストルール

Workerは、記録されたリクエストの特性を分類します。クライアントが誰によって制御されているかを確立せずに、決定論的にルールを適用できます。このセクションは、分類子を実装する人向けです。測定された結果は、実装の詳細なしに読むことができます。エッジカウンターは、適格な成功したページ GET の後にD1観測をスケジュールします。プリフェッチ、/stats、APIルート、および非ページ応答を除外します。HTMLおよびネゴシエートされたMarkdownページ応答を含みます。直接の .md リクエストはこのカウンターの範囲外です。その収集境界は適格性コードに由来します。

4つの証拠源が分類にフィードされます。

1. ネットワークメタデータ。 Cloudflareはクライアントの自律システム番号（ASN）を提供します。これはエッジに到達するネットワークを説明します。クライアントはHTTPヘッダーを編集してそれを変更することはできませんが、別のネットワークまたはプロキシを通じてサイトに到達することはできます。それはオペレーターの目的を確立しません。
2. Fetch Metadata。 Sec-Fetch-Mode: navigate および Sec-Fetch-Dest: document はページナビゲーションを説明します。Sec-Fetch-Site は none、same-origin、same-site、または cross-site のいずれかです。分類子はそれを記録しますが、特定の値を要求しません。ヘッダー定義。
3. AcceptとAccept-Language。 ルールは、HTMLが受け入れ可能かどうか、および言語ヘッダーが存在するかどうかをチェックします。これらはリクエストの特性であり、注意の証拠ではありません。
4. User-Agent。 名前付きクローラーおよびアシスタントルールは、クライアントの宣言に一致します。同じ文字列は、以下で使用されるブラウザバージョンクレームも提供します。クライアントはそれを模倣できます。

D1は選択されたヘッダー、派生フラグ、名前、および分類理由を保存します。完全なUser-Agentは保持しません。既存のCloudflare運用ログには、追加のリクエスト詳細が含まれています。派生フラグを保存することは有用ですが、将来のすべてのパーサー変更を再現するのに十分な情報は保持しません。

ルール1：既知のホスティングネットワークをブラウザの形状の前に分類する。 署名および名前付きクライアントルールに続いて、キュレーションされたホスティングリスト上のブラウザ-UAリクエストは、ナビゲーションヘッダーチェックを通過した場合でも cloud-browser になります。元の72時間ログサンプル（9月3日終了）では、844件の成功したページGETのうち430件がホスティングネットワーク上のナビゲーション形状のトラフィックでした。最大のクラスターは、Chrome Mobile 114を主張する1つのGoogle Cloudクライアントに起因する374件のリクエストでした。ヘッダーの存在では、そのクラスターを分離できませんでした。元の測定とカバレッジ。

クラウドブラウザは、人のために有用な作業を実行している可能性があります。私はそのアクセスを記録し、可視化したいと考えています。ネットワークラベルはサイトへの到達方法を説明しており、それをブラウザから移動しても観測は削除されません。

キュレーションされたネットワークリストは、いくつかの共有サービスおよびコンシューマーVPNネットワークを除外します。広範なホスティングリストには、正当なブラウジングを運ぶネットワークが含まれる場合があります。リストのキュレーションは、反対のコストを受け入れます。一部の自動化は、リスト外のネットワークを通じて到達します。

ルール2：主張されたブラウザバージョンに対して欠落しているFetch Metadataをチェックする。 実装は、Chromium 76+、Firefox 90+、およびSafari/iOS 16.4+をチェックします。リクエストがこれらのエンジンのいずれかを主張しているが Sec-Fetch-Mode を欠いている場合、それは http-client となり、理由は no-fetch-metadata になります。古いまたは読み取れないクレームは legacy-browser を受け取ります。Fetch Metadataを持つリクエストがナビゲーションの組み合わせに失敗した場合、not-navigation-shaped を受け取ります。分類子コード。

これらのバージョンしきい値はブラウザサポートデータ（2026年9月6日確認）に従っています。それらは期待されるブラウザ機能を確立しますが、各リクエストを認証したり、すべての埋め込みクライアントに対してゼロ誤検出率を確立したりするものではありません。私たちは Sec-Fetch-User を要求しません。Safari互換性調査では、それなしで他のFetch Metadataヘッダーのサポートが見つかりました。

フォローアップ監査では、私たち自身の Accept チェックにも欠陥が見つかりました。元の extractRequestMetadata() は、Accept: text/html;q=0 に対して acceptsHtml: 1 を返し、Accept: text/* に対して 0 を返しました。前者はHTMLを明示的に除外し、後者はそれを許可します。部分文字列チェックは、HTTPの品質とメディア範囲のルールを無視していました。RFC 9110、Acceptセマンティクス; 記録された再現。

9月6日の修正により、品質、特異性、および一致する表現パラメータが評価されるようになりました。12件の選択されたローカル取り込みケースでは、7件の誤った受け入れ結果がゼロになりました。これは回帰チェックであり、本番のエラー率推定ではありません。実行された実験と成果物。保存されたブール値では、欠陥が影響した履歴リクエストの数を知ることはできません。

オープンソース分類子が貢献したもの

有用な先行技術は、この設計の特定の要素を提供しました。宣言されたボット検出、ネットワーク分類、および保持された理由です。私たちの調査では、この組み合わせが新しいものであるとは確立されず、他のすべてのカウンターが同じトラフィックを見逃しているとも確立されませんでした。

これらのソースは9月6日にチェックされました。改訂とソースの境界はピン留めされたレビューにあります。isbot は、認識を対象とする宣言済みクライアントに引き続き有用です。Anubisはアクセス制御の決定を行いますが、このカウンターはアクセスを保持し説明することを目的としています。

GoatCounterから採用した部分は、各分類に付随する理由でした。合計値が低いことはあまり意味がありません。リクエストのテーブルとそれらを分類したルールは、何が変更されたかを教えてくれます。

エージェント名、署名、およびリクエストの目的

サイトはすでに名前付きUser-Agentマッチを記録し、サポートされているWeb Bot Auth署名を検証しています。間違いは、それらのIDシグナルを、人がアシスタントに読み取りを依頼したことの証拠として扱うことでした。署名メカニズムは有用ですが、グループ化と用語の修正が必要です。

検証者が起動して以来の保存されたコホートでは、9月5日UTCまで、D1には verified 結果が保存された9件のリクエストが含まれています。

これらは保存された検証者の結果であり、すべての元の署名メッセージの新しい独立した再検証ではありません。コホートとクエリは意図的なテストを分離します。署名付きリクエストが到着しなかったという以前の主張は誤りでした。

署名付きクライアントはクローラーである可能性があります。ExaはExaSearchBotをページを取得してインデックス化するものとして文書化しています。署名は、検証者のチェックの下で、リクエストを署名IDに関連付けます。それは開始した人のID、委任、または目的を確立しません。バージョン化されたWeb Bot Authドラフトはこれらの境界を明示しています。それを引用することは、私たちの実装があのドラフトのすべての規定に準拠しているという主張ではありません。

現在の統計グループは、signed-agent と ai-assistant をAIエージェントの下で一緒に配置しています。そのグループ化は認証とクライアントの役割を混同しており、修正待ちです。通常の取り込みはUser-Agentルールに一致し、署名を検証します。それは、フェッチャーヘッダープローブ研究で手動で行ったベンダーIP検証を実行しません。

古い30日間のスナップショットは、8つのパスにわたる33件の ChatGPT-User マッチ観測、31のパスにわたる51件の PerplexityBot 観測、36のパスにわたる37件の Amazonbot 観測、および21のパスにわたる21件の GPTBot 観測を記録しました。これらは記録されたアクセスパターンです。それらは33件の人間による読書行動を確立するものではなく、同様のリクエスト/パス合計もクロールが発生した理由を独立して証明するものではありません。

これらのトラフィックすべてを保持する理由は、その背後にある公開の質問です。

ホーム接続上のヘッドレスブラウザ、例えばPlaywrightやCypress、あるいはあらゆる種類の自動化を使用するMeshclawsやHermessクラウドエージェントについても知りたいです。私たちはそれらを誤って数えたりブロックしたりしたくありません。それどころか、私はそれらを受け入れたいです。誰でも私の記事を読むことができます... 私は完全な可視性と透明性、そして分類を知る必要があります。つまり、誰が誰であるかを明確に知る必要があります（もちろん、PIIを尊重して）。しかし、多くの人々は直接記事を読むのをやめ、MeshclawsやHermesエージェントのようなクラウドで実行されるAIエージェントを使用して記事を読むかもしれません。そして、誰が何を読んでいるのかを知りたいです。つまり、人々が私の記事をどのように使用しているのかを理解しようとしています... 理想的には、私の記事の公式な引用のようなものも持てたらと思います。例えば、Arxivや研究論文に引用があるように？私もそれを受け入れたいです。人々が私のコンテンツを価値あるものとして読み、必要に応じて引用を推奨してくれるような、引用に関する可視性のようなもの。もう一つの例は、scholar.google.comが「引用数合計 51」のように表示することです。そのようなものがあれば素晴らしいでしょう。

その質問に対して、有用なテーブルは、主張されたクライアント、検証された署名者、文書化された役割、および直接知られているトリガーを区別します。通常の運用リクエストは通常、トリガーを不明のままにします。ID研究は、それを個別に調査できます。このカウンターを観察されていない読書行動のカウントに変えることなく。

ブラウザカテゴリが確立できないこと

ブラウザには、私たちのルールを通過したリクエストが含まれており、一部の自動化も含まれます。また、クラウドブラウザや異常なクライアントによる正当なアクセスを除外することもあります。そのエラーは両方向に発生する可能性があるため、確立された下限または上限ではありません。

私たちのフェッチャーヘッダー研究は、ブラウザUser-Agentとナビゲーションヘッダーを持つクライアントを介してGrokがフェッチしていることを捕捉しました。これには、ブラウザーのルールを通過したリクエストも含まれます。通常のブラウザを駆動するエージェントは、人間がブラウジングに使用するのと同じ特性を生成できます。アクセスは価値がありますが、ヘッダーだけでは、それが会話、スケジュールされたジョブ、または他のプロセスに従ったかどうかを明らかにしません。

新しい運用ウィンドウは、調査すべき具体的なケースを追加します。95件のブラウザ観測のうち22件は、uniuit.com リファラーと繰り返しのホームページ/記事パターンを共有しています。検査されたWorkerログは、Redroid Android WebViewを宣言しています。後続のゾーンデータ相関は、22件中19件の候補の中にその宣言を見つけました。診断証拠とマッチング制限。

これは自動化の調査をサポートしますが、認証されたオペレーターの名前を付けるものではありません。User-Agentは宣言であり、ゾーンマッチには共有リクエスト識別子がありません。これらの22件の観測すべてを感度計算として除外しても、73対14、つまり5.21倍が残ります。このクラスターを説明しても、全体の不一致は説明されません。

後続の修正は、参照スパムに対して分析を防御する方法でカバーされています。バージョン化されたレポートポリシーは、一致する観測を除外しますが、証拠を保持し、どのリファラー名が公開されるかを制限します。上記の履歴比較は、元のスコープを保持します。

有用なクレームは、読者数よりも狭いものです。これらのリクエストは、文書化されたルールを満たしました。そのカテゴリのどれだけが記事を消費している人々を表しているかを判断するには、ルールが収集しない証拠が必要です。

分類変更が履歴に与えた影響

分類の変更は、変更前に観測されたものを保持する必要があります。私たちの最初の修正では、古いオーディエンスがデフォルトビューから一時的に消え、その履歴を復元することは、ルールを改善することと同じくらい重要でした。

証拠列は古い行には存在しませんでした。最初のヘッダーとネットワークチェックが一緒にリリースされたとき、デフォルトの統計ビューにはその週の3ページビューが表示されました。

なぜすべてのビューがなくなったのですか（笑）... 正しく移行し、履歴ビューを維持する必要があります。たとえ誤って計算されていたとしても問題ありません。コミット履歴をたどって、何が起こり、なぜ起こったのかを完全に正直に知ることができます。

その週は戻ってきましたが、記録された時点での証拠でマークされました。新しいチェックに失敗したリクエストの最初の不成功な名前は、Browser-likeでした。

これは少し混乱します。「browser-like」と言うのは少し誤解を招き、自信が低いことを示唆します。ブラウザはどのようなものですか？決定論的にわかっていますか、それとも何ですか？ブラウザ ブラウザライク ボット AI UA すべて

もっと地に足をつける必要があります。

その信頼性ラベルを名前付きルールに置き換えることで、システムは検査しやすくなりました。それはすべての分類をクライアントに関する認証された事実にしたわけではありません。

次の間違いは、WebViewがFetch Metadataを省略するという広範な主張を受け入れたことでした。私たちはいくつかの防御的なプロジェクトを読み、参照トラフィックが来るまで待つことを計画していました。

他の人や先行技術から学べませんか？これは2026年9月です。

サポート履歴はすでに利用可能でした。2019年のAndroid WebViewの問題は、Chromium 76以降のヘッダーを記録しました。2025年9月のSafari互換性レポートは、運用観測とBrowserStackの再現を説明しました。SafariとそのWebViewは、Sec-Fetch-User を欠いている間 Sec-Fetch-Mode を送信しました。それは、WebViewの包括的な主張を却下するのに十分でした。それは、私たち自身のサイトで異常なリクエストを調査する必要性をなくすものではありませんでした。

そして、すでに持っていたログがありました。

Cloudflareに生のログがすでにありませんか？

元の72時間サンプルには、844件の成功したページGETのうち、ホスティングリスト外のナビゲーション形状のリクエストが112件含まれていました。これはサンプルのルールを満たす約13%であり、証明された人間による読書行動の13%ではありません。そのサンプル内の外部参照されたすべての12件のリクエストはFetch Metadataを運んでいました。12件は有用な裏付けであり、誤検出率の測定ではありません。

古い行については、保持されたゾーンデータにより部分的な再構築が可能でした。1,962件の証拠前の観測のうち、1,429件は、一致する時間/パス/国/デバイスグループ内のすべてのサンプリングリクエストがネットワークに同意した場合にのみASNを受け取りました。191件の曖昧な行と342件の一致しない行がありました。移行レコードはネットワークを asn_source = 'zone-sample' として再構築しました。これはサンプリングされた属性方法であり、正確なリクエスト結合ではありません。再構築方法。

フォローアップで別の欠陥が見つかりました。2026年9月3日05:05:22 UTCから2026年9月6日01:29:53 UTCまでの検査されたすべての1,797件の観測で、asn_source がnullでした。当時アクティブだったINSERTはそのフィールドを省略していました。したがって、すべての行がネットワーク出所を記録しているという私の以前の発言は誤りでした。移行は、それが実行されたときに存在した行をマークしました。それは将来の取り込みを修正しませんでした。出所監査。

9月6日の将来書き込み修正により、ASNが利用可能な場合は asn_source = 'request' が記録され、欠落しているネットワークはマークされなくなりました。デプロイメントと後続書き込みチェック。履歴を保持するには、移行と後続の書き込みの両方をチェックする必要があります。分類の改訂、データベース移行、Workerのデプロイは別々のイベントです。1つを記録しても、他のものは確立されません。

9月4日～5日の測定結果

新しいルールは大きな測定効果をもたらしており、残りのカウントはまだ調整されていません。この比較では、両方のソースで、9月4日00:00から9月6日00:00 UTCまで（終了は除く）を使用します。

ルールは372件のブラウザ-UA観測値のうち277件（74.5%）を再分類しました。その元のブラウザ-UA集団のうち、クラウド分類されたリクエストの60件がナビゲーションヘッダーの組み合わせを通過しました。したがって、ネットワーク証拠は、ヘッダーの組み合わせだけでは許可されるリクエストを分離します。これはルールの効果を測定するものであり、すべての277件のリクエストを個別にラベル付けして分類子の精度を測定したわけではありません。

RUMはこの期間中のボットと2つの/statsロードを除外します。すべてがRUMグループを返したサンプル間隔は1でした。ボットタグ付きロードを含めると、比較可能なRUM合計は16になり、95/16 = 5.94倍になります。ボットフィルタリングだけでは、不一致は説明されません。D1は所有者の除外を適用しますが、不完全な所有者のマーキングは比較の限界のままです。SQLと保存された結果。

読み取り専用抽出ツールは、別のキャプチャで95/14 = 6.79倍の結果を再現し、クエリ、サンプリング、およびデプロイメントメタデータを保存しました。抽出コマンドは比較を再現可能にします。それは2つのソースを同一の集団にしたり、それらをCloudflareから独立して認証したりするものではありません。

次の調査では、既存の呼び出しログとトレースを使用し、次に制御されたクライアントを使用して、分類、スクリプト実行、およびビーコン配信を個別にテストします。個々のトレーススパンの検査とこれらの制御されたクライアントのトライアルは、まだ完了していません。より長いキャリブレーションは9月17日頃に計画されています。この記事は、すでに測定されたルール効果を報告するためにそれらの結果を必要としませんが、読者数問題が解決されたと主張することはできません。

他のサイトの分析への適用

転送可能な方法は、有用なリクエスト証拠を保持し、分類理由を可視化し、解釈する前に収集段階を比較することです。

1. イベントを定義します。 どの方法、ルート、応答、表現、プリフェッチがカウンターに入るかを述べます。
2. 明示的なウィンドウと単位を比較します。 ページ観測、スクリプトページロード、訪問、および日次識別子は異なる質問に答えます。フィルタとサンプリングを記録します。
3. 分類の横に証拠を保持します。 ルールを検査し、派生値のみが残る場所を開示するために必要なフィールドを保持します。新しい書き込みが出所を埋めていることを確認します。
4. ネットワークとブラウザの形状を個別に評価します。 ホスティングリストとナビゲーションヘッダーチェックは異なるトラフィックを捕捉します。共有ネットワークの除外とバージョン処理を文書化します。
5. 宣言されたID、検証、および目的を分離します。 アシスタントアクセスだけでなく、署名されたクローラーアクセスも保持します。どちらからも人間のトリガーを製造しないでください。
6. 履歴を説明可能に保ちます。 ルール変更と再構築方法を記録します。曖昧な観測と一致しない観測を保持します。
7. 未解決のメカニズムをテストします。 ブラウザ数の減少や有利な比率は完了基準ではありません。

これにより、より有用なカウンターが得られます。リクエストがどのように分類されたかを検査でき、証拠から次の実験を選択できます。読者数は測定すべき質問として残ります。

方法、制限、および改訂履歴

リサーチディレクトリには、元の測定値、後続の修正、一次資料のノート、および集計エクスポートが保存されています。クレームレジャーは、完了した研究と保留中の実装を区別します。その修正ノートは、初期のアーティファクトの過剰な主張に優先し、それらのアーティファクトはその歴史的な用語を保持します。

D1観測、プライベートWorkerログ/トレース、およびCloudflare RUMは別々のコレクションです。D1にないフィールドは、運用診断に存在する場合があります。公開された証拠には、選択された観測とレビューされた集計が含まれており、プライベートCloudflareアカウントへのアクセスは含まれていません。保存された署名結果は独立した再検証ではなく、推測されたゾーンマッチは共有ID結合ではありません。個々の人、読書行動、または引用の検証されたカウントは、これらのカウンターからは得られません。

9月6日の修正： 9月4日～5日の測定値を追加しました。普遍的な精度しきい値と下限の主張を削除しました。署名到着、ベンダーIP検証、およびネットワーク出所を修正しました。Accept の欠陥を開示しました。元の公開日とURLはそのままです。パーサーと将来の書き込み出所の修正は、その後マージされ、9月6日にデプロイされました。ローカル回帰結果は上記でリンクされています。完全なブラウザ/ビーコン研究は引き続き別々の作業です。

このページは、見つけられなかった夜に存在したかったのです。もし、これらのルールのいずれかに矛盾するキャプチャされたブラウザリクエスト、または同様のカウンターギャップの測定された説明をお持ちの場合は、どこが間違っているか教えてください。