Schema.org e dados estruturados: rich snippets no Google

Você já reparou que alguns resultados do Google aparecem com estrelinhas de avaliação, preços, perguntas frequentes expandidas ou imagens de receitas? Esses resultados turbinados não são sorte: são consequência de dados estruturados que o site informa ao buscador. Neste guia você vai entender o que é o Schema.org, como escrever marcação em JSON-LD, quais tipos rendem resultados ricos e como testar tudo antes de publicar.

O que são dados estruturados

Dados estruturados são uma forma padronizada de descrever o significado do conteúdo de uma página para máquinas. Um humano olha para "4,8 estrelas em 320 avaliações" e entende na hora. Já um robô de busca vê apenas texto solto, a menos que você diga explicitamente: "isto aqui é uma nota de avaliação, e este número é a quantidade de avaliações".

É exatamente esse o papel da marcação semântica. Em vez de deixar o algoritmo adivinhar, você anota o HTML com rótulos que descrevem entidades (um produto, um artigo, uma pessoa, uma receita) e suas propriedades (preço, autor, ingredientes, data de publicação).

Quando o Google consegue interpretar essas entidades com confiança, ele pode exibir os chamados rich snippets (ou resultados ricos): aqueles blocos visualmente diferenciados que ocupam mais espaço e atraem mais cliques.

O que é o Schema.org

O Schema.org é um vocabulário compartilhado para dados estruturados, criado em 2011 por uma colaboração entre Google, Microsoft (Bing), Yahoo! e Yandex. A ideia central era acabar com a fragmentação: até então, cada buscador tinha seu próprio jeito de entender marcação, e os desenvolvedores precisavam manter várias versões.

Como descrevem Guha, Brickley e Macbeth (2016), o Schema.org se tornou rapidamente o vocabulário dominante de dados estruturados na web justamente por oferecer um padrão único, mantido de forma colaborativa e extensível. Em vez de competir, os grandes players concordaram em falar a mesma língua semântica.

O vocabulário define centenas de tipos organizados em uma hierarquia. No topo está Thing (coisa), e abaixo dele descem categorias cada vez mais específicas:

Cada tipo herda as propriedades dos seus "pais" na hierarquia e adiciona as suas próprias, num modelo parecido com herança em programação orientada a objetos.

Tipos, propriedades e a hierarquia na prática

Entender a herança ajuda a escrever marcação correta. Um BlogPosting é um tipo de Article, que por sua vez é um CreativeWork, que é um Thing. Isso significa que um BlogPosting pode usar qualquer propriedade definida em qualquer um desses níveis: name (de Thing), author e datePublished (de CreativeWork), headline (de Article), e assim por diante. Quando estiver em dúvida sobre quais propriedades um tipo aceita, consulte a página dele no próprio Schema.org — ela lista as propriedades próprias e as herdadas.

Outro conceito útil é o de valores esperados (expected types). A propriedade author espera um Person ou uma Organization, não uma string solta. A propriedade datePublished espera uma Date no formato ISO 8601. Respeitar esses tipos esperados é o que faz a marcação passar nos validadores.

Por que isso importa para SEO

Dados estruturados não são um fator de ranqueamento direto: marcar uma página não a faz subir magicamente para a primeira posição. Mas eles influenciam como seu resultado aparece, e isso afeta a taxa de cliques (CTR).

Vale lembrar que a busca moderna nasceu da análise de links e relevância textual, como mostraram Brin e Page (1998) ao apresentar o PageRank. Hoje, os sinais são muito mais numerosos, mas a lógica permanece: o Google quer entender e confiar no seu conteúdo. Dados estruturados reduzem a ambiguidade e ajudam o buscador a construir uma representação confiável da sua página. Se você ainda não dominou o panorama geral, vale a leitura sobre como funciona o Google: crawling, indexação e ranking.

Os principais benefícios práticos são:

O efeito real na taxa de cliques

