抓取截断：一个容易被忽略的入口损耗
排查抓取问题时，大家习惯先看状态码、robots、Sitemap 和跳转，却很少关注单个响应体的体积。搜索引擎抓取页面时对 HTML 有大小上限，不同引擎的数值不一样，计算口径通常是最初返回的、未压缩的 HTML 字节数。以公开说明为例，主流引擎对 HTML 的单次抓取上限多在 2MB 以内，超出部分往往不会进入后续解析与链接提取。页面在浏览器里看起来完整，但后半段正文和底部内链实际上没有被处理。
这类问题不会报错，也没有明显状态码异常，只能通过对比发现：索引里的正文比页面上少一截，底部导航区的新链接迟迟不被发现，结构化数据缺失。
先确认是不是体积造成的
- 用命令行拉取原始 HTML 并统计未压缩字节数，例如 curl -s -H 'Accept-Encoding: identity' 页面地址 | wc -c，这个值更接近蜘蛛实际拿到的体积。
- 同时记录压缩后的传输体积，区分“传输大”和“解析体积大”，两者不是一回事。
- 把 HTML 存成文件，标出正文结束位置、第一批内链位置、结构化数据所在行，看它们分别落在多少 KB 处。
- 在抓取日志里观察同一批页面的响应大小分布，找出明显偏大的模板或栏目。
- 如果被截断的内容恰好包含分页链接或列表项，就能解释“深层页面长期不被发现”的现象。
体积通常堆在哪里
- 内联的大段 CSS 与 JavaScript，尤其是把整站样式表塞进 head 的模板。
- 以 base64 形式内嵌的图片、字体和整组 SVG 图标。
- 模板注释、调试输出、被注释掉的旧版块和重复的导航、页脚 HTML。
- 长列表一次性渲染全部条目，条目越多，正文越靠后。
- 富文本编辑器带出的冗余标签、行内样式和空白字符。
其中前两项最容易在改版或引入前端框架后迅速膨胀，且不容易被日常检查发现。
截断之后的连锁反应
抓取截断不只是“少读一段字”。内链如果集中在页面底部，被截断后这些链接就不会进入待抓取队列，久而久之形成孤岛；分页链接如果排在列表末尾，深层列表页的发现速度会明显下降；结构化数据、面包屑和 canonical 如果写在靠后位置，也可能一并缺失。换句话说，体积问题会伪装成内链问题和索引问题。
收敛体积的处理顺序
- 先把 CSS 和 JavaScript 外链化，并做压缩与合并，避免每个页面重复携带。
- 去掉无用注释、调试信息和重复的模板片段，清理空白字符。
- 图片、字体、图标改为独立 URL 引用，不使用内嵌数据。
- 长列表分页，每页条目数控制在合理范围，让正文尽早出现。
- 把关键内链、面包屑、结构化数据前置到正文附近，不要依赖页脚。
- 开启 gzip 或 brotli 压缩传输层，降低带宽占用，但它改变的是传输体积，不会提高解析上限。
- 对确实难以瘦身的页面，用 Sitemap 或独立入口补充链接，减少对内链的依赖。
改完之后怎么核对
核对时看三个量：单页未压缩体积的分布、抓取日志中响应大小的变化、底部内链被发现的速度。如果体积降下来后，原本依赖页脚链接的页面开始出现在抓取记录里，说明方向正确。也可以抽查几个页面，对比源站 HTML 与索引正文的长度差异。
不要用隐藏链接或堆积大量无关内链的方式去“补偿”被截断的部分，这既解决不了体积问题，也会带来新的质量风险。把内容本身放在前部，才是更稳的做法。
小结
抓取截断属于典型的“页面正常但抓取不全”的问题。排查顺序建议是：先量未压缩 HTML 体积，再定位体积来源，然后按外链化、清理冗余、分页拆分、入口前置的顺序收敛，最后用日志和索引结果回看效果。体积降下来，内链和正文的发现才谈得上稳定。