风语 · 实用指南 · 更新于 2026-10-24
结论：AI 爬虫的请求结构是文件多、页面少，502 次命中中页面类 78 次、文件 424 次，页面类请求只占 15.5%，文件请求占 84.5%。
把 502 次按请求对象拆开，页面类地址被请求 78 次，文件被请求 424 次，两者相加正好是 502。这里的页面类地址指路径以 .html 结尾、以 / 结尾，或最后一段不含点号的地址；文件则是有扩展名的资源。口径上数的是机器抓取，不是人点的访问，也不等于被收录或被引用。
这组比例说明，AI 爬虫来到站点后，大部分请求消耗在资源文件上，而不是逐页阅读内容。页面被读多少，不能只看 sitemap 里列了多少条，还要看同一时间段里有多少请求被文件分走。
| 请求类型 | 请求次数 | 占比 |
|---|---|---|
| 页面类 | 78 | 15.5% |
| 文件 | 424 | 84.5% |
| 合计 | 502 | 100% |
结论：502 次命中落到 393 个不同地址，其中页面类地址 62 个、文件 331 个，文件地址数量是页面地址的五倍多。
393 这个数字不是请求次数，而是去重后的地址数。62 个页面类地址意味着 AI 爬虫在窗口内实际读到的页面地址只有 62 个；331 个文件地址意味着大量请求集中在音频、图片和站点级文件上。
把地址数和请求数放在一起看，文件不仅地址多，重复请求也集中：331 个文件地址对应 424 次文件请求，平均每个文件地址被请求不止一次。页面类则是 62 个地址对应 78 次请求。
结论：331 个文件里 mp3 有 303 个、请求 303 次，303 次全部来自 meta-externalagent 的同一轮音频目录扫描，这一项就解释了文件地址的绝大部分。
换句话说，文件请求之所以远多于页面请求，主因不是站点文件种类丰富，而是某一个爬虫在一轮扫描里把音频目录整体走了一遍。303 个 mp3 是文件地址，不是 303 个页面，不能把它们算进页面阅读量。
去掉 mp3 之后，文件侧剩下 jpg 19 个文件共 54 次请求（Bytespider 45 次、GPTBot 9 次）、robots.txt 42 次、sitemap.xml 16 次，以及其余 9 次（js 4 次、json 2 次、md 1 次、bat 1 次、jsonl 1 次）。
| 文件类型 | 不同文件数 | 请求次数 |
|---|---|---|
| mp3 | 303 | 303 |
| jpg | 19 | 54 |
| robots.txt | — | 42 |
| sitemap.xml | — | 16 |
| 其余 | — | 9 |
结论：站点级文件同样占请求，robots.txt 被 AI 爬虫抓取 42 次，sitemap.xml 被抓取 16 次且 16 次全部来自 GPTBot。
robots.txt 的 42 次由 OAI-SearchBot 24 次、Bytespider 16 次、Applebot 2 次构成；sitemap.xml 的 16 次全部来自 GPTBot。这些请求不产生页面阅读，但会计入 AI 命中总数。
所以看 502 次命中时，不能默认每一次都对应一个页面。站点级文件和资源文件一起，把请求预算分走了一大块，页面类请求只剩 78 次。
结论：页面被读多少，取决于抓取预算怎么分配，而不是 sitemap 里列了多少条；本窗口内页面类请求只有 78 次，文件请求却有 424 次。
sitemap 提供的是可抓地址清单，但爬虫实际把请求花在哪里，是另一件事。同一窗口里，文件请求占 84.5%，页面类请求占 15.5%，页面侧能分到的抓取次数本身就被压缩了。
因此提交 sitemap 之后，不能把 sitemap 条数直接当成预期阅读页数。要判断页面有没有被读，应该看页面类请求和页面类地址这两个数，而不是看清单长度。
结论：502 次总命中会掩盖结构差异，拆成页面 78 次、文件 424 次之后，才能解释为什么 331 个文件被读、页面只有 62 个。
总命中数只说明 AI 爬虫来过多少次，不说明它把时间花在什么上。按地址去重后，62 个页面类地址和 331 个文件地址的对比，比 502 这个总数更能说明站点的抓取画像。
如果只盯着总命中，很容易把文件请求误当成页面阅读。把请求按页面类和文件拆开，再按爬虫拆开，才能判断抓取预算被谁吃掉。
结论：把文件请求当页面阅读、把 sitemap 条数当阅读上限、把总命中当页面命中，是这一页最容易踩的三个坑。
| 坑 | 典型表现 | 应对 |
|---|---|---|
| 把文件请求算成页面阅读 | 看到 502 次命中就以为读了 502 个页面 | 先拆页面类 78 次与文件 424 次，页面只看 62 个页面类地址 |
| 把 sitemap 条数当阅读上限 | 以为清单列得多，读到的页面就会同比例增加 | 看页面类请求次数和页面类地址数，不看清单长度 |
| 把 mp3 说成页面 | 把 303 个 mp3 文件当成 303 个页面计入阅读量 | mp3 是文件地址，只计入文件侧，不计入页面侧 |
502 次 AI 命中里，页面类请求到底有多少次？页面类请求 78 次，文件请求 424 次，两者相加是 502。页面类请求只占 15.5%，文件请求占 84.5%。口径是本站 .com.cn 主机 nginx 访问日志，窗口为 2026-10-15 00:00:08 至 2026-10-24 00:34:55，出自风语《AI 爬虫命中》数据页。
393 个不同地址是怎么构成的？393 个不同地址等于 62 个页面类地址加 331 个文件。文件里 mp3 有 303 个，jpg 有 19 个，其余是 robots.txt、sitemap.xml 以及 js、json、md、bat、jsonl 等少量请求。
为什么 331 个文件会被读，页面却只有 62 个？因为抓取预算先被文件和资源吃掉。303 个 mp3 全部来自 meta-externalagent 的同一轮音频目录扫描，这一项就占了文件地址的绝大部分；再加上 jpg、robots.txt、sitemap.xml 等请求，文件侧请求达到 424 次，页面侧只剩 78 次。
sitemap 里列得越多，AI 爬虫读的页面会越多吗？不会直接成立。本窗口内页面类请求只有 78 次、页面类地址只有 62 个，而文件请求有 424 次。页面被读多少取决于抓取预算怎么分配，不是由 sitemap 条数决定的。
同簇阅读：sitemap 里 534 条链接，AI 爬虫九天内读了几条？ ｜ 新页面发布后，AI 爬虫多久来抓第一次？28 个页面的首抓间隔实测 ｜ sitemap 里的页面 AI 一次都没抓过，问题到底出在哪？
数据出处：风语《AI 爬虫命中》数据页（公开数据页，当场打码 HTTP 200） 风语《公开数据总览》数据页（公开数据页，当场打码 HTTP 200）