把目标链接塞进 iframe，是不少蜘蛛池入口页的做法：主文档看起来干净、模板改动小，还能在一个页面里拼多个来源。但从搜索蜘蛛的角度看，iframe 里的链接和主文档里的 <a href> 完全不是一回事。先给结论：能被发现的概率明显更低，就算抓到了，通常也拿不到正常的锚文本和链接上下文。
搜索蜘蛛遇到 iframe 时的处理顺序
主流搜索引擎的大致流程是：解析主文档 → 发现 iframe 的 src → 把 src 当成一个独立 URL 放进抓取队列 → 抓回来单独解析，里面的链接再按那个页面的规则处理。
这带来两个直接后果：
- iframe 的 src 本身必须是一个可抓取的 HTML 地址，例如 /frame/1.html。如果是 about:blank、data:、javascript:void(0)，或者由脚本写入 srcdoc，主文档里就没有能被提交的 URL。
- 帧内文档里的链接，其发现优先级和信号强度都低于主文档中的同级链接。很多情况下只是被记进待抓队列，是否真抓还取决于站点的抓取配额和对链接重要性的判断。
容易被忽略的几个拦截点
1. 帧地址本身被挡
常见情况是 iframe 所在目录整段被 robots.txt 屏蔽、被防火墙规则拦成 403，或者需要 Referer 校验导致爬虫请求被拒。主文档一切正常，帧文档却整片抓不到，日志里只看得到主文档返回 200，看不到 frame 请求。
2. 响应头阻止框架加载
X-Frame-Options 设为 DENY 或 SAMEORIGIN，以及 CSP 中的 frame-ancestors 指令，都会阻止文档被嵌入。纯解析型爬虫通常不检查这些响应头，但带渲染的抓取会因此拿不到帧内的 DOM，链接也就无从发现。跨域嵌入时尤其要留意。
3. 内容靠 JavaScript 注入
如果 iframe 是脚本创建，或者 src 在页面加载后才被改写，链接发现就完全依赖渲染。渲染是有预算的，入口页数量一大，很多页面根本等不到渲染那一步。
4. 多层嵌套与滚动区
iframe 套 iframe，或者帧内还要滚动才露出的链接，被跟到的比例会进一步下降。别把核心目标 URL 放在第二层嵌框里。
想确认有没有被提交，按这个顺序查
- 以爬虫 UA 请求主文档，确认原始 HTML 里能搜到 iframe 的 src，而不是脚本拼接出来的字符串。
- 单独请求那个 src，确认返回 200、Content-Type 为 text/html，正文里能看到目标链接的 a 标签。
- 检查 robots.txt、响应头和防火墙规则，确认帧文档没有被挡。
- 翻服务器日志，看有没有对帧地址以及目标 URL 的爬虫请求。只有主文档请求、没有帧请求，说明卡在前两步。
- 把同一条目标链接临时放进主文档做对照，判断差异是否来自 iframe。
更稳妥的写法
如果目的只是统一页面结构，用服务端包含或模板片段渲染成主文档里的普通链接更划算：
- 主文档中保留一层可见的链接，锚文本写清楚，别用“点击这里”。
- iframe 可以作为补充入口，但不要当作唯一入口。
- 链接总量控制在合理范围，重要的目标放在靠前位置。
- 链接尽量是静态 HTML，避免依赖运行时脚本生成。
iframe 不是“藏链接”的好办法，它把链接发现拆成了两次抓取：第一次抓主文档，第二次抓帧地址。任何一步被挡，目标 URL 就不会被提交。
最后提醒一句：链接能被发现，不等于会被收录。iframe 的问题通常卡在“发现”这一环，排查时先确认爬虫有没有真的请求过帧地址和目标 URL，再去讨论后面的收录与排名。