先把结论说清楚
能发现，但不一定顺利。搜索蜘蛛处理 HTTP 302 的方式是「跟随」：只要跳转链路没有中断、没有被 robots.txt 拦截、最终地址能正常返回，蜘蛛一般会沿着 302 走到目标地址，把它当成这条链接的实际落点。但 302 表达的是「临时状态」，蜘蛛会保留原地址，也不会像 301 那样迅速把信号合并过去，所以它在抓取和后续回访上都会更谨慎一些。
换句话说，302 本身不是发现不了的原因，真正的问题往往出在链路上的某一跳。
302、301 和页面内跳转的差别
- 301 永久跳转：语义明确，蜘蛛倾向于把两个地址视为同一个目标来处理，后续回访也更稳定。
- 302 / 307 临时跳转：蜘蛛会跟，但会保留原地址，认为落点可能随时变化，因此不会立刻做合并判断。
- meta refresh 或 JS 跳转：属于页面内部的跳转，依赖渲染和脚本执行，稳定性明显低于 HTTP 状态码跳转。
放在入口页里的目标链接，如果经过的是 302，链路本身通常不会直接导致「发现不了」，但会增加蜘蛛判断的成本：它需要多一次请求才能确认最终地址，也会在后续抓取中反复核对这个跳转是否还成立。
哪些情况会让 302 真的挡住发现
- 跳转链路过长：A 到 B 到 C 再到 D，中间任何一跳超时、返回错误或变得不稳定，链路就走不完。
- 落点返回 404、503 或拦截页：蜘蛛走到了，但拿不到可用内容，这一次抓取基本算白跑。
- 落点所在站点 robots.txt 禁止抓取：入口页允许抓，不代表目标站允许，跨域时这点经常被忽略。
- 跳转目标每次请求都变：比如按 IP 或随机分流到不同落地页，蜘蛛每次看到的结果不一致，容易降低这条链接的可信度。
- 跳到登录页、验证页或同意条款页：这不是最终内容，蜘蛛一般不会继续往下猜。
能改就改的几点建议
- 入口页里尽量直接写最终 URL，少一跳就少一层不确定性。
- 必须用 302 的场景（统计跳转、地域分流、活动临时页）尽量只保留一跳，不要再套第二层。
- 确认最终地址可以匿名访问、返回 200、robots.txt 允许抓取，并且没有对蜘蛛单独返回验证页。
- 不要让跳转目标频繁更换，尤其是同一批链接每天指向不同地址。
- 跳转链路稳定后，观察一段时间再决定是否改成 301 或直接链接。
怎么从日志确认蜘蛛走通了跳转
比较直接的办法是看服务器日志的时间序列：先出现对入口页或跳转地址的请求，状态码是 302，紧接着出现对最终地址的请求，且 User-Agent 与搜索蜘蛛一致，说明这一跳被跟上了。如果日志里只看到 302 记录，后面没有对应的落点请求，重点排查三件事：跳转目标是否可访问、目标站 robots.txt 是否放行、链路中间是否有多余跳转。
发现不等于收录。蜘蛛走到最终 URL，只说明这次抓取把它识别出来了；是否编入索引，取决于页面本身的质量、重复程度和站点整体表现，跳转方式不背这个锅。
几个常见误区
- 「用 302 就能把真实地址藏起来」：藏不住，蜘蛛照样会跟过去，只是多花一次请求。
- 「链路上多套几层跳转更安全」：更多跳转等于更多失败点，也更容易被判断为质量不佳。
- 「蜘蛛来过一次就一直没问题」：链路中断过、落点改动过，后续回访都可能不再走通。
小结
入口页里的目标链接经过 302，蜘蛛通常还是能发现最终 URL，前提是跳转链路短、落点可访问、跨站规则放行。如果你希望发现过程更稳定，最省事的做法是把链路压到一跳以内，并定期用日志确认这条链路真的被走通了，而不是只在入口页上看到链接就默认没问题。