很多人預設：入口頁只要返回 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 與主動提交可以作為补充通道，但不宜当作頁面内連結發現的替代品。
最後提醒：各搜尋引擎都没有公開解析上限的具体數值，本文给出的判断方式是基于日誌現象的排查思路，不能保證調整後一定带来抓取量變化。先测、再改、再看日誌，把改動和结果對應起来，比盲目堆連結更有效。