蜘蛛的抓取并不是打开页面看一眼这么简单。一次抓取大致包含下载、解析、必要时渲染三个阶段，每个阶段都要消耗资源。页面做得越重，蜘蛛真正能拿到的内容反而可能越少，URL 发现也会跟着受影响。
下载阶段：HTML 响应体是有量级上限的
搜索引擎在公开文档里提到过对 HTML 响应体的处理量级，通常在几 MB 级别。超过的部分往往会被截断，不会继续解析。这不是惩罚，而是资源分配的结果：同样的时间和带宽，抓十个轻页面还是抓一个重页面，蜘蛛会算这笔账。
被截断之后，后果比较直接：
- 位于 HTML 尾部的链接可能根本没被解析，URL 发现在这里就断了；
- 正文后半段、参数表、常见问题等内容不会进入索引；
- canonical、hreflang、结构化数据等写在后面的标签可能一起丢失。
常见的体积来源往往不是正文，而是内联脚本、重复输出的 JSON 数据、未压缩的 base64 图片、大段注释和冗余的模板结构。它们对用户几乎不可见，却实打实地占掉了抓取额度。
渲染阶段：脚本生成的内容要排第二次队
纯前端渲染的页面，蜘蛛第一次拿到的其实是一份近乎空壳的 HTML，链接和正文要等进入渲染队列、执行完脚本才会出现。渲染本身更贵，等待时间通常也比普通抓取更长，而且渲染有超时限制，超时后蜘蛛拿到什么就是什么。
懒加载与无限滚动最容易出问题
图片、评论区、列表项如果依赖滚动或点击才加载，蜘蛛不一定会去触发。只在渲染完成后才插入 DOM 的链接，也可能就停在没被发现这一步，等于少了一批入口。
渲染失败还会带来重复成本
如果同一个 URL 每次渲染都失败或超时，蜘蛛可能反复重试，把配额花在同一个页面上，其他页面的抓取机会就被挤掉了。这类问题在日志里通常表现为同一地址的多次请求。
把抓取成本降下来的一些做法
- 关键正文和主要内链走服务端直出，不要等脚本生成；
- 控制单个页面的 HTML 体积，长列表拆成有独立 URL 的分页；
- 导航和列表用真实的 a 标签加 href，不要用点击事件跳转；
- 图片使用原生 img 的 src，比纯 CSS 背景图更稳妥；
- 把 canonical、hreflang 和结构化数据放在 head 里靠前的位置；
- 模板里重复的数据尽量精简，别把整份接口响应直接塞进页面。
如果日志里蜘蛛请求返回的字节数明显小于页面实际体积，先怀疑被截断，而不是先下结论说蜘蛛不来了。
怎么确认自己有没有踩线
可以对比三种视角：一是服务器日志里蜘蛛请求对应的响应体大小；二是用工具以不执行脚本的方式看一次页面，检查正文和主要内链是否完整；三是带上渲染再看一次，看只有渲染后才出现的 URL 有多少。两个结果差距越大，说明页面越依赖渲染。
抓取没有越轻越好或越大越好的绝对答案，但有一点比较确定：让蜘蛛用更低的成本拿到更完整的内容，URL 发现和内容收录都会走得更顺。