入口頁做得很“厚”是很常见的情况：模板里塞了一整套内联样式和脚本，图片直接内联成 base64，連結列表又放了上百條。頁面本身能打開，没有任何报错，但搜尋蜘蛛能不能完整讀到你想让它發現的那批連結，就變成另一個問题了。
搜尋蜘蛛對單次抓取确實有体积上限
主流搜尋引擎的公開文档里都提到，抓取和解析 HTML 时有大小限制，量級通常在 1MB 到 2MB 之間，不同引擎、不同时期會調整，以官方文档為准。超出這個范围的字节，一般不會被繼續解析，連結和正文都可能讀不到。這個限制针對的是 HTML 文档本身，但如果图片、脚本以 base64 形式内联在 HTML 里，它們同样會被算進去。
換句话说，頁面上限不是按“條數”算的，而是按“字节”算的。同一頁放 50 條連結還是 300 條連結，哪個更危險，取决于每條連結带了多少額外的 HTML。
連結最容易處在被截断的位置
- 連結列表放在頁尾，前面的内联样式、脚本、面包屑、推荐位已经把体积吃掉大半。
- 連結外层包了大量 标簽、data 属性、图标和說明文案，單條連結的 HTML 從几十字节膨胀到几百字节。
- 用同一套模板批量生成入口頁，每條連結還带缩略图或摘要，体积更容易失控。
這些情况下，搜尋蜘蛛抓到的 HTML 可能是“半截”的：前面正常解析，後面直接停住。日誌里看得到抓取成功、狀態碼 200，但你關心的目标 URL 一條都没被抓，容易誤判成連結质量或權重問题。
先判断頁面是不是真的“虚胖”
- 用 curl 或浏览器開發者工具看 HTML 原始大小，注意不是压缩後传輸的大小。開啟 Gzip / Brotli 能减少传輸量，但不改變解析时面對的文档体积。
- 把内联样式、脚本抽成外部文件，图片換回普通 URL 引用，只做這一步往往就能砍掉一大半体积。
- 重要連結尽量前置，放在正文靠上的位置，而不是頁尾的“相關推荐”。
- 連結條數特別多时，拆成多個入口頁，用分頁或分组的思路分散，而不是堆在一頁里。
- 如果入口頁本身就是模板批量生成，先精简模板里的公共部分，再考虑加連結。
用日誌驗證，而不是猜
抓取日誌通常會记錄响應狀態碼和响應字节數，部分日誌還會记錄蜘蛛 UA 和抓取耗时。可以做的對照是：入口頁被訪問时的响應大小是否接近你预期的完整体积；同一時間窗口内，目标 URL 有没有出現新的抓取记錄。如果入口頁天天被訪問、目标 URL 長期零抓取，同时响應大小明顯小于實际文件大小，那就要怀疑截断。
注意区分“抓取”和“解析”：蜘蛛能把 HTML 下载完整，不代表所有連結都會進入待抓取队列，連結本身的可用性和頁面相關性依然有影响。
几個實际建议
入口頁的体积控制和連結數量控制，本质上是一件事：让搜尋蜘蛛一次能讀完你希望它讀到的内容。與其在一頁里塞几百條連結，不如保證每條連結都落在被解析的范围内、结构干净、可正常訪問。定期用原始 HTML 大小做個巡检，比事後從日誌里反推原因省事得多。