Los iframes no transfieren link equity. Los widgets de reseñas son iframes. Haz las cuentas..

Una blogger escribe un artículo sobre los mejores sérums limpios de 2026. Incluye un enlace a una de las páginas de producto del comerciante, con un texto de anclaje que cita una reseña de un cliente que la blogger encontró mediante una búsqueda en Google. El enlace es un voto. Ese voto debería, en el grafo de enlaces de Google, acumularse en el dominio del comerciante. El comerciante debería escalar posiciones para "sérum limpio 2026" como resultado.

En la configuración que la mayoría de las plataformas de reseñas envían por defecto, ese voto no se acumula en el comerciante. Se acumula en la plataforma de reseñas.

Este ensayo explica por qué ocurre, cómo comprobarlo y qué significa para una tienda pequeña que paga por una distribución que no le pertenece.

Un iframe es un elemento HTML que carga un documento separado dentro de una ventana en una página principal. El navegador renderiza la página padre y la página hija como dos documentos distintos, con árboles DOM separados, orígenes separados, CSS separado, runtimes de JavaScript separados y URLs con direcciones independientes.

El comprador en el navegador ve ambos documentos superpuestos visualmente: estrellas y reseñas que parecen vivir dentro de la página de producto. El navegador sabe que son dos páginas. Google sabe que son dos páginas. El grafo de enlaces las trata como dos páginas.

Este es el problema mecánico en su totalidad.

Trustpilot es el despliegue de iframes con más tráfico en el comercio digital. Un comerciante que instala el widget de estrellas de Trustpilot en una página de producto de Shopify está enviando, en el HTML de esa página, un iframe cuya fuente es widget.trustpilot.com seguido de una larga cadena de identificadores. El iframe se carga. Dentro de él, Trustpilot renderiza las estrellas, el recuento y, quizás, una reseña reciente.

El contenido del iframe está en widget.trustpilot.com. Su URL canónica está en widget.trustpilot.com. Sus metaetiquetas están en widget.trustpilot.com. Cualquier enlace permanente a una reseña concreta en el sistema de Trustpilot está en trustpilot.com/review/[comerciante]. Ninguna de estas URLs pertenece al dominio del comerciante.

Supón que la blogger lee una de esas reseñas en la página de producto, hace clic en el titular de la reseña y lo cita en su artículo. En muchos casos, enlaza a la URL canónica de Trustpilot, porque esa es la URL de la reseña en la que hizo clic. El enlace va a trustpilot.com. El link equity va a trustpilot.com. La página de producto del comerciante no recibe nada.

Supón ahora que la blogger enlaza a la página de producto del comerciante, con la reseña citada como texto de anclaje. El enlace va al dominio del comerciante. Google rastrea el dominio del comerciante. Google analiza el HTML. Google encuentra el iframe. Google no trata, en el caso estándar, el contenido del iframe como parte de la página del comerciante; el iframe es un documento separado, indexado (cuando se indexa) bajo widget.trustpilot.com. El texto de anclaje que usó la blogger, la cita de la reseña, es por tanto una descripción semántica de contenido que vive en un origen diferente. La señal de relevancia es parcial. La página recibe algo de crédito, pero no el crédito que recibiría si ese mismo texto estuviera en el HTML propio de la página.

Esta es la pérdida mecánica básica. Las reseñas son contenido que el comerciante ha pagado, que los clientes del comerciante escribieron y que enlazan a un dominio que el comerciante no posee.

Algunas plataformas de reseñas (Yotpo en su instalación estándar, Okendo, Junip, Stamped) no usan iframes. Inyectan las reseñas mediante JavaScript en un div de la propia página del comerciante. Mecánicamente, esto es mejor. Las reseñas, una vez renderizadas, viven en el DOM del comerciante. La URL en la que está el comprador es la URL del comerciante. El canonical es el canonical del comerciante. El link equity fluye correctamente.

El problema, como explicamos en the end of the review widget, es que las reseñas solo existen cuando el JavaScript se ejecuta. Para Googlebot, el JavaScript se ejecuta eventualmente, con el retardo de actualización que describimos. Para GPTBot, ClaudeBot y PerplexityBot, el JavaScript no se ejecuta en absoluto. Las reseñas no están en la página que ve el rastreador.

Hay, entonces, tres configuraciones.