É importante calibrar a expectativa. Os dados estruturados raramente mudam sua posição no ranking, mas mudam quanto da atenção do usuário você captura naquela posição. Um quarto lugar com estrelas e preço pode receber mais cliques do que um segundo lugar com snippet "seco". Em nichos competitivos (e-commerce, receitas, eventos), não marcar é abrir mão de uma vantagem que os concorrentes já estão usando.

Os três formatos de marcação

Existem três sintaxes para inserir Schema.org no HTML:

O JSON-LD (JavaScript Object Notation for Linked Data) é o vencedor disparado, e por bons motivos. Ele fica isolado do HTML visível, então você não precisa poluir suas tags nem arriscar quebrar o layout. Se você ainda tem dúvidas sobre a estrutura desse formato, dê uma olhada em o que é JSON, o formato de dados da web — o JSON-LD é simplesmente JSON com algumas chaves especiais.

Veja a diferença. Com Microdata, a marcação se mistura ao conteúdo:

<div itemscope itemtype="https://schema.org/Article">
  <h1 itemprop="headline">Como assar pão em casa</h1>
  <span itemprop="author">Maria Silva</span>
</div>

Com JSON-LD, ela fica num bloco limpo e separado:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Como assar pão em casa",
  "author": {
    "@type": "Person",
    "name": "Maria Silva"
  }
}
</script>

A diferença em legibilidade e manutenção é enorme. Com Microdata, qualquer reorganização do HTML risca quebrar a marcação; com JSON-LD, o bloco é independente do layout e fácil de gerar dinamicamente no servidor. Por isso, daqui pra frente focaremos em JSON-LD.

Anatomia de um bloco JSON-LD

Todo bloco JSON-LD do Schema.org tem duas chaves obrigatórias:

A partir daí, você adiciona as propriedades específicas daquele tipo. Veja um exemplo completo de artigo de blog:

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Schema.org e dados estruturados",
  "image": "https://exemplo.com/capa.jpg",
  "datePublished": "2026-06-24",
  "dateModified": "2026-06-24",
  "author": {
    "@type": "Person",
    "name": "Ana Costa",
    "url": "https://exemplo.com/autores/ana"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Schematize",
    "logo": {
      "@type": "ImageObject",
      "url": "https://exemplo.com/logo.png"
    }
  }
}

Repare no aninhamento: author não é só uma string, é outro objeto com seu próprio @type. Esse encadeamento permite descrever relações complexas entre entidades.

Conectando entidades com @id

Em sites maiores, a mesma entidade aparece em várias páginas: a Organization que publica todos os artigos, o Person que assina vários posts. Repetir o bloco inteiro em cada página é redundante e propenso a inconsistências. O JSON-LD resolve isso com a chave @id, que dá um identificador único e estável a uma entidade:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://exemplo.com/#organizacao",
  "name": "Schematize",
  "url": "https://exemplo.com"
}

Em outras páginas, você apenas referencia {"@id": "https://exemplo.com/#organizacao"} em vez de redefinir a organização inteira. Isso ajuda o Google a entender que se trata da mesma entidade em todo o site, fortalecendo a construção do grafo de conhecimento.

Exemplos práticos por tipo de página

Vamos a casos comuns que rendem resultados ricos.

Produto com avaliação — gera as estrelinhas no e-commerce:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Fone Bluetooth X200",
  "offers": {
    "@type": "Offer",
    "price": "199.90",
    "priceCurrency": "BRL",
    "availability": "https://schema.org/InStock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "reviewCount": "320"
  }
}

FAQ — pode expandir perguntas direto na busca:

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [{
    "@type": "Question",
    "name": "Schema.org melhora o ranking?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "Não diretamente, mas habilita resultados ricos."
    }
  }]
}

Receita — entra em carrosséis com tempo de preparo e calorias:

