做蜘蛛池的人迟早會遇到這個疑問：入口頁為了塞進更多目标 URL，模板越堆越厚，HTML 体积一路涨，结果發現排在後面的連結好像一直没被動過。到底是蜘蛛没發現，還是發現了没抓？先说结论：頁面体积确實會影响連結的發現與跟進，但它不是“超過某個數字就全部失效”的開關，更常见的表現是抓取预算被吃掉、解析被截断，越靠後的内容越容易掉队。
單頁 HTML 存在解析上限吗
主流搜尋引擎對單個 HTML 文档都有解析上限，公開提到的量級大致在几 MB，各家數字不同且會調整，所以不必去记某個精确阈值。更值得留意的是两個经常被混淆的概念：传輸大小和解压後大小。入口頁開啟 gzip 或 brotli 之後，解压後 2MB 的 DOM 可能只传几百 KB，但蜘蛛最终要解析的仍然是解压後的内容。只看 Network 面板里的传輸体积，很容易得出“頁面很轻”的错誤判断。
体积失控时，最先出問题的是哪一环
- 响應超时：文件大、服務器又慢，蜘蛛在超时時間内没讀完，就可能提前断開，只拿到頁面的一部分。
- 抓取预算被浪費：同一批入口頁如果都很重，蜘蛛花在每個頁面上的资源變多，單位時間内能訪問的 URL 數量就下降。
- 解析截断：就算完整下载了，超出解析上限的那段 HTML 也可能被忽略，里面的連結自然不會被提取。
這三件事常常同时發生，表現出来就是“入口頁被訪問了，但後面的目标 URL 在日誌里一直没出現”。
哪些寫法最容易把入口頁撑大
- 把大段 CSS、JS 直接内联在模板里，每個入口頁都重复一份；
- 用 base64 方式嵌入图片、字体或图标；
- 把几百上千條目标連結铺在同一個頁面上，且不做分頁或拆分；
- 在 HTML 里内联整包 JSON 資料供前端渲染；
- 模板里顺手带上的統計脚本、客服组件、第三方 SDK。
這些内容對搜尋蜘蛛發現目标 URL 没有任何帮助，却實打實地占用了解析額度。
連結位置往往比連結數量更關键
即使頁面没有被截断，靠後的連結在抓取優先級上通常也排在後面。同样是 200 條連結，集中堆在頁脚和分散在正文前段，蜘蛛的跟進顺序和覆盖率可能完全不一样。與其纠结“一個入口頁到底能放多少條”，不如先把最想被發現的 URL 放在 HTML 结构靠前的位置，正文区块優先于頁脚区块。
怎么確認後面的連結有没有被抓
- 在服務器日誌里按蜘蛛 UA 過滤，看它請求入口頁之後，是否繼續請求了頁面後段的目标 URL；
- 用各站長平台的 URL 检查或抓取測試工具，查看實际抓取到的 HTML 是否完整；
- 自己抓一次入口頁，統計解压後的字节數和提取到的連結條數，和预期對比。
優化时建议的顺序
- 先把 CSS、JS、图片外鏈化，這一步通常能砍掉一半以上的体积；
- 控制單頁連結數量，把入口頁拆成多個，而不是把連結都塞進一頁；
- 把核心目标連結放到頁面靠前的位置；
- 保持服務器响應稳定，開啟压缩和缓存，避免响應時間抖動；
- 改完用日誌驗證，而不是凭感觉判断。
頁面變轻、结构變清晰，只是让目标 URL 被發現的概率更高一些，並不能保證被收錄或获得排名。蜘蛛池的作用是缩短發現路径，不是替代内容质量。
如果你現在的入口頁已经堆到几百 KB 甚至几 MB，可以先挑一個做减法，對比改動前後日誌里目标 URL 的命中情况，再决定要不要整体調整。多數情况下，問题不在“蜘蛛不来”，而在于来了之後没有把頁面讀完。