很多人看日志时会遇到一种情况：服务器明明返回了 200，页面也确实被蜘蛛请求过，但页面里的新链接过了很久才出现在抓取记录里，甚至一直没出现。原因往往不在抓取环节，而在抓取之后的渲染排队。
抓取和渲染是两个阶段
对蜘蛛来说，一次完整的处理通常分成两步：先把 HTML 拉回来，再决定是否放进渲染队列，用浏览器内核执行页面脚本，拿到最终形态的 DOM。第一步的速度取决于你的服务器和网络，第二步取决于蜘蛛自己的渲染资源，以及全站有多少页面在排队等待渲染。
关键在于：只有在渲染完成后才出现在 DOM 里的链接，才可能在渲染这一步被看到。如果渲染没有发生，或者发生在很晚之后，这些 URL 的发现时间就会整体后移。
渲染排队怎样拖慢 URL 发现
- 链接依赖前端路由或接口返回后再插入 DOM，初始 HTML 里没有痕迹。
- 页面脚本体积大、依赖多，渲染一次的成本高，容易被排到队列后面。
- 同一批模板生成的页面大量重复排队，渲染预算被摊薄。
- 渲染失败的页面通常不会立刻重排，链接就跟着一起被搁置。
表现上，它不像 5xx 那样醒目：抓取是成功的，只是“看到了却没读懂”。
哪些页面更容易在渲染环节掉队
列表页、聚合页、筛选页通常是重灾区，因为新 URL 大多由它们带出来。其次是靠组件懒加载渲染的导航和推荐位。相对安全的是服务端直出的静态页面，链接写在 HTML 里，抓到即看到。
让关键 URL 出现在初始 HTML 里
- 把主导航、面包屑、分类列表的核心链接改成服务端输出，不依赖脚本插入。
- 列表页首屏的分页入口、下一页链接，直接写在 HTML 中，而不是点击后再请求。
- 为重要栏目提供一份纯 HTML 的入口页，把链接集中放在那里，降低渲染依赖。
- 减少首屏必须执行的脚本量，让渲染更快完成，减少排队时间。
- 如果确实要用 JS 生成链接，尽量在 HTML 中保留等价的可爬链接作为兜底。
这些做法的共同思路是：把 URL 发现这件事，从渲染阶段挪回抓取阶段。
怎么验证是不是渲染问题
关闭浏览器脚本，直接请求页面源码，看目标链接是否还在。如果源码里没有、渲染后才有，就基本可以确认。再对照抓取日志里该页面的请求时间和新 URL 首次被抓的时间差，判断延迟是排队造成还是别的原因。
抓取成功只说明 HTML 到手，链接是否被发现，还要看渲染这一关有没有过、过得快不快。
把链接放回初始 HTML，既减少了对渲染资源的依赖，也让 URL 发现路径更短、更稳定。