Dados estruturados com JSON-LD: exemplos para copiar e testar

Resposta curta: dados estruturados descrevem o conteúdo de uma página numa forma que os buscadores leem diretamente. O Google recomenda para isso o formato JSON-LD, um bloco de JSON dentro de uma tag <script type="application/ld+json">. Copie um dos dois exemplos abaixo, troque os valores com example.com por informações que estejam visíveis na sua página e confira o resultado no Rich Results Test do Google. Um código válido deixa a página elegível a rich results; o Google não garante que eles apareçam.

O que são dados estruturados, e o que o Google faz com o JSON-LD?

O Google define dados estruturados como “a standardized format for providing information about a page and classifying the page content” (Google), isto é, um formato padronizado para dar informações sobre uma página e classificar o conteúdo dela. A maior parte do vocabulário vem do schema.org. Você pode escrevê-lo de três maneiras: JSON-LD, Microdata ou RDFa. As duas últimas acrescentam atributos ao HTML visível. O JSON-LD, ao contrário, fica num bloco separado, que você pode incluir ou consertar sem mexer no layout.

Segundo o Google, “all 3 formats are equally fine for Google”, desde que a marcação seja válida e esteja bem implementada. Mesmo assim, ele recomenda o JSON-LD quando a sua tecnologia permite, porque é “the easiest solution for website owners to implement and maintain at scale” (Google).

O que você pode ganhar: o Google escreve que dados estruturados “can enable search results that are more engaging to users”, e chama isso de rich results (resultados enriquecidos). Ele mantém uma galeria dos recursos compatíveis, entre eles Article, Breadcrumb, Event, Organization, Product e Recipe. Mais um ponto da introdução do Google: para saber como a Pesquisa se comporta, vale a documentação do próprio Google, e não a do schema.org, que tem mais atributos e objetos do que a Pesquisa Google precisa.

Três regras das diretrizes gerais de dados estruturados do Google valem antes de você escrever qualquer código:

• Descreva a página em que a marcação está e só o que os visitantes veem ali.
• Não bloqueie para o Googlebot as páginas que têm dados estruturados, nem com robots.txt, nem com noindex, nem de outra forma.
• Preencha todas as propriedades obrigatórias do tipo que você usa. Itens a que falta uma “are not eligible for rich results”, ou seja, não são elegíveis a rich results.

Exemplo 1: marcação Organization para a sua página inicial

O Google recomenda pôr a marcação Organization na página inicial ou numa única página que descreva a organização, como “Sobre nós”. Você não precisa dela em todas as páginas (Google). O tipo não tem propriedades obrigatórias; o Google recomenda acrescentar as que se aplicam. Troque todos os valores:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Exemplo Bikes",
  "url": "https://www.example.com/",
  "logo": "https://www.example.com/images/logo.png",
  "description": "A Exemplo Bikes fabrica bicicletas sob medida.",
  "email": "contato@example.com"
}
</script>

O que cada propriedade faz, segundo a página do Google:

• name: use o mesmo nome que você usa como nome do site.
• url: o endereço do seu site, que ajuda o Google a identificar a organização de forma única.
• logo: no mínimo 112 × 112 px, rastreável e indexável. Pode ajudar o Google a decidir qual logotipo mostrar nos resultados de busca e nos painéis de conhecimento.
• description e email: detalhes opcionais. Acrescente address, contactPoint ou sameAs (um perfil em outro site) só se valerem para você.

Se um subtipo mais específico se encaixa, o Google o recomenda, por exemplo OnlineStore para uma loja ou um subtipo de LocalBusiness para um restaurante.

Exemplo 2: Article e breadcrumbs num post de blog

O Google entende vários itens numa página, quer você os aninhe, quer os liste separadamente (Google). Este exemplo lista dois itens num array JSON, cada um com o seu próprio @context, o padrão que o Google mostra para itens individuais:

<script type="application/ld+json">
[
  {
    "@context": "https://schema.org",
    "@type": "BlogPosting",
    "headline": "Como escolher um capacete de bicicleta",
    "image": [
      "https://www.example.com/photos/capacete-16x9.jpg",
      "https://www.example.com/photos/capacete-4x3.jpg",
      "https://www.example.com/photos/capacete-1x1.jpg"
    ],
    "datePublished": "2026-10-12T08:00:00+02:00",
    "dateModified": "2026-11-04T09:20:00+01:00",
    "author": [
      {
        "@type": "Person",
        "name": "Maria Silva",
        "url": "https://www.example.com/team/maria-silva"
      }
    ]
  },
  {
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
      { "@type": "ListItem", "position": 1, "name": "Blog", "item": "https://www.example.com/blog" },
      { "@type": "ListItem", "position": 2, "name": "Ciclismo", "item": "https://www.example.com/blog/ciclismo" },
      { "@type": "ListItem", "position": 3, "name": "Como escolher um capacete de bicicleta" }
    ]
  }
]
</script>

