Iframes y SEO: cómo los trata Google y cómo optimizarlos

La pregunta que más se repite sobre iframes es si Google lee lo que hay dentro. La respuesta corta es que sí lo intenta, pero hay un matiz que cambia decisiones: el contenido no pertenece solo a la página que lo incrusta. La URL del iframe es otra página, con su propio HTML, y Google puede indexarla por separado. Lo que no está documentado es cuál de las dos acaba mostrando en cada consulta.

Aquí separo lo que Google ha dicho de lo que se da por sabido, explico cuándo un iframe es buena idea y cuándo no, repaso los atributos y las cabeceras que importan, y cuento con honestidad qué hay en mi propia web, que es menos de lo que esperarías.

Qué es un iframe y por qué importa para el SEO

Un <iframe> incrusta un documento HTML dentro de otro. El navegador carga la URL del src como una página independiente, con su propio DOM, sus propios scripts y su propio ciclo de carga, y la pinta en un recuadro de la página anfitriona.

Para SEO eso tiene tres consecuencias. La primera es de contenido: lo que se ve dentro del recuadro vive en otra URL. La segunda es de rendimiento: cada iframe es una navegación adicional con sus recursos. La tercera es de control: tú decides qué incrustas, pero otros pueden incrustar lo tuyo si no lo impides.

Cómo trata Google el contenido de un iframe

Hay una fuente primaria reciente. En las office hours de Google de diciembre de 2023, John Mueller respondió a una pregunta sobre cómo indexar el contenido de un iframe. Su respuesta fue que, en general, los sistemas de Google «tratarían de asociar» el contenido de la subpágina como parte de la página principal para la indexación. Añadió que no está garantizado, porque ambas páginas son también páginas HTML independientes.

Esto matiza una idea muy extendida: que el contenido de un iframe «cuenta para la URL del iframe y no para la página». Lo que dice Google es lo contrario como intención por defecto, con una salvedad. Tampoco explica cómo resuelve cuando las dos URLs compiten por la misma consulta, y no he encontrado documentación que lo detalle.

Hay un antecedente de 2017 que va en la misma línea. Search Engine Roundtable recogió una respuesta de Mueller en un hangout: a quien preguntaba cómo hacer que la URL del iframe recibiera el crédito en lugar de la página que lo incrusta, le dijo que «la versión corta es que no se puede». Es una fuente secundaria y antigua, y la uso solo como contexto.

Lo que no está documentado

No hay cifra oficial sobre cuántos iframes renderiza Googlebot, ni sobre si trata igual un iframe cargado con loading="lazy", uno inyectado con JavaScript o uno que necesita interacción. Lo razonable es asumir que un contenido que solo aparece tras un clic no se verá, igual que ocurre con cualquier contenido que exige acción del usuario (el caso general, con sus matices, está en mi guía de JavaScript SEO). Esto último es una inferencia mía, no una afirmación de Google.

Cuándo usar un iframe y cuándo no

La regla que aplico es sencilla: si el contenido debe posicionar a tu nombre, va en tu HTML. Si es un servicio de otro que solo necesitas mostrar, puede ir en un iframe.

Una trampa frecuente es usar un iframe para una página de otro dominio propio, por ejemplo un blog alojado aparte, y esperar que la página principal herede el contenido. Lo más probable es que acabes con dos URLs indexables compitiendo, que es justo lo que Mueller advierte que no se puede controlar del todo. Si necesitas ese contenido en el dominio principal, es mejor servirlo desde ahí.

Atributos clave del iframe

Un iframe sin atributos funciona, pero cada uno de los que siguen evita un problema concreto. Todos aparecen en la documentación de MDN.

Un ejemplo completo

<iframe
  src="https://www.youtube.com/embed/ID_DEL_VIDEO"
  title="Vídeo: cómo auditar los Core Web Vitals"
  width="560" height="315"
  loading="lazy"
  allow="fullscreen"
  referrerpolicy="strict-origin-when-cross-origin"
></iframe>

El sandbox no lo he puesto porque YouTube necesita scripts y, si activas el sandbox con allow-scripts y allow-same-origin, pierdes buena parte de su utilidad. Con widgets de terceros menos fiables sí lo uso, con la lista mínima de permisos que haga falta, y pruebo que el embed sigue funcionando.

Iframes, Core Web Vitals e INP

Un iframe de terceros suele ser de lo más pesado de una página. El artículo de web.dev sobre buenas prácticas con embeds indica que muchos incluyen más de 100 KB de JavaScript, a veces hasta 2 MB. Eso afecta a la carga, pero hay dos métricas con matices propios.

