做蜘蛛池的人经常會遇到一種情况：入口頁里明明放了上百條目标 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 都待在蜘蛛愿意讀到的地方。