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.

Melhor esquema inicial Article, WebPage e BreadcrumbList para a maioria das páginas de guia.
Melhor fluxo de trabalho Gere schema a partir dos mesmos metadados que alimentam título, descrição, canonical e Open Graph.
Melhor verificação de realidade A marcação FAQPage e WebSite ainda pode descrever conteúdo, mas não baseie estratégia em exibições do Google descontinuadas.

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.

Importante: Dados estruturados devem apoiar a página, não substituir conteúdo útil. Se a página visível for fraca, confusa, desatualizada ou enganosa, a marcação não a tornará um resultado forte.

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.

01

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.

02

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.

03

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.

04

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.

05

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.

06

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.

07

Renderizar cedo

No Blazor e apps JavaScript, prefira JSON-LD prerenderizado ou renderizado no servidor para crawlers verem no HTML inicial.

08

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.

HTMLExemplo de JSON-LD para artigo
<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>
C#Padrão helper em C#
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>");
}
Regra prática: Use URLs estáveis para url e @id. Use a mesma URL canônica em todos os lugares. Se a mesma página aparecer em URLs de idiomas diferentes, gere metadados específicos para cada idioma e mantenha a configuração hreflang/canonical consistente.

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 Results

Vocabulá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 Markup

Erros 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

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.

01 Introdução aos dados estruturados do Google developers.google.com 02 Políticas de dados estruturados do Google developers.google.com 03 Dados estruturados Google Article developers.google.com 04 Dados estruturados Google Breadcrumb developers.google.com 05 Dados estruturados Google FAQ developers.google.com 06 Atualização da caixa de busca sitelinks do Google developers.google.com 07 Introdução ao Schema.org schema.org 08 Teste de Rich Results do Google search.google.com 09 Validador de Marcação Schema validator.schema.org

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.