先给结论
會抓，但發現效率通常比直接寫在主文档里的 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 發現手段，會省心很多。