Verificação de dados estruturados

Uma segunda cópia da página, escrita para máquinas

Mostre uma página de produto a uma pessoa e ela sabe na hora qual número é o preço e qual é o estoque. Um programa só vê texto. Os dados estruturados poupam esse trabalho de adivinhação. Ao lado da página visível, você publica os mesmos fatos em campos com rótulo, usando os nomes do vocabulário compartilhado em schema.org. Esta coisa é um Product, o name dela é este, as offers dela têm um price de 49.00 em USD.

Há três formas de escrever isso. O JSON-LD põe tudo numa única tag script, separada do layout, e é a forma que o Google recomenda. Microdados e RDFa espalham os rótulos pelas tags HTML, como atributos.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How tides work",
  "datePublished": "2026-03-14T09:30:00+00:00",
  "author": { "@type": "Person", "name": "Jane Doe" }
}
</script>

Os buscadores usam esses campos para montar resultados mais ricos, com estrelas de avaliação, um preço, a foto de uma receita ou a data de um evento. São os chamados resultados avançados (rich results).

O que esta verificação lê

Nosso servidor baixa a página uma vez, até 3 MB, e não executa os scripts dela. Depois trabalha em quatro etapas.

1. Sintaxe. Cada bloco JSON-LD passa por um leitor de JSON rigoroso. No primeiro defeito, ele informa a linha, o caractere e a causa provável: uma vírgula antes de uma chave de fechamento, aspas dentro de um texto sem escape, aspas curvas coladas de um editor de texto, um comentário HTML, uma quebra de linha crua. Basta um defeito para um parser descartar o bloco inteiro.
2. Itens. As listas @graph são abertas para que cada item apareça separado, com o tipo e a estrutura das propriedades. Uma propriedade que aponta para outro item com @id é seguida quando o destino está na página.
3. Propriedades. Para os tipos que alimentam um resultado avançado, o item é comparado com uma lista de propriedades obrigatórias e recomendadas tirada da documentação do Google.
4. Valores. Em todos os itens, os endereços têm de ser absolutos, datas e durações têm de seguir a ISO 8601, o @context tem de ser schema.org e cada ponteiro @id tem de levar a algum lugar.

Microdados (itemscope, itemtype) e RDFa (typeof) são contados e nomeados por tipo. As propriedades deles não são validadas.

Os tipos que comparamos e o que eles exigem

Os outros tipos têm a estrutura mostrada e os valores verificados, sem lista de propriedades obrigatórias.

Consertando o que o relatório mostra

Um erro de sintaxe

Blocos editados à mão quebram em vírgulas e aspas. Gere o bloco com um codificador JSON (json_encode em PHP, JSON.stringify em JavaScript) e toda essa família de erros desaparece. Num CMS, cole o JSON-LD num campo de código. Nunca use o editor visual para isso, porque ele entorta as aspas.

Falta uma propriedade obrigatória

Acrescente-a, com o valor que o visitante vê na página. Os buscadores comparam os dois, e uma marcação que descreve algo que a página não mostra pode render uma ação manual.

Um endereço relativo

Escreva https://www.example.com/img/cover.jpg por extenso, não /img/cover.jpg.

Uma data fora da ISO 8601

Primeiro o ano, depois T, depois a hora e a diferença em relação ao UTC: 2026-03-14T09:30:00+00:00. Só o dia, 2026-03-14, também é válido.

Um ponteiro para lugar nenhum

"author": {"@id": "…/#jane"} só funciona se um item com exatamente esse @id estiver na mesma página. Acrescente o item ou escreva o autor ali mesmo.

O que esta verificação não consegue dizer

Ela lê o HTML como ele é entregue. Dados estruturados acrescentados depois por JavaScript ou por um gerenciador de tags ficam invisíveis aqui, embora o Google possa vê-los após a renderização. As imagens não são baixadas, então uma imagem quebrada ou pequena demais passa despercebida. As listas de propriedades cobrem os tipos de resultado mais comuns. Não cobrem todos os tipos nem todos os campos opcionais.