很多站点把連結交给前端框架在浏览器里生成，结果在日誌里看到蜘蛛来訪，却没有跟進任何新 URL。原因往往不在抓取能力，而在于蜘蛛第一次拿到的 HTML 里没有連結，之後要等渲染队列排期，才能看到真正的入口。
首次抓取看到的連結才算入口
搜尋蜘蛛處理一個 URL 通常分两段：先按普通 HTTP 請求取回原始响應，做基础解析；頁面如果依赖 JS 生成内容，才會被放進渲染队列，由渲染服務执行脚本後再解析一次。第一段看到的連結會較快進入調度；第二段看到的連結要等排期，延迟從几小时到几天不等。如果站点的头部連結都藏在第二段，URL 發現的速度就會明顯變慢。
由此得到一個直接结论：越重要、越希望被尽快發現的入口，越應该出現在原始 HTML 中。渲染队列不是失敗，但它是一個有容量限制的中間环节，不该承担全部的發現工作。
渲染排期受哪些因素影响
- 站点被抓取的總量：队列是共享的，抓取量大的站点渲染任務通常也更多。
- 頁面渲染耗时：脚本越多、外部請求越多，單頁占用時間越長。
- 渲染服務對资源的取舍：图片、字体、統計脚本被拦截是常態，依赖它們才出現的連結可能一直不出現。
- 接口權限：需要登入態或强依赖 Cookie 的接口返回空資料，渲染後自然没有連結。
首屏連結暴露顺序的調整
不需要全站改成服務端渲染，先保證關键路径可用即可。
- 主導航、面包屑、栏目列表第一頁的連結，直接寫在 HTML 里，不要等 JS 注入。
- 列表頁的前若干條内容用服務端輸出，滚動加载只作為补充。
- 分頁入口使用带 href 的 a 标簽，避免用按钮加事件替代。
- 接口返回的資料如果决定連結是否存在，检查未登入狀態下是否仍有可用的兜底輸出。
- 確認 robots.txt 没有拦住渲染所需的 JS、CSS 或資料接口，否則渲染结果等于空頁。
怎么確認連結是否被及时發現
看抓取日誌
把原始 HTML 里的 URL 集合與蜘蛛實际請求的 URL 集合做差集。差集里長期没有记錄的部分，基本就是只存在于渲染结果中的入口。同时观察同一 URL 两次訪問之間的間隔，間隔很長，說明它在等渲染排期。
看渲染前後的等價视图
用禁用脚本的方式取一次頁面，再與開啟脚本的结果對比。两者連結數量差距過大，就需要調整輸出方式，而不是繼續加内鏈。
看资源可達性
渲染服務請求 JS 與接口时如果返回 403 或超时，渲染结果會截断。检查服務器的訪問控制是否對非浏览器 UA 或缺少某些头部的請求做了拦截。
渲染可以补全内容，但不能替代基础的内鏈輸出。把發現入口的责任交给渲染队列，等于把 URL 發現的速度交给別人排期。
一個常见的誤判
有人看到日誌里有渲染請求，就認為連結已经被發現。實际上渲染請求只說明頁面被處理過，連結是否進入調度，還要看後續是否出現對這些 URL 的抓取。判断标准應该落在目标 URL 的首次抓取時間上，而不是渲染次數。
把這件事拆開看會更清楚：原始 HTML 负责快速發現，渲染负责补充内容與深层連結。两者都做，URL 發現的节奏才稳定；只靠後者，站点規模越大越容易积压。