Article. O Google aceita Article, NewsArticle e BlogPosting. Ele não lista propriedades obrigatórias e recomenda author, datePublished, dateModified, headline e image, para ajudar o Google a “show better title text, images, and date information” (Google). Escreva as datas em ISO 8601 com fuso horário; sem ele, o Google usa o fuso do Googlebot. Liste cada autor como uma entrada própria, com tipo, nome e url. Mantenha o título curto, porque “long titles may be truncated on some devices”. Para as imagens, o Google recomenda vários arquivos de alta resolução nas proporções 16x9, 4x3 e 1x1, relevantes para o artigo e que não sejam logotipos.

Breadcrumbs. Aqui as regras são rígidas. Uma BreadcrumbList precisa de pelo menos duas entradas ListItem, e cada uma normalmente precisa de position, name e item (o endereço). Só a última pode omitir item; nesse caso o Google usa o endereço da própria página (Google). O Google recomenda um caminho típico do usuário, e não uma cópia da estrutura de URLs, e indica que o recurso está disponível no desktop. A nossa leitura das diretrizes: mostre a mesma trilha na página, porque marcação de coisas que o leitor não vê não é permitida.

Como testar o JSON-LD antes e depois de publicar?

1. Rich Results Test (search.google.com/test/rich-results). O Google o chama de “the official Google tool for testing your structured data”. A página da ferramenta aceita um endereço ou código colado, então você pode testar um exemplo antes de ele ir ao ar. Corrija primeiro os erros críticos; segundo o Google, os avisos não críticos são opcionais para a elegibilidade.
2. Schema Markup Validator (validator.schema.org). A página de testes do Google o descreve como uma verificação de toda marcação baseada em schema.org “without Google feature specific warnings”, isto é, sem avisos específicos de recursos do Google. Use-o quando nenhum recurso do Google combinar com o seu tipo.
3. Inspeção de URL no Search Console, depois de publicar algumas páginas. O Google pede que você confirme que a página não está bloqueada por robots.txt, noindex ou login; rastrear uma página nova pode levar vários dias.
4. Relatórios de rich results no Search Console. O Google observa que a marcação pode quebrar depois da publicação, por causa de modelos de página ou de problemas na entrega; por isso, olhe de novo a cada mudança de modelo (Google).

Como conferimos os dois exemplos acima em 4 de novembro de 2026: os dois blocos são lidos como JSON válido (módulo json do Python), e as propriedades seguem as páginas do Google sobre Organization, Article e Breadcrumb (última atualização em 8 de setembro de 2026). Não os colamos na ferramenta do Google, então a sua primeira colagem é o teste de verdade.

O que o JSON-LD não faz

• Não garante um rich result. O Google escreve: “Google does not guarantee that your structured data will show up in search results” (Google). Entre os motivos, está que o algoritmo pode decidir que um resultado de texto simples se encaixa melhor e que a marcação pode estar errada de formas que o teste não pega.
• Não é promessa de ranking. Não encontramos, nessas páginas do Google, nenhuma afirmação de que dados estruturados melhoram a posição. O Google descreve o benefício como elegibilidade a rich results. Uma ação manual por dados estruturados, acrescenta ele, tira essa elegibilidade e “doesn't affect how the page ranks in Google web search”, ou seja, não afeta a posição da página na busca web do Google.
• As respostas de IA não precisam dele. O guia do Google sobre recursos de IA generativa diz: “Structured data isn't required for generative AI search, and there's no special schema.org markup you need to add” (Google). Mesmo assim, o Google chama os dados estruturados de uma boa ideia para a elegibilidade a rich results. O SEOgrinder não mede se algum sistema de IA cita o seu site.
• A marcação de FAQ não tem mais resultado no Google. O registro de alterações do Google diz: “This feature will no longer appear in Google Search starting May 7, 2026” (Google). Não acrescente marcação FAQPage com essa finalidade.

Erros comuns: 5 tropeços com JSON-LD

1. Marcar o que ninguém vê

