很多人盯抓取问题，只看状态码、Sitemap 和 robots.txt，却忽略了一个很朴素的因素：蜘蛛抓一个 URL，需要下载并解析的东西到底有多大。页面体积不直接决定收录，但它会影响蜘蛛在同样时间里能走多远。
蜘蛛抓取一次，成本不只是“下载正文”
一次抓取大致包括：域名解析、建立连接、发送请求、读取响应头、下载响应体，然后解析 HTML。如果页面里还有需要单独请求的资源，那又是另外的抓取通道。对蜘蛛来说，单页越重，单位时间内能处理的 URL 就越少。
这并不是说页面必须极简，而是要让主要成本花在有用的内容上。内联了大量用不到的 JSON、把图片转成 base64 塞进 HTML、重复的模板结构，都会让响应体膨胀，而蜘蛛能从中提取的有效信息并没有增加。
HTML 体积通常从哪里膨胀
- 把整份数据对象内联在页面里，其中大部分字段首屏根本用不到；
- 图片以 base64 形式写在 HTML 或 CSS 中，体积比独立请求大得多；
- 列表页一次性输出几百条记录，分页形同虚设；
- 大量注释、空标签、重复的 class 与内联样式；
- 未做压缩，直接输出几百 KB 的原始 HTML。
控制体积的几个实际做法
- 开启压缩：gzip 或 brotli 对 HTML 的压缩效果通常很明显，服务器和 CDN 都能配置。
- 把数据放到接口里：首屏不需要的字段不要内联，让页面渲染依赖按需请求。
- 图片用独立地址：静态资源走单独的 URL，既减小 HTML，也便于缓存。
- 列表页分页或懒加载：每页条目控制在合理范围，后续内容通过链接或翻页暴露。
- 清理模板冗余：合并重复结构，去掉无用注释和空节点。
体积为什么会间接影响 URL 发现
蜘蛛的抓取资源是有限的。同一台服务器、同一段时间里，如果每个页面都很重，蜘蛛能完整走到的新链接就更少，新 URL 的发现和验证会被拖后。列表页、标签页、频道页这些承担着内链分发作用的页面，尤其值得先瘦身。
与此同时，Sitemap 和清晰的导航仍然是发现路径的主干。体积优化让蜘蛛走得更顺，但不能替代可抓取的链接结构。两者配合，效果才稳定。
怎么确认问题出在体积上
在服务器日志或抓取统计里看响应字节数、响应时间与抓取频次的对应关系。如果某些页面的响应明显偏大、耗时偏长，而蜘蛛访问它们的间隔也变长，就值得检查输出内容。也可以在本地对比压缩前后的大小，通常会有直观的差距。
服务器稳定性同样是前提
体积优化不只是为了蜘蛛。更小的响应体、合理的缓存策略，能同时降低带宽和数据库压力。服务器响应稳定，蜘蛛的抓取节奏才不会被频繁的超时和错误打断。
页面体积不是排名因素，但它影响蜘蛛在单位时间里能走多远。把 HTML 控制在合理范围，让抓取预算花在真正需要被发现的 URL 上。