为什么主文档体积会影响链接发现
蜘蛛抓取一个 URL 时，先下载主文档，再从中解析链接、抽取正文。主文档体积并没有一个全球统一的硬上限，但抓取端通常存在字节预算、超时和解析成本的限制：文档越大，下载与解析消耗的时间和配额越多，尾部内容被截断或跳过解析的概率就越高。表现上往往不是整页不抓，而是页面顶部的导航和正文链接正常被发现，页面底部的分页、相关推荐、标签聚合、页脚栏目链接长期不出现在抓取日志里。
常见的体积膨胀来源
- 把接口返回的整段 JSON 直接内联在 HTML 里，随首屏数据一起下发；
- 图片、字体、图标以 base64 内嵌，单条就能带来几十到几百 KB；
- 模板渲染时循环输出隐藏节点，例如全量筛选项、全量城市列表、全量 SKU；
- 注释、调试信息和重复埋点脚本在打包时没有清理；
- 服务端渲染输出的数据快照与后续 JSON 重复下发。
如何判断是体积问题而不是别的原因
先把怀疑的 URL 单独拿出来核对，不要一上来就加内链：
- 记录主文档未压缩大小与压缩后大小，对比站点其他正常页面的均值；
- 在抓取日志中筛出该目录，观察请求是否成功、状态码是否为 200、是否存在中断迹象；
- 定位关键链接在文档中的位置，估算它们距离文档开头的字节偏移；
- 把同一批链接临时挪到文档靠前的位置做对照测试，观察是否恢复发现。
如果链接在浏览器里可点可爬，但抓取日志中长期没有对应请求，优先怀疑解析层面的截断，而不是直接认定该链接不值得抓。
收敛体积的常规做法
- 页面数据改为按需请求接口，首屏只下发必要的结构与文本；
- 把内联脚本、样式抽出为可缓存的外部文件，减少每页重复下发；
- 列表页做真分页，用 a 标签给出下一页链接，避免上千条数据铺在一个文档里；
- 把重要导航、分页、面包屑放在文档靠前且结构清晰的位置；
- 不要用大量隐藏 DOM 承载筛选参数，筛选维度多时只输出可被抓取的稳定入口。
与抓取配额的关系
主文档体积不只影响单页解析，也占用站点整体的抓取预算。每次抓取一个笨重的页面，等于用同样的时间换取更少的有效链接和正文。把这类页面瘦身后，同样的抓取量能覆盖更多 URL，新页面被发现的周期通常会缩短。
上线后的观察方式
调整之后不要只盯着是否立刻收录。更实际的观察项是：抓取日志中目标目录的请求量变化、关键链接对应的请求是否出现、单次抓取的平均响应字节是否下降，以及新发布页面从提交到被抓取的间隔。如果这些指标都没有变化，再回头排查是否还有第二处体积膨胀点，而不是继续堆叠内链入口。