{
  "@context": "https://schema.org",
  "@type": "Recipe",
  "name": "Pão caseiro rústico",
  "image": "https://exemplo.com/pao.jpg",
  "recipeIngredient": [
    "500g de farinha de trigo",
    "10g de sal",
    "350ml de água"
  ],
  "totalTime": "PT3H",
  "recipeYield": "1 pão"
}

Note o totalTime no formato de duração ISO 8601 (PT3H = 3 horas). Esse detalhe de formato é onde muita marcação falha silenciosamente.

Breadcrumb — exibe a trilha de navegação no resultado, melhorando a hierarquia percebida do site:

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {"@type": "ListItem", "position": 1, "name": "Blog", "item": "https://exemplo.com/blog"},
    {"@type": "ListItem", "position": 2, "name": "SEO", "item": "https://exemplo.com/blog/seo"}
  ]
}

Combinando vários tipos na mesma página

Páginas reais quase nunca são uma entidade só. Um artigo de blog tem um autor (Person), um publicador (Organization), uma trilha de navegação (BreadcrumbList) e talvez um bloco de perguntas frequentes (FAQPage). Você pode declarar múltiplas entidades de duas formas: blocos JSON-LD separados, um para cada tipo, ou um único bloco usando a chave @graph, que agrupa entidades relacionadas em uma só estrutura:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://exemplo.com/#org",
      "name": "Schematize"
    },
    {
      "@type": "BlogPosting",
      "headline": "Schema.org na prática",
      "publisher": { "@id": "https://exemplo.com/#org" }
    }
  ]
}

Usar @graph com @id mantém a marcação enxuta e sem repetição, e é a abordagem que muitos CMS adotam por baixo dos panos. Repare como o BlogPosting referencia a organização pelo @id em vez de redeclará-la inteira.

Como testar e validar

Nunca publique marcação sem validar. Dois recursos são indispensáveis:

Erros comuns que esses validadores pegam:

A regra de ouro: marque apenas o que o usuário realmente vê na página. Inventar avaliações ou preços que não existem é considerado spam estruturado.

Monitorando depois da publicação

Validar antes de publicar é o mínimo; monitorar depois é o que mantém a saúde a longo prazo. O Google Search Console tem um relatório de "Aprimoramentos" que mostra, por tipo de dado estruturado, quantas páginas estão válidas, com avisos ou com erros. Acompanhe-o regularmente: uma mudança no template do site pode quebrar a marcação de centenas de páginas de uma vez, e o relatório é onde isso aparece primeiro.

Como o Google usa os dados estruturados

Vale entender o que acontece nos bastidores depois que você publica a marcação. Quando o robô rastreia a página, ele extrai os blocos JSON-LD e os interpreta contra o vocabulário do Schema.org. Se a entidade é de um tipo suportado para resultado rico e atende aos requisitos mínimos daquele tipo, a página fica elegível — note bem, elegível, não garantida. O Google decide caso a caso se exibe o resultado rico, levando em conta a qualidade do conteúdo, a confiança no domínio e a consulta específica do usuário.

Isso explica por que duas páginas com marcação idêntica podem ter destinos diferentes: uma ganha as estrelas, a outra não. A marcação é condição necessária, mas não suficiente. Foque em conteúdo genuíno e em sinais de confiança do site como um todo; a marcação apenas destrava a possibilidade.

Os dados também alimentam o Knowledge Graph, a base de entidades que o Google usa para entender o mundo. Marcar consistentemente sua Organization, seus autores (Person) e suas relações ajuda o buscador a reconhecer sua marca como uma entidade real e conectada, o que tem efeitos de longo prazo na forma como ela aparece nas buscas.

Dados estruturados além do Google

Embora a motivação mais comum seja o Google, o Schema.org é um padrão aberto consumido por muitos outros agentes. O Bing usa dados estruturados em seus próprios recursos; redes sociais leem marcação para gerar prévias; assistentes de voz e, cada vez mais, sistemas de IA que respondem perguntas se apoiam em dados estruturados para extrair fatos confiáveis de páginas web. Investir em marcação correta é, portanto, preparar seu conteúdo para um ecossistema de consumo de informação muito maior do que uma única página de resultados.

