Dados estruturados: implementação e elegibilidade
Veja como implementar JSON-LD com Schema.org, evitar marcações falsas e validar dados estruturados e elegibilidade a resultados enriquecidos.
Nesta página
O que é e como funciona
Dados estruturados ajudam mecanismos de busca a interpretar entidades e propriedades da página. Marcação válida não garante exibição de rich results e nem melhora posições por si só.
CMS e plugins podem emitir marcações conflitantes; templates replicam propriedades incorretas; equipes copiam exemplos de tipos não aplicáveis ao conteúdo. O código pode ser JSON válido e ainda assim estar incompleto para um recurso específico do Google.
Qual problema resolve
Resolve a ambiguidade na interpretação da página pelos buscadores. Sem marcação, é mais difícil associar o conteúdo a entidades (produto, artigo, organização, pessoa, evento) e às suas propriedades, e informações factuais visíveis acabam sendo lidas apenas como texto solto.
Com dados estruturados válidos e coerentes com o que o visitante vê, a página torna-se elegível a formatos de apresentação quando o buscador considerar apropriado, e a informação fica mais legível para sistemas automatizados. A marcação não resolve posicionamento nem garante rich results; marcar o que não existe na página pode resultar em ação manual por dados estruturados enganosos.
Marcação inconsistente dificulta a interpretação de entidades e pode impedir elegibilidade a determinados recursos de busca. Não existe garantia de rich result, posição ou menção em IA por adicionar Schema.org.
Quando utilizar
- Páginas de produtos, artigos, organizações e outras tipologias com marcação suportada.
- Há informações factuais e visíveis que podem ser descritas com propriedades apropriadas.
Quando não utilizar
- A informação não existe ou não é visível na página; não invente avaliações, preços ou autores.
- O objetivo é obter rich result de um tipo não suportado ou não elegível no Google; JSON-LD válido não cria elegibilidade.
- Há problemas de conteúdo ou indexabilidade não resolvidos: marcação não substitui texto útil, acesso e qualidade editorial.
Matriz de decisão
| Situação | O que usar | Por quê |
|---|---|---|
| Artigo ou post com título, data e autor visíveis | Article/BlogPosting com as propriedades recomendadas na documentação vigente (o Google não exige propriedades para Article; recomenda headline, image, datePublished, dateModified e author, de preferência ligado por @id) | Entidade clara e verificável; os requisitos do recurso devem ser conferidos na documentação vigente. |
| Página institucional da empresa | Organization (ou LocalBusiness quando há endereço de atendimento) com dados iguais aos perfis públicos | Consistência de entidade entre site e fontes externas; nunca inventar telefone, endereço ou avaliações. |
| Produto com preço e disponibilidade reais no CMS | Product com Offer sincronizado com os dados do catálogo | Preço ou estoque divergentes do visível geram erro e perda de confiança. |
| Avaliações inexistentes, não verificáveis ou copiadas de terceiros | Não marcar AggregateRating/Review | Marcação sem avaliação real é dado enganoso: risco de ação manual. |
| Página sem entidade clara (listagem genérica, página de busca) | Só WebPage e BreadcrumbList; não forçar um tipo "rico" | Tipo que não representa a página não traz elegibilidade e confunde a interpretação. |
Pré-requisitos
- Inventário de templates e dos scripts JSON-LD emitidos por tema, plugins e aplicação.
- Mapeamento de cada propriedade para um dado real do CMS e sua representação visível na página.
- Documentação do tipo Schema.org e dos requisitos do recurso do Google, se esse for o objetivo.
Passo a passo detalhado
- Identifique o tipo real de página e o recurso de busca desejado, se houver.
- Consulte Schema.org e a documentação do Google específica para o recurso; não presuma que todo tipo gera rich result.
- Mapeie cada propriedade a um campo real do CMS e ao conteúdo visível.
- Gere JSON-LD válido no servidor, com @context, @type e @id consistente quando apropriado.
- Remova blocos duplicados ou contraditórios gerados por tema e plugins.
- Teste sintaxe no Schema Markup Validator e elegibilidade no Rich Results Test.
- Acompanhe relatórios de melhorias e mudanças de template, distinguindo erros, avisos e ausência de elegibilidade.
Exemplos práticos e códigos
Exemplo ilustrativo: adapte ao contexto do seu projeto.
<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "Article", "headline": "Guia de SEO técnico", "author": {"@type": "Person", "name": "Autor Exemplo"} } </script>Caso completo — sintoma, causa, correção e evidência: Cenário ilustrativo: uma página de artigo contém dois blocos Article com autores diferentes, um vindo do tema e outro do plugin. Identifique ambos no HTML renderizado, defina uma fonte única de dados, use @id estável e valide novamente. Registre que ausência de erro no teste não garante exibição enriquecida.
Contraexemplo: Exemplo incorreto: marcar AggregateRating com nota e avaliações inexistentes apenas para tentar obter estrelas.
Fragmento JSON-LD ilustrativo: insira no conteúdo de um script application/ld+json e valide os dados reais.
{
"@context": "https://schema.org",
"@type": "BlogPosting",
"@id": "https://www.exemplo.com.br/blog/guia/#article",
"headline": "Guia ilustrativo",
"datePublished": "2026-10-01",
"image": "https://www.exemplo.com.br/imagens/guia.jpg",
"author": {"@type": "Person", "name": "Autor de exemplo"}
}Exemplo ilustrativo: propriedades e elegibilidade devem ser conferidas na documentação vigente; não copie dados fictícios para produção.
Como validar a implementação
- Execute o Rich Results Test para tipos suportados pelo Google.
- Execute o Schema Markup Validator para consistência de Schema.org.
- Confirme que os dados marcados correspondem ao texto visível.
- Acompanhe relatórios de aprimoramentos e erros de marcação.
Ferramentas recomendadas
- Schema Markup Validator — valida o vocabulário, não garante rich result.
- Google Rich Results Test — verifica suporte e problemas para recursos do Google, não garante exibição.
- Google Search Console — monitora relatórios aplicáveis, sem corrigir o CMS.
Ferramentas do laboratório relacionadas
Erros comuns
- Marcar avaliações, preços ou atributos que não existem ou não aparecem no conteúdo visível.
- Confundir validade sintática com elegibilidade para rich results.
- Manter blocos JSON-LD contraditórios, como autor ou organização emitidos ao mesmo tempo pelo tema e por um plugin.
Checklist de execução
Marque as etapas concluídas. O progresso fica salvo apenas neste navegador.
Referências oficiais
- Introdução aos dados estruturados Google Search Central
- Vocabulário Schema.org Schema.org
- Article structured data Google Search Central
Histórico de atualizações
- Revisão editorial das consultas rápidas e matrizes de decisão: propriedades do Article remetidas à documentação vigente (exigidas e recomendadas).
- Revisão final para publicação: o Google não exige propriedades para Article (as citadas são recomendadas) e erros comuns consolidados.
- Publicação após revisão técnica e editorial final (precisão, exemplos, referências oficiais e acessibilidade).
Conteúdos relacionados
Tag canonical: como evitar URLs duplicadas
Entenda a canonical, identifique duplicidades, escolha URLs preferenciais, corrija conflitos e valide a seleção do Google com exemplos práticos.
Core Web Vitals: diagnosticar e melhorar
Entenda LCP, INP e CLS, investigue dados reais e de laboratório, priorize correções por template e valide melhorias sem confundir métricas.
Conteúdo para busca com IA: entidades, evidências e clareza
Entenda como preparar conteúdo verificável para busca com IA, observar menções e citações e medir resultados sem prometer presença em respostas.