Ir para o conteúdo principal
Bethemesh
GuiaBoas práticas

Schema.org e JSON-LD: adicionar dados estruturados úteis sem prometer demasiado

Compreenda como Schema.org e JSON-LD descrevem explicitamente uma página, que tipos escolher, como evitar markup enganador e porque os rich results nunca são garantidos.

Publicado 29 de agosto de 2026Leitura : 3 minPor Equipa Bethemesh
Intermédio
Mostrar índice
  1. Schema.org não é um formato de ficheiro
  2. Exemplo de JSON-LD
  3. O markup deve descrever a página real
  4. JSON-LD não substitui o conteúdo visível
  5. Escolher o tipo mais preciso sem forçar
  6. Schema.org e requisitos dos motores são diferentes
  7. Um resultado enriquecido nunca é garantido
  8. URLs e imagens devem ser reais e coerentes
  9. Evitar informação duplicada mas contraditória
  10. Gerar e depois rever
  11. Um esquema pequeno e exato é melhor

Uma página Web já contém muitas informações compreensíveis por uma pessoa: título, autor, data, preço, organização ou uma sequência de passos. Os dados estruturados procuram exprimir parte dessa informação de forma mais explícita para as máquinas.

Schema.org fornece o vocabulário; JSON-LD é uma forma prática de o escrever.

Schema.org não é um formato de ficheiro

Schema.org define tipos e propriedades, por exemplo:

Article
Organization
Product
BreadcrumbList
Person
Event

Um Article pode ter propriedades como headline, author, datePublished e image. O mesmo vocabulário pode ser utilizado com várias sintaxes. JSON-LD é conveniente porque pode ser colocado num bloco separado do HTML visível.

Exemplo de JSON-LD

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Compreender o SEO técnico",
  "datePublished": "2026-08-29"
}
</script>

Um gerador pode ajudar a criar esta estrutura e evitar erros de sintaxe, mas não consegue decidir se os dados declarados são verdadeiros.

O markup deve descrever a página real

Esta é a regra mais importante. Se uma página não apresentar qualquer preço, adicionar um Product com um preço inventado para tentar obter um rich result é uma má prática.

O mesmo se aplica a avaliações, classificações, autores, datas, eventos, FAQ e disponibilidade. Os dados estruturados não devem transformar-se numa segunda versão fictícia da página.

JSON-LD não substitui o conteúdo visível

Se o bloco declarar:

{
  "@type": "Article",
  "headline": "Guia completo do robots.txt"
}

mas a página falar essencialmente de CSS, o esquema não obriga o motor a aceitar essa descrição. O markup deve reforçar informação já coerente com o conteúdo, title, H1, URL e contexto geral.

Escolher o tipo mais preciso sem forçar

Se a página for realmente um artigo, Article é mais descritivo do que uma entidade genérica. Mas não existe um tipo “mais SEO” que deva ser escolhido a qualquer custo. A pergunta correta é: que tipo descreve honestamente este recurso?

Uma página também pode incluir várias entidades relacionadas quando isso corresponde à realidade, como uma organização que publica um artigo e uma BreadcrumbList que representa a navegação.

Schema.org e requisitos dos motores são diferentes

Schema.org inclui muitas propriedades possíveis. Os motores que oferecem experiências enriquecidas podem, porém, documentar apenas um subconjunto específico.

vocabulário Schema.org

requisitos de uma funcionalidade do motor

Um JSON-LD pode estar sintaticamente correto sem ser elegível para um determinado rich result.

Um resultado enriquecido nunca é garantido

Mesmo com markup válido, completo, conforme às recomendações e corretamente indexado, o motor pode decidir não apresentar qualquer enriquecimento. Schema.org não é um botão para “ativar estrelas no Google”.

O principal benefício é, antes de tudo, a clareza semântica.

URLs e imagens devem ser reais e coerentes

Propriedades como url e image devem apontar para recursos acessíveis e coerentes com a página. Evite, sem razão específica, situações como:

canonical : https://example.com/artigo
JSON-LD url : https://example.com/artigo?source=test

Se declarar uma imagem, confirme que a URL é pública, que o ficheiro existe, que o formato é utilizável e que a imagem representa efetivamente a página.

Evitar informação duplicada mas contraditória

A mesma informação pode surgir em vários locais:

H1       → "Guia de SEO técnico"
title    → "SEO técnico: guia completo"
headline → "Guia SEO 2024"

Uma pequena variação de formulação é normal; uma data ou um título desatualizado já é um problema. Não declare uma nova data de atualização apenas porque a página foi reconstruída tecnicamente se o conteúdo não mudou.

Gerar e depois rever

Depois de gerar o JSON-LD, verifique sempre:

  1. o tipo escolhido;
  2. nomes e datas;
  3. URLs;
  4. imagens;
  5. propriedades vazias;
  6. correspondência com o conteúdo visível.

Um esquema pequeno e exato é melhor

Adicionar dezenas de propriedades aumenta o risco de dados desatualizados, URLs incoerentes, campos inventados e erros de manutenção. Comece pelas informações que consegue manter com segurança.

Os dados estruturados funcionam melhor quando fazem parte do processo de publicação: conteúdo finalizado, URL definitiva, metadados coerentes, JSON-LD pertinente, validação e controlo da página realmente publicada.

Ferramentas relacionadas

Web e SEO

Gerador Schema.org JSON-LD

Crie dados estruturados JSON-LD prontos a integrar numa página Web.

100% local
Utilizar esta ferramenta

Fontes e referências

  1. 1.Schema.org
  2. 2.Google Search Central — Structured data

Coleção

Dominar o SEO técnico de um site Web

  1. 01SEO técnico: compreender como os motores exploram e interpretam uma página
  2. 02Title, meta description, canonical e Open Graph: preencher corretamente os metadados
  3. 03robots.txt: compreender crawl, indexação e erros a evitar
  4. 04Schema.org e JSON-LD: adicionar dados estruturados úteis sem prometer demasiado
  5. 05Criar URLs limpas: slugs, parâmetros e normalização
  6. 06Checklist SEO técnica antes de publicar uma página Web

Este artigo foi útil?