抓取不只是“能不能打开”
很多运营者判断一个页面是否被正常处理，只看状态码和响应时间。状态码 200、TTFB 在两百毫秒以内，看起来一切正常，但抓取日志里这个 URL 可能只出现过一次，之后再没被回访，或者回访了却没有内容进索引。这时问题往往不在服务器，而在于抓取程序拿到的这一份响应体是否被完整解析。
抓取程序对单个响应有大小与时间上的处理边界。响应体越大，解析、抽取、去重所消耗的资源越多；当正文被压在几十万字符的 DOM 之后时，抽取环节可能提前结束，页面在索引侧就表现为“内容稀疏”或“无有效正文”。
体积膨胀的常见来源
- 首屏内联了大量 CSS 与 JS，尤其是把整套组件库直接打进 HTML 模板。
- 图片以 base64 内联，单张几十 KB，一个列表页就能累积到数百 KB。
- 导航、页脚、相关推荐在每篇文章里重复渲染大段结构相同的节点。
- 列表页一次性输出全部数据，不做分页或懒加载占位。
- 内联 SVG 图标、调试注释、未压缩的 JSON 数据块。
这些内容单看都不致命，叠加起来却会让一个本该 30 KB 的页面变成 400 KB。对用户来说只是加载慢一点，对抓取程序来说则是解析成本成倍上升。
正文前置的实际做法
所谓正文前置，不是把标题强行提到 body 标签开头，而是让主要内容在 DOM 中的位置尽量靠前，减少抓取程序在无关节点上的遍历。
模板层面的调整
- 把全局导航、侧边栏等结构放到正文之后，或用统一模板在渲染层插入，避免每个页面生成不同副本。
- 首屏关键样式内联，其余样式外链；脚本尽量加 defer 或 async。
- 图片使用外链地址与固定尺寸，避免内联 base64 与布局抖动。
内容层面的调整
- 列表页控制单页条数，超出部分交给分页入口，而不是一次性铺开。
- 把与正文无关的推荐位、评论区折叠到正文之后。
- 去掉模板里长期用不到的注释与调试代码。
一套可复现的排查顺序
- 从抓取日志里筛出“访问次数少但页面正常返回 200”的 URL，形成样本。
- 用命令行抓取这几个 URL，记录响应体的字节数与下载耗时，和站内均值对比。
- 查看正文起始位置：统计第一个正文段落出现在 HTML 中的字符偏移量。偏移越大，抽取风险越高。
- 对比移动端与桌面端模板，确认是否有一端额外加载了整套组件。
- 逐步精简：先关掉内联图片，再外链脚本，观察响应体大小的变化。
- 修改后重新提交，或在站内加一条指向该页的内链，观察下一轮抓取是否带回正文。
观察与节奏
体积优化通常不会立刻体现在抓取量上。抓取程序对页面的信任是逐步建立的，删减掉冗余节点后，需要几轮抓取才能确认页面稳定。建议一次只改一类问题，保留前后对比的响应体大小记录，避免多个变量同时变化导致无法判断效果。
把“响应体大小”和“正文偏移量”加入日常巡检指标，比单纯盯着状态码更容易发现隐性抓取问题。
另外要注意，压缩响应体不等于牺牲内容。目标是去掉重复、冗余、与正文无关的部分，而不是削减正文本身。若页面确实需要承载大量结构化数据，可以考虑拆分为独立入口，让每个 URL 的职责更单一，也更利于被抓取程序稳定处理。