很多站点把内容交给前端框架渲染，HTML 源码里只有一层骨架。蜘蛛第一次拿到这个响应时，看到的并不是用户最终看到的页面。理解这中间的流程，能解释不少「URL 明明在 Sitemap 里，却迟迟没有抓取反馈」的情况。
一次抓取，通常分成两步
处理 JS 页面时，搜索引擎一般会先做一次普通的 HTML 抓取，把响应体存下来；如果页面里存在需要执行的脚本，且这些脚本可能影响内容或链接，这个 URL 会被放进渲染队列，等有空闲资源时再执行一次。两步不一定连续，也不一定在同一个时间点完成。
对站点来说，这意味着同一个 URL 可能在日志里留下两次访问记录，而且两次请求的响应大小、耗时都不一样。看到这种情况不必紧张，它只是流程的一部分。
第一轮：HTML 里能拿到什么
第一轮决定了很多基础判断：状态码、canonical、meta robots、hreflang，以及 HTML 中本来就存在的 a 标签链接。如果这些信息要等脚本执行后才写入 DOM，第一轮就可能读不到。
- 链接直接写在 HTML 里，URL 发现的路径最短；
- 链接靠脚本拼接或点击后才插入，发现时间会被推迟；
- canonical 由脚本写入，容易出现两轮判断不一致。
第二轮：渲染队列的排队与超时
渲染要消耗比普通抓取多得多的资源，所以队列是有限的。队列里的等待时间取决于站点整体情况、页面数量、渲染失败率等因素，并没有一个可以查询的固定秒数。
常见的卡点
- 脚本报错或依赖接口超时，页面渲染不出内容；
- 首屏内容在用户交互后才出现，渲染时拿到的仍是空壳；
- 渲染需要登录态或地理位置，抓取环境拿不到；
- 同一模板下大量 URL 都要渲染，队列被低价值页面占满。
渲染不是「一定发生」的兜底机制，它更像给必要页面的一次补抓机会。越少依赖它，抓取路径越稳定。
让关键 URL 少排队的做法
- 把正文、标题、主要链接放进服务端返回的 HTML，至少保证首屏可见；
- 重要的栏目页、详情页用静态 a 标签串联，不依赖脚本跳转；
- 把不必要的脚本延后或按需加载，减少渲染时的失败点；
- Sitemap 只放真正需要被抓取的 URL，别把筛选组合页全塞进去；
- 关注服务端渲染或预渲染方案，但不要为了渲染而堆叠多层代理。
怎么确认自己有没有卡在渲染上
- 用抓取工具关闭脚本请求一次页面，看核心内容是否还在；
- 对比服务器日志中同一 URL 的两次访问，看第二次是否请求了脚本资源；
- 在站长平台的抓取统计里，观察已抓取与已渲染两个口径的差异；
- 抽查几个重点 URL，看抓取快照里的内容和用户看到的是否一致。
如果发现大量 URL 只有第一轮记录，重点先排查脚本错误和接口超时，而不是急着改 Sitemap。渲染队列的优先级很难被外部手段直接提升，能做的通常是把「必须渲染才能看懂」的页面，变成「不渲染也能看懂」的页面。