站内链接是搜索蜘蛛发现 URL 的主要入口，但如果这些链接要等 JavaScript 跑完才出现在页面上，抓取路径就多了一道门槛。理解原始 HTML 与渲染后 DOM 的差别，能帮我们判断哪些入口是稳的、哪些只能看运气。
抓取通常分成两步
搜索蜘蛛请求一个地址时，最先拿到的是服务器直接返回的 HTML。它会在这一份内容里找链接、记录 URL，然后把新地址放进抓取队列。对于依赖 JS 才能显示内容的页面，搜索引擎可能还会把页面放进渲染队列，用浏览器环境再跑一遍，拿到渲染后的 DOM，再从里面提取链接。
问题在于渲染是有成本的，排队、执行、超时都可能让这一步延后，甚至跳过。链接如果只在渲染后才出现，它的发现时机会被推后，而且不保证每次都能被走到。
哪些写法会让链接只活在渲染之后
- 用 div、span 加 click 事件模拟跳转，没有真实的 a 标签与 href。
- href 写死成 # 或空脚本，真实地址藏在 data 属性或事件回调里。
- 列表数据由前端接口拉取后生成，服务端返回的 HTML 里没有对应链接。
- 内容默认折叠，只有展开或滚动到可视区域时才插入链接。
- 依赖 hash 路由，路径变化只体现在井号之后的部分。
这些写法对用户可能没什么问题，但对 URL 发现来说，入口的可靠性下降了一档。
让 JS 链接更容易被发现的几种做法
- 首屏链接用服务端渲染或静态生成。列表页、栏目页、详情页之间的关键互链，尽量在初始 HTML 里就已经存在。
- 保留真实的 a 标签。即使用了前端框架做跳转，也让 href 指向真实地址，用户和蜘蛛都能读到。
- 给纯前端列表留一个静态入口。比如「查看全部」指向一个服务端渲染的分页页，覆盖那些只在滚动里出现的地址。
- 用 sitemap 做兜底。渲染依赖很重的站点，把重要 URL 放进 sitemap，等于多一条独立的发现路径，但它不能替代内链的作用。
- 控制首屏体积。渲染超时常见的原因是首屏脚本太重，关键链接还没插进去，渲染窗口就过去了。
渲染是补充手段，不是内链的替代品。能在原始 HTML 里出现的链接，就不该只留在渲染之后。
无限滚动与分页的组合
无限滚动很常见，但页面往往只加载第一屏，后面的 URL 对蜘蛛不可见。比较稳妥的做法是保留可访问的分页地址，滚动加载只作为体验增强，而不是唯一入口。同理，筛选和排序如果会产生独立 URL，最好也有一个不带参数的静态列表版本作为主干。
怎么自查
最直接的办法是禁用 JavaScript 打开页面，看还能不能顺着链接走到下一级；或者查看页面源代码，确认首屏的关键链接是否出现在返回的 HTML 里。再结合服务器日志，看看那些只靠渲染才出现的地址，是否真的被请求过。如果长期没有请求记录，就要考虑把它们挪到原始 HTML 或 sitemap 中，减少对渲染环节的依赖。