• CLS. Si no declaras width y height, el recuadro mide 300 × 150 hasta que el embed se redimensiona y empuja el contenido de debajo. Web.dev menciona anuncios y widgets que se redimensionan como causa de desplazamientos. Los umbrales son 0,1 o menos para «bueno» y por encima de 0,25 para «malo».
• INP. Web.dev indica que las interacciones ocurren en el documento principal o en iframes embebidos, y que la API de medición no reporta eventos de interacciones dentro de iframes. En iframes de otro origen, a veces no se puede medir el INP con JavaScript. Eso puede explicar diferencias entre CrUX y tu medición propia. El umbral de «bueno» es 200 ms o menos.

Mi lectura práctica: un widget lento dentro de un iframe puede estropear la experiencia sin aparecer en tus herramientas de medición propias. Por eso, ante un INP alto sin causa clara en tus scripts, conviene revisar qué iframes hay en la página. Los fundamentos de las tres métricas están en mi guía de Core Web Vitals.

Carga diferida de iframes

Poner loading="lazy" en los iframes que quedan bajo el pliegue es el primer paso. Web.dev calcula que en un embed de YouTube puede ahorrar unos 500 KB en la carga inicial. Cómo funciona, qué umbral usa cada navegador y los problemas habituales los trato en el artículo sobre lazy loading de iframes; aquí solo me interesa que no es lo mismo que una facade.

Facade para YouTube y Google Maps: cargar al clic

Una facade es un sustituto ligero que ocupa el lugar del embed: una imagen con un botón de reproducir. El iframe real solo se crea cuando el usuario hace clic. La documentación de Chrome lo resume en tres pasos: se añade la facade al cargar, al pasar el ratón se precarga la conexión con el proveedor y al hacer clic se sustituye por el producto real.

Para YouTube, las librerías de código abierto que citan tanto Chrome como web.dev son lite-youtube-embed y alternativas como lite-youtube. Web.dev afirma que lite-youtube-embed es 224 veces más rápido que el embed original; es una cifra del propio artículo y depende de cómo se mida. Para Vimeo existen lite-vimeo-embed y similares.

Una facade casera para mapas

Para un mapa no necesitas librería. Un botón con una imagen estática y un script mínimo bastan:

<button type="button" class="mapa-facade" data-src="https://www.google.com/maps/embed?pb=...">
  <img src="/img/mapa-oficina.webp" width="600" height="400" alt="">
  Ver mapa interactivo
</button>
<script>
document.querySelectorAll('.mapa-facade').forEach(function (b) {
  b.addEventListener('click', function () {
    var f = document.createElement('iframe');
    f.src = b.dataset.src; f.width = 600; f.height = 400;
    f.title = 'Mapa de la oficina'; f.loading = 'lazy';
    b.replaceWith(f);
  });
});
</script>

Las contrapartidas están en la propia documentación de Chrome: las facades no tienen toda la funcionalidad, y el autoplay de vídeos cargados de forma diferida puede no funcionar de forma consistente. Además, el contenido que solo existe tras el clic no se ve al rastrear (inferencia mía, como arriba). Por eso la dirección, el teléfono y el horario deben estar siempre como texto en tu HTML, no solo dentro del mapa.

noindex e indexifembedded en la URL del iframe

Si el contenido del iframe es tuyo y no quieres que su URL aparezca en resultados, la combinación documentada es noindex más indexifembedded en la propia URL del iframe. La documentación de Google lo recoge como regla de robots: permite indexar el contenido de una página cuando está embebida en otra mediante iframe o etiquetas HTML similares, a pesar de una regla noindex. Solo tiene efecto acompañada de noindex, y otros buscadores pueden no tratarla igual. Además, Google solo lee esa directiva si puede rastrear la URL del iframe: si la bloqueas en robots.txt, no verá el noindex, como explico en mi guía de robots.txt.

<meta name="robots" content="noindex, indexifembedded">

Search Engine Roundtable recogió en marzo de 2023 que la herramienta de inspección de URLs de Search Console ya mostraba la presencia de indexifembedded en la URL de embebido de un vídeo. El caso de uso que contaba Vimeo era el de vídeos no listados. Si prefieres una cabecera en lugar de una meta, el funcionamiento de X-Robots-Tag lo explico en mi guía de X-Robots-Tag; no he probado indexifembedded en cabecera, así que compruébalo en la inspección de URLs si lo necesitas.

