做站点运营时，大家更常盯着状态码、内链和 Sitemap，却很少留意一件事：蜘蛛把页面 HTML 完整拿回去之前，究竟能读进去多少。页面体积本身不决定排名，但它会影响链接和正文能不能被完整解析，尤其是那些把入口藏在页面后半段的站点。
抓取环节有没有“读取上限”
主流搜索引擎对单个 HTML 响应体都有处理上限，只是数值不公开、也会调整。超过上限的部分，往往不会进入后续的解析流程。换句话说，如果某个链接出现在被截断的位置之后，它可能连“被发现”这一步都走不到。
需要说明的是，这个上限通常按未压缩大小计算。你启用了 gzip 或 br 压缩，传输体积会小很多，但蜘蛛解压后看到的仍然是完整文档，判断依据还是解压后的内容。所以“开了压缩就没问题”是一种常见的误解。
什么会把 HTML 撑得很大
- 把 CSS 和 JS 直接内联进页面，尤其是整段的组件库代码；
- 用 base64 把图片、字体塞进 style 或 src 属性；
- 一次性渲染几百上千个 DOM 节点，比如未分页的长列表；
- 模板留下的重复注释、调试信息、被注释掉的旧代码；
- 把结构化数据的 JSON 整段贴在页面头部。
这些内容对用户价值有限，却会让文档体积成倍增长，后面真正需要被发现的链接反而被挤到尾部。
被截掉的多半是这类内容
从经验看，正文尾部、页脚导航、相关推荐、分页控件是最容易受影响的部分。这些位置恰恰承担着把抓取范围铺开的作用。一旦它们没能进入解析，内链结构上就会出现断点，蜘蛛在同一批页面里能走到的入口变少，原本连贯的抓取路径也会在这里停下。
渲染后的 DOM 也计入
如果页面依赖前端框架渲染，蜘蛛拿到的初始 HTML 可能很小，但执行脚本后生成的 DOM 会迅速膨胀。此时体积问题出现在渲染阶段，同样需要留意：真正带链接的节点是不是已经排到了文档很靠后的位置。
怎么自查页面体量
- 用浏览器开发者工具查看文档本身的响应大小（未压缩），而不是整个页面的资源总量；
- 把 HTML 保存下来，看总字符数，同时看目标链接大概落在第多少字节；
- 随机挑几个内容页，检查页脚和分页链接是否在文档靠后的位置；
- 对照访问日志，看这些页面的抓取频次是否明显低于同层级的其他页面。
可以做的几件事
- 把内联样式和脚本外链化，让浏览器和蜘蛛分别缓存；
- 图片走独立文件，不要用 base64 内嵌；
- 长列表做分页或懒加载，但保留可抓取的分页链接；
- 重要入口尽量往文档前部放，例如主导航和核心栏目的链接；
- 清理模板注释和无用属性，减少重复的 class 与 data 属性。
别把它当成唯一变量
体量只是抓取环节中的一个因素。服务器响应慢、URL 参数混乱、内链断裂同样会让蜘蛛提前离开。建议把它当作排查清单里的一项：当某个区域的页面长期不被抓取，而状态码、robots 文件、Sitemap 都正常时，再回头看看 HTML 本身是不是过于臃肿。
页面不是越小越好，而是要保证真正需要被发现的链接，出现在蜘蛛能完整读到的位置。