不少人在做入口頁时會遇到這種情况：頁面源碼里明明寫了目标連結，用浏览器打開也能点，但搜尋蜘蛛来過後，後面的連結一條都没被抓。除了連結层級、robots、nofollow 這些常见原因，還有一個容易被忽略的点——頁面本身的 HTML 体积太大，超出了搜尋蜘蛛單頁處理的長度。
搜尋蜘蛛為什么會“讀不完”一個頁面
搜尋蜘蛛抓取一個 URL 时，並不是無限制地把内容全部讀進去。出于抓取效率和存储成本的考虑，各搜尋引擎對單個 HTML 文档的可處理体积都有大致上限，超過上限的部分會被截断，不再參與連結解析和正文分析。
也就是说，如果你的目标連結恰好排在几千行模板代碼、内联脚本或者一大段冗余内容之後，它很可能落在截断线外面，表現就是“頁面被抓了，連結没被發現”。
几種常见的“連結被挤到截断线外”的情况
1. 模板把正文推得太靠後
有些入口頁把導航、友情連結、統計代碼、广告位堆在 body 最前面，正文和目标連結排到最後。代碼量一大，連結的位置就非常靠後。
2. 内联脚本和样式過多
把大量 JS、CSS 直接寫在 HTML 里，尤其是框架生成的内联 JSON 資料，會让源碼迅速膨胀。這部分内容對搜尋蜘蛛發現連結几乎没有帮助，却實打實占用了解析長度。
3. Base64 图片、内联 SVG
把图片轉成 Base64 直接嵌在 HTML 中，一張图就可能几十上百 KB。這類内容体积大、可讀性差，很容易把後面的連結挤出去。
4. 一頁塞入過多連結
入口頁上挂几百上千條連結，源碼行數同样會變得很長。正常情况下没有必要，反而會稀释每條連結能分到的注意力。
怎么判断自己的入口頁有没有這個問题
- 在浏览器里右键“查看網頁源代碼”，看總行數和文件大小；
- 確認目标連結出現在源碼的第几行、大概處于百分之多少的位置；
- 用抓取工具或日誌里的响應大小，看看搜尋蜘蛛實际拿到的是压缩前還是压缩後的体积；
- 把頁面另存為纯 HTML，去掉图片後比較体积，判断膨胀主要来自哪里。
注意：服務器開啟 gzip / brotli 压缩，只影响传輸体积。搜尋蜘蛛拿到响應後會解压再解析，判断标准仍然是解压後的 HTML，不是压缩後的數字。
几個可以落地的調整方向
- 把目标連結前置：不需要它出現在頁首，但尽量不要排在几千行代碼之後，正文区域靠前的位置更稳。
- 精简模板：去掉入口頁上不參與發現的模块，統計、广告、推荐位能异步加载就异步加载。
- 拆分頁面：連結數量多的时候分頁處理，每頁控制在合理范围，比堆在一頁更利于被抓到。
- 外鏈资源化：把 JS、CSS、图片改為外部引用，减少單個 HTML 文档的体积。
- 避免重复内容：多個入口頁内容高度雷同时，精简掉重复段落，让有效信息更集中。
常见誤区
“压缩後只有几十 KB，應该没問题”
压缩比只影响網絡传輸，解析用的是解压後的内容。一個压缩後 30 KB 的頁面，解压後可能有三四百 KB，判断标准要用後者。
“連結放在頁脚也會被抓”
頁脚不必然抓不到，但在体积偏大的頁面上，頁脚的位置風險明顯更高。位置本身不是绝對因素，位置背後的“排在第几行”才是。
“抓到了頁面就等于發現了所有連結”
抓取和連結解析是两件事。頁面被抓取，只代表搜尋蜘蛛拿到了這個 URL；里面的連結能不能進入待抓队列，還要看解析时有没有讀到。
小结
HTML 体积不是入口頁效果的决定性因素，但它是一個很容易被忽略、排查成本又很低的环节。把源碼体积压下来、把目标連結往前放，属于“不會更差”的基础動作。需要提醒的是，這些調整只能提高目标 URL 被發現的概率，無法保證一定被抓取或收錄——最终结果仍取决于目标站本身的质量、服務器响應以及搜尋引擎的抓取安排。