搜索蜘蛛发现 URL，主要靠跟随 HTML 源码里的链接。很多人把注意力放在链接放了多少、放在哪个位置，却忽略了更前置的问题：这些链接在源码里到底是不是一条能被跟随的链接。位置再好，写法不对，等于没有入口。
一条可被跟随的链接长什么样
判断标准其实很朴素：打开页面的查看源代码，在 HTML 里能不能看到一个带 href 的 a 标签，href 的值是不是一个完整的、可解析的地址。
- a 标签加 href：最可靠的形式，路径可以用绝对地址，也可以用相对地址。
- href 指向真实页面：不是 javascript:void(0)，不是单独的 #，不是空值。
- 不依赖脚本执行：链接在初始 HTML 里就存在，而不是等前端路由渲染完才出现。
几种常见的假链接
下面这些写法在浏览器里点起来没问题，但对 URL 发现来说是断的。
用脚本绑定点击
把跳转写在 onclick、事件监听或者框架的路由方法里，标签可能是 div、span、button。浏览器能跳，源码里却没有一条可跟随的地址。
整站靠前端路由渲染
单页应用如果只输出一个空容器，首屏链接都要等脚本跑完才有，就等于把所有入口押在渲染结果上。至少应该让关键导航和列表在服务端渲染或预渲染阶段输出。
隐藏与折叠内容里的链接
display:none、高度为零、被弹层遮挡的链接，处理方式并不统一。更稳妥的做法是让重要入口留在正常可见的 DOM 里。
表单、图片与 iframe
POST 表单提交的地址不构成跟随入口；图片链接和 iframe 里的内容即便能被处理，也不如一条普通 a 标签清晰可预期。
rel 属性与页面级限制
链接存在，不等于一定会被跟随。nofollow、sponsored、ugc 这类 rel 值会影响跟随判断；页面头部的 meta robots 或 X-Robots-Tag 也会限制整页链接的处理。核对时要把链接存在和链接可跟随分开看。
发现是抓取的前一步。入口没有暴露出来，后面的抓取、渲染、索引都无从谈起。
分页与加载更多的入口处理
列表页的后续内容如果只能通过按钮触发脚本追加，那么第二页之后的 URL 就没有稳定入口。常见做法是保留一组可跟随的分页链接，脚本加载只作为体验优化；如果确实不想暴露分页地址，也要考虑这些 URL 通过 Sitemap 或其他内链被发现的方式。
内链和 Sitemap 的关系
Sitemap 是补充入口，不是替代品。它适合提交那些内链覆盖不到、层级较深的 URL。反过来，如果一个 URL 只出现在 Sitemap 里、站内没有任何可跟随链接指向它，它被回访的频率通常也不会高。
上线前的自查顺序
- 取一个典型页面，禁用 JavaScript 后查看源码，确认导航、面包屑、正文链接是否还在。
- 抽查链接的 href 是否为可解析地址，排除 javascript:、占位符和空值。
- 检查重要入口是否被 nofollow 或页面级规则挡住。
- 确认列表页翻页有可跟随链接，而不是纯脚本追加。
- 核对 Sitemap 是否覆盖了内链薄弱但需要被发现的 URL。
- 用日志观察这些入口对应的 URL 是否有持续的抓取记录。
这些检查都不复杂，但顺序很重要：先确认链接存在且可跟随，再谈链接放的位置和数量。把这一层做扎实，URL 发现的地基才算立住。