O schema de review (Review e AggregateRating) é o código que faz o Google mostrar nota ao lado do resultado de busca, e só funciona quando o conteúdo marcado existe de verdade e está visível na página. A restrição de "self-serving reviews" da documentação oficial do Google, atualizada em 8 de setembro de 2026, vale pra páginas marcadas como LocalBusiness ou Organization avaliando a si mesmas, não pra um Product de terceiros, então a review de afiliado sobre o produto de outra empresa não cai nessa regra. O código correto usa a propriedade review pra aninhar a avaliação dentro do Product, nunca com nota inventada ou copiada de outro site.
- A regra de self-serving reviews do Google vale só pra LocalBusiness e Organization avaliando a si mesmas, não pra Product de terceiros
- A propriedade que aninha a Review dentro do Product é review, e itemReviewed só é obrigatório quando a Review está sozinha, sem Product
- O Google proíbe agregar nota de outro site e marcar conteúdo que não aparece visível na página
- Violar a regra gera ação manual que ignora o schema, não remove a página do índice
O schema de review é o código que diz ao Google, sem ambiguidade, que a sua página contém uma avaliação de produto com nota declarada. Sem ele, o buscador lê um texto qualquer. Com ele, pode mostrar as estrelinhas no resultado de busca, que chamam mais o clique antes mesmo da pessoa entrar na página. A dúvida que trava quem tem página de afiliado não costuma ser como escrever o código. É se a própria avaliação, por ser sua e não de um cliente, conta como válida pro Google. A resposta está na documentação oficial, e ela separa dois casos que a maioria confunde.
O que o schema de review faz na sua página de afiliado?
Ele marca, em código que o visitante não vê, que determinado trecho da página é uma avaliação com nota, referenciando um item específico. A documentação do Google (Review snippet, atualizada em 8 de setembro de 2026) define review snippet como "um trecho curto de uma avaliação, ou uma nota, de um site de avaliações, em geral a média combinada das notas de vários avaliadores". Na prática, pra uma página de review de afiliado, o formato mais comum é o que a Célia já ensina no curso: um bloco único de Product, com a avaliação (Review) aninhada dentro dele através da propriedade review, declarando a nota numa escala clara.
Esse código roda por baixo do texto visível, descrevendo pro Google o que já está escrito ali. É por isso que a primeira regra geral de dados estruturados do Google, repetida em quase todo documento técnico deles, é que o conteúdo marcado precisa estar visível pra quem lê a página. Se o código diz que existe nota 4,7, a página precisa mostrar essa nota 4,7 em algum lugar que a pessoa enxerga, com a mesma escala declarada no código.
Na busca, o efeito prático de ter esse código correto é a estrela aparecendo ao lado do título e da descrição do seu resultado, destacando a página no meio de uma lista de links sem nenhum diferencial visual. Numa pergunta do tipo "produto X funciona", quando duas páginas competem pela mesma posição, a que mostra nota some menos no meio das outras.
Sua review é "self-serving" pro Google?
Não, se você está avaliando um produto de outra empresa. A restrição que existe, e que é real, tem nome e mira um alvo bem mais específico do que a maioria pensa. A própria documentação do Google chama isso de review "self-serving" (autosservida, em tradução livre) e explica o caso exato: quando a entidade avaliada controla as avaliações sobre si mesma, seja diretamente, seja através de um widget de terceiros. Nesse caso, páginas marcadas com LocalBusiness ou qualquer outro tipo Organization ficam inelegíveis pro recurso de estrelas.
Repara no alvo: é a empresa marcando a si própria como LocalBusiness ou Organization e exibindo nota sobre o próprio negócio. Isso é diferente de você, afiliado, escrevendo uma avaliação sobre o produto de outra empresa e marcando esse produto com Product. O avaliado ali é sempre o produto de outra empresa, nunca o seu próprio negócio. A regra do self-serving simplesmente não se aplica a esse desenho. O que o Google exige em troca é mais simples e mais justo: que a nota seja real, venha de uma experiência ou análise de verdade, e esteja visível na página do jeito que o código descreve.
Quais campos o código precisa ter pra mostrar a nota?
A documentação lista como obrigatórios o nome de quem avalia (author, com menos de 100 caracteres) e a nota em si (reviewRating com ratingValue). Como recomendados, entram a data de publicação (datePublished) e a escala da nota (bestRating e worstRating; se você não declarar, o Google assume escala de 1 a 5 por padrão). O campo itemReviewed também é obrigatório, mas só quando a Review está sozinha na página, sem estar aninhada dentro de um Product. Aninhada, como no formato que este artigo recomenda, ele some: o próprio Product que envolve a Review já deixa claro qual é o item avaliado.
Se a página reúne várias avaliações e mostra uma média, entra também a AggregateRating, que exige o item avaliado, a nota média (ratingValue) e pelo menos uma contagem, seja de notas (ratingCount) seja de avaliações com texto (reviewCount).

