很多人默认：入口页只要返回 200、里面有链接，搜索蜘蛛就会顺着抓。实际解析是有成本的，蜘蛛通常按一定字节数读取 HTML，超出部分可能不再解析其中的链接。这个上限不是公开的固定数字，不同搜索引擎、不同抓取队列下表现也不一样，但“页面越臃肿，靠后的链接越容易被忽略”这个方向相对稳定。
体积的两种算法：传输大小与解压后大小
开启 gzip 或 brotli 后，一个 500KB 的 HTML 传输时可能只有 60KB，但蜘蛛拿到后要解压，真正参与解析的是解压后的文档。所以只看 Content-Length 容易误判，它反映的往往是压缩后的大小。判断入口页是否“超重”，要看解压后正文的字节数。
分块传输（chunked）时没有 Content-Length，只能借助抓取日志里的响应体大小字段，或本地用 curl 加 --compressed 对比压缩前后的差异来估算。
哪些写法最容易把预算吃掉
- 把 CSS、JS 内联写在 head 里，尤其是打包后的框架代码，动辄上百 KB。
- 图片、图标以 base64 直接嵌进 HTML，一张图就可能占几十 KB。
- 整站导航、页脚、友情链接全量输出，每个入口页都重复一遍。
- 链接列表放在文档末尾，前面先铺一大段无关正文。
- 注释里塞调试信息或埋点代码。
链接位置往往比链接总数更关键
蜘蛛是从前往后读的。假设解析上限在 500KB 附近，而目标 URL 的链接出现在 520KB 的位置，它基本不会被发现；把同一批链接挪到 50KB 以内，结果可能完全不同。所以链接总量不是唯一变量，链接出现在文档中的位置同样重要。比较稳妥的做法是把核心链接放在靠前的区块，装饰性内容和长文本往后放。
一个简单的自测方法
- 用 curl --compressed 抓取入口页，保存为本地文件。
- 查看文件字节数，再定位第一条目标 URL 链接出现的字节偏移。
- 如果链接普遍落在 200KB 之后，就该考虑精简页面结构了。
- 对比抓取日志中蜘蛛读取的响应体大小，看是否明显小于本地文件。
超出上限不一定等于彻底不抓
截断更常见的表现是：前面的链接照抓，后面的链接长期没有动静。日志上看起来“蜘蛛来过、也抓了入口页”，但目标 URL 一直没有新的发现记录。这种时候先别急着换 IP 或加池子，先确认是不是入口页本身太长。
如果入口页的内容确实需要很长，可以把链接拆到多个分页或子入口页，每个页面只承载一部分链接，通常比全部堆在一个超长页面上更容易被完整解析。
精简时的几个注意点
- 不要为了减体积把正文删空，页面缺少实质内容同样会影响后续处理。
- 外链 CSS、JS 能明显降低 HTML 体积，但别让它阻塞渲染到蜘蛛看不到链接。
- 压缩传输是好事，不要为了“看起来大”而关掉 gzip。
- sitemap 与主动提交可以作为补充通道，但不宜当作页面内链接发现的替代品。
最后提醒：各搜索引擎都没有公开解析上限的具体数值，本文给出的判断方式是基于日志现象的排查思路，不能保证调整后一定带来抓取量变化。先测、再改、再看日志，把改动和结果对应起来，比盲目堆链接更有效。