很多站点把抓取问题归因于权重、外链或者更新频率，却忽略了一个更基础的变量：你交给蜘蛛的那个页面本身有多重。抓取是有成本的，只是这份账单不记在你的服务器上。
抓取的成本由什么构成
蜘蛛从你的服务器取走一个页面，要消耗带宽、连接时间、HTML 解析时间，之后还要进入渲染队列等待执行。对搜索引擎来说，这些资源总量有限，需要在全网的 URL 之间分配。所以页面越重，在同样的抓取额度下能覆盖的 URL 就越少。这不是惩罚，而是资源分配的自然结果。
HTML 体积：先看服务器实际吐出了多少字节
很多页面在浏览器里看起来清爽，查看源代码却发现体积惊人。常见的体积来源包括：
- 把 CSS 和 JS 全部内联在 HTML 里，尤其是构建工具默认内联的小文件积少成多
- base64 编码的图片、图标字体直接写进 HTML
- 用脚本标签塞进大段 JSON，比如首屏数据、埋点配置、模板片段
- 导航、页脚、推荐位在每页重复输出，几十个 URL 就多出几十份副本
- 没有开启 gzip 或 brotli 压缩传输
这些内容不会直接导致抓取失败，但会让每次抓取付出的字节数变多。如果站点有几万甚至几十万个 URL，这个差距会被成倍放大。
DOM 节点数与渲染成本
HTML 只是第一步。蜘蛛最终需要拿到渲染后的页面，才能看到由 JS 生成的链接和内容。DOM 节点越多，渲染耗时越长，出问题的概率也越高。
- 首屏之外的模块也全部直出，节点数动辄破万
- 用层层嵌套的容器做布局，一层包裹一层
- 无限滚动列表一次性挂载上千条记录
渲染是有超时限制的。一个页面在渲染队列里耗的时间越长，同一批次里能处理完的页面就越少，部分链接甚至可能在渲染完成前就被截断，蜘蛛根本没机会看到。
链接密度：路标太多，每条都不显眼
页面里的链接数量同样影响发现效率。导航、面包屑、相关推荐、标签云、最新文章、热门排行全部堆上去，一个列表页能出几百上千条链接。蜘蛛会走，但每条链接能分到的关注度被稀释，真正重要的详情页反而淹没在噪声里。
更麻烦的是筛选参数、排序参数、会话参数混在其中，一次抓取就衍生出大量语义重复的 URL，把额度消耗在无价值的组合上。
怎么判断自己的页面算不算重
- 查看源代码体积，和同类型站点的同类页面比一比，差距通常在数倍以上
- 用开发者工具统计 DOM 节点总数，列表页控制在两千以内相对从容
- 数一数页面内实际可点的链接数量，导航加正文加推荐合计别失控
- 确认是否开启压缩传输，HTML 是否被 CDN 合理缓存
- 从访问日志看蜘蛛的抓取间隔与单页响应时间，判断是否被体积拖慢
瘦身动作的优先顺序
- 开启压缩传输，把内联的大段数据挪到异步接口
- 图片改用外链引用，不要 base64 内联进 HTML
- 列表页控制单页条目数，用分页替代一次性直出
- 推荐位、标签云这类模块延迟加载，但保留主要链接在初始 HTML 中可被抓取
- 减少无意义的嵌套容器，能一层解决的不要三层
别走极端
页面瘦身的目标是让蜘蛛用同样的成本看到更多有效内容，而不是把页面砍到只剩骨架。正文、必要的导航和内链是抓取的基础，不能为了追求体积指标而牺牲。体积只是抓取效率的一个维度，内容质量、更新节奏、服务器稳定性同样参与决定蜘蛛愿意来多勤。
比较稳妥的做法是定期回看日志和抓取数据，找出那些体积异常、链接异常密集的模板，优先处理占比最高的那几类页面，而不是逐个手工修改。