蜘蛛抓取一个页面时，并不是“看一眼全部”。它按字节顺序读取 HTML，读完一定量之后就会停下，剩下的内容留给下一次，或者干脆不读。所以当页面体积膨胀、正文和链接被推到很后面时，问题往往不是“没被抓”，而是“读到的部分里没有关键信息”。
读不完的那条线在哪里
不同搜索引擎的读取上限不一致，也会随时间调整，常见量级在 1MB 到 2MB 之间。这个数字指的是 HTML 源码本身，不含图片、视频这类外链资源。超过这条线的内容，在解析和索引阶段都可能被忽略。
更麻烦的是顺序：蜘蛛从上往下读，先遇到的是 head 里的元信息、内联样式、内联脚本，然后才是 body。如果模板在 body 开头塞了几百 KB 的 JSON 数据，正文和导航链接就会被推到读取范围之外。
哪些内容在悄悄占位
- 把整个页面的初始数据以 JSON 形式内联在 HTML 里，列表页和商品页尤其常见；
- base64 内嵌的图片、字体、图标；
- 未拆分的内联 CSS 与第三方脚本；
- 重复的导航、页脚、弹窗模板；
- 被注释掉但仍留在源码里的旧版块。
这些内容对用户未必可见，但对蜘蛛来说一样占用读取额度。
怎么判断自己是否踩线
- 用“查看网页源代码”（而不是审查元素）看 HTML 总大小，以及正文第一段出现在第多少字节；
- 看主要内链，尤其是通往详情页的链接，出现在源码的什么位置；
- 在浏览器里禁用 JavaScript 后打开页面，看还剩多少内容和链接；
- 对照服务器日志，看蜘蛛请求的响应体积与状态码是否稳定。
一个简单的经验：如果正文和核心内链都落在前三分之一，基本不用太担心读取上限；如果链接全在页面底部、前面是大段脚本，就该动手了。
把内容往前挪的几种做法
结构层面
- 把列表页和详情页的正文、主链接放在模板靠前的位置，侧栏、推荐位往后放；
- 导航保持精简，深层入口用分组页承接，而不是全部堆在顶部；
- 分页列表控制单页条数，让 HTML 体积可预期。
资源层面
- 内联数据改为异步接口获取，首屏只保留必要字段；
- 图片、字体走外链而不是 base64；
- CSS、JS 压缩后外部引用，避免大段重复内联。
传输层面
开启 gzip 或 brotli 压缩能减少传输字节，但要注意：压缩减少的是网络传输量，解析上限通常按解压后的 HTML 计算，所以压缩不能替代减体积。同时留意响应是否稳定，忽快忽慢会让蜘蛛降低抓取频率。
延迟加载与内链的取舍
为了首屏速度做懒加载时，最容易出问题的是把链接也一起延迟。图片延迟通常没影响，但列表项、分页入口如果靠滚动才渲染，蜘蛛第一轮可能什么都看不到。折中做法是：链接保持直出，非关键资源再延迟。
最后
体积问题很少单独出现，它往往和内链深度、分页路径、服务器响应速度一起影响抓取效果。与其纠结某一条规则，不如按“源码前三分之一里有什么”这个标准定期检查，把正文和通往下一层的链接稳定地放在蜘蛛读得到的地方。