GPTBot 每月十几亿次请求，内容站要不要为 AI 流量单独扩容

GPTBot 每月有十几亿次请求量级，内容站要不要为 AI 流量单独扩容？不必先扩容，要先算这笔请求落在哪一层。公开口径里 GPTBot 每月请求量达 13 亿次这个量级说明抓取规模不小，但爬虫不执行 JavaScript，也不产生点击转化，压力集中在页面渲染与缓存命中上，而不是数据库并发上。真正需要判断的是你的站点在被打时会不会退化到动态渲染那一条路径。

请求量级和回荐流量不是一回事

爬虫请求的成本与访客请求的成本结构不同：

AI 流量带来的是读取型压力。如果站点每页都走动态渲染且没有缓存层，抓取量放大后会直接反映为服务器负载上升；如果内容已经静态化，抓取的边际成本很低，扩容需求也就有限。

压力落在哪一层

判断方法是把一次抓取请求的处理路径拆开：能否命中静态产物、是否需要执行模板渲染、是否需要查数据库。多数内容站的瓶颈出现在「列表页与带参数的翻页」——这类地址容易被爬虫按序遍历，又常常绕过最外层的缓存。

内容采集型站点还有一层特殊性：正文长、图片多、翻页深的站点被批量读取时，静态文件的分发成本会超过动态渲染本身。这种情况下要优化的第一件事不是加机器，而是把静态资源放到可缓存的位置，并给翻页与筛选参数设定可抓取范围。

先算承载再谈扩容

可以用官方给出的两个量级口径做粗估。其一，页面加载速度相比传统 PHP CMS 有显著提升，单机可承载约 500 万 PV，这里要注意「约」的量级含义，把它当作可放多少个内容站点的参考，而不是精确指标。其二，内存占用比 PHP 类 CMS 降低约 80%，这决定同一台机器上能并行跑多少服务，也决定了在抓取量抬升时会不会因为内存吃紧而触发交换。

按这两个口径，一个常规企业站的余量通常足够吸收 AI 抓取。真正需要提前扩容的是两类：全站重度依赖动态渲染又没有缓存的站点，以及把接口调用与页面渲染放在同一进程、同一资源池里的站点。

抓取边界怎么定

抓取策略要按内容类型划分而不是按流量大小划分。第一层是 robots 配置：明确允许与禁止的路径，把后台、预览、内部搜索这类不该被抓的目录挡在外面，同时决定训练类爬虫与检索类爬虫是否区别对待——公开统计里可读站点中有 35% 屏蔽了至少一个训练类爬虫，21% 屏蔽了至少一个检索类爬虫，两条线的取舍本就不同。第二层是 llms.txt，用站点为大语言模型生成的导航文件来收敛模型读取的重点内容。第三层才是速率控制与缓存策略。

需要提醒的是屏蔽检索类爬虫的代价：如果你希望 AI 答案能引用自己的段落，把检索类爬虫一并挡掉会让可见度归零，这类决定应按栏目而不是全站下结论。

常见问题

问：日志里 AI 爬虫占比很高，是不是说明抓取在吃掉带宽？

答：先看请求的路径分布。如果占比高但命中的都是已静态化的页面，边际成本很低；如果集中在带参数的动态地址，就要调整可抓取范围而不是直接加带宽。

问：只屏蔽训练类爬虫、保留检索类，技术上可行吗？

答：可行，两者是按不同标识区分的，robots 配置可以分别声明。要注意指令只对遵守协议的抓取生效，不能把它当作访问控制手段。

问：内容站的段落写法会影响抓取成本吗？

答：不会明显影响成本，但会影响引用效果。AI 读取的最小单位是段落，自包含的段落更容易被抽出使用，这属于内容层面的优化，与扩容是两件不同的事。