Um site criado por IA pode sair com um bloco de JSON-LD que parece sofisticado e ainda descreve a empresa errada, uma oferta que não existe ou uma página diferente daquela que o visitante vê. Também pode acontecer o contrário: a marca tem dados confiáveis, mas o script quebra na build ou nunca chega ao HTML publicado.

Validar dados estruturados é conferir sintaxe, tipo, conteúdo e entrega. A marcação precisa representar a página real, permanecer correta depois da geração estática e estar presente na URL que mecanismos de busca conseguem acessar.

Este guia organiza essa revisão sem tratar schema markup como atalho de ranking e sem permitir que o agente complete informações comerciais no chute.

O que dados estruturados fazem — e o que não fazem

Dados estruturados descrevem entidades e relações em um formato legível por máquinas. Em uma página, o formato mais comum é JSON-LD dentro de um <script type="application/ld+json">.

A introdução do Google a dados estruturados explica que a marcação pode ajudar o mecanismo a compreender o conteúdo e tornar a página elegível a apresentações específicas nos resultados. Elegibilidade não é garantia de rich result, posição ou tráfego.

Separe quatro resultados possíveis:

Resultado O que ele prova
JSON válido o bloco pode ser interpretado como JSON
schema coerente tipos e propriedades formam uma estrutura reconhecível
teste específico aprovado a página atende requisitos técnicos daquela experiência testada
rich result exibido o mecanismo escolheu usar a apresentação naquele contexto

Uma etapa não promete a seguinte. A orientação geral do Google deixa explícito que uma marcação tecnicamente correta ainda precisa representar o conteúdo visível e seguir as políticas aplicáveis.

Escolha o tipo a partir da página

Não comece pedindo ao agente “adicione schema para melhorar SEO”. Primeiro identifique o que a página realmente é.

Exemplos de decisões que exigem contexto:

  • um artigo editorial pode ter marcação compatível com artigo;
  • uma página institucional pode descrever a organização, sem repetir esse bloco indiscriminadamente em todas as rotas;
  • breadcrumbs só fazem sentido quando representam uma hierarquia de navegação real;
  • dados de produto, preço, estoque ou avaliação exigem fonte comercial confiável e conteúdo correspondente na página;
  • um tipo disponível em Schema.org não é automaticamente elegível a uma experiência de busca específica.

Consulte a documentação atual do recurso pretendido antes de implementar. Requisitos, propriedades recomendadas e experiências suportadas podem mudar.

Se a página não corresponde com clareza a um tipo útil, não force uma entidade apenas para preencher o <head>.

Faça um inventário de fatos autorizados

Antes de escrever JSON-LD, reúna os dados que podem ser publicados:

URL canônica:
tipo de página:
nome oficial:
descrição aprovada:
imagem pública e URL absoluta:
autor ou organização responsável:
data de publicação e atualização:
breadcrumbs visíveis:
oferta, preço e disponibilidade, quando aplicável:
fonte de cada valor:

Marque o que está ausente. Nome jurídico, telefone, endereço, avaliações, datas, preços e disponibilidade não devem ser inferidos de layouts, nomes de arquivo ou textos provisórios.

O inventário também ajuda a remover excesso. Se o JSON-LD fala de uma entidade que não aparece nem se relaciona com a página, a marcação pode estar tecnicamente bem formada e semanticamente errada.

Gere JSON-LD sem misturar dado e template

Um documento editorial poderia produzir uma estrutura semelhante a esta:

<script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "Título visível e aprovado",
    "datePublished": "2026-08-13",
    "author": {
      "@type": "Organization",
      "name": "Nome oficial"
    },
    "mainEntityOfPage": "https://www.exemplo.com/artigo/"
  }
</script>

O exemplo mostra a forma, não valores para copiar. O tipo precisa corresponder à página, a URL deve ser a canônica daquele conteúdo e as datas precisam vir da fonte editorial.

No projeto, separe:

  • constantes verificadas da organização;
  • dados específicos da página;
  • serialização do objeto;
  • componente ou layout que injeta o script;
  • testes que rejeitam campos obrigatórios ausentes.

Evite montar JSON com concatenação de strings. Gere o objeto e use uma serialização segura para não quebrar aspas, acentos ou caracteres vindos do conteúdo.

Procure marcação duplicada ou herdada

Sites criados a partir de templates podem carregar mais de uma fonte de dados estruturados. Um plugin, layout e componente de página podem gerar blocos sobrepostos.

Faça uma busca na origem:

Terminal window
rg -n 'application/ld\+json|schema.org|@type|jsonLd' src public

