做蜘蛛池的人经常会遇到一种情况：入口页里明明放了上百条目标 URL，日志里也天天有搜索蜘蛛来访，但仔细一看，被抓的永远是排在前面的那几十条，后面的链接像是被忽略了。换域名、换模板、重新提交，效果都不明显。这时候可以往一个容易被忽略的方向排查：页面本身是不是太大了。
搜索蜘蛛解析 HTML 不是无限的
很多人默认只要页面返回 200，里面的链接就一定会被读到。实际不是这样。主流搜索引擎对单个 HTML 文档都有处理上限，超过这个上限之后的内容，不保证被解析、更不保证被索引。Google 曾公开提过其索引的 HTML 存在大小限制，量级在 2MB 左右，其他引擎各有各的阈值，但共同点是——都不是无限。
这里有一个容易混淆的点：这个上限通常指解压之后的 HTML 内容大小，而不是 gzip 传输时的大小。也就是说，即使你开了压缩、传输只用了 200KB，浏览器和蜘蛛解压后拿到的是 2MB，判断依据仍是后者。所以“我已经开了 gzip 了”并不能解决体积问题。
还有一个更隐蔽的情况：蜘蛛确实把整个文件下载下来了，但解析阶段只处理了前面一段，后面的链接没有被提取出来。表现出来就是日志里能看到访问，抓取量却不见增长。
怎么判断是不是体积问题
不需要复杂工具，几个动作就能大致判断：
- 把入口页的源码复制出来，看未压缩的字节数。超过 1MB 就该警惕，超过 2MB 基本可以重点怀疑。
- 统计被抓 URL 在源码中的位置分布。如果日志里被抓的链接集中在源码前三分之一，后面几乎为零，这个特征就很典型。
- 找一个链接数量相近、但页面明显更精简的入口页做对比，看被抓比例是否有差异。
- 把同样的链接精简后重新输出一版，观察后续日志里后半段链接的抓取是否出现变化。
要注意的是，光看“被抓数量少”不能直接归因到体积上，抓取配额、入口页权重、链接本身的层级都会影响结果，体积只是其中一个变量。
除了体积，这些也会让链接被“吞掉”
- 大段内联 CSS 和 JavaScript 占据了页面主要篇幅，真正的链接被挤到很后面。
- 链接由 JavaScript 动态渲染，蜘蛛执行脚本的预算本身就有限，不一定跑完。
- 页面里嵌入了 base64 编码的图片，字符数膨胀得很快，几十张图就能顶掉一大半体积。
- 链接藏在折叠区块或需要交互才展开的结构里，静态 HTML 中根本没有对应的 a 标签。
调整思路
- 精简 HTML。把内联样式和脚本抽成外部文件，图片改为外链引用，能去掉的框架代码尽量去掉。
- 把重要的目标 URL 前置。不管页面多大，靠前的部分总是更安全。把优先级高的链接放在 HTML 结构的最前面，而不是被导航、公告、统计代码挡在后面。
- 拆分布局。一个入口页不要无限制地堆链接，控制在合理数量，剩下的分到多个入口页，让每个页面的体积都可控。
- 用 sitemap 或 URL 提交接口做补充。入口页不是唯一的发现渠道，多一条路就多一层保险。
- 区分传输优化和解析优化。压缩、CDN 解决的是传输速度问题，链接能不能被读到，取决于解压后的内容结构。
体积只是 URL 发现链路里的一个环节。改完之后不要急着下结论，先观察一到两周的日志，看被抓链接的位置分布有没有变化，再决定要不要继续调整。
蜘蛛池运营里很多“抓取不进来”的问题，最后都落在很朴素的细节上。页面写得越臃肿，后半段的内容就越容易被跳过。与其不断换域名、换 IP，不如先把入口页瘦下来，让每一条目标 URL 都待在蜘蛛愿意读到的地方。