很多站点把抓取问题归因于服务器、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 首次被抓取的时间差。观察一到两周，看趋势是否变化。如果只是个别页面被抓，不必立刻下结论，抓取调度本身存在波动。
页面体积优化能改善抓取效率，但不等于必然带来更多抓取或收录。它只是减少一项阻碍，最终结果仍取决于内容质量、站点整体结构与抓取策略。