抓取截断：一個容易被忽略的入口损耗
排查抓取問题时，大家习惯先看狀態碼、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 体积，再定位体积来源，然後按外鏈化、清理冗余、分頁拆分、入口前置的顺序收敛，最後用日誌和索引结果回看效果。体积降下来，内鏈和正文的發現才谈得上稳定。