做站点运营时，大家更常盯着狀態碼、内鏈和 Sitemap，却很少留意一件事：蜘蛛把頁面 HTML 完整拿回去之前，究竟能讀進去多少。頁面体积本身不决定排名，但它會影响連結和正文能不能被完整解析，尤其是那些把入口藏在頁面後半段的站点。
抓取环节有没有“讀取上限”
主流搜尋引擎對單個 HTML 响應体都有處理上限，只是數值不公開、也會調整。超過上限的部分，往往不會進入後續的解析流程。換句话说，如果某個連結出現在被截断的位置之後，它可能连“被發現”這一步都走不到。
需要說明的是，這個上限通常按未压缩大小計算。你啟用了 gzip 或 br 压缩，传輸体积會小很多，但蜘蛛解压後看到的仍然是完整文档，判断依據還是解压後的内容。所以“開了压缩就没問题”是一種常见的誤解。
什么會把 HTML 撑得很大
- 把 CSS 和 JS 直接内联進頁面，尤其是整段的组件库代碼；
- 用 base64 把图片、字体塞進 style 或 src 属性；
- 一次性渲染几百上千個 DOM 节点，比如未分頁的長列表；
- 模板留下的重复注释、調试信息、被注释掉的舊代碼；
- 把结构化資料的 JSON 整段贴在頁面头部。
這些内容對用戶價值有限，却會让文档体积成倍增長，後面真正需要被發現的連結反而被挤到尾部。
被截掉的多半是這類内容
從经驗看，正文尾部、頁脚導航、相關推荐、分頁控件是最容易受影响的部分。這些位置恰恰承担着把抓取范围铺開的作用。一旦它們没能進入解析，内鏈结构上就會出現断点，蜘蛛在同一批頁面里能走到的入口變少，原本连贯的抓取路径也會在這里停下。
渲染後的 DOM 也計入
如果頁面依赖前端框架渲染，蜘蛛拿到的初始 HTML 可能很小，但执行脚本後生成的 DOM 會迅速膨胀。此时体积問题出現在渲染阶段，同样需要留意：真正带連結的节点是不是已经排到了文档很靠後的位置。
怎么自查頁面体量
- 用浏览器開發者工具查看文档本身的响應大小（未压缩），而不是整個頁面的资源總量；
- 把 HTML 儲存下来，看總字符數，同时看目标連結大概落在第多少字节；
- 随机挑几個内容頁，检查頁脚和分頁連結是否在文档靠後的位置；
- 對照訪問日誌，看這些頁面的抓取频次是否明顯低于同层級的其他頁面。
可以做的几件事
- 把内联样式和脚本外鏈化，让浏览器和蜘蛛分別缓存；
- 图片走獨立文件，不要用 base64 内嵌；
- 長列表做分頁或懒加载，但保留可抓取的分頁連結；
- 重要入口尽量往文档前部放，例如主導航和核心栏目的連結；
- 清理模板注释和無用属性，减少重复的 class 與 data 属性。
別把它当成唯一變量
体量只是抓取环节中的一個因素。服務器响應慢、URL 參數混乱、内鏈断裂同样會让蜘蛛提前离開。建议把它当作排查清單里的一項：当某個区域的頁面長期不被抓取，而狀態碼、robots 文件、Sitemap 都正常时，再回头看看 HTML 本身是不是過于臃肿。
頁面不是越小越好，而是要保證真正需要被發現的連結，出現在蜘蛛能完整讀到的位置。