很多站点把内容交给前端框架渲染，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。渲染队列的優先級很难被外部手段直接提升，能做的通常是把「必须渲染才能看懂」的頁面，變成「不渲染也能看懂」的頁面。