Iframes não transferem link equity. Widgets de avaliação são iframes. Faça as contas..

Uma blogueira escreve um texto sobre os melhores séruns clean de 2026. Ela linka para a página de produto de um lojista, com texto âncora que cita uma avaliação de cliente que ela encontrou numa busca no Google. O link é um voto. No grafo de links do Google, esse voto deveria se acumular ao domínio do lojista. O resultado esperado: o lojista rankeia melhor para "sérum clean 2026".

Na configuração padrão da maioria das plataformas de avaliação, esse voto não vai para o lojista. Vai para a plataforma.

Este ensaio explica por quê, como verificar e o que isso significa para uma loja pequena que paga por uma distribuição que não lhe pertence.

Um iframe é um elemento HTML que carrega um documento separado dentro de uma janela na página principal. O navegador renderiza a página pai e a página filha como dois documentos distintos, com DOM trees separadas, origens separadas, CSS separado, runtimes JavaScript separados e URLs separados e endereçáveis de forma independente.

O comprador no navegador vê os dois documentos sobrepostos visualmente: estrelas e avaliações que parecem estar dentro da página de produto. O navegador sabe que são duas páginas. O Google sabe que são duas páginas. O grafo de links trata como duas páginas.

Este é o problema mecânico inteiro.

O Trustpilot é o iframe mais utilizado no comércio. Um lojista que instala o widget de estrelas do Trustpilot em uma página de produto do Shopify está colocando, no HTML da página, um iframe cuja origem é widget.trustpilot.com seguida de uma longa sequência de identificadores. O iframe carrega. Dentro do iframe, o Trustpilot renderiza as estrelas, a contagem, talvez uma avaliação recente.

O conteúdo do iframe está em widget.trustpilot.com. Sua URL canônica está em widget.trustpilot.com. Suas meta tags estão em widget.trustpilot.com. O permalink de qualquer avaliação específica no sistema Trustpilot está em trustpilot.com/review/[lojista]. Nenhuma dessas URLs é o domínio do lojista.

Imagine agora que a blogueira lê uma dessas avaliações na página de produto, clica no título da avaliação e a cita no seu texto. Em muitos casos, ela linka para a URL canônica do Trustpilot, porque é essa a URL da avaliação que ela clicou. O link vai para trustpilot.com. O link equity vai para trustpilot.com. A página de produto do lojista não recebe nada.

Imagine agora que a blogueira linka para a página de produto do lojista, com o trecho da avaliação como texto âncora. O link vai para o domínio do lojista. O Google rastreia o domínio do lojista. O Google faz o parse do HTML. O Google encontra o iframe. No caso padrão, o Google não trata o conteúdo do iframe como parte da página do lojista: o iframe é um documento separado, indexado (quando indexado) sob widget.trustpilot.com. O texto âncora que a blogueira usou, a citação da avaliação, é semanticamente uma descrição de conteúdo que vive em outra origem. O sinal de relevância é parcial. A página recebe algum crédito, mas não o crédito que um parágrafo do mesmo texto no próprio HTML da página receberia.

Esta é a perda mecânica básica. As avaliações são um conteúdo que o lojista pagou, que os clientes do lojista escreveram, e que linkam para um domínio que o lojista não possui.

Algumas plataformas de avaliação (Yotpo na instalação padrão, Okendo, Junip, Stamped) não usam iframes. Elas injetam avaliações via JavaScript em uma div na própria página do lojista. Isso é mecanicamente melhor. As avaliações, quando renderizadas, vivem no DOM do lojista. A URL que o comprador está visitando é a URL do lojista. O canônico é o canônico do lojista. O link equity flui corretamente.

O problema, como discutimos em o fim do widget de avaliações, é que as avaliações existem apenas quando o JavaScript é executado. Para o Googlebot, o JavaScript é executado eventualmente, com o atraso de atualização que já descrevemos. Para o GPTBot, ClaudeBot e PerplexityBot, o JavaScript não é executado. As avaliações não estão na página que o rastreador vê.

Existem, portanto, três configurações.

A configuração com iframe: as avaliações vivem em outro domínio, o link equity não vai para o lojista, nenhum rastreador vê as avaliações do lojista porque não há avaliações na página do lojista.

