Iframes y SEO: qué indexa Google y a quién se lo atribuye

Cuando insertas contenido en tu página mediante una etiqueta iframe, ese contenido no se convierte automáticamente en parte del texto que Google usa para evaluar tu página. Se atribuye al documento cargado dentro del iframe, que tiene su propia URL y, si nadie lo impide, su propia entrada en el índice. Si estás confiando en un iframe para añadir texto relevante con la esperanza de que sume a la relevancia de la página anfitriona, ese texto probablemente esté trabajando para otra URL, no para la tuya.

Este artículo explica cómo procesa Google el contenido dentro de un iframe durante el renderizado, en qué condiciones la URL embebida termina indexada por su cuenta, qué problema genera eso cuando el mismo iframe se reutiliza en muchas páginas, y cómo separar "que este documento no aparezca como resultado propio" de "que su contenido pueda contarse cuando está embebido" con las directivas noindex e indexifembedded.

Cómo procesa Google el contenido dentro de un iframe

El renderizador de Google, basado en un motor de tipo Chromium, ejecuta la página completa incluyendo los contextos de navegación anidados que crea una etiqueta iframe. Durante el renderizado, Google solicita el documento indicado en el atributo src como una petición HTTP independiente, ejecuta su JavaScript si lo tiene y compone el resultado dentro del DOM final de la página.

Pero "renderizar junto" no es "tratar como un solo documento". A efectos de indexación, el documento cargado en el iframe conserva su identidad propia: su URL, su robots.txt, su meta robots y su código de estado HTTP. El texto del recuadro no deja de pertenecer a esa URL solo por mostrarse encajado dentro de otra.

Esto ocurre en este orden:

• Googlebot descarga primero el HTML de la página anfitriona.
• Detecta la etiqueta iframe y, en su turno en la cola de renderizado, solicita el documento de su atributo src como una petición aparte.
• Ese documento se procesa con sus propias reglas de acceso e indexación, sin heredar nada de la página que lo incrusta.
• El resultado visual compone ambos documentos en una sola pantalla, pero como dos entidades separadas de cara al índice.

¿El contenido del iframe cuenta para el SEO de la página que lo incluye?

En la práctica, no de forma directa. Los sistemas de indexación de Google atribuyen el texto relevante para el posicionamiento a la URL propietaria de ese texto, no a la página que lo incrusta, aunque visualmente ambas se muestren como una sola.

La consecuencia práctica: si la parte que responde a la intención de búsqueda —el párrafo que explica el producto, la tabla de precios, el texto que resuelve la duda— vive únicamente dentro de un iframe, tu página puede parecerle a Google mucho más delgada de lo que le parece a un visitante humano. Ejemplo habitual: una calculadora de precios embebida desde una herramienta SaaS de terceros, donde toda la explicación vive dentro del iframe y la página que la incrusta solo aporta un título y un botón. Para el usuario, la página está completa. Para el rastreador, tiene un título y un botón.

No es una prohibición de usar iframes, es una cuestión de dónde vive el texto que quieres que cuente. Si necesitas que un contenido influya en el posicionamiento de la página anfitriona, la solución no es forzar que Google "vea a través" del iframe: es no ponerlo en un iframe. Un include del lado del servidor, o simplemente copiar el texto, logran el mismo resultado visual sin la barrera de indexación.

Cuándo la URL del iframe se indexa por separado

El atributo src de un iframe es una URL completa como cualquier otra. Si no está bloqueada por el robots.txt de su propio dominio y no lleva noindex, Google puede añadirla a su índice como página independiente, con su propio título y su propia posibilidad de aparecer por sí misma en una búsqueda.

Hay dos caminos hacia el índice. El descubrimiento directo: si la URL está enlazada desde otro sitio o incluida en un sitemap, Google la rastrea como a cualquier página nueva. Y el descubrimiento vía renderizado: al renderizar la página que la incrusta, Google solicita esa URL como parte de la composición visual, y esa solicitud puede alimentar la cola de rastreo igual que lo haría una imagen o un script.

Esto sorprende cuando no se espera. Un módulo de preguntas frecuentes servido desde un subdominio y embebido en cientos de páginas de clientes puede acabar indexado por su cuenta, apareciendo en resultados sin ningún contexto de marca reconocible, porque la URL que muestra Google no es la de ninguna página cliente, sino la del propio módulo.

Recursos embebidos vía iframe que suelen indexarse por su cuenta sin que nadie lo decida a propósito:

• Encuestas o formularios alojados en un dominio propio distinto del principal.
• Checkouts o pasos de pago embebidos desde una plataforma de comercio.
• Sistemas de comentarios de terceros con su propio dominio.
• Reproductores de vídeo servidos desde un subdominio dedicado.
• Widgets de reservas con contenido de texto propio, no solo un mapa visual.

Un problema típico: contenido sindicado en cientos de páginas

El caso más frecuente: un widget propio que una empresa distribuye entre sus clientes o sus propias landing. Imagina un comparador de precios alojado en comparar.ejemplo.com/widget/producto-x, instalado mediante iframe en quinientas páginas distintas.

Sin control adicional, el resultado es previsible. Google indexa esa URL una sola vez, porque técnicamente es un solo contenido. Ese texto, idéntico en las quinientas páginas, nunca se acredita a ninguna de ellas individualmente. Peor: la URL del widget puede terminar posicionando para términos que habrían sido útiles a las páginas cliente, compitiendo contra ellas y repartiendo la autoridad que debería concentrarse en las páginas de destino reales.