X-Frame-Options y frame-ancestors: cuando alguien incrusta tu contenido

Hasta aquí hemos hablado de los iframes que pones tú. Hay un segundo lado: quién puede incrustar tus páginas en las suyas. Se controla con cabeceras en la respuesta de tu servidor.

Una política tipo default-src 'none' sin frame-ancestors no impide que te incrusten, porque la directiva no hereda. Es un error fácil de cometer al endurecer una CSP.

Content-Security-Policy: frame-ancestors 'self' https://socio.example
X-Frame-Options: SAMEORIGIN

Para SEO esto tiene dos efectos. Por un lado, evita que terceros enmarquen tu web con otro diseño o publicidad encima (clickjacking). Por otro, según las office hours de diciembre de 2023, una cabecera X-Frame-Options que impide el iframe evita que ese contenido se indexe dentro de la página anfitriona. Si quieres que otros sitios te incrusten y que sumes por ello, no pongas la restricción en esas URLs.

Cómo lo tengo en mi web

Esto es lo que he comprobado leyendo el código de cristofercruz.net, sin añadir nada:

• Ningún iframe. No hay <iframe> en las plantillas, en las páginas de servicios ni en las de ubicaciones. Tampoco hay vídeos, <video> ni <embed>.
• Ningún mapa. La única referencia a Google Maps en el código es un campo de texto de una herramienta, donde pegas una URL. No incrusta ningún mapa.
• Banner de cookies propio, sin iframes. El aviso es un script mío. Las plantillas de proveedores (analítica, píxeles de publicidad) son <template> inertes con scripts, y en la configuración de seguimiento todos los proveedores están desactivados hoy.
• Formulario propio. El formulario de contacto es HTML de la propia web, no un formulario de terceros incrustado.
• Cabecera X-Frame-Options: SAMEORIGIN. Está en el .htaccess, con Header always set dentro de un bloque mod_headers. Solo mi propio dominio puede incrustar mis páginas.
• frame-ancestors 'none' en send.php. El manejador del formulario envía además una CSP con esa directiva y X-Robots-Tag: noindex, nofollow.

Un límite: la cabecera del .htaccess no la he comprobado en la web en producción. El servidor PHP de pruebas con el que trabajo no interpreta el .htaccess, y mi lectura se basa en el archivo. Compruébalo con curl -I contra el dominio real, como explico más abajo.

Tampoco aplico frame-ancestors a las páginas normales: dependen de X-Frame-Options. Si algún día incrusto algo, el orden es el de este artículo: title, dimensiones, loading, facade si pesa, y la dirección o los datos clave siempre como texto.

Cómo auditar los iframes de una web

1. Inventario. Rastrea el sitio con un crawler que extraiga elementos con XPath (//iframe) o busca iframe en el código renderizado. Apunta página, src y proveedor. Los iframes inyectados por scripts solo salen en el HTML renderizado.
2. Atributos. Para cada uno, comprueba title, width, height y loading. Los que no tengan título ni dimensiones son los primeros de la lista.
3. Contenido propio. Si el src es una URL tuya, inspecciónala en Search Console: indexación permitida, canonical y si aparece indexifembedded. Ahí decides si debe seguir indexable.
4. Rendimiento. En DevTools, pestaña Network, filtra por «Doc» y mira cuánto pesa cada iframe y cuándo empieza. Si alguno es de los más pesados, es candidato a facade.
5. Cabeceras. Comprueba qué envían tus URLs:

curl -sI https://tudominio.com/pagina/ | grep -i -E "x-frame-options|content-security-policy"

Si quieres que lo revise alguien con ojo de auditor en todo el sitio, es parte de lo que incluyo en una auditoría técnica.

Preguntas frecuentes sobre iframes y SEO

Referencias y fuentes

1. December 2023 Google SEO office hours Google Search Central
2. Robots meta tag, data-nosnippet y X-Robots-Tag Google Search Central
3. <iframe>: The Inline Frame element MDN Web Docs
4. X-Frame-Options MDN Web Docs
5. CSP: frame-ancestors MDN Web Docs
6. Best practices for using third-party embeds web.dev
7. Lazy load third-party resources with facades Chrome for Developers
8. Interaction to Next Paint (INP) web.dev
9. Cumulative Layout Shift (CLS) web.dev
10. Google & iFrames: Debunking Myths, Understanding SEO Impact Search Engine Journal
11. Google Search Console Shows If embedURL Page Uses indexifembedded Search Engine Roundtable
12. Google Can Index Content In iFrames: SEOing iFrames Search Engine Roundtable