蜘蛛抓取一個頁面时，並不是“看一眼全部”。它按字节顺序讀取 HTML，讀完一定量之後就會停下，剩下的内容留给下一次，或者干脆不讀。所以当頁面体积膨胀、正文和連結被推到很後面时，問题往往不是“没被抓”，而是“讀到的部分里没有關键信息”。
讀不完的那條线在哪里
不同搜尋引擎的讀取上限不一致，也會随時間調整，常见量級在 1MB 到 2MB 之間。這個數字指的是 HTML 源碼本身，不含图片、视频這類外鏈资源。超過這條线的内容，在解析和索引阶段都可能被忽略。
更麻烦的是顺序：蜘蛛從上往下讀，先遇到的是 head 里的元信息、内联样式、内联脚本，然後才是 body。如果模板在 body 開头塞了几百 KB 的 JSON 資料，正文和導航連結就會被推到讀取范围之外。
哪些内容在悄悄占位
- 把整個頁面的初始資料以 JSON 形式内联在 HTML 里，列表頁和商品頁尤其常见；
- base64 内嵌的图片、字体、图标；
- 未拆分的内联 CSS 與第三方脚本；
- 重复的導航、頁脚、彈窗模板；
- 被注释掉但仍留在源碼里的舊版块。
這些内容對用戶未必可见，但對蜘蛛来说一样占用讀取額度。
怎么判断自己是否踩线
- 用“查看網頁源代碼”（而不是审查元素）看 HTML 總大小，以及正文第一段出現在第多少字节；
- 看主要内鏈，尤其是通往詳情頁的連結，出現在源碼的什么位置；
- 在浏览器里禁用 JavaScript 後打開頁面，看還剩多少内容和連結；
- 對照服務器日誌，看蜘蛛請求的响應体积與狀態碼是否稳定。
一個简單的经驗：如果正文和核心内鏈都落在前三分之一，基本不用太担心讀取上限；如果連結全在頁面底部、前面是大段脚本，就该動手了。
把内容往前挪的几種做法
结构层面
- 把列表頁和詳情頁的正文、主連結放在模板靠前的位置，侧栏、推荐位往後放；
- 導航保持精简，深层入口用分组頁承接，而不是全部堆在顶部；
- 分頁列表控制單頁條數，让 HTML 体积可预期。
资源层面
- 内联資料改為异步接口获取，首屏只保留必要字段；
- 图片、字体走外鏈而不是 base64；
- CSS、JS 压缩後外部引用，避免大段重复内联。
传輸层面
開啟 gzip 或 brotli 压缩能减少传輸字节，但要注意：压缩减少的是網絡传輸量，解析上限通常按解压後的 HTML 計算，所以压缩不能替代减体积。同时留意响應是否稳定，忽快忽慢會让蜘蛛降低抓取频率。
延迟加载與内鏈的取舍
為了首屏速度做懒加载时，最容易出問题的是把連結也一起延迟。图片延迟通常没影响，但列表項、分頁入口如果靠滚動才渲染，蜘蛛第一轮可能什么都看不到。折中做法是：連結保持直出，非關键资源再延迟。
最後
体积問题很少單獨出現，它往往和内鏈深度、分頁路径、服務器响應速度一起影响抓取效果。與其纠结某一條規則，不如按“源碼前三分之一里有什么”這個标准定期检查，把正文和通往下一层的連結稳定地放在蜘蛛讀得到的地方。