Guia prático de dados estruturados
Guia de marcação JSON-LD para SEO prático
JSON-LD ajuda motores de busca a entender o que é a página, quem publicou, como se encaixa no site e quais fatos usar em recursos de busca suportados.
O objetivo útil não é adicionar todo tipo de schema que encontrar. É ter dados estruturados precisos que correspondam à página visível, validem corretamente e se mantenham sincronizados com as mudanças.
A versão curta útil
Use JSON-LD quando puder descrever a página com fatos honestos e visíveis: título, descrição, autor, data de publicação, breadcrumbs, detalhes do produto, dados de vídeo ou conteúdo claro de perguntas e respostas. Não adicione schema para prometer recursos que o Google não mostra mais ou para marcar conteúdo invisível ao usuário.
Sumário
O que JSON-LD realmente faz
JSON-LD é um bloco legível por máquina de dados estruturados. Normalmente fica em um script no head ou corpo da página e descreve entidades com vocabulário schema.org. Motores de busca usam como camada de clareza sobre o conteúdo visível.
Clareza do parser
Significado
Transforma fatos da página em entidades nomeadas e propriedades, como Article, author, datePublished, BreadcrumbList ou SoftwareApplication.
Recurso de busca
Elegibilidade
Pode tornar a página elegível para rich results suportados, mas o Google decide o que mostrar baseado em qualidade, política, consulta e disponibilidade.
Grafo do site
Consistência
Oferece ao seu CMS ou app Blazor um local estruturado para reutilizar a mesma URL canônica, idioma, título, datas, imagens e dados do editor.
Não é atalho
Limite
Não corrige conteúdo fraco, avaliações falsas, respostas FAQ ocultas, datas desatualizadas ou páginas que não correspondem aos dados estruturados.
Escolha o schema conforme a função da página
A forma mais fácil de evitar dados estruturados spam ou duplicados é perguntar o que a página tenta fazer. Adicione o menor conjunto de schema que descreva essa função com precisão.
Conteúdo
Article / BlogPosting
- Use para
- Guias, tutoriais, reviews, posts tipo notícia e explicações longas.
- Adicionar quando
- A página tem título claro, autor ou editor, data de publicação, data de modificação, URL canônica e imagem.
- Evitar quando
- A página é principalmente uma interface de ferramenta, lista de produtos, página de categoria ou landing page simples.
Navegação
BreadcrumbList
- Use para
- Quase todas as páginas abaixo da página inicial.
- Adicionar quando
- Usuários conseguem entender onde a página está na hierarquia do site.
- Evitar quando
- O caminho breadcrumb diverge dos links internos, URLs canônicas ou navegação visível.
Identidade do site
WebPage / WebSite / Organization
- Use para
- Página inicial, hubs, páginas sobre e onde a identidade do editor importa.
- Adicionar quando
- Você quer um grafo de entidades estável que conecte a página, site, editor e idioma.
- Evitar quando
- Você está adicionando marcação WebSite só para tentar o antigo display da caixa de busca sitelinks.
Produto ou app
Product / SoftwareApplication
- Use para
- Ferramentas, apps, páginas SaaS, extensões, software para download ou páginas reais de produto.
- Adicionar quando
- O conteúdo visível da página inclui nome, descrição, sistema operacional ou categoria, preço, ofertas e avaliações quando marcados.
- Evitar quando
- Avaliações, preço, disponibilidade ou reviews não estão visíveis para usuários na página.
Perguntas
FAQPage
- Use para
- Seções visíveis de perguntas e respostas que realmente ajudam usuários a entender o tema.
- Adicionar quando
- O conteúdo de perguntas e respostas é útil na página mesmo que o Google não exiba rich results de FAQ.
- Evitar quando
- Você adiciona perguntas e respostas genéricas só para ocupar espaço na busca ou repetir a mesma resposta em várias páginas.
Mídia
VideoObject / ImageObject
- Use para
- Páginas com vídeo incorporado importante, vídeo tutorial ou imagem rastreável.
- Adicionar quando
- A mídia é central na página e tem título, descrição, miniatura, data de upload e URL estável.
- Evitar quando
- A mídia é decorativa, oculta, bloqueada ou não relevante para o propósito principal da página.
Checklist de implementação que evita a maioria dos erros
Um JSON-LD bom é simples no melhor sentido: consistente, gerado de campos confiáveis, fácil de validar e difícil de esquecer ao mudar a página.
Escolha uma entidade principal da página
Decida se a página é principalmente um artigo, produto, app, vídeo, FAQ, coleção ou página genérica. O schema secundário deve apoiar a entidade principal.
Corresponder ao conteúdo visível
Toda informação marcada deve ser visível ou claramente inferível na página: título, autor, datas, preço, avaliação, perguntas e respostas, breadcrumbs e imagens.
Use valores @id estáveis
Dê IDs estáveis às entidades importantes, como URL canônica mais #article, #webpage, #organization ou #faq. Isso ajuda parsers a conectar partes do grafo.
Gerar a partir de metadados compartilhados
Reutilize os mesmos campos fonte que criam títulos, meta descrições, URLs canônicas, imagens Open Graph, tags de idioma e datas de última modificação.
Mantenha datas honestas
Altere dateModified apenas quando o conteúdo relevante da página mudar. Não atualize datas automaticamente só para parecer mais recente nos resultados.
Torne imagens rastreáveis
Use URLs absolutas para imagens, dimensões adequadas e arquivos não bloqueados por robots, autenticação ou renderização só por lazy-loading.
Renderizar cedo
No Blazor e apps JavaScript, prefira JSON-LD prerenderizado ou renderizado no servidor para crawlers verem no HTML inicial.
Validar e monitorar
Execute o teste Rich Results antes de publicar, verifique a sintaxe no Schema Markup Validator e monitore o Search Console após indexação.
Um padrão limpo de JSON-LD para páginas Blazor
No Blazor, o padrão mais seguro é criar o schema a partir dos metadados da página na inicialização ou prerenderização, serializar uma vez e renderizar o script application/ld+json onde crawlers vejam no HTML inicial.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Article",
"@id": "https://example.com/en/json-ld-schema-guide/#article",
"headline": "JSON-LD Schema Markup Guide for Practical SEO",
"description": "A practical guide to choosing, generating, and validating structured data.",
"image": "https://example.com/images/json-ld-guide.png",
"datePublished": "2026-03-28T10:00:00+00:00",
"dateModified": "2026-05-31T10:00:00+00:00",
"author": {
"@type": "Organization",
"name": "Example Publisher"
},
"publisher": {
"@type": "Organization",
"name": "Example Publisher",
"logo": {
"@type": "ImageObject",
"url": "https://example.com/logo.png"
}
},
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://example.com/en/json-ld-schema-guide/"
}
}
</script>private MarkupString BuildJsonLd(PageMetaData meta)
{
var pageUrl = BuildPageUrl(meta);
var schema = new Dictionary<string, object?>
{
["@context"] = "https://schema.org",
["@type"] = "Article",
["@id"] = $"{pageUrl}#article",
["headline"] = meta.Title,
["description"] = meta.Description,
["url"] = pageUrl,
["datePublished"] = meta.Published?.ToString("O"),
["dateModified"] = meta.Modified?.ToString("O"),
["inLanguage"] = CS.Culture
};
var json = JsonSerializer.Serialize(schema, new JsonSerializerOptions
{
DefaultIgnoreCondition = JsonIgnoreCondition.WhenWritingNull
});
return new MarkupString($"<script type=\"application/ld+json\">{json}</script>");
}Valide JSON-LD antes de confiar nele
A validação tem duas funções. O Schema Markup Validator verifica se o vocabulário e a sintaxe JSON-LD são compreensíveis. O Rich Results Test do Google verifica se o Google reconhece a página como elegível para tipos de rich results suportados.
Elegibilidade Google
Teste de Resultados Enriquecidos
Verifica se o Google consegue ler a página e se os dados estruturados detectados são elegíveis para tipos de rich results suportados.
Abrir teste Rich ResultsVocabulário
Validador de Marcação Schema
Verifica a estrutura geral do schema.org e a sintaxe JSON-LD, incluindo tipos, propriedades, entidades aninhadas e JSON malformado.
Abrir validador de Schema MarkupApós a publicação
Search Console
Use os relatórios de Inspeção de URL e Melhorias para identificar problemas de rastreamento, indexação e dados estruturados após o Google processar a página.
Leia a documentação de dados estruturados do GoogleErros comuns em JSON-LD que prejudicam a confiança
A maioria dos problemas de schema não são bugs técnicos complexos. São incompatibilidades entre o que a marcação diz e o que o usuário ou crawler pode verificar na página.
Marcar conteúdo oculto ou ausente
Se usuários não veem resposta, avaliação, oferta, imagem ou autoria, não coloque nos dados estruturados. É a forma mais rápida de perder confiança.
Adicionando FAQPage a tudo
O schema FAQ pode descrever perguntas e respostas visíveis, mas não deve ser um bloco copiado em todos os artigos. Use só quando melhorar a página.
Scripts duplicados conflitantes
Múltiplos blocos Article com títulos, datas ou URLs diferentes dificultam a interpretação da página. Um grafo claro é melhor que três parciais.
Canonical ou @id incorretos
URLs do schema devem corresponder à página canônica, URL de cultura e configuração hreflang. URLs em idiomas mistos geram conteúdo duplicado e confusão de entidades.
Falsa atualização
Não atualize dateModified para edições de template, rastreamento ou atualizações só de schema. Use a data para mudanças reais no conteúdo.
Renderização tardia só no cliente
Se JSON-LD aparecer só após renderização tardia no cliente, crawlers podem não ver. Prefira renderização no servidor ou prerenderização para páginas importantes.
Receitas práticas de schema por tipo de página
Raramente você precisa de um grafo gigante. Essas combinações cobrem as páginas que a maioria dos sites pequenos, blogs, ferramentas e projetos de review realmente publicam.
Artigo guia
Article + BreadcrumbList + WebPage
- Use Article para título, autor, editor, imagem, datas e nomes de seção.
- Use BreadcrumbList para o caminho visível do site.
- Use referências WebPage ou @id para conectar a página e a entidade do artigo.
Página de ferramenta
SoftwareApplication + WebPage + BreadcrumbList
- Use SoftwareApplication só se a página for sobre um app ou ferramenta real.
- Inclua sistema operacional, categoria, preço ou detalhes da oferta só quando visíveis.
- Evite marcação de avaliação ou classificação a menos que a página mostre dados reais.
Página de avaliação
Avaliação / Produto só quando a página suportar
- Marque o item avaliado, autor, data e avaliação só quando a página os mostrar claramente.
- Mantenha links afiliados e contexto comercial transparentes.
- Use a mesma pontuação no schema e no conteúdo visível.
Página de perguntas
FAQPage só para perguntas e respostas úteis e visíveis
- Faça cada resposta útil por si só, não apenas uma variação de palavra-chave.
- Não esconda respostas atrás de UI bloqueada inacessível para crawlers.
- Não espere rich results de FAQ como principal benefício de SEO.
Fontes verificadas
Fontes pesquisadas para este guia
As orientações acima são baseadas na documentação oficial do Google Search Central e schema.org, transformadas em um checklist prático de JSON-LD.
Perguntas frequentes
A marcação JSON-LD é fator de ranqueamento?
JSON-LD não é um interruptor mágico de ranqueamento. Ajuda motores a entender conteúdo elegível e pode suportar rich results, mas ranqueamento depende de qualidade, relevância, rastreabilidade, links e outros sinais.
Onde o JSON-LD deve ficar na página?
Um script no head é geralmente mais fácil de gerenciar, mas o Google também pode ler JSON-LD no corpo. O importante é que a marcação esteja na página renderizada e corresponda ao conteúdo visível.
Ainda devo usar schema FAQPage?
Use FAQPage só quando a página tiver perguntas e respostas visíveis realmente úteis. Não conte com ele para espaço extra no Google, pois o rich result FAQ foi muito reduzido e descontinuado para a maioria dos sites.
Uma página pode ter vários blocos JSON-LD?
Sim. Uma página de artigo normal pode ter dados Article, BreadcrumbList e WebPage. Mantenha os blocos consistentes, evite entidades duplicadas conflitantes e use valores @id estáveis para conectar partes relacionadas.
JSON-LD é melhor que Microdata?
Para a maioria dos sites modernos, sim. O Google suporta JSON-LD, Microdata e RDFa, mas JSON-LD é mais fácil de manter pois não exige atributos schema no HTML visual.
Com que frequência devo validar dados estruturados?
Valide sempre que mudar templates, campos de metadados, helpers de schema, URLs, roteamento de idioma, geração de imagens, dados de avaliação ou seções FAQ. Também verifique o Search Console após indexação de páginas importantes.