先给结论
会抓，但发现效率通常比直接写在主文档里的 a 标签低一档。搜索蜘蛛处理 iframe 的基本逻辑是：入口页本身和 iframe 里的文档，被当成两个独立的 URL 分别处理。蜘蛛要先解析主文档里的 iframe src 属性，把这个地址当作一个新 URL 排进抓取队列，抓回来之后再解析框架文档里的链接。也就是说，目标 URL 的发现路径凭空多了一跳。
为什么 iframe 里的链接“能发现但不划算”
- 多一跳队列：框架文档本身要先被抓、被解析，里面的链接才有机会进入队列。中间任一环节出问题，比如地址被 robots.txt 拦住、返回 5xx、加载超时，目标 URL 就直接断链。
- 归属关系变弱：主文档里的普通链接更容易被当作该页面的出链；iframe 里的链接归属偏向框架文档自身，传递关系更模糊。
- 叠加渲染依赖：如果是用脚本动态写入 iframe 的 src，或者框架内容由前端注入，那就同时增加了“需要执行脚本”的门槛。
- 层级叠加：iframe 里再套 iframe，等于把发现链拉长到两跳以上，漏抓概率明显上升。
哪些情况基本不会被发现
- iframe 地址被 robots.txt 禁止抓取。主文档能抓，框架文档抓不了，里面的链接等于不存在。
- iframe 设置了懒加载，且始终没有进入视口，部分抓取环境不做滚动，框架可能压根不加载。
- 框架内容要等用户点击后才插入 DOM，或者依赖登录态、cookie 才能返回正常内容。
- 跨域 iframe 带着 X-Frame-Options 或 CSP 限制，渲染层可能拿不到框架内容。
- iframe 地址返回 3xx 跳转链过长，跳到一半就断了，后续链接自然无从解析。
怎么判断蜘蛛有没有真的进 iframe
最直接的办法是看服务器日志，分三步核对：
- 第一步：日志里有没有框架文档 URL 的抓取记录，并且 UA 确实是搜索蜘蛛。
- 第二步：框架文档被抓之后，日志里是否紧接着出现里面目标 URL 的抓取记录。时间差可能几秒，也可能几天。
- 第三步：如果框架文档天天被抓，但里面的目标 URL 一个都没出现，说明卡在解析环节，重点查 robots.txt、状态码和渲染依赖。
一个常见误判：入口页日志里一直有蜘蛛访问，就以为目标 URL 一定被发现了。入口页被访问只能证明主文档被抓，不能证明 iframe 里的链接被解析、被排进队列。
不同搜索引擎的表现差异
把 iframe 作为主要的链接承载方式，不同搜索引擎的解析能力并不一致。有的会主动抓取框架地址并解析其中的链接，有的只把它当作页面元素记录，不保证跟进。所以同一套入口页，在不同搜索引擎下的 URL 发现速度可能差出好几倍。做数据观测时，建议按搜索引擎分开统计，而不是把所有蜘蛛日志混在一起看平均值。
和 JS 渲染、meta refresh 的区别
这三者常被混在一起讨论，其实卡点不同：JS 渲染卡在“要不要执行脚本”，meta refresh 卡在“要不要跟跳转”，iframe 卡在“要不要把框架文档当成独立 URL 再抓一次”。如果入口页同时用了这三种，任何一个环节失败，目标 URL 都发现不了。排查时要逐个拆开验证，而不是一起改。
更稳妥的做法
如果目标是让搜索蜘蛛尽快发现新 URL，iframe 不是好选择。可以从这几处调整：
- 把关键链接改成主文档里的普通 a 标签，放在首屏可见区域，不用脚本拼接。
- 确实需要 iframe 承载内容时，同时在主文档里放一份同地址的普通链接作为兜底。
- 控制层级，一层够用就别套第二层。
- 保证框架文档本身可抓，状态码返回 200，robots.txt 不要拦住它。
- 配合 sitemap 或主动提交，别把 URL 发现的全部希望压在一个框架页上。
小结
iframe 里的链接属于“能抓，但要绕路”。链接越靠近主文档、越接近纯 HTML、跳数越少，被抓到的确定性就越高。做站点运营时，把 iframe 当成页面展示手段，而不是 URL 发现手段，会省心很多。