不少站点在浏览器里点起来很顺，导航、列表、翻页都能跳转，但抓取工具取回的初始 HTML 里可能一条链接都没有。链接是页面被发现的入口，如果它只在脚本执行之后才出现，URL 就会晚一步进入队列，严重时干脆进不去。这篇讲的是渲染前后链接可见性的差别，以及怎么把这件事查清楚。
抓取工具看到的，和用户看到的不是同一个东西
处理一条 URL 大致分两步：先把原始 HTML 取回来，再在需要时执行脚本、拿到渲染后的 DOM。第一步拿到的是源码，第二步才接近用户眼里的页面。如果导航、列表项、分页入口全部由脚本注入，第一步就看不到这些地址。
这不等于一定收不到，但要意识到一件事：新 URL 的发现路径被拉长了，而且多了一道依赖。
哪些写法会让链接“渲染后才出现”
- 用 div、span 加点击事件做跳转，而不是 a 标签带 href。
- 前端路由切换视图，初始 HTML 只是一个几乎空的容器。
- “加载更多”按钮靠事件监听发请求，拼接出来的地址只存在于接口参数里。
- 标签页、折叠面板的内容由脚本请求后插入，展开前页面里没有对应链接。
- 无限滚动列表，后续条目没有各自独立的静态地址。
这些写法对用户体验往往没问题，但把“可发现”这件事完全押在了脚本执行上。
URL 进入抓取队列的常见入口
- 站内 a 标签的 href，包括导航、面包屑、正文内链。
- sitemap 文件里列出的地址。
- 外部页面指向本站的链接。
- 已抓取页面在渲染后读到的链接。
- 历史抓取记录中出现过、之后被重新检查的地址。
前三条不依赖脚本执行，属于相对稳定的来源；第四条要看渲染能力，通常更慢也更不确定。如果你的重要页面只有第四条能走到，节奏就不在自己手里。
自查顺序：从“能不能看到”开始
- 用禁用 JavaScript 的方式打开页面，看导航和正文里还能不能找到指向目标页的普通链接。
- 检查关键入口是否用的是 href，而不是点击事件或脚本跳转。
- 看 sitemap 是否覆盖了需要被发现的地址，尤其是深层详情页和分页后续页。
- 看分页与“加载更多”是否对应可被抓取的静态地址，比如带页码参数的独立 URL。
- 确认重要页面至少有一条来自其他页面的普通链接，不是只靠脚本生成。
- 对照服务端日志或抓取记录，确认目标地址到底有没有被访问过。
这六步走完，基本能分清问题出在发现环节，还是出在发现之后的抓取与处理环节。
可以做的一些调整
让初始 HTML 里就有链接
把重要导航、分类入口、分页链接改成服务端输出或预渲染输出，保证源码里就有可读的 a 标签。前端路由接管跳转可以保留，但底层留一个真实链接做兜底。
给批量内容留独立地址
无限滚动配合分页 URL，每个片段都有稳定地址；标签页内容如果值得被单独发现，也尽量给一个可访问的地址，而不是只存在于展开动作之后。
把 sitemap 当补充，而不是唯一依靠
sitemap 能帮助列出一批地址，但它替代不了站内链接所表达的层级和重要性。两者都缺的时候，深层内容最容易掉队。
脚本渲染只是把链接送到抓取工具面前的一种方式，它本身不保证页面被收录。正文质量、重复程度、URL 规范，仍然决定后续结果。
什么时候可以不用太紧张
如果脚本生成的链接只是锦上添花，核心页面在初始 HTML 里已经有一套完整入口，那渲染差异带来的影响通常有限。反过来，如果整站导航都靠脚本拼出来，就把“链接可见性”当成一项常规检查项，而不是等出问题再回头补。