很多人把入口頁当成一張清單，恨不得一次性把几千個連結全塞進去。但搜尋蜘蛛抓取一個頁面时，並不是“看到多少就處理多少”——它只解析响應体的一部分，超過這個量的内容往往不會被繼續讀取。于是就出現一個實际問题：当 HTML 体积過大时，排在後面的連結有可能根本不會被發現。
搜尋蜘蛛讀取頁面时确實有“讀取上限”
主流搜尋引擎對單個 HTML 文档的大小都有類似限制，但各家數值不同，也没有公開统一的标准，具体以各引擎官方文档為准。歷史上 Google 提到的量級在 2MB 左右，其他引擎的量級並不一致。關键有两点：
- 上限针對的是 HTML 源碼本身，不是你眼里的“頁面有多長”；
- 超限的部分通常不再解析連結，頁面整体也未必被判為無效，但連結就被漏掉了。
体积是怎么被撑大的
- 把图片以内联 base64 的形式寫進 HTML，一條就几百 KB；
- 内联大段 CSS、JS，或者模板里重复渲染統計代碼；
- 每條連結外面包了多层 div、table 或大量 style 属性；
- 锚文本、title、說明文字寫得很長，逐條累加；
- 一次放几千條連結，光 li 标簽就能堆出很大体积。
怎么判断自己的入口頁有没有超
- 浏览器“查看源代碼”，另存為文件，直接看未压缩的体积；
- 做一個只保留連結的极简版本做對比，看体积主要来自哪里；
- 在抓取日誌里观察搜尋蜘蛛對该頁的抓取频次、返回碼和响應大小；
- 用抓取模拟工具確認拿到的 HTML 是否完整、連結是否都在。
如果發現体积的大头来自内联资源或冗余标簽，而不是連結本身，那說明還有很大的压缩空間。
更稳妥的几種组织方式
- 把連結往前放：別让關键連結被模板、頁脚、統計脚本压在最後；
- 减少内联资源：CSS/JS 尽量外鏈並压缩，图片用外鏈地址；
- 分批投放或分頁承载：新連結分几次添加，每頁控制在較轻的量級；
- 让入口頁只做“發現”這一件事：不要顺手塞無關正文、广告、推荐模块；
- 用 sitemap 作為补充通道：不要把發現 URL 的希望全部压在入口頁上。
体积上限只影响“連結能不能被解析到”，並不决定收錄。連結被發現，也只是進入待抓取队列，後續是否抓取、抓多少，仍由搜尋引擎自己决定。
几個容易踩的誤区
- 以為開啟 gzip 传輸就能绕過限制：上限通常按解压後的内容計算；
- 以為連結數量比体积更重要：几千條連結挤在超大頁面里，可能一條都没被讀到；
- 以為連結藏在折叠区域就没事：折叠多由 CSS/JS 控制，HTML 里還在就照样算体积；
- 以為頁面能正常打開就說明没問题：人能滚到底，蜘蛛未必讀到那么遠。
入口頁的核心任務很简單：把 URL 交出去。保持 HTML 轻、结构简單、連結位置靠前，比追求單頁連結總數更實际。我們能控制的是別让体积成為發現环节的障碍，剩下的交给各引擎自己的抓取策略。