El mismo patrón aparece con encuestas, calendarios de reservas compartidos entre franquicias o cualquier fragmento reutilizable servido desde una sola URL hacia decenas de páginas: el contenido aporta valor visual, pero su beneficio de indexación no llega a donde debería.

La solución no pasa por eliminar el iframe ni por duplicar el widget en cada dominio, sino por decidir de forma explícita qué papel debe jugar la URL del widget en el índice, y eso se controla con la etiqueta meta robots del propio documento embebido.

Controlar la indexación con noindex e indexifembedded

La etiqueta meta robots del documento cargado en el src del iframe admite dos valores relevantes aquí, y la diferencia entre usarlos por separado o combinados resuelve el caso anterior.

noindex, usado solo, le dice a Google que no muestre ese documento como resultado independiente. Siguiendo la interpretación estándar de la directiva, un noindex sin más también deja fuera de consideración ese contenido cuando el documento está embebido en otra página: la instrucción no distingue entre "este documento solo" y "este documento dentro de otro". El efecto neto es que el contenido queda descartado en ambos contextos a la vez.

indexifembedded existe para separar esas dos preguntas. Junto a noindex, en la forma "noindex, indexifembedded", le dice a Google: no indexes este documento como resultado propio, pero si aparece dentro de un iframe en una página indexable, puedes seguir teniendo en cuenta su contenido en ese contexto. Solo tiene efecto acompañada de noindex; puesta sola, no hace nada.

La directiva se coloca en la cabecera del documento cargado en el src del iframe —o en la cabecera HTTP X-Robots-Tag cuando ese recurso no es HTML, por ejemplo un PDF—, nunca en la página anfitriona. Ponerla en la página que incrusta el widget no tiene efecto: describe cómo tratar el propio documento embebido, no una instrucción sobre lo que ese documento incrusta dentro de sí.

Esto se traduce en tres combinaciones prácticas:

• Sin ninguna directiva: el documento embebido puede indexarse por sí mismo como cualquier URL. Correcto cuando quieres que esa URL también reciba tráfico directo, como un vídeo alojado en tu propio subdominio.
• noindex solo: no aparece como resultado propio y tampoco debería contarse embebido. Adecuado para contenido puramente funcional —anuncios, píxeles de seguimiento, formularios de terceros— sin expectativa de beneficio SEO en ningún sentido.
• noindex junto con indexifembedded: nunca aparece como resultado independiente, pero su contenido puede seguir considerándose parte de las páginas que lo incrustan, siempre que esas páginas no tengan a su vez noindex. La combinación adecuada para el widget sindicado: evita las quinientas copias compitiendo por la misma URL, sin renunciar del todo a que el contenido aporte algo en cada página donde vive.

Robots.txt no es lo mismo que noindex

Un error habitual es bloquear la ruta del iframe en el robots.txt del dominio de origen, asumiendo que eso equivale a impedir su indexación. No es así, y la diferencia importa especialmente aquí.

Bloquear una URL con robots.txt impide que Googlebot la rastree, es decir, que la descargue y lea su contenido. Pero no garantiza que nunca aparezca en resultados: si hay enlaces externos que apuntan a ella, o Google la descubrió antes del bloqueo, puede seguir mostrándose, aunque sin fragmento de texto, con un mensaje del tipo "no hay información disponible para esta página". Ocurre precisamente porque el bloqueo de rastreo impide que Google llegue a leer la etiqueta noindex del documento: si nunca se descarga, nunca se lee su cabecera.

Para widgets embebidos, la herramienta correcta casi siempre es noindex —con o sin indexifembedded—, no un bloqueo por robots.txt. Si además quieres que ese contenido cuente dentro de las páginas que lo incrustan, bloquear el acceso es doblemente contraproducente: Google tampoco podrá renderizar el iframe en ese contexto, así que el contenido queda invisible en ambos sentidos, justo lo opuesto de lo que buscaba indexifembedded.

Casos prácticos: qué hacer según el tipo de iframe

Con la mecánica y las directivas claras, la decisión se reduce a identificar qué papel juega cada iframe concreto y aplicar el tratamiento correspondiente.

• Mapas, calendarios de reservas o vídeos de un proveedor externo (Google Maps o equivalentes): no necesitas tocar nada. El dominio gestiona su propia indexación y tu página no debería depender de ese texto para posicionar. Trátalo como una función interactiva, no como contenido único.
• Sistemas de comentarios embebidos desde un servicio externo: comprueba si el proveedor ya aplica noindex; si no puedes controlarlo, asume que ese texto no suma nada y evita que sea la única fuente de contenido de la página.
• Un widget propio distribuido en muchas páginas —comparadores, calculadoras, tablas de precios—: aplica noindex junto con indexifembedded en el documento del widget, y añade en cada página anfitriona un párrafo único fuera del iframe que explique qué hace. Ese párrafo sí compite en el índice por cuenta propia.
• Un vídeo que además quieres que posicione por su cuenta, en un subdominio propio: déjalo indexable, sin noindex, acepta que aparecerá como resultado independiente, y enlázalo también de forma normal, no solo vía iframe.
• El contenido que responde a la intención de búsqueda por la que alguien llegó a la página: nunca lo coloques exclusivamente dentro de un iframe. Renderízalo como HTML normal de la página, aunque venga de un gestor de contenidos externo; un include del lado del servidor logra el mismo resultado visual sin la barrera de indexación.