蜘蛛第一次拿到的，往往不是你在浏览器里看到的页面
用浏览器打开页面时，JS 会执行、接口会返回数据、列表会渲染出来。但抓取器请求 URL 时，第一步拿到的通常只是服务器返回的初始 HTML。如果链接是 JS 执行后才插入 DOM 的，它在这份 HTML 里并不存在。
这不代表这些 URL 永远不会被发现，而是它们进入了另一条时间线：先被抓取，再进入渲染队列，渲染完成后才可能提取到新链接，然后再排队抓取。多出来的环节，就是延迟和遗漏的来源。
URL 发现的两条时间线
- 初始 HTML 中的链接：抓到即解析，解析即发现，路径最短。
- 渲染后才出现的链接：需要占用渲染资源，受渲染队列长度、超时、资源加载失败等因素影响。
渲染资源是有限的，站点越大，排在后面的页面等待越久。对于重要目录、新上线的栏目，把入口放在初始 HTML 里，等于把它从第二条时间线挪回第一条。
哪些链接最容易掉进盲区
- 由 JS 拼接生成的分页链接、加载更多按钮
- 点击后才请求接口、再填充列表的栏目页
- 懒加载区域里的链接，需要滚动才出现在 DOM 中
- 依赖登录态、Cookie 或本地存储才渲染的导航
- 前端路由生成的地址，没有对应的 a 标签
这些位置往往正好是深层内容的主要入口。一旦渲染没跑通，整批 URL 就只能靠 Sitemap 撑着，发现速度会明显受制于申报频率和解析顺序。
让关键 URL 出现在初始 HTML 里
- 对首屏做服务端渲染或预渲染，至少保证导航、面包屑、列表页前若干条的链接是真实的 a 标签。
- 分页保留可点击的链接地址，不要只用按钮加事件。
- 重要栏目的入口放在主导航和页脚，不依赖 JS 注入。
- Sitemap 与内链并行，不要把它当成唯一的发现通路。
- 渲染失败时给出可读的降级内容，而不是一个空白容器。
渲染失败时会发生什么
渲染请求对站点也是一次真实访问，会消耗服务器资源。如果页面里脚本和第三方请求偏多，或者服务器响应偏慢，渲染容易在超时前没能完成，结果是这一轮既没提取到链接，也没留下可用内容。反复几次，抓取资源被消耗在同一个页面上，却没有新的 URL 进入队列。
所以判断顺序建议是：先确认初始 HTML 里有没有链接，再确认渲染能不能稳定跑完，最后才考虑用 Sitemap 补漏。顺序反了，容易一直在补，却始终没碰到源头。
怎么确认链接到底有没有被看到
可以对照几类记录：服务器访问日志里该 URL 有没有出现过真实的 GET 请求；抓取统计中渲染请求的数量是否明显少于抓取请求；用抓取工具关闭 JS 打开页面，看还剩多少链接。三者放在一起看，基本能判断问题出在“没进初始 HTML”还是“渲染没跑通”。
提示：渲染额度不是可以无限消耗的。把结构性的链接放进初始 HTML，比事后依赖渲染补偿更省资源，也更稳定。
小结
URL 发现的关键不在于链接“能不能”出现，而在于它出现在哪一层。初始 HTML 里的链接路径最短、最稳；渲染后的链接多一道工序，就多一层不确定性。把导航、列表、分页这些结构性入口做扎实，Sitemap 作为补充，蜘蛛的抓取路径会清晰很多。