Erros comuns e como evitá-los

Perguntas frequentes

Schema.org melhora meu ranking? Não diretamente. Ele habilita resultados ricos que aumentam a taxa de cliques, o que pode, indiretamente, reforçar sinais de engajamento. Mas não há um "bônus de posição" por usar marcação.

Preciso marcar todas as páginas? Não. Marque as páginas onde o tipo faz sentido e rende resultado rico: produtos, artigos, FAQs, receitas, eventos. Marcar uma página de contato com Recipe não traz benefício.

JSON-LD ou Microdata? JSON-LD, na quase totalidade dos casos. É o formato recomendado pelo Google, mais fácil de manter e independente do HTML visível.

Posso usar tipos não suportados pelo Google? Pode, e isso ajuda outros consumidores de dados estruturados. Mas só os tipos suportados pelo Google geram resultados ricos na busca dele.

Gerando JSON-LD dinamicamente

Em sites com dezenas ou milhares de páginas, escrever marcação à mão é inviável e perigoso — um erro no template se multiplica. O caminho profissional é gerar o bloco a partir dos mesmos dados que alimentam a página. Em um framework moderno, isso costuma ser uma função que recebe o objeto do conteúdo e devolve o JSON-LD:

function articleJsonLd(post) {
  return {
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    headline: post.title,
    datePublished: post.publishedAt,   // já em ISO 8601
    dateModified: post.updatedAt,
    author: { "@type": "Person", name: post.author.name },
  };
}

Duas recomendações importantes ao gerar dinamicamente: escape corretamente qualquer texto que entre no JSON (aspas e caracteres especiais quebram o bloco) e renderize no servidor, para que o robô encontre a marcação no HTML inicial sem depender de JavaScript. Como o JSON-LD é apenas JSON, derivá-lo dos dados da página é direto — outro motivo pelo qual ele venceu os formatos baseados em atributos.

Integrando com a estratégia técnica

Dados estruturados são uma peça do quebra-cabeça maior de SEO técnico. Eles funcionam melhor quando o resto da fundação está sólida: o Google precisa rastrear suas páginas (veja o sitemap XML para ajudar o Google a indexar seu site), renderizar o conteúdo com bom desempenho (os Core Web Vitals para medir e melhorar a experiência do usuário influenciam aqui) e então interpretar a marcação.

Para uma visão completa de como tudo se encaixa — do robots.txt aos cabeçalhos canônicos —, recomendo o SEO técnico: o guia completo para devs. Dados estruturados são o capítulo que dá voz semântica a uma base já bem construída.

Se você gera páginas dinamicamente (com um framework moderno ou um CMS), o ideal é renderizar o bloco JSON-LD no servidor, garantindo que ele esteja presente no HTML inicial — assim o robô não depende de executar JavaScript para encontrá-lo. Em aplicações renderizadas no cliente, certifique-se de que o serviço de renderização do Google consegue executar o script; do contrário, a marcação simplesmente não será vista.

Boas práticas que valem para qualquer tipo

Independente do tipo que você marca, algumas práticas se repetem e sustentam uma marcação saudável:

Adotar essas práticas desde o início evita o retrabalho de descobrir, meses depois, que centenas de páginas marcadas estão inelegíveis por um detalhe de formato.

Conclusão

Schema.org transformou a web em algo mais legível para máquinas, e o JSON-LD tornou essa marcação trivial de adicionar. Comece pelos tipos que mais combinam com seu conteúdo — Article, Product, FAQPage, Recipe —, entenda a hierarquia de tipos e propriedades, conecte entidades com @id, valide sempre antes de publicar e nunca marque o que o usuário não vê. Acompanhe a saúde da marcação no Search Console depois de publicar. Embora não seja um fator de ranqueamento direto, dados estruturados aumentam a visibilidade, a confiança e os cliques, fazendo seu trabalho de SEO render muito mais.

Referências