Dados estruturados: quais schemas realmente fazem sentido

Dados estruturados: quais schemas realmente fazem sentido

Implementar schema.org sem critério é uma das formas mais rápidas de poluir o HTML do site sem ganhar nada em troca — e, em alguns casos, de sinalizar spam estrutural para o buscador. A pergunta certa nunca é "qual schema eu posso adicionar?", mas sim "qual schema descreve com honestidade o que já está nesta página e gera algum retorno prático?". Este texto organiza os critérios de decisão, os tipos que ainda entregam valor real, as sobreposições mais confusas, os usos indevidos mais comuns e as mudanças recentes de elegibilidade que reordenam prioridades.

Os três filtros antes de escolher qualquer schema

Antes de abrir a documentação de qualquer tipo, uma marcação precisa passar por três filtros simultâneos. Se um deles falha, o schema não deve entrar na página.

1. A página realmente representa aquela entidade? Um schema descreve o que a página é, não o que você gostaria que ela fosse. Uma página de categoria de blog não é um Article. Uma listagem de produtos não é um Product. Uma página institucional de "quem somos" não é um LocalBusiness só porque a empresa tem endereço. Marcar entidade errada não é neutro: cria descompasso entre o conteúdo visível e o dado estruturado, o que é justamente o critério que o Google usa para desqualificar marcações.

2. Existe rich result suportado — ou uso comprovado no Knowledge Graph? Nem todo schema.org gera resultado enriquecido na SERP. A referência canônica é a galeria de tipos suportados do Google Search Central: se o tipo não aparece lá com documentação própria, ele pode até ser válido segundo o vocabulário do schema.org, mas não vai render nenhuma exibição diferenciada. Isso não invalida o uso — schemas como Organization e Person alimentam o Knowledge Graph mesmo sem rich result direto —, mas muda a prioridade: a implementação passa a ser um investimento em identidade de entidade, não em CTR.

3. A informação marcada está visível para o usuário? Esta é a regra que mais gente ignora e é a mais fácil de o Google detectar automaticamente. Preço, avaliações, perguntas, passos, ingredientes: se a informação não está na página renderizada, marcá-la é violação explícita das diretrizes de dados estruturados. Um Product com aggregateRating que não existe visualmente na página é candidato natural à ação manual por spam estrutural.

Se um schema não passa nos três filtros, ele não entra. Sem exceção.

Os schemas que ainda entregam valor prático

A lista de tipos suportados evolui. O núcleo abaixo, no momento, mantém retorno claro — seja em rich result, em Knowledge Graph ou em desambiguação semântica que ajuda a página a ser interpretada corretamente.

• Article / NewsArticle / BlogPosting — para páginas de conteúdo editorial. Habilita elegibilidade a features de "top stories" (no caso de NewsArticle em publishers reconhecidos) e a exibições de artigo em resultados enriquecidos.
• Product + Offer — para páginas de produto individual (não categoria, não coleção). Continua sendo um dos schemas de maior impacto visual na SERP: preço, disponibilidade, avaliação agregada.
• LocalBusiness — para negócios com atendimento físico em endereço real. Alimenta a ficha da empresa, aparece em resultados locais e conecta com o Google Business Profile.
• Organization — para a entidade da empresa como um todo. Não gera rich result próprio, mas é a marcação que ajuda a consolidar identidade da marca no Knowledge Graph (logo, canais oficiais, sameAs para perfis).
• Person — útil em páginas de autor, biografias e páginas institucionais de equipe. Também alimenta Knowledge Graph, sem rich result direto na SERP orgânica.
• BreadcrumbList — dos schemas de maior custo-benefício. Substitui a URL crua por trilha navegável no resultado de busca. Simples de implementar, praticamente sem risco.
• FAQPage — com ressalvas importantes descritas mais adiante. A elegibilidade a rich result hoje é restrita.
• HowTo — também com ressalvas: perdeu presença em mobile, o que reduz muito o motivo prático de implementar.
• Event — para eventos com data, local e ingresso. Gera exibição enriquecida em busca e em recursos de descoberta de eventos.
• Recipe — para páginas de receita real, com ingredientes, tempo e modo de preparo. Continua sendo um dos rich results mais completos.
• Review / AggregateRating — sempre aninhado a uma entidade legítima (produto, livro, receita, negócio local, curso, evento, software). Nunca isolado, nunca sobre a própria empresa que publica.
• VideoObject — para páginas com vídeo hospedado ou incorporado. Habilita miniatura, marca temporal e destaque em resultados de vídeo.
• WebSite com SearchAction — marcação leve para o site como um todo. Historicamente associada à sitelinks searchbox; independentemente da presença atual desse recurso, é uma declaração de identidade do site que tem baixíssimo custo.

