Os iframes não passam link equity. Os widgets de avaliações são iframes. Faça as contas..

Uma blogueira escreve um artigo sobre os melhores séruns naturais de 2026. Liga para uma das páginas de produto do lojista, com texto âncora que cita uma avaliação de cliente que a blogueira encontrou através de uma pesquisa no Google. A hiperligação é um voto. Esse voto, no grafo de hiperligações do Google, deve acumular-se no domínio do lojista. O lojista devia passar a posicionar-se melhor para "sérum natural 2026" como resultado.

Na configuração que a maior parte das plataformas de avaliações instala por defeito, o voto não se acumula no lojista. Acumula-se na plataforma de avaliações.

Este ensaio explica porquê, como verificar, e o que significa para uma pequena loja que paga por distribuição que não controla.

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

O comprador no browser vê os dois documentos sobrepostos visualmente: estrelas e avaliações que parecem pertencer à página de produto. O browser sabe que são duas páginas. O Google sabe que são duas páginas. O grafo de hiperligações trata-as como duas páginas.

Este é o problema mecânico na sua totalidade.

O Trustpilot é a instalação de iframe com mais tráfego no comércio. Um lojista que instala o Widget de estrelas do Trustpilot numa página de produto Shopify está a incluir, no HTML da página, um iframe cuja origem é widget.trustpilot.com seguida de uma longa cadeia de identificadores. O iframe carrega. Dentro do iframe, o Trustpilot apresenta as estrelas, a contagem e, por vezes, uma avaliação recente.

O conteúdo do iframe está em widget.trustpilot.com. O seu URL canónico está em widget.trustpilot.com. As suas meta tags estão em widget.trustpilot.com. Qualquer hiperligação permanente para uma avaliação específica no sistema Trustpilot está em trustpilot.com/review/[lojista]. Nenhum destes URLs pertence ao domínio do lojista.

Suponha agora que a blogueira lê uma dessas avaliações na página de produto, clica no título da avaliação e cita-a no seu artigo. Em muitos casos, liga para o URL canónico do Trustpilot, porque é esse o URL da avaliação que clicou. A hiperligação vai para trustpilot.com. O link equity vai para trustpilot.com. A página de produto do lojista não recebe nada.

Suponha em vez disso que a blogueira liga para a página de produto do lojista, com a avaliação citada como texto âncora. A hiperligação vai para o domínio do lojista. O Google faz o fetch do domínio do lojista. O Google analisa o HTML. O Google encontra o iframe. O Google não trata, no caso padrão, o conteúdo do iframe como parte da página do lojista; o iframe é um documento separado, indexado (quando o é) sob widget.trustpilot.com. O texto âncora que a blogueira utilizou, a citação da avaliação, é, portanto, semanticamente uma descrição de conteúdo que reside numa origem diferente. O sinal de relevância é parcial. A página recebe algum crédito, mas não o crédito que um parágrafo com o mesmo texto no próprio HTML da página receberia.

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

Algumas plataformas de avaliações (o Yotpo na sua instalação padrão, o Okendo, o Junip, o Stamped) não utilizam iframes. Injetam avaliações via JavaScript numa div na própria página do lojista. Este método é mecanicamente melhor. As avaliações, quando apresentadas, residem no DOM do lojista. O URL em que o comprador se encontra é o URL do lojista. O canónico é o canónico do lojista. O link equity flui corretamente.

A ressalva, como foi descrito em o fim do Widget de avaliações, é que as avaliações só existem quando o JavaScript é executado. Para o Googlebot, o JavaScript é executado eventualmente, com o atraso de atualização de que falámos. Para o GPTBot, o ClaudeBot e o PerplexityBot, o JavaScript não é executado. As avaliações não estão na página que o crawler vê.

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

A configuração com iframe: as avaliações residem num domínio diferente, o link equity não se acumula no lojista, nenhum crawler vê as avaliações do lojista porque não há avaliações na página do lojista.