O ponto que costuma pegar quem tem página de saúde ou suplemento é a tentação de inventar a nota pra página parecer mais forte. Isso quebra duas regras ao mesmo tempo: a nota deixa de representar algo real, e deixa de estar visível (porque não existe de verdade pra mostrar). Se você ainda não comprou o produto que promove, dá pra montar uma nota com dado próprio e conferível, sem fingir uso, e o método pra isso está em review de produto sem ter usado.
O que faz o Google ignorar ou até punir o schema?
Três comportamentos específicos, todos descritos nas diretrizes oficiais de review snippet. O primeiro é agregar avaliações ou notas de outros sites: você não pode copiar a nota que o produto tem na página do produtor, na Amazon ou em qualquer loja e colar na sua. A nota precisa nascer na sua própria página. O segundo é incluir avaliação falsa ou incentivada sem divulgação clara, o exemplo que o próprio Google dá é nota trocada por dinheiro, desconto ou produto grátis sem avisar isso de forma visível. O terceiro, e o mais comum sem querer, é marcar algo que não aparece pra quem lê a página, como uma nota no código que não tem correspondência nenhuma no texto visível.
A consequência de qualquer um dos três chega como ação manual que ignora o schema inteiro: a página continua indexada normalmente, só perde o direito às estrelinhas no resultado. Ainda assim, vale tratar com cuidado, porque reconstruir a confiança de uma página marcada leva tempo.
Como pedir esse schema pro Claude sem inventar nota?
O comando funciona melhor quando você entrega os dados reais primeiro e proíbe o Claude de completar o que falta. A ideia é a mesma de outros comandos do curso: dar a instrução certa e entender o que volta, nunca aprovar um código sem ler.
Vou te passar os dados reais da minha avaliação deste produto: nome do produto [nome], minha nota de [nota] numa escala de 1 a 5, meu nome como autor, e a data de hoje. Quero que você gere o código JSON-LD de dados estruturados, no formato Product com uma Review aninhada dentro dele na propriedade review, seguindo exatamente as diretrizes de review snippet do Google. Use somente os dados que eu passei. Não invente número de avaliações, não invente nota agregada, não preencha nenhum campo com valor que eu não informei. Se algum campo obrigatório estiver faltando nos dados que te dei, me avise em vez de inventar um valor. No fim, me diga claramente em que lugar da página esse código espera encontrar a nota escrita de forma visível, pra eu conferir se ela está lá.

O pedido de avisar em vez de inventar é o que evita o erro mais caro desse processo. Um Claude sem essa instrução tende a completar campo vazio com um valor plausível, porque esse é o comportamento padrão de um modelo de linguagem. Pedir a lista de onde cada dado precisa aparecer no texto visível transforma a conferência final numa tarefa de comparar, não de adivinhar.
Como confirmar que o código está certo antes de publicar?
Rodando o teste de resultados enriquecidos do Google (Rich Results Test) com a URL da página, ou colando o código direto nele antes de publicar. Ele aponta erros e avisos campo a campo. Depois de publicado, vale repetir a conferência pela Inspeção de URL do Search Console, que mostra como o Google de fato leu o código daquela página específica.
Um ponto honesto pra fechar: nenhum dos dois testes garante que as estrelinhas vão aparecer na busca. O código correto só credencia a página a concorrer ao recurso, nada além disso. A decisão final de mostrar ou não o rich result é do algoritmo do Google, e varia por busca, por dispositivo e por quanto a página já é confiável aos olhos dele. O que está sob seu controle é garantir que o código não tenha nenhum motivo pra ser descartado, e repetir essa conferência toda vez que mudar a nota, o preço ou qualquer outro dado marcado na página.
Dá pra aplicar esse schema numa página que já está no ar hoje, sem reconstruir nada. Se você ainda está organizando a estrutura da sua página de review do zero, vale começar pelo guia de SEO para afiliados, que mostra onde o schema entra dentro do conjunto todo de ajustes. E se você quer aprender a dar esse tipo de comando pro Claude em qualquer parte da sua página, não só no schema, essa é a base do Curso SEO para Afiliados.
Apareça no Google, no Bing e nas IAs
O passo a passo pra fazer isso na sua própria página, dando os comandos pro Claude e entendendo cada peça. Sem escrever código do zero.
Conhecer o SEO para Afiliados