La configuración con iframe: las reseñas viven en un dominio diferente, el link equity no se acumula en el comerciante, y ningún rastreador ve las reseñas porque no hay reseñas en la página del comerciante.

La configuración con JavaScript: las reseñas viven en el dominio del comerciante cuando se renderizan, el link equity sí se acumula, pero las reseñas son invisibles para los rastreadores de IA y parcialmente visibles para Googlebot.

La configuración con HTML renderizado en el servidor: las reseñas están en el HTML del comerciante, el link equity se acumula, todos los rastreadores ven las reseñas. Esta es la configuración que casi ningún widget de reseñas activa por defecto.

La lógica es directa. El iframe es lo peor. La inyección de JavaScript queda en el medio. El HTML renderizado en el servidor es lo mejor. La mayoría de las tiendas en 2026 utilizan una de las dos peores opciones.

Existe una segunda dimensión, mecánicamente separada del asunto del link equity pero añadida sobre el mismo incidente. Los Core Web Vitals son una señal de posicionamiento de Google desde 2021, actualizados en 2024 con la introducción del Interaction to Next Paint. Una de las tres señales es el Cumulative Layout Shift, que mide cuánto se mueve el contenido de la página mientras se carga. Google penaliza las páginas con una puntuación CLS superior a 0,1.

Un widget de reseñas cargado en un iframe es, en muchas implementaciones, dimensionado en tiempo de ejecución por el script que lo crea. La página se renderiza inicialmente sin el widget. El script se carga. El iframe se inyecta. El contenido de la página se desplaza hacia abajo entre 200 y 400 píxeles cuando el widget reclama su espacio debajo del botón de compra. La puntuación CLS de esa carga de página aumenta en una cantidad que depende de cuánto espacio del viewport ocupa el contenido desplazado. En nuestras propias mediciones de campo a principios de 2026, hemos observado desplazamientos de 0,18 a 0,34 provocados por widgets de reseñas basados en iframes en temas de Shopify por lo demás bien optimizados.

Una página con una puntuación CLS de 0,25 no posiciona tan bien como una página con una puntuación de 0,05, en igualdad de condiciones. El comerciante está pagando, en términos de posición en el ranking, por alojar un bloque de contenido que no pertenece a su dominio. La metodología de medición y el desglose por widget los abordamos en una pieza separada. El punto aquí es estructural: el iframe pierde en dos ejes a la vez, el eje del link equity y el eje de los CWV, y ambos son parte del algoritmo. El comerciante no puede corregir ninguno de los dos cambiando de proveedor de plataforma de reseñas. El iframe es la forma, y la forma es la pérdida.

Un defensor del modelo de iframe dirá: las reseñas viven en Trustpilot porque son reseñas de Trustpilot. El usuario se registró en Trustpilot, escribió allí, y Trustpilot es el hogar canónico de ese contenido. El iframe es una visualización de cortesía.

Esto es cierto, e irrelevante. El comerciante que instala el widget de Trustpilot está tomando una decisión de distribución de contenido: elige mostrar el contenido de Trustpilot en su propia página de producto. El coste de esa elección es de lo que trata este ensayo. La escritura del usuario es, desde el punto de vista del comprador, contenido en la página del comerciante; el comprador no distingue entre un iframe y un bloque en línea. El rastreador sí. El grafo de enlaces sí. La medición de CWV sí.

La escritura del usuario es también, en términos comerciales, un activo de contenido. El comerciante pagó por la relación con el cliente que lo generó. El comerciante pagó por el flujo de poscompra que lo solicitó. El comerciante paga por la plataforma que lo aloja. El comerciante no posee la URL canónica donde vive esa escritura y, por tanto, no captura el beneficio a largo plazo de su capacidad de descubrimiento.

De eso trataba the category error, a un nivel más profundo. El error de categoría fue tratar la reseña como una característica de interfaz, no como un activo de contenido. La configuración con iframe es la versión más extrema de ese error: el comerciante ha pagado por el contenido, ha mostrado el contenido y no posee la URL donde vive ese contenido.

Una segunda respuesta: el iframe es la versión mala. El widget de JavaScript es la versión buena. Elige una plataforma que use inyección de JavaScript en lugar de iframes y el problema está resuelto.