A configuração com injeção de JavaScript: as avaliações residem no domínio do lojista quando apresentadas, o link equity acumula-se, mas as avaliações são invisíveis para os crawlers de IA e parcialmente visíveis para o Googlebot.

A configuração com renderização do lado do servidor: as avaliações estão no HTML do lojista, o link equity acumula-se, todos os crawlers veem as avaliações. Esta é a configuração para a qual quase nenhum Widget de avaliações está configurado por defeito.

A matemática é simples. O iframe é o pior. A injeção de JavaScript fica no meio. O HTML renderizado no servidor é o melhor. A maior parte das lojas em 2026 está a utilizar uma das duas piores opções.

Há uma segunda dimensão, mecanicamente separada da questão do link equity mas que se sobrepõe ao mesmo problema. Os Core Web Vitals são um sinal de posicionamento 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 uma pontuação de CLS superior a 0,1.

Um Widget de avaliações carregado num iframe é, em muitas implementações, dimensionado em tempo de execução pelo script que o cria. A página apresenta-se inicialmente sem o Widget. O script carrega. O iframe é injetado. O conteúdo da página desloca-se para baixo entre 200 e 400 píxeis enquanto o Widget ocupa o espaço abaixo do botão de compra. A pontuação de CLS, para esse carregamento de página, aumenta num valor que depende de quanto da janela de visualização o conteúdo deslocado ocupa. Nas nossas medições de campo realizadas no início de 2026, observámos deslocamentos de 0,18 a 0,34 causados por Widgets de avaliações baseados em iframe em temas Shopify bem otimizados.

Uma página com uma pontuação de CLS de 0,25 não se posiciona tão bem como uma página com uma pontuação de 0,05, mantendo tudo o resto igual. O lojista está a pagar, em termos de posição nos resultados, pelo privilégio de alojar um bloco de conteúdo que não pertence ao seu domínio. Abordámos a metodologia de medição e a análise por Widget numa peça separada. O ponto aqui é estrutural: o iframe perde em dois eixos simultaneamente, o eixo do link equity e o eixo dos Core Web Vitals, ambos da responsabilidade do algoritmo. O lojista não pode corrigir nenhum dos dois mudando de fornecedor de plataforma de avaliações. O iframe é a forma, e a forma é a perda.

Um defensor do modelo de iframe dirá: as avaliações estão no Trustpilot porque são avaliações do Trustpilot. O avaliador registou-se no Trustpilot, escreveu lá, e o Trustpilot é o lar canónico desse conteúdo. O iframe é uma apresentação por cortesia.

Isto é verdade, e irrelevante. O lojista que instala o Widget do Trustpilot está a tomar uma decisão de distribuição de conteúdo: está a optar por apresentar o conteúdo do Trustpilot na sua própria página de produto. O custo dessa escolha é o tema deste ensaio. A escrita do avaliador é, do ponto de vista do comprador, conteúdo na página do lojista; o comprador não distingue entre um iframe e um bloco inline. O crawler distingue. O grafo de hiperligações distingue. A medição de Core Web Vitals distingue.

A escrita do avaliador é também, em termos comerciais, um ativo de conteúdo. O lojista pagou pela relação com o cliente que a produziu. O lojista pagou pelo fluxo pós-compra que a solicitou. O lojista paga pela plataforma que a aloja. O lojista não controla o URL canónico onde o conteúdo reside e, por isso, não beneficia a longo prazo da descoberta desse conteúdo.

Foi disso que tratou o erro de categoria, a um nível mais profundo. O erro de categoria foi tratar a avaliação como uma funcionalidade 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, apresentou o conteúdo e não controla o URL onde o conteúdo reside.

Uma segunda resposta: o iframe é a má versão. O Widget de JavaScript é a boa versão. Escolha uma plataforma que faça injeção de JavaScript em vez de iframes e o problema fica resolvido.