A diretriz do Google: “Don't mark up content that is not visible to readers of the page.” O exemplo do próprio Google: se a marcação descreve um artista, o corpo da página precisa descrever esse mesmo artista.

2. JSON quebrado

Um único deslize de sintaxe quebra o bloco inteiro. O relatório de dados estruturados não analisáveis do Google no Search Console (em inglês, “Unparsable structured data report”) cita tipos de erro como vírgula ou chave de fechamento faltando, dois-pontos faltando e sequência de escape inválida numa string, por exemplo uma barra invertida solta como \q dentro de um texto. A dica do Google para achar o deslize: comece com um objeto vazio e vá recolocando o seu código aos poucos.

3. Propriedades obrigatórias faltando

O Google diz que itens sem as propriedades obrigatórias não são elegíveis a rich results. O caso mais comum são entradas de breadcrumb sem position, name ou item.

4. Um tipo que não combina com a página

O Google pede o tipo aplicável mais específico. Os exemplos dele de marcação irrelevante: um site de transmissões esportivas que marca as transmissões como eventos locais e um site de marcenaria que marca instruções como receitas.

5. Bloquear a página ou as imagens dela

As páginas com dados estruturados precisam continuar abertas ao Googlebot, e os endereços de imagem na marcação precisam ser rastreáveis e indexáveis. Uma regra Disallow para a sua pasta de imagens pode desfazer uma marcação cuidadosa.

Como o SEOgrinder verifica dados estruturados?

O SEOgrinder é a nossa ferramenta, e nós a construímos. Analise uma página, abra a área “Página no Google” e olhe dois cartões. “Dados estruturados” lista os tipos encontrados em JSON-LD e Microdata. “Verificação de campos” conta as entidades e mostra quantas estão “Inválidas” (falta um campo obrigatório) ou “Incompletas” (faltam só campos recomendados), com os nomes dos campos que faltam. Na lista de tarefas elas aparecem como “Faltam campos obrigatórios aos dados estruturados”, “Dados estruturados incompletos”, “Sem dados estruturados” e, para código que não pode ser lido, “Um bloco de dados estruturados avariado”. Depois de uma correção, clique em Verificar de novo.

Quatro limites. O SEOgrinder lê o HTML que o seu servidor entrega, então um JSON-LD que só um script acrescenta no navegador não é visto por ele, embora o Google consiga lê-lo. Ele lê JSON-LD e Microdata, não RDFa. Ele conhece os campos obrigatórios de uma lista de tipos comuns, não de todos os tipos. E ele não decide se o Google mostrará um rich result; essa prévia quem faz é o Rich Results Test.

Lemos as nossas próprias páginas do mesmo jeito em 4 de novembro de 2026. Este comando mostra 1 para um artigo e 0 para a página inicial:

curl -sS https://seogrinder.com/pt/blog/checklist-de-auditoria-seo | grep -c 'application/ld+json'

O único bloco do artigo contém um BlogPosting e uma BreadcrumbList com três entradas (SEOgrinder, Blog, o artigo). Na página inicial, não temos dados estruturados.

Perguntas frequentes

Preciso de dados estruturados em todas as páginas?

Não. Acrescente um tipo só onde ele combina com a página: Organization na página inicial ou em “Sobre nós”, Article nos posts. Muitas páginas não têm um tipo correspondente, e tudo bem.

Posso acrescentar JSON-LD com um plugin ou com JavaScript?

Sim. O Google diz que quem usa um CMS pode encontrar uma página de configurações ou um plugin para dados estruturados e que o Google consegue ler JSON-LD inserido por scripts (Google). Confira o resultado com o Rich Results Test e lembre que o SEOgrinder só vê o que o servidor entrega.

O JSON-LD melhora o meu ranking?

As páginas do Google descrevem elegibilidade a rich results, não posições melhores. Ninguém pode prometer uma posição.

Seu próximo passo

Escolha a página mais importante para você. Cole o exemplo 1 ou o 2 no Rich Results Test com os seus próprios valores e corrija o que ele apontar. Publique, analise a página com o SEOgrinder, abra “Página no Google” e leia o cartão “Verificação de campos”. Para ver o quadro geral, a nossa checklist de auditoria SEO mostra onde os dados estruturados ficam entre as outras verificações.

Leia também

• Title tag para SEO: tamanho, palavra-chave na frente e 5 exemplos
• Tamanho da meta description: o que o Google diz (+ 3 exemplos)
• Verificador de SEO para WordPress: o que o plugin realmente entrega