把目标連結塞進 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，再去讨论後面的收錄與排名。