Depois responda:

  • quantos blocos cada rota produz;
  • qual arquivo controla cada bloco;
  • se IDs e URLs conectam entidades iguais ou criam duplicatas;
  • se alguma marcação ainda traz domínio, nome ou imagem de um template;
  • se uma rota recebe um tipo que só pertence a outra página.

Não apague blocos apenas porque existem vários. Uma página pode descrever entidades relacionadas de forma legítima. O problema é contradição, duplicação sem intenção ou informação falsa.

Valide em três camadas

1. Fonte

Revise os dados antes da build. Confirme tipos, campos obrigatórios, URLs, datas e a origem de cada valor. Essa camada é onde a correção deve permanecer.

2. Build

Gere o pacote publicável e procure os scripts nos HTMLs finais:

Terminal window
rg -n 'application/ld\+json' dist -g '*.html'

Abra cada bloco e faça parse como JSON. Verifique se a geração escapou o conteúdo corretamente e se a rota recebeu os dados esperados. Um componente correto não prova que o HTML final ficou correto.

3. URL publicada

Depois do deploy, abra a URL final e inspecione o HTML servido. Confira hostname, canonical, conteúdo visível e JSON-LD na mesma versão.

O contrato de Publicação transforma os arquivos estáticos em Pages e assets. Se a marcação está na fonte, mas não aparece na URL, compare public/, Site ID e deploy ativo antes de reescrever o componente.

Use o teste certo para a pergunta

Durante o desenvolvimento, o Rich Results Test ajuda a validar experiências compatíveis do Google. Depois da publicação, relatórios do Search Console podem mostrar problemas encontrados nas URLs processadas.

Essas ferramentas cobrem a parte técnica, mas não aprovam automaticamente:

  • veracidade de uma avaliação;
  • autorização para publicar preço ou endereço;
  • correspondência entre a marcação e todo o conteúdo visível;
  • escolha editorial do tipo mais adequado;
  • qualidade geral da página.

Teste primeiro o código ou a build, depois a URL publicada. Registre qual versão foi analisada. Um teste sobre um trecho local e outro sobre uma URL antiga podem dar resultados diferentes sem que a ferramenta esteja errada.

Confira consistência com os outros sinais

Dados estruturados não vivem isolados. Compare os valores com:

  • <title> e H1;
  • descrição e conteúdo visível;
  • URL canonical;
  • imagem pública e texto alternativo;
  • links internos e breadcrumbs;
  • idioma, autor e datas exibidas;
  • sitemap.xml e política de indexação.

Se o JSON-LD aponta para https://exemplo.com/pagina/, mas canonical e sitemap usam outro hostname, corrija a decisão de URL antes de ajustar apenas a marcação.

Também preserve a atualização editorial. Mudar dateModified a cada build, sem alteração real no conteúdo, transforma um campo útil em ruído.

Peça ao agente uma revisão fechada

Um prompt seguro mantém diagnóstico separado de edição:

Revise os dados estruturados deste site sem alterar arquivos ainda.


Domínio oficial: [domínio aprovado]
Páginas no escopo: [rotas]
Fontes autorizadas: [arquivos ou sistema]


Para cada página, retorne:
- blocos encontrados e arquivo de origem;
- tipo e propriedades;
- divergências com o conteúdo visível e canonical;
- campos ausentes, duplicados ou sem fonte confiável;
- resultado esperado na build;
- correção mínima proposta.


Não invente entidade, avaliação, preço, data, endereço ou relação.
Não publique. Pare quando faltar uma decisão editorial.

Depois da aprovação, peça o diff, a build e os testes. Publique no mesmo Site, confira a URL e use o ciclo de republicação com agente de IA se houver correção.

Checklist final

Antes de considerar a marcação pronta:

  • tipo escolhido a partir do conteúdo real;
  • propriedades conferidas na documentação atual;
  • todo valor sensível ou comercial tem fonte autorizada;
  • JSON válido e serializado com segurança;
  • nenhum dado de template, preview ou localhost;
  • conteúdo marcado também está visível e coerente na página;
  • URLs concordam com canonical, links e sitemap;
  • blocos duplicados foram entendidos;
  • HTML da build foi inspecionado;
  • URL publicada foi testada;
  • resultado registrado com Site ID, rota e versão;
  • nenhum rich result ou ranking foi prometido.

Dados estruturados confiáveis não são um enfeite técnico. Eles resumem fatos que a página já sustenta. Quando fonte, build e URL publicada contam a mesma história, a marcação deixa de ser um palpite gerado pelo agente e passa a ser uma parte verificável da entrega.