Comparações entre schemas que se sobrepõem

Boa parte dos erros de implementação vem de escolher o tipo errado entre opções muito próximas. Alguns pares merecem decisão consciente.

Article vs NewsArticle vs BlogPosting Os três são subtipos de CreativeWork. NewsArticle implica cobertura jornalística com apuração, edição e periodicidade — usar em conteúdo de blog corporativo é impreciso e pode desqualificar a página para features de notícias. BlogPosting é adequado para posts de blog editorial. Article é o guarda-chuva neutro quando o conteúdo é editorial mas não se encaixa nas duas outras categorias. Na prática: se você não é publisher jornalístico, escolha entre BlogPosting e Article — não NewsArticle.

Organization vs LocalBusiness LocalBusiness é subtipo de Organization, então toda propriedade de organização vale nele. A diferença é o critério de aplicação: LocalBusiness exige que exista atendimento presencial em endereço físico real. Uma agência 100% remota não é LocalBusiness, é Organization. Uma rede com várias unidades usa Organization na página institucional principal e LocalBusiness em cada página de unidade, com endereço próprio.

Product vs Offer isolado Offer sem Product não descreve nada — é uma oferta sem objeto. O padrão é Product como entidade principal com um ou mais Offer aninhados descrevendo preço, moeda, disponibilidade e vendedor. Marcar Offer solto em página que não é de produto (por exemplo, uma landing page de serviço genérica) costuma ser mais forçado do que útil.

WebPage vs schemas específicos WebPage (e seus subtipos como AboutPage, ContactPage) é genérico e raramente gera rich result. Se a página tem um tipo mais específico aplicável (Article, Product, Recipe), use o específico. WebPage só vale a pena quando nenhum tipo específico descreve a página e você quer, ainda assim, declarar propriedades como autor, data de publicação e entidade principal (mainEntity).

Priorização por tipo de site

A escolha do que implementar primeiro depende do objetivo do site. Uma matriz simples resolve a maior parte dos casos.

E-commerce Prioridade máxima em Product + Offer em cada página de produto, com AggregateRating e Review quando houver avaliações reais visíveis. Depois: BreadcrumbList em toda hierarquia de categoria/produto e Organization na raiz do site.

Site local / prestador de serviço com endereço Prioridade em LocalBusiness (ou subtipo mais específico como Dentist, Restaurant, Plumber) com endereço, horário, telefone e área de atendimento. Depois: BreadcrumbList e, se houver conteúdo editorial, Article/BlogPosting no blog.

Publisher / portal editorial Prioridade em Article ou NewsArticle (dependendo do enquadramento real) em toda matéria, com Person para autores e Organization para o veículo. Depois: BreadcrumbList, VideoObject quando houver vídeo incorporado.

Institucional / corporativo sem venda direta Prioridade em Organization na página principal com sameAs apontando para perfis oficiais, Person em páginas de liderança e BreadcrumbList na navegação. Sem forçar Product ou Service em páginas que só descrevem o que a empresa faz.

O princípio: implementar todos os schemas do núcleo em ordem descendente de retorno, sem forçar tipos que não descrevem o conteúdo real.

Usos indevidos e erros comuns

Alguns padrões aparecem repetidamente em auditorias e são exatamente os que as diretrizes de dados estruturados citam como motivo para ação manual.

