短答案：可能被发现，但明显弱于正文链接
把目标 URL 放进 iframe，搜索蜘蛛并不是完全看不到。主文档里的 iframe src 本身是一个独立 URL，蜘蛛在抓取主文档时通常会把这个地址当作子资源或子文档去请求。只要框架地址可访问、内容是可解析的 HTML，框架里面的链接就有机会被继续发现。
但要说清楚一点：“有机会”不等于“和正文链接一样”。在搜索引擎的链接图谱里，框架内的链接通常不被当作主文档的正文链接来对待，传递的信号更弱、被发现的优先级更低，稳定性也差很多。用于 URL 发现可以，把它当成主力手段就不合适了。
搜索蜘蛛处理 iframe 的基本逻辑
- 主文档与框架文档是两个 URL：抓取时分别请求、分别归属，主文档的链接计数里不一定包含框架里的链接。
- 渲染型引擎会加载框架：具备渲染能力的抓取程序会加载 iframe 并执行其中的 HTML，但渲染是有预算的，不保证每次都做完整。
- 框架地址本身要先能抓：如果 iframe 的 src 被 robots.txt 拦截、被 WAF 挑战、或者返回 403、404，框架内容自然无从谈起。
- 框架内的链接权重有限：即便被发现，也很难享受和主文档正文链接同等的待遇。
哪些写法会让框架里的链接基本失效
1. 框架地址是动态生成的
常见写法是先加载一个空白框架，再用 JavaScript 把 src 改成真实地址。对不执行脚本的抓取程序来说，这个框架等于空的；对执行脚本的抓取程序来说，也要看渲染是否覆盖到了这一步。请求不稳定，发现也就断断续续。
2. 框架被响应头或安全策略挡住
有些站点给框架页设置了 X-Frame-Options 或 CSP 的 frame-ancestors 限制，本意是防嵌套，结果连抓取程序也拿不到框架内容。这类限制在日志里表现为主文档被抓、框架 URL 从不出现。
3. 框架被藏起来
宽高为 0、display:none、或者用定位挪到屏幕外的框架，比正常展示的框架更容易被忽略。搜索引擎对隐藏内容的处理一向谨慎，指望靠隐藏框架做发现，效果通常不稳定。
4. 框架内容需要登录或校验
框架页要求 Cookie、Token 或人机校验才能返回链接列表时，抓取程序拿到的往往是登录页或拦截页，链接自然发现不了。
想让框架内的目标 URL 更可能被发现，可以这样做
- 把重要链接同时放在主文档正文里。这是最有效的做法，框架作为补充，而不是唯一通道。
- 框架 src 写成静态、可直接访问的地址，不要依赖脚本二次替换。
- 框架页返回正常的 200 和可解析 HTML，不要用 meta refresh、JS 跳转层层过渡。
- 避免给框架页加反嵌套响应头，也不要用验证码、登录墙挡在前面。
- 控制框架数量。一页里嵌十几个框架，抓取预算很快被消耗，反而拖慢主要链接的发现。
- 框架内链接保持 URL 规范，统一协议、域名和大小写，减少同一目标被拆成多个地址的情况。
怎么确认框架里的目标 URL 真的被抓了
不要靠猜，看日志最直接：
- 在服务器日志里筛选抓取程序的 User-Agent，先看主文档被抓了几次。
- 再看框架 URL 是否出现请求记录。如果主文档有、框架没有，说明抓取程序没有继续加载框架。
- 如果框架有请求记录，再查框架里具体的目标 URL 有没有被抓。目标 URL 一次都没出现，说明链接没被解析出来，或者被判定为不值得抓。
- 观察时间分布。零星几次请求说明只是偶发，不代表通路已经稳定。
框架能带来少量额外的发现机会，但它不是一条可靠的通道。真正决定目标 URL 能不能被持续发现的，还是入口页本身的可访问性、链接结构的清晰度，以及站点整体被抓取的频率。把希望全押在 iframe 上，通常得不偿失。
小结
iframe 里的目标 URL 理论上能被搜索蜘蛛发现，但受框架地址可抓性、脚本渲染、隐藏方式和安全策略的多重影响，稳定性远不如正文链接。更稳妥的做法是：正文里放主要链接，框架只做补充，并用服务器日志持续验证框架 URL 与目标 URL 的实际抓取情况，再决定要不要保留这种结构。