A configuração com injeção JavaScript: as avaliações vivem no domínio do lojista quando renderizadas, o link equity vai para o lojista, mas as avaliações são invisíveis para os rastreadores de IA e parcialmente visíveis para o Googlebot.

A configuração com server-side rendering: as avaliações estão no HTML do lojista, o link equity vai para o lojista, todos os rastreadores veem as avaliações. Esta é a configuração que quase nenhum widget de avaliação adota por padrão.

A matemática é direta. Iframe é o pior. Injeção JavaScript é o meio-termo. HTML renderizado no servidor é o melhor. A maioria das lojas em 2026 usa uma das duas piores opções.

Há uma segunda dimensão, mecanicamente separada da questão do link equity, mas sobreposta ao mesmo problema. Os Core Web Vitals são um sinal de ranqueamento do Google desde 2021, atualizados em 2024 com a introdução do Interaction to Next Paint. Um dos três sinais é o Cumulative Layout Shift, que mede o quanto o conteúdo da página se move enquanto carrega. O Google penaliza páginas com pontuação CLS acima de 0,1.

Um widget de avaliações carregado em um iframe é, em muitas implementações, dimensionado em runtime pelo script que o cria. A página renderiza inicialmente sem o widget. O script carrega. O iframe é injetado. O conteúdo da página desce 200 a 400 pixels enquanto o widget ocupa seu espaço abaixo do botão de compra. A pontuação CLS, para aquele carregamento, aumenta de acordo com o quanto do viewport o conteúdo deslocado ocupa. Nas nossas próprias medições em campo no início de 2026, observamos shifts de 0,18 a 0,34 em widgets de avaliação baseados em iframe, em temas Shopify que eram bem otimizados em outros aspectos.

Uma página com pontuação CLS de 0,25 não rankeia tão bem quanto uma página com CLS de 0,05, com todo o resto igual. O lojista está pagando, em posição de ranqueamento, pelo privilégio de hospedar um bloco de conteúdo que não pertence ao seu domínio. A metodologia de medição e o detalhamento por widget foram tratados em outro texto. O ponto aqui é estrutural: o iframe perde em dois eixos ao mesmo tempo, o eixo do link equity e o eixo dos Core Web Vitals, ambos sinais do algoritmo. O lojista não pode corrigir nenhum dos dois simplesmente trocando de plataforma de avaliação. O iframe é a forma, e a forma é a perda.

Um defensor do modelo iframe dirá: as avaliações ficam no Trustpilot porque são avaliações do Trustpilot. O avaliador se cadastrou no Trustpilot, escreveu lá, e o Trustpilot é o local canônico do conteúdo. O iframe é apenas uma exibição cortesia.

Isso é verdade, e irrelevante. O lojista que instala o widget do Trustpilot está tomando uma decisão de distribuição de conteúdo: está escolhendo exibir o conteúdo do Trustpilot na sua própria página de produto. O custo dessa escolha é o que este ensaio aborda. O texto do avaliador é, do ponto de vista do comprador, um conteúdo na página do lojista. O comprador não sabe a diferença entre um iframe e um bloco inline. O rastreador sabe. O grafo de links sabe. A medição dos Core Web Vitals sabe.

O texto do avaliador é também, em termos comerciais, um ativo de conteúdo. O lojista pagou pelo relacionamento com o cliente que o gerou. O lojista pagou pelo fluxo pós-compra que o solicitou. O lojista paga pela plataforma que o hospeda. O lojista não possui a URL canônica onde o texto vive e, portanto, não captura o benefício de longo prazo da descoberta desse conteúdo.

É sobre isso que o erro de categoria tratava, num nível mais profundo. O erro categórico foi tratar a avaliação como um recurso de interface, não como um ativo de conteúdo. A configuração com iframe é a versão mais extrema desse erro: o lojista pagou pelo conteúdo, exibiu o conteúdo, e não possui a URL onde o conteúdo vive.

Uma segunda resposta: o iframe é a versão ruim. O widget JavaScript é a versão boa. Escolha uma plataforma que faz injeção JavaScript em vez de iframes e o problema está resolvido.

