把入口页做成一个壳页，真正的链接列表放在 iframe 里，是不少人在做蜘蛛池时会尝试的写法：主文档看起来干净，链接集中在另一个文档中。问题随之而来——搜索蜘蛛到底会不会跟着 iframe 里的链接走到目标 URL。
搜索蜘蛛怎么处理 iframe
主流搜索引擎会把 iframe 的 src 当成一个独立的 URL 去抓取和解析。也就是说，iframe 里的文档有机会被抓到，里面的 a 标签也有机会被发现。但有几个前提：src 必须是可解析、可抓取的 HTTP(S) 地址；iframe 文档本身没有被 robots.txt、登录墙、403／429 之类拦住；里面的链接是真实的 href，而不是靠脚本点击才生成。
- 父页面被抓到，不等于 iframe 文档一定被抓到，这是两个分开的抓取任务。
- 用 srcdoc 直接写 HTML 的 iframe 通常没有独立 URL，引擎很难把它当成一个页面来解析。
- iframe 的 src 由脚本动态写入、或滚动到可视区才注入，能否被发现取决于渲染环节，并不稳定。
- iframe 内页面的链接，父页面拿不到上下文，锚文本和周围文字都不算在父页面上。
对 URL 发现的三个实际影响
- 发现链条多了一跳。本来主文档里的 a 标签就能直接暴露目标 URL，现在变成“主文档 → iframe 文档 → 目标 URL”，中间任何一环抓取失败，整条链路就断了。
- 失败点变多。父页面可抓、iframe 文档被拦、iframe 文档返回 5xx、iframe 里的链接是脚本生成的，任何一条都会让目标 URL 发现不了。
- 通常只解决“被发现”这一件事。iframe 内的链接缺少正常页面上下文，别指望它承担锚文本或权重传递的作用。
常见的踩坑写法
- iframe 套 iframe，甚至三层以上，抓取和渲染成本都在涨，漏掉的风险也在涨。
- 用了 loading=“lazy”或者滚动才注入 src，蜘蛛不一定会触发滚动。
- iframe 里放的其实是 302 跳转页或脚本跳转页，URL 发现变成一道额外的重定向题。
- sandbox 属性限制过严，脚本被禁用，本来靠脚本生成的链接就彻底没了。
- 父页面被 robots.txt 屏蔽，只放行 iframe 文档。这种情况下蜘蛛往往连父页面都不抓，自然也看不到 iframe 的 src。
确实要用 iframe，怎么做稳妥一点
- 把关键链接直接放在主文档的 a 标签里，iframe 只作补充，而不是唯一出口。
- iframe 的 src 静态写死为可抓取 URL，不依赖懒加载或脚本注入。
- 不要嵌套，一个入口页里的 iframe 数量也要控制，避免抓取预算被容器文档吃掉。
- 入口页之外配好 sitemap 和主动提交作为兜底，让目标 URL 有第二条被发现的路。
- 目标 URL 自身要可抓：不被 robots.txt 屏蔽、不返回 4xx／5xx、不做多级跳转。
怎么自查 iframe 有没有起作用
- 看服务器日志里有没有对 iframe 文档 URL 的抓取记录，完全没有记录，说明这一层根本没被抓。
- 用抓取调试类工具查看渲染后的 HTML，确认 iframe 的 src 真实存在、里面的链接是 href 而不是按钮或脚本。
- 对比用 iframe 前后，目标 URL 的首次被抓时间有没有明显变化，判断这条路是否真的通了。
- 如果目标 URL 长期只有零星抓取，优先回到最直接的做法：主文档里的普通链接加 sitemap。
iframe 不是不能用，但它把一条直路变成了两段路。任何一段断了，目标 URL 都不会出现。能用普通链接解决的事，不必绕到 iframe 里。