• Marcar conteúdo que não existe visualmente na página. Perguntas em FAQPage que só aparecem no JSON-LD, avaliações em AggregateRating sem seção visível de reviews, passos em HowTo que não estão renderizados. É o erro mais fácil de detectar e o mais penalizado.
• FAQPage ou HowTo fora do escopo atual do Google. Detalhado no próximo tópico.
• Review sobre a própria empresa. Marcar avaliações que a própria empresa fez sobre si mesma, ou usar Review para citar frases genéricas de clientes sem estrutura de avaliação real, viola diretriz explícita.
• Product sem propriedades obrigatórias. Um Product sem name, sem image, sem offers (com price e priceCurrency) não é elegível a rich result e ainda sinaliza implementação descuidada.
• LocalBusiness sem endereço físico real. Marcar LocalBusiness em site de serviço 100% online, ou com endereço genérico/caixa postal, cria a mesma inconsistência entre marcação e realidade.
• Marcações concorrentes na mesma página. Empilhar Article, BlogPosting e NewsArticle na mesma URL, ou repetir a mesma entidade em vários blocos JSON-LD, gera ambiguidade que o parser resolve descartando.
• Copiar sameAs para perfis que não existem ou não são oficiais. sameAs só vale para canais oficiais controlados pela entidade.
• Testar depois de publicar. O Rich Results Test e o validador de schema.org devem rodar antes de cada implementação ir ao ar. Erros em produção continuam válidos para desqualificação até que a marcação corrigida seja recrawleada.

Mudanças recentes de elegibilidade que reordenam prioridades

Duas restrições feitas pelo Google nos últimos ciclos mudaram a matemática de priorização para dois schemas que antes eram quase padrão.

FAQPage A elegibilidade a rich result de FAQ foi drasticamente restringida. Hoje, a exibição enriquecida está limitada a sites de autoridade governamental e de saúde. Para a esmagadora maioria dos sites — comerciais, editoriais, institucionais —, marcar FAQPage não vai mais gerar o bloco de perguntas expansíveis na SERP. Isso não significa que a marcação seja inválida (ela continua tecnicamente correta), mas o retorno prático caiu a quase zero. A decisão realista é despriorizar FAQPage em novos projetos e não gastar esforço adicional expandindo o uso em sites existentes fora daqueles nichos.

HowTo O rich result de HowTo foi removido do mobile, que hoje representa a maior parte do tráfego de busca. Na prática, mesmo em sites elegíveis, a exibição enriquecida só aparece em uma fatia pequena do tráfego. O cálculo mudou: continua fazendo sentido implementar HowTo em páginas que são genuinamente tutoriais estruturados por passos, mas não é mais um schema de retorno alto o suficiente para justificar reestruturar conteúdo em torno dele.

O impacto nas decisões de priorização é direto: schemas que antes ocupavam o topo da lista de "implementar rapidamente por causa do CTR" hoje ficam abaixo de Product, BreadcrumbList, Article, LocalBusiness, Event, Recipe e VideoObject em quase todos os cenários.

Fluxo de decisão condensado

Para cada página candidata a receber dados estruturados, o caminho é sempre o mesmo:

1. Identifique o tipo real de conteúdo que a página representa.
2. Consulte a galeria de tipos suportados do Google Search Central para confirmar se existe rich result ou uso conhecido no Knowledge Graph.
3. Se existir, leia as propriedades obrigatórias e recomendadas — implemente as obrigatórias e o máximo de recomendadas que corresponda a dados reais.
4. Verifique se todas as informações marcadas aparecem visualmente na página.
5. Descarte tipos cujo rich result foi descontinuado ou restrito a nichos que não são o seu.
6. Rode Rich Results Test e validador de schema.org antes do deploy.
7. Depois de publicado, acompanhe no Search Console (relatórios de aprimoramento) se a marcação está sendo lida sem erros.

Marcação boa é a que descreve com precisão o que já existe na página, se encaixa em um tipo que o buscador ativamente usa e sobrevive a auditoria sem depender de tolerância. Todo o resto é ruído — na melhor hipótese ignorado, na pior tratado como spam estrutural.