入口頁上明明寫了目标連結，日誌里也看到搜尋蜘蛛来抓過入口頁，可目标 URL 的抓取记錄迟迟不出現。這種情况除了检查 robots、nofollow、JS 渲染之外，還有一個容易被忽略的原因：入口頁的 HTML 体积太大，搜尋蜘蛛讀到一半就不再往後解析了。
頁面解析确實存在上限，只是各家没公布确切數字
搜尋蜘蛛抓取頁面时，要先下载响應体，再交给解析器抽取連結。下载有大小限制，解析也有時間和内存開销。各搜尋引擎對這個上限的设定並不相同，也没有對外公開一個可以直接照搬的准确字节數，而且會随渲染方式、响應速度、站点整体情况變化。可以确定的只有一件事：超過一定体积之後，後半部分的連結被解析到的概率會明顯下降，越靠後的内容越吃亏。
涨体积的通常不是正文，而是這几類東西
- 把整套 CSS 和 JS 内联在 head 里，尤其是未压缩的框架代碼；
- 用 base64 直接嵌入的图片、字体和图标；
- 每個入口頁都複製同一套頁头頁脚、導航和友鏈模块；
- 大量 data-* 属性、未清理的調试注释、模板残留的隐藏节点；
- 為了堆連結，把目标 URL 一條條拼成超長列表，甚至连 query 參數一起堆進去。
怎么判断自己是不是踩到了体积問题
- 用 curl 拉一次入口頁，看响應头里的 Content-Length。這只是压缩後的传輸大小，不等于解析器看到的解压後大小，注意区分；
- 把 gzip 解压後的 HTML 存下来看文件大小，這才是解析器實际要處理的量；
- 检查日誌：如果入口頁抓取正常、返回 200，但同一批目标 URL 長期没有任何抓取记錄，可以怀疑連結没有被解析到；
- 做一次對比測試：把同一批連結從頁面底部挪到靠前的位置，或者拆成两個入口頁，观察一段時間再看日誌差异。
實操上的几個控制点
- CSS 和 JS 尽量走外鏈，让浏览器和蜘蛛都能缓存；
- 图片、字体用獨立文件，不要用 base64 塞進 HTML；
- 連結区块放在頁面靠前的位置，別埋在十几屏模板块之後；
- 入口頁只承担“被發現有連結”這一件事，内容尽量精简，不需要完整的站点框架；
- 連結多的时候優先拆成多個入口頁，而不是堆成一個超長頁面。
這里没有给一個硬性數字，因為不同入口頁的结构差別很大。實用的做法是给自己定一個内部标准，比如解压後控制在几十到一百多 KB 的区間，然後長期用日誌驗證：連結是否真的被跟到了。
別把体积当成唯一解释
連結没被跟，還可能是因為用了 rel="nofollow"、連結由 JS 在交互後插入、跳轉鏈太長、入口頁本身返回了非 200 狀態，或者目标 URL 在 robots.txt 里被挡住。
体积只是其中一個變量。把入口頁做小、把連結提前，是成本最低的一步，但不要指望它單獨解决所有抓取問题。