為什么主文档体积會影响連結發現
蜘蛛抓取一個 URL 时，先下载主文档，再從中解析連結、抽取正文。主文档体积並没有一個全球统一的硬上限，但抓取端通常存在字节预算、超时和解析成本的限制：文档越大，下载與解析消耗的時間和配額越多，尾部内容被截断或跳過解析的概率就越高。表現上往往不是整頁不抓，而是頁面顶部的導航和正文連結正常被發現，頁面底部的分頁、相關推荐、标簽聚合、頁脚栏目連結長期不出現在抓取日誌里。
常见的体积膨胀来源
- 把接口返回的整段 JSON 直接内联在 HTML 里，随首屏資料一起下發；
- 图片、字体、图标以 base64 内嵌，單條就能带来几十到几百 KB；
- 模板渲染时循环輸出隐藏节点，例如全量篩選項、全量城市列表、全量 SKU；
- 注释、調试信息和重复埋点脚本在打包时没有清理；
- 服務端渲染輸出的資料快照與後續 JSON 重复下發。
如何判断是体积問题而不是別的原因
先把怀疑的 URL 單獨拿出来核對，不要一上来就加内鏈：
- 记錄主文档未压缩大小與压缩後大小，對比站点其他正常頁面的均值；
- 在抓取日誌中筛出该目錄，观察請求是否成功、狀態碼是否為 200、是否存在中断迹象；
- 定位關键連結在文档中的位置，估算它們距离文档開头的字节偏移；
- 把同一批連結临时挪到文档靠前的位置做對照測試，观察是否恢复發現。
如果連結在浏览器里可点可爬，但抓取日誌中長期没有對應請求，優先怀疑解析层面的截断，而不是直接認定该連結不值得抓。
收敛体积的常規做法
- 頁面資料改為按需請求接口，首屏只下發必要的结构與文本；
- 把内联脚本、样式抽出為可缓存的外部文件，减少每頁重复下發；
- 列表頁做真分頁，用 a 标簽给出下一頁連結，避免上千條資料铺在一個文档里；
- 把重要導航、分頁、面包屑放在文档靠前且结构清晰的位置；
- 不要用大量隐藏 DOM 承载篩選參數，篩選维度多时只輸出可被抓取的稳定入口。
與抓取配額的關系
主文档体积不只影响單頁解析，也占用站点整体的抓取预算。每次抓取一個笨重的頁面，等于用同样的時間換取更少的有效連結和正文。把這類頁面瘦身後，同样的抓取量能覆盖更多 URL，新頁面被發現的周期通常會缩短。
上线後的观察方式
調整之後不要只盯着是否立刻收錄。更實际的观察項是：抓取日誌中目标目錄的請求量變化、關键連結對應的請求是否出現、單次抓取的平均响應字节是否下降，以及新發布頁面從提交到被抓取的間隔。如果這些指标都没有變化，再回头排查是否還有第二處体积膨胀点，而不是繼續堆叠内鏈入口。