抓取不只是“能不能打開”
很多运营者判断一個頁面是否被正常處理，只看狀態碼和响應時間。狀態碼 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 的职责更單一，也更利于被抓取程序稳定處理。