很多人盯抓取問题，只看狀態碼、Sitemap 和 robots.txt，却忽略了一個很朴素的因素：蜘蛛抓一個 URL，需要下载並解析的東西到底有多大。頁面体积不直接决定收錄，但它會影响蜘蛛在同样時間里能走多遠。
蜘蛛抓取一次，成本不只是“下载正文”
一次抓取大致包括：域名解析、建立连接、發送請求、讀取响應头、下载响應体，然後解析 HTML。如果頁面里還有需要單獨請求的资源，那又是另外的抓取通道。對蜘蛛来说，單頁越重，單位時間内能處理的 URL 就越少。
這並不是说頁面必须极简，而是要让主要成本花在有用的内容上。内联了大量用不到的 JSON、把图片轉成 base64 塞進 HTML、重复的模板结构，都會让响應体膨胀，而蜘蛛能從中提取的有效信息並没有增加。
HTML 体积通常從哪里膨胀
- 把整份資料對象内联在頁面里，其中大部分字段首屏根本用不到；
- 图片以 base64 形式寫在 HTML 或 CSS 中，体积比獨立請求大得多；
- 列表頁一次性輸出几百條记錄，分頁形同虚设；
- 大量注释、空标簽、重复的 class 與内联样式；
- 未做压缩，直接輸出几百 KB 的原始 HTML。
控制体积的几個實际做法
- 開啟压缩：gzip 或 brotli 對 HTML 的压缩效果通常很明顯，服務器和 CDN 都能配置。
- 把資料放到接口里：首屏不需要的字段不要内联，让頁面渲染依赖按需請求。
- 图片用獨立地址：静態资源走單獨的 URL，既减小 HTML，也便于缓存。
- 列表頁分頁或懒加载：每頁條目控制在合理范围，後續内容通過連結或翻頁暴露。
- 清理模板冗余：合並重复结构，去掉無用注释和空节点。
体积為什么會間接影响 URL 發現
蜘蛛的抓取资源是有限的。同一台服務器、同一段時間里，如果每個頁面都很重，蜘蛛能完整走到的新連結就更少，新 URL 的發現和驗證會被拖後。列表頁、标簽頁、频道頁這些承担着内鏈分發作用的頁面，尤其值得先瘦身。
與此同时，Sitemap 和清晰的導航仍然是發現路径的主干。体积優化让蜘蛛走得更顺，但不能替代可抓取的連結结构。两者配合，效果才稳定。
怎么確認問题出在体积上
在服務器日誌或抓取統計里看响應字节數、响應時間與抓取频次的對應關系。如果某些頁面的响應明顯偏大、耗时偏長，而蜘蛛訪問它們的間隔也變長，就值得检查輸出内容。也可以在本地對比压缩前後的大小，通常會有直观的差距。
服務器稳定性同样是前提
体积優化不只是為了蜘蛛。更小的响應体、合理的缓存策略，能同时降低带宽和資料库压力。服務器响應稳定，蜘蛛的抓取节奏才不會被频繁的超时和错誤打断。
頁面体积不是排名因素，但它影响蜘蛛在單位時間里能走多遠。把 HTML 控制在合理范围，让抓取预算花在真正需要被發現的 URL 上。