在入口页里放目标链接时，有人习惯用短链服务或自建的跳转页，好处是能统计点击、随时换目标、隐藏真实地址。但从 URL 发现的角度看，多一层跳转就多一层不确定性：搜索蜘蛛会不会跟到最终的目标页，取决于跳转是怎么实现的，以及这条链路上有没有额外的拦截。
先分清跳转的几种实现方式
同样叫“短链”，背后的技术实现差别很大，蜘蛛看到的也不一样：
- 服务端 301 / 302 / 307 重定向：请求短链地址时，服务器直接返回状态码和 Location 头，浏览器和蜘蛛都是靠这个响应跳转。
- meta refresh：先返回一个 HTML 页面，页面里用 meta 标签声明几秒后跳走。
- JavaScript 跳转：返回的 HTML 里靠 location.href 之类的脚本执行跳转。
- 短链平台自有逻辑：先返回一个中间页，前端再调接口换取真实地址，中间页本身可能带 robots 规则或登录校验。
搜索蜘蛛在这些链路上会怎么走
服务端 301 / 302：通常会被跟随，但跳数有限
服务端重定向是蜘蛛最容易处理的形式。它拿到 Location 头后，会继续请求下一跳。需要留意两点：一是跳数，多数搜索引擎对单个 URL 的连续重定向有上限（常见说法在 5 跳左右），链条太长，后面的地址很可能就不追了；二是重定向链里如果任何一跳返回 5xx、404，或者被 robots.txt 的 Disallow 挡住，链路就断在那里。
meta refresh 与 JS 跳转：不确定性明显更大
这两种方式都需要蜘蛛先把 HTML 抓下来、再去解析或渲染。HTML 层面的解析通常没问题，但 JS 跳转要看渲染环节是否执行到那一段，尤其是脚本被外链、被混淆、或者依赖某个接口返回成功才跳转的时候，实际能否跟进就很难保证。把跳转逻辑放在异步请求之后，等于把 URL 发现交给了运气。
短链平台自己的规则可能直接挡住
不少短链服务对爬虫并不友好：中间页可能带 nofollow，可能对非浏览器 UA 返回验证页，也可能在 robots.txt 里限制抓取。这时候不是“蜘蛛跟不跟”的问题，而是它在第一跳就被挡回来了。自建跳转页相对可控，但同样要检查 robots.txt、UA 判断和 WAF 规则有没有误伤。
用短链或跳转页做 URL 发现，值不值得
结论不复杂：如果目标只是统计点击，短链很方便；如果目标是让搜索蜘蛛从入口页走到目标页，那每一层跳转都是在削减成功率。跳转链条越长、越依赖脚本、中间页越“聪明”（UA 判断、风控、验证码），被发现的可能性就越低。
另外还有一个容易被忽略的点：即使蜘蛛跟到了最终页，它记录下来的发现路径也是这条跳转链。跳转平台的域名如果本身抓取频率低或被限制，入口页给出的这条信号就会打折扣。
怎么验证蜘蛛到底跟到了哪一步
- 看入口页所在服务器的访问日志，确认蜘蛛请求了短链地址。
- 看短链服务或跳转页的日志，确认同一时间是否收到来自蜘蛛 UA 的请求，以及它请求的是哪一条。
- 看最终目标页的服务器日志，是否出现对应 UA 的请求，请求时间是否接在跳转之后。
- 如果只看到第一跳、看不到后面，就把跳转方式临时换成服务端 302，再观察一次，用来判断是渲染问题还是被拦截。
这三段日志能对上，才说明链路是通的。只看某一处，容易得出“蜘蛛来了”或“蜘蛛没来”的错误结论。
更稳妥的做法
- 入口页里直接写目标页的完整 URL，让蜘蛛一跳到位，短链只用于站外的点击统计场景。
- 确实需要跳转时，优先用服务端 301 / 302，不要用 JS 跳转。
- 把跳转链控制在两跳以内，中间不要串多个不同域名。
- 检查跳转页和短链域名下有没有 robots.txt 限制、UA 白名单或风控拦截。
- 重要的目标页，除了入口页链接，也可以用 sitemap 或站内链接单独给它一条发现路径，不要只依赖跳转链。
短链和跳转页解决的是点击统计和链接管理问题，不是 URL 发现问题。把它们当成入口页里的唯一下发路径，通常会丢掉一部分抓取机会；真正要长期被发现的页面，还是给它一条干净、直接的链接更省心。