Isso é uma solução parcial. O widget JavaScript vive no DOM do lojista, o que resolve a questão do link equity. Ele não vive no HTML inicial, o que deixa a questão do rastreador de IA completamente em aberto e a questão de atualização do Googlebot apenas pela metade resolvida. Já percorremos o experimento de curl contra três rastreadores em outro lugar; o resultado é que o widget JavaScript é invisível para GPTBot, ClaudeBot e PerplexityBot, e parcialmente visível para o Googlebot.

O lojista que troca de um widget iframe para um widget JavaScript melhorou o fluxo de link equity. Não tornou as avaliações visíveis para a economia de citações. Em termos práticos, saiu do "pior" para o "meio-termo". O passo correto é continuar: da injeção JavaScript para HTML renderizado no servidor, onde as avaliações estão na página que qualquer rastreador pode ler, e onde o link equity, a citação e a atualização fluem de volta para o domínio do lojista juntos.

O modelo de injeção JavaScript cria uma versão mais suave do mesmo problema do iframe: as avaliações vivem no DOM do lojista, mas as URLs das fotos, as páginas de perfil dos avaliadores e os permalinks de avaliações individuais frequentemente apontam de volta para o CDN da plataforma ou para as páginas de detalhe de avaliação da plataforma. A blogueira que cita uma avaliação do Yotpo na página de produto de um lojista, ao copiar a avaliação, muitas vezes acaba em um permalink yotpo.com para aquela avaliação específica. Mesmo na configuração melhor, fragmentos do ativo de conteúdo do lojista ficam hospedados no domínio de outra pessoa. A mitigação é garantir que cada URL relacionada a avaliações na página resolva para o próprio domínio do lojista. A maioria dos padrões não faz isso.

O iframe é a ilustração mais clara do erro de categoria. O lojista paga pelo texto, exibe o texto, e não possui a URL onde o texto vive. O cliente escreveu uma carta de amor à marca. O lojista colocou na caixa de correio de outra pessoa.

Três verificações, dez minutos cada.

Verificação um. Abra a página de produto no navegador, clique com o botão direito na seção de avaliações e escolha "Inspecionar elemento". Procure uma tag iframe dentro do bloco de avaliações. Se houver uma, as avaliações estão em outro documento. Verifique o atributo src do iframe para ver de qual domínio se trata.

Verificação dois. Abra a página no Chrome DevTools, na aba Performance, grave um carregamento do zero com o cache desativado. Observe as entradas de Layout Shift. Se o widget de avaliações contribui com um shift de 0,1 ou mais, a página está pagando uma penalidade de Core Web Vitals a cada carregamento. Em nossas verificações pontuais, dois terços dos problemas de CLS em páginas de e-commerce em 2026 têm origem em widgets de avaliação.

Verificação três. Faça uma busca na web por uma frase específica de uma avaliação recente do lojista. Se o buscador retornar uma página no trustpilot.com, no reviews.io ou em qualquer outro domínio de plataforma de avaliação, com o produto do lojista mencionado, e não a própria página de produto do lojista, o local canônico daquele texto é diferente de onde o lojista coleta a receita. A blogueira que linkar para aquela avaliação vai linkar para aquele domínio. O comprador que chegar por aquele link vai chegar naquele domínio. O funil começa na propriedade de outra pessoa.

O lojista que instala um widget de avaliações está tomando, na maioria das vezes sem saber, uma decisão de distribuição de conteúdo. A configuração com iframe distribui conteúdo que o lojista pagou para um domínio que o lojista não possui. A configuração com injeção JavaScript mantém o conteúdo no domínio do lojista no navegador do comprador, mas não no índice do rastreador. A configuração com HTML renderizado no servidor mantém o conteúdo no domínio do lojista em todos os contextos que importam.

Passamos quinze anos construindo plataformas de avaliação sobre o iframe e o widget JavaScript. No e-commerce, pagamos pela distribuição e aceitamos que a URL canônica do texto dos nossos próprios clientes vive em algum lugar diferente da página onde vendemos. Isso não é mais uma troca tolerável. O link equity é do lojista. As avaliações são do lojista. A página deveria ser do lojista.

A meia-vida de uma página de produto, como escrevemos em a meia-vida de uma página de produto, depende da página acumular conteúdo que se compõe ao longo do tempo. As avaliações são o ativo mais composto que um lojista tem. O iframe entrega esse ativo a um domínio diferente. Faça as contas. As contas não são sutis.