Es una solución parcial. El widget de JavaScript sí vive en el DOM del comerciante, lo que resuelve el problema del link equity. Pero no vive en el HTML inicial, lo que deja el problema de los rastreadores de IA completamente abierto y el problema del retardo de Googlebot a medias. Ya hemos recorrido el experimento de curl contra tres rastreadores en otro lugar; el resultado es que el widget de JavaScript es invisible para GPTBot, ClaudeBot y PerplexityBot, y parcialmente visible para Googlebot.

El comerciante que pasa de un widget iframe a un widget JavaScript ha mejorado el flujo del link equity. No ha hecho visibles las reseñas para la economía de la cita. En efecto, ha pasado de "lo peor" a "el punto medio". El movimiento correcto es seguir avanzando: de la inyección de JavaScript al HTML renderizado en el servidor, donde las reseñas están en la página que cualquier rastreador puede leer y donde el link equity, la cita y la actualidad fluyen de vuelta al dominio del comerciante al mismo tiempo.

El modelo de inyección de JavaScript crea una versión más suave del mismo problema del iframe: las reseñas viven en el DOM del comerciante, pero las URLs de las fotos, las páginas de perfil de los usuarios y los enlaces permanentes de cada reseña apuntan con frecuencia al CDN de la plataforma o a las páginas de detalle de reseña de la plataforma. La blogger que cita una reseña de Yotpo en la página de producto de un comerciante acaba, muchas veces, en un enlace permanente de yotpo.com para esa reseña concreta. Incluso en la configuración mejor, fragmentos del activo de contenido del comerciante quedan ubicados bajo el dominio de otro. La solución es garantizar que todas las URLs relacionadas con reseñas en la página se resuelvan en el dominio propio del comerciante. La mayoría de los valores predeterminados no lo hacen.

El iframe es la ilustración más clara del error de categoría. El comerciante paga por la escritura, muestra la escritura y no posee la URL donde vive esa escritura. El cliente escribió una carta de amor a la marca. El comerciante la puso en el buzón de otra persona.

Tres comprobaciones, diez minutos cada una.

Comprobación uno. Abre la página de producto en un navegador, haz clic derecho en la sección de reseñas y elige "Inspeccionar elemento". Busca una etiqueta iframe dentro del bloque de reseñas. Si hay una, las reseñas están en un documento diferente; comprueba el atributo src del iframe para ver de qué dominio se trata.

Comprobación dos. Abre la página en las DevTools de Chrome, en la pestaña Performance, y registra una carga en frío con la caché desactivada. Mira las entradas de Layout Shift. Si el widget de reseñas contribuye con un desplazamiento de 0,1 o más, la página está pagando una penalización de CWV en cada carga. Dos tercios de los problemas de CLS en páginas de comercio en 2026, según nuestras comprobaciones puntuales, se deben a widgets de reseñas.

Comprobación tres. Busca en la web una frase concreta de una reseña reciente del comerciante. Si el buscador devuelve una página en trustpilot.com, reviews.io o cualquier dominio de plataforma de reseñas, con el producto del comerciante mencionado y no la propia página de producto del comerciante, el hogar canónico de ese fragmento de escritura está en otro lugar distinto a donde el comerciante obtiene los ingresos. La blogger que enlace a esa reseña enlazará a ese dominio. El comprador que llegue a través de ese enlace llegará a ese dominio. El embudo comienza en la propiedad de otra persona.

El comerciante que instala un widget de reseñas está tomando, en su mayoría sin saberlo, una decisión de distribución de contenido. La configuración con iframe distribuye contenido que el comerciante ha pagado a un dominio que el comerciante no posee. La configuración con JavaScript mantiene el contenido en el dominio del comerciante en el navegador del comprador, pero no en el índice del rastreador. La configuración con HTML renderizado en el servidor mantiene el contenido en el dominio del comerciante en todos los contextos que importan.

Llevamos quince años construyendo plataformas de reseñas sobre iframes y widgets de JavaScript. En el comercio digital, hemos pagado por la distribución y aceptado que la URL canónica de la escritura de nuestros propios clientes viva en algún lugar distinto a la página desde la que vendemos. Ya no es un intercambio tolerable. El link equity es del comerciante. Las reseñas son del comerciante. La página debería ser del comerciante.

La vida media de una página de producto, como escribimos en the half life of a product page, depende de que la página acumule contenido que se compone con el tiempo. Las reseñas son el activo que más se compone que tiene un comerciante. El iframe entrega ese activo a un dominio diferente. Haz las cuentas. Las cuentas no son sutiles.