很多站点把抓取問题归因于服務器、robots 或 Sitemap，却忽略了一個更基础的因素：單個頁面本身有多大、结构有多复杂。搜尋蜘蛛每次抓取都要先下载 HTML 源碼，再解析文档、抽取連結。在抓取资源有限的前提下，頁面越重，單位時間能處理的 URL 就越少。
抓取成本不只是下载一個 URL
蜘蛛訪問一個 URL 时至少要完成三步：請求並接收 HTML、解析文档结构、從可抓取的連結中繼續排队。這三步都受頁面体积和 DOM 規模影响。HTML 源碼几百 KB、DOM 节点上萬、内联大量脚本和样式的頁面，單次抓取的资源消耗明顯更高。
這不代表頁面大就一定不被抓，而是说在抓取總时長有限的前提下，重頁面會挤占其他頁面的抓取机會，尤其是那些内鏈层級較深的老頁面。
常见的体积與结构問题
- 把图片直接以 base64 内联進 HTML，單頁源碼動辄几百 KB 到几 MB。
- 首屏資料以巨型 JSON 内联在脚本里，包含全站配置或全量列表資料。
- 模板輸出大量注释、重复空白與換行，压缩開關没有打開。
- 彈窗、推荐位、隐藏菜單全部渲染出来，DOM 节点數量遠超實际内容需要。
- 列表頁一次性輸出數千條連結，没有分頁，入口虽多但抓取效率低。
核對顺序
- 看源碼，不看渲染後：用查看源碼或命令行抓取 HTML 原文件，統計字节數。浏览器開發者工具里的元素面板是渲染後的结果，包含脚本注入内容，容易誤判真實体积。
- 對比压缩前後：確認响應头里是否啟用了 gzip 或 brotli。同一段 HTML，压缩前後差距可能有 5 到 10 倍。
- 統計 DOM 节点：在控制台执行 document.getElementsByTagName('*').length，普通内容頁通常在几千以内，超過两三萬就值得精简。
- 抽查列表頁與首頁：這两類頁面的模板最容易被堆功能，也最影响蜘蛛繼續向内爬。
- 检查内联资源占比：把 HTML 里的内联脚本、内联样式、base64 图片單獨拎出来，看它們占了多少字节。
可行的精简方向
- 图片、字体、图标改為外鏈资源，按需加载，而不是塞進 HTML。
- 非首屏内容、彈窗、折叠面板延迟加载，但正文核心連結仍要保留在服務端輸出的 HTML 中。
- 開啟 HTML 压缩，去掉模板注释與多余空白。
- 列表頁合理分頁，每頁連結數量控制在可讀、可抓的范围内。
- 合並重复的模板片段，减少無意义的外层容器。
- 確認真實内容没有被大段内联脚本挤到文档靠後的位置。
传輸层的配合
体积優化之外，响應時間和传輸方式同样影响抓取吞吐。啟用压缩、合理設定缓存头、保持 TTFB 稳定，能让同样的抓取請求更快完成。需要区分的是：压缩解决的是传輸字节數，模板精简解决的是解析成本，两者都需要，但不能互相替代。
調整後怎么驗證
更稳妥的做法是保留調整前後的服務器日誌，按天統計蜘蛛抓取的 URL 總數、不同目錄的分布、狀態碼比例，以及新 URL 首次被抓取的時間差。观察一到两周，看趋势是否變化。如果只是個別頁面被抓，不必立刻下结论，抓取調度本身存在波動。
頁面体积優化能改善抓取效率，但不等于必然带来更多抓取或收錄。它只是减少一項阻碍，最终结果仍取决于内容质量、站点整体结构與抓取策略。