抓取不只是一次 HTML 请求
当蜘蛛请求一个 URL，它拿到的第一份东西是服务器返回的 HTML。对静态页面来说，事情到这里基本结束；但对依赖前端渲染的页面，HTML 往往只是一个壳子，真正的内容要等脚本执行完才出现。蜘蛛为了看到这些内容，需要额外拉取一批资源——这些请求同样要排队，同样占用带宽和抓取资源。
很多站点排查抓取问题时只看“这个 URL 被没被抓到”，却很少看这一次抓取一共发起了多少个请求。把这两个数字放在一起，往往能解释一部分“页面被抓了，但内容没被理解”的现象。
一次页面渲染，通常会牵动哪些请求
- HTML 文档本身：主体，也是抓取调度的基础单位。
- 阻塞渲染的 CSS：样式表通常要先拿到，页面才具备可渲染条件。
- JS 文件：包括框架代码、业务代码，以及首屏渲染必须执行的那部分逻辑。
- 接口数据：前端渲染的内容大多来自内部 API 或 JSON 接口，这是最容易漏掉的一块。
- 图片、字体、图标：影响首屏呈现，但通常不阻塞内容文本的生成。
前四项里，任何一项抓取失败，页面都可能渲染出空白或残缺的内容。而它们各自的抓取是相互独立的请求，都会计入站点的抓取开销。
接口请求为什么容易被忽略
静态资源通常写在 HTML 里，一眼能看到；接口地址却往往藏在打包后的 JS 中，只有执行脚本才会暴露。这意味着即使 HTML 和 JS 都抓到了，只要接口没被成功请求，页面上依然是空容器。
判断一个页面是不是“渲染依赖型”，最简单的办法是：禁用 JS 打开它。如果正文、标题、主要链接都不见了，那它就是在等渲染。
资源抓取对站点意味着什么
抓取资源是有限的。一个页面渲染要拉十来个 JS 和接口，站点能覆盖的 URL 数量自然会被压缩。对于内容量大、更新频繁的站点，这种消耗会在抓取日志里表现为：一部分 URL 抓得很勤，另一部分长期没动静。
需要留意的是，资源被请求不等于会被长期复用。如果文件名带随机哈希、接口带随机参数，每次渲染都可能重新拉一遍，开销会成倍增加。
几个可以立刻检查的点
- 首屏内容是否必须依赖 JS 才能出现，还是可以在 HTML 里先给出。
- JS 与 CSS 是否被打包成一个大文件，还是按页面拆分。
- 接口是否稳定返回，是否存在超时或偶发 5xx。
- 静态资源是否带了可长期缓存的头，文件名是否稳定。
- 是否有只在渲染后才生成的链接，导致这些 URL 只能靠渲染被发现。
该保留哪些、该削减哪些
削减的目标不是“资源越少越好”，而是让抓取资源花在内容上。几个常见的取舍方向：
- 把首屏正文和主要导航放进服务端输出或预渲染结果，让基础内容不依赖脚本。
- 把关键接口合并，减少渲染链路上的请求数量。
- 非首屏的评论、推荐、社交组件延后加载，不必出现在抓取路径上。
- 静态资源使用内容哈希加长期缓存，避免重复下载。
如果站点同时维护移动版和桌面版，还要确认两者的资源链路是否一致——蜘蛛以哪一版为准，就决定了它会走哪条链路。
怎么确认蜘蛛实际走了哪条链路
服务端日志里能看到的不只是 HTML 请求，还有随后的 JS、CSS 和接口请求（前提是它们同样命中你的服务器）。按时间排序，把同一蜘蛛 IP 在几秒内发起的一串请求挑出来，就能大致还原一次渲染过程。
也可以借助抓取工具查看渲染前后的 DOM 差异，或者观察渲染后页面里新增了哪些链接。差异小，说明 HTML 已经承载了主要内容；差异大，说明抓取路径高度依赖渲染。
小结
蜘蛛抓一个页面，代价可能是十几次请求。把这条链路捋一遍，通常比反复提交 URL 更有效：先确认内容能不能在更靠前的位置出现，再决定哪些资源必须让蜘蛛拉取，哪些可以等用户来了再说。