Esta é uma solução parcial. O Widget de JavaScript reside no DOM do lojista, o que resolve a questão do link equity. Não reside no HTML inicial, o que deixa a questão do crawler de IA completamente em aberto e a questão da atualidade do Googlebot semi-fechada. Já descrevemos noutro lado a experiência de executar curl contra três crawlers; o resultado é que o Widget de JavaScript é invisível para o GPTBot, o ClaudeBot e o PerplexityBot, e parcialmente visível para o Googlebot.

O lojista que muda de um Widget de iframe para um Widget de JavaScript melhorou o fluxo de link equity. Não tornou as avaliações visíveis para a economia de citações. Na prática, passou de "o pior" para "o intermédio". O movimento certo é continuar: da injeção de JavaScript para o HTML renderizado no servidor, onde as avaliações estão na página que qualquer crawler pode ler, e onde o link equity, a citação e a atualidade fluem todos para o domínio do lojista.

O modelo de injeção de JavaScript cria uma versão mais suave do mesmo problema do iframe: as avaliações residem no DOM do lojista, mas os URLs de fotografias, as páginas de perfil dos avaliadores e os links permanentes por avaliação apontam frequentemente 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 numa página de produto do lojista acaba, muitas vezes ao copiar a avaliação, a aterrar num link permanente de yotpo.com para essa avaliação específica. Mesmo na configuração melhor, fragmentos do ativo de conteúdo do lojista ficam alojados no domínio de terceiros. A mitigação consiste em garantir que todos os URLs relacionados com avaliações na página resolvem para o próprio domínio do lojista. A maior parte das configurações por defeito não o faz.

O iframe é a ilustração mais clara do erro de categoria. O lojista paga pelo conteúdo, apresenta o conteúdo e não controla o URL onde o conteúdo reside. O cliente escreveu uma carta de amor à marca. O lojista colocou-a na caixa do correio de outra pessoa.

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

Verificação um. Abra a página de produto num browser, clique com o botão direito na secção de avaliações e escolha "Inspecionar Elemento". Procure uma tag iframe dentro do bloco de avaliações. Se existir, as avaliações estão num documento diferente; verifique o atributo src do iframe para ver de que domínio se trata.

Verificação dois. Abra a página no Chrome DevTools, no separador Performance, e grave um carregamento novo com a cache desativada. Observe as entradas de Layout Shift. Se o Widget de avaliações contribuir com um deslocamento de 0,1 ou mais, a página está a pagar uma penalização de Core Web Vitals em cada carregamento. Dois terços dos problemas de CLS em páginas de comércio em 2026, nas nossas verificações pontuais, têm origem em Widgets de avaliações.

Verificação três. Pesquise na web uma frase específica de uma das avaliações recentes do lojista. Se o motor de pesquisa devolver uma página em trustpilot.com ou reviews.io ou em qualquer domínio de plataforma de avaliações, com o produto do lojista mencionado, e não a própria página de produto do lojista, o lar canónico desse conteúdo está algures que não é onde o lojista recebe a receita. A blogueira que ligar a essa avaliação vai ligar a esse domínio. O comprador que chegar por essa hiperligação vai chegar a esse domínio. O funil começa na propriedade de outra pessoa.

O lojista que instala um Widget de avaliações está a tomar, na maior parte das vezes sem saber, uma decisão de distribuição de conteúdo. A configuração com iframe distribui conteúdo pelo qual o lojista pagou para um domínio que o lojista não controla. A configuração com injeção de JavaScript mantém o conteúdo no domínio do lojista no browser do comprador, mas não no índice do crawler. A configuração com HTML renderizado no servidor mantém o conteúdo no domínio do lojista em todos os contextos que importam.

Passámos quinze anos a construir plataformas de avaliações sobre o iframe e o Widget de JavaScript. No comércio, pagámos por distribuição e aceitámos que o URL canónico dos textos dos nossos próprios clientes reside algures que não é a página de onde vendemos. Isto deixou de ser uma troca tolerável. O link equity é do lojista. As avaliações são do lojista. A página deve ser do lojista.

O tempo de vida de uma página de produto, como escrevemos em o tempo de vida de uma página de produto, depende de a página acumular conteúdo que se compõe. 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. A matemática não é subtil.