JSON-LD como infraestrutura de dados para SEO, GEO e AEO: fundamentos, arquitetura, implementação e auditoria

Atualizado em 14/08/2026 23 min de leitura Publicado em 29/07/2026

TL;DR

JSON-LD não aparece na interface da página: fica em um script no HTML, comumente gerado por um plugin como o Yoast (WordPress). Este guia explica o formato, o vocabulário Schema.org, o modelo de grafo, a sincronização com o conteúdo no WordPress e como validar sem confundir validade técnica com ranqueamento, rich results ou citações em IA.

JSON-LD costuma ser apresentado no mercado como um recurso de SEO que adiciona preços, autores, local, oferta, perguntas e outros possíveis elementos ao conteúdo de determinada página (URL) tendo como meta otimizar visibilidade e atrair cliques em resultados de pesquisa.

Essa descrição é até válida, mas ainda está incompleta em uma perspectiva profissional.

Então se você quer dominar o assunto com profundidade, vem comigo que vai valer a pena!

Um ponto que já quero esclarecer e que é muito importante: um visitante não vê JSON-LD na interface da página do teu site.

Um usuário comum que abre a URL do teu site pelo navegador, vai ser capaz de visualizar: título, texto, imagens, botões, vídeo, etc. Mas ele não vai ver diretamente o JSON-LD.

O JSON-LD fica em um bloco <script type="application/ld+json"> no HTML que não é renderizado (vou falar mais sobre isto na prática, abaixo).

Nós, humanos, só vamos encontrar esses dados se inspecionarmos o código-fonte, utilizando recursos do DevTools (Google Chrome – ou similar) do navegador ou uma ferramenta própria de teste, como o Teste de Pesquisa Aprimorada.

Já as Máquinas (crawlers), validadores e alguns sistemas de Inteligência Artificial leem o bloco contendo o JSON-LD junto com o restante da página, automaticamente.

Em uma implementação madura, JSON-LD funciona como uma camada de publicação de dados: transforma informações já existentes no site em entidades, propriedades e relacionamentos legíveis por máquinas.

Essa camada pode ajudar a interpretar uma página, tornar conteúdo elegível a recursos visuais e reduzir ambiguidades sobre organizações, pessoas, produtos, artigos e serviços.

Todavia, vamos ter cautela: a marcação tecnicamente válida não pode prometer que determinada página irá “subir de posição” na SERP (Search Engine Results Page), isto é, a página de resultados que o Google mostra, nem receber um rich result, nem ser citada por uma inteligência artificial.

Trabalhar com JSON-LD é uma etapa de processo, é uma engrenagem de um motor muito maior.

Entre o script e um resultado de negócio existem outros eventos como: rastreamento, renderização, indexação, suporte do consumidor, políticas, elegibilidade, exibição, clique e conversão.

Este guia apresenta uma abordagem de engenharia para planejar, implementar, validar e governar JSON-LD.

O foco prático aqui é o WordPress (a ampla maioria de quem me lê, alunos, parceiros e clientes) especialmente quando o Yoast SEO já é o Plugin utilizado e constrói o grafo.

Outras stacks existem, obviamente, cada um sincroniza o markup à sua maneira.

Então, se o seu site não for WordPress e você precisar de suporte técnico, entre em contato.

NOTA TÉCNICA: as informações daqui retratam a minha experiência e o meu método de trabalho. Você é o responsável por alterações no seu site ou no site de seus clientes. Nos responsabilizamos exclusivamente em parcerias formalizadas por contrato. Em dúvida, visite o Aviso Legal.

Escopo temporal: recursos suportados e descontinuados foram verificados em agosto de 2026. Mecanismos de busca alteram a documentação com frequência; consulte a fonte oficial antes de cada projeto ou revisão relevante.

O que você não vê na página

Vou reforçar: JSON-LD não é um componente visual.

Não aparece como um box, um selo ou um rodapé. Ele é um objeto JSON embutido no HTML, em geral no <head> ou no <body>, sem relação obrigatória com o CSS da página.

Isso tem três consequências práticas:

o conteúdo visível e o grafo podem divergir sem que o editor perceba no Gutenberg;
inspecionar a URL publicada (e a versão renderizada) é parte do trabalho, não um extra;
tudo o que entra no JSON-LD é público e coletável, mesmo que “não apareça na tela”.

Para ver o bloco neste site, ou em qualquer outro:

abra a URL;
use “ver código-fonte” ou o inspetor do navegador;
busque application/ld+json;
confira o mesmo HTML em uma ferramenta, não só no editor.

Ferramentas gratuitas de inspeção, cada uma com um papel diferente:

Rich Results Test — mostra quais rich results do Google a página pode gerar. Um tipo válido que o Google não usa para experiência visual pode simplesmente não aparecer ali;
Schema Markup Validator — valida o vocabulário Schema.org, independentemente do suporte do Google;
JSON-LD Playground — ajuda a entender o formato em si. A especificação e o ecossistema estão em json-ld.org.

Vamos aqui deixar notas importantes: nenhuma dessas ferramentas substitui a outra; o Rich Results Test não é um validador universal de Schema.org.; o Playground não diz se o Google vai exibir um snippet; o código-fonte não diz se o crawler recebeu a versão renderizada.

Ficou claro?

Dados estruturados, Schema.org, JSON-LD e grafos

Quatro conceitos circulam no mercado como se fossem a mesma coisa. Não são.

Quatro camadas que não são sinônimos

Dados estruturados são informações organizadas em campos, tipos e relações. Uma tabela de produtos com nome, SKU, preço e disponibilidade já é dado estruturado, mesmo antes de existir numa página.

Schema.org é o vocabulário compartilhado para descrever entidades. Ele define tipos como Organization, Person, Article, Product, Event e Service, e propriedades como name, url, author, offers e sameAs. O projeto foi fundado por Google, Microsoft, Yahoo e Yandex e evolui em processo comunitário aberto.

JSON-LD (JavaScript Object Notation for Linked Data) é um formato baseado em JSON para serializar dados conectados. Ele não é o vocabulário. Ele carrega o vocabulário — em geral Schema.org — sem espalhar atributos pelo HTML visível. A spec é do W3C; o site de referência do formato é json-ld.org.

Grafo de entidades é o modelo resultante quando os objetos deixam de ser registros isolados e passam a se relacionar. Um artigo pode ser publicado por uma organização, escrito por uma pessoa, integrar um website e ser a entidade principal de uma página. O valor está nos nós e nas relações.

Empacotando tudo isto, podemos dizer que o JSON-LD é um formato de structured data que, no uso de busca, quase sempre emprega o vocabulário Schema.org e permite trabalhar o resultado como grafo.

O grafo não é um “bônus místico”. Ele aparece quando os nós se referenciam de forma estável, em geral por @id.

Veja um exemplo básico:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://www.example.com/#organization",
  "name": "Example Engenharia Digital",
  "url": "https://www.example.com/"
}
</script>

Esse bloco declara uma entidade Organization, atribui um identificador persistente e informa nome e URL.

Exemplo de teste prático no site do próprio Search Console:

imagem exemplo json-ld site google

Mas precisamos ter em mente que o bloco não prova que a empresa é confiável, não cria autoridade e não garante um painel de conhecimento.

JSON-LD não é o banco de dados nem a fonte de verdade

Um erro comum é tratar a marcação como cadastro principal da empresa, do produto ou do conteúdo. Na arquitetura correta, o JSON-LD é uma saída derivada de fontes já governadas: cadastro institucional, perfil de autor, CMS, catálogo, preços, agenda, página visível.

Se o preço muda no ERP e não muda no JSON-LD, a marcação mente: teremos problemas.

Se a biografia do autor muda e o grafo aponta para uma URL removida, a identidade se degrada.

O problema deixa de ser sintaxe e vira sincronização entre sistemas.

Então antes de desenvolver, responda:

Qual sistema possui o valor oficial de cada campo?
Quem pode alterar esse valor?
Como a atualização chega à página e ao JSON-LD?
Qual atraso é aceitável?
Como uma divergência será detectada?

JSON-LD, Microdata e RDFa

Este é um assunto que achei relativamente difícil de encontrar em outras páginas que falam sobre JSON-LD, logo criei uma pequena seção para alguns esclarecimentos.

Vamos reforçar que o Schema.org não “nasce” amarrado ao JSON-LD.

O mesmo vocabulário pode ser publicado em outros formatos que o Google orienta para dados estruturados, desde que válidos e implementados conforme a documentação do recurso.

Formato	Onde mora	Situação prática
JSON-LD	Bloco `<script>` separado do HTML visível	Padrão atual de CMS e plugins. Mais fácil de gerar, auditar e manter
Microdata	Atributos no HTML visível (`itemscope`, `itemtype`, `itemprop`)	Ainda aparece em temas antigos e alguns e-commerces. Quebra com mais facilidade quando o template muda
RDFa	Atributos no HTML, com outra sintaxe de linked data	Válido. Mais comum em contextos acadêmicos, governamentais ou de web semântica do que em WordPress editorial

Todavia o Google recomenda JSON-LD porque, na maior parte dos sites, ele é o formato mais fácil de implementar e manter, não porque possua algum peso ou “bônus” de ranking.

Os três formatos são igualmente aceitáveis para o Google quando estão corretos.

Logo, não existe “JSON-LD ranqueia mais que Microdata”, isto é MITO.

JSON-LD tende a ser melhor quando você quer desacoplar dados da apresentação, gerar o grafo no backend ou no plugin, e inspecionar um bloco só.

Microdata pode fazer sentido em marcações muito coladas ao texto visível, mas o custo de manutenção sobe.

O RDFa continua sendo uma opção técnica, mas raramente é a escolha default de um site WordPress em 2026.

Desta forma o critério profissional não é “qual formato está na moda”.

É: o que a stack já publica, o que você consegue manter sincronizado com o conteúdo visível, e o que o consumidor-alvo documenta.

O que JSON-LD pode e não pode fazer

JSON-LD pode:

fornecer pistas explícitas sobre o significado de uma página;
descrever entidades e relações;
tornar páginas elegíveis a recursos compatíveis;
facilitar consistência entre templates;
servir como interface pública legível por máquinas;
apoiar auditorias de autoria, datas, preços, disponibilidade e identidade;
reduzir ambiguidades quando os identificadores são estáveis.

JSON-LD não pode:

garantir posicionamento;
garantir rich result;
compensar conteúdo fraco;
tornar indexável uma página bloqueada;
corrigir arquitetura de URLs defeituosa;
substituir links internos;
provar experiência, autoridade ou confiabilidade;
fazer uma empresa entrar automaticamente no Knowledge Graph;
garantir citação em AI Overviews, AI Mode, ChatGPT, Copilot ou outro sistema generativo.

Outro ponto técnico relevante: os mecanismos de busca também podem extrair informação diretamente do texto, do HTML, dos links, das imagens e de outras fontes, então dados estruturados são uma declaração adicional, não a única forma de compreensão.

Os níveis de evidência

Para impedir que hipótese vire fato comercial, classifique cada recomendação:

Nível	Definição	Exemplo
Documentado	Há documentação primária do consumidor	`Product` pode tornar uma página elegível a experiências de produto no Google
Inferência técnica	A arquitetura sugere benefício, sem garantia específica	Identificadores estáveis reduzem ambiguidade dentro do próprio grafo
Hipótese experimental	A relação precisa ser testada e pode variar	Determinada expansão de entidade aumentaria citações em respostas generativas

Observações relevantes: oportunidade documentada entra no escopo com critério de aceite; inferência técnica se justifica como decisão arquitetural; hipótese exige plano de teste, prazo, métrica e a possibilidade explícita de resultado nulo (como profissionais sérios, não podemos garantir resultados – nós garantimos compatibilidade técnica com as melhores práticas do mercado).

SEO, AEO e GEO

Vamos ver um pouco agora sobre as novidades do mercado de search com o uso de IA, incluindo os termos AEO (Answer Engine Optimization) e GEO (Generative Engine Optimization); para além do convencional SEO (Search Engine Optimization).

Já adianto: a busca não abandonou palavras-chave em favor de entidades!

Sistemas modernos combinam linguagem, intenção, entidades, passagens, links, qualidade, mídia e modelos. Entidades adicionam persistência e desambiguação.

Um conteúdo maduro pensa e usa as duas coisas, mais hierarquia, URLs estáveis, links internos e dados estruturados sempre que fizer sentido.

Vamos analisar as responsabilidades:

SEO busca tornar conteúdo rastreável, indexável, compreensível e competitivo em mecanismos de busca.

AEO concentra-se em tornar respostas identificáveis por interfaces que respondem perguntas.

GEO concentra-se na presença e representação de marcas e fontes em experiências generativas.

NOTA: As fronteiras desses nomes novos (AEO, GEO) ainda não são padronizadas. Um projeto deve definir qual superfície está chamando de AEO ou GEO, em vez de assumir que o rótulo já descreve a entrega.

A base comum continua sendo um trabalho de excelência em SEO, acesso do crawler, indexação, conteúdo verificável, autoria transparente e consistência da entidade.

Na própria documentação do Google, não há (ainda) requisito técnico extra de JSON-LD para aparecer como link de apoio em AI Overviews ou AI Mode.

A página precisa estar indexada e elegível a snippet. Isso reduz o espaço para “tática secreta de GEO” e aumenta o valor da infraestrutura tradicional bem feita.

O papel defensável do JSON-LD nessas superfícies é publicar fatos em formato padronizado, manter identidades coerentes e facilitar o consumo por sistemas que suportem aquele vocabulário.

Não é razoável transformar isso em garantia de impressão (exibição) seleção, citação ou recomendação. Se algum profissional estiver te prometendo coisa do tipo, cautela!

Exemplo: Um tipo pode continuar válido no Schema.org depois que um mecanismo deixa de exibi-lo. O SearchAction segue válido, mas o sitelinks search box do Google saiu globalmente em novembro de 2024. O FAQPage segue no vocabulário, mas o FAQ rich result do Google deixou de aparecer em 7 de maio de 2026.

Logo, compreendemos que: “Válido” não significa “prioritário”!

Como priorizar schemas por página, consumidor e resultado

Antes de implementar, percorra esta sequência:

Qual é a entidade principal da página?
O conteúdo correspondente está visível?
O tipo existe no Schema.org?
O consumidor-alvo declara suporte?
Existe um recurso ativo ou apenas valor semântico?
Quais propriedades aquele consumidor exige?
Qual resultado justifica o custo?
Como os valores serão mantidos atualizados?
Como a implementação será validada?

Essa cadeia evita a pergunta errada: “qual schema está em alta?”.

Arquétipo	Tipo principal	Resultado documentado no Google	Observação
Site institucional	`Organization` e `WebSite`	Informações organizacionais e preferência de site name	Concentrar detalhes na home ou na página da organização
Negócio com endereço físico	subtipo de `LocalBusiness`	Experiências locais	Usar o subtipo mais específico
Artigo editorial	`Article`, `BlogPosting` ou `NewsArticle`	Melhor compreensão de título, imagens, datas e autoria	Datas, imagens e autor precisam bater com o visível
Perfil de autor	`ProfilePage` e `Person`	Identificação de página de perfil	Conectar `author` a um nó `Person` estável
Produto	`Product` e `Offer`	Product snippets e, quando aplicável, merchant listings	Preço, moeda e disponibilidade exigem sincronização rigorosa
Serviço B2B	`Service`	Não há rich result genérico equivalente a `Product`	Valor descritivo; não prometer efeito visual. O Rich Results Test pode não destacar esse tipo
Curso	`Course`	Depende da experiência atualmente suportada	Não confundir Course list com Course info já retirado
Evento	`Event`	Experiência de evento	Data, local, status e oferta precisam estar atuais
Vaga	`JobPosting`	Busca de vagas	Remover ou atualizar vagas encerradas
Vídeo principal	`VideoObject`	Recursos de vídeo	O vídeo deve ser conteúdo principal e acessível
FAQ do próprio site	`FAQPage`	FAQ rich result retirado em maio de 2026	Manter só com justificativa semântica ou outro consumidor
Fórum com respostas de usuários	`QAPage`	Recurso de Q&A, quando elegível	Não usar como substituto de FAQ

O Schema.org é amplo. Google, Bing ou outro sistema consomem só uma parte e impõem requisitos próprios. Uma propriedade opcional no vocabulário pode ser obrigatória para um recurso específico, então pesquise e se informe, garantindo que está acessando uma informação atualizada e de fonte segura.

Tipos `Organization`, `LocalBusiness` e `WebSite`

Organization descreve a entidade organizacional. LocalBusiness entra quando existe um negócio local compatível, com o subtipo mais específico. Não são rótulos intercambiáveis. WebSite representa o site, não a empresa. Na home, name e, se preciso, alternateName indicam a preferência de site name.

O Google recomenda publicar os detalhes completos da organização na home ou em uma página institucional. Não é necessário repetir o cadastro inteiro em todas as URLs. Reproduzir o mesmo nó com o mesmo @id não é automaticamente um erro; o problema é identificador ou valor conflitante.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://www.example.com/#organization",
      "name": "Example Engenharia Digital",
      "url": "https://www.example.com/",
      "logo": {
        "@type": "ImageObject",
        "@id": "https://www.example.com/#logo",
        "url": "https://www.example.com/assets/logo.png"
      },
      "sameAs": [
        "https://www.linkedin.com/company/example"
      ]
    },
    {
      "@type": "WebSite",
      "@id": "https://www.example.com/#website",
      "url": "https://www.example.com/",
      "name": "Example Engenharia Digital",
      "publisher": { "@id": "https://www.example.com/#organization" },
      "inLanguage": "pt-BR"
    },
    {
      "@type": "WebPage",
      "@id": "https://www.example.com/#webpage",
      "url": "https://www.example.com/",
      "name": "Example Engenharia Digital",
      "isPartOf": { "@id": "https://www.example.com/#website" },
      "about": { "@id": "https://www.example.com/#organization" }
    }
  ]
}
</script>

Os valores são ilustrativos. Não publique campo só porque apareceu no exemplo. Se um dado não deve ser público, ele não entra no grafo.

Em artigos, BlogPosting descreve a obra, Person o autor, ProfilePage a página cujo assunto é o autor, e Organization o publisher. Isso torna a autoria explícita. Não cria E-E-A-T sozinho. Credibilidade continua dependendo de biografia visível, precisão, reputação e fontes.

O Google aceita itens aninhados ou separados. @graph torna as relações visíveis e facilita a governança; não é obrigatório. Breadcrumb continua semanticamente útil, mas o rich result de breadcrumb do Google está disponível somente em desktop desde 2025.

Tipos `Product`, `Service` e recursos retirados

Product tem suporte documentado a experiências de produto. Isso exige disciplina em Offer, preço, moeda e disponibilidade. Service descreve serviços e não deve ser vendido como equivalente de Product para rich results. Em uma landing B2B, ele pode integrar o grafo:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Service",
  "@id": "https://www.example.com/servicos/auditoria-tracking/#service",
  "name": "Auditoria de tracking e web analytics",
  "url": "https://www.example.com/servicos/auditoria-tracking/",
  "description": "Auditoria técnica de GA4, Google Tag Manager e eventos de conversão.",
  "provider": { "@id": "https://www.example.com/#organization" },
  "areaServed": { "@type": "Country", "name": "Brasil" }
}
</script>

Esse bloco não deve conter preço, prazo ou resultado que não estejam na página. inLanguage descreve o idioma de uma obra (WebPage, artigo); não é a propriedade esperada em um Service genérico.

Pontos de revisão contínua:

WebSite continua relevante; SearchAction não produz mais o sitelinks search box do Google;
FAQPage não produz FAQ rich results no Google desde maio de 2026;
HowTo existe no Schema.org, mas guias antigos não bastam — veja a galeria atual;
Course info foi retirado; isso não apaga todos os recursos de curso;
tipos sem experiência no Google podem não aparecer no Rich Results Test nem nos relatórios do Search Console.

Tipo descontinuado não precisa ser apagado em pânico. A decisão considera custo de manutenção, outros consumidores e risco de inconsistência.

WordPress e Yoast: quem gera e quem atualiza o grafo

No WordPress, o editor não “salva o JSON-LD” junto com o parágrafo.

O WordPress grava título, conteúdo, autor, datas e imagem.

Na renderização da URL, algum gerador monta o <script type="application/ld+json">. Na ampla maioria dos sites que atendo (e recomendo), esse gerador é o Yoast SEO.

O que o Yoast realmente faz?

O Yoast não “coloca um schema”. Ele publica um @graph em JSON-LD em todas as páginas, com peças reutilizáveis: Organization ou Person (conforme a configuração da entidade), WebSite, WebPage e, no tipo da URL, peças extras como Article, breadcrumb e autor.

Os nós se conectam por @id. Essa arquitetura é, na prática, o modelo de grafo descrito acima, já implementado por um plugin, não por um JSON colado à “mão”.

Parte dos valores vem do post: título, SEO title, meta description, datas, autor, imagem destacada; a outra parte vem das configurações do Yoast: nome da organização, logo, perfis sociais (sameAs), representação Pessoa vs Organização.

Mudar o texto visível da página “Sobre” não atualiza sozinho o nó Organization se o setting do plugin não for atualizado.

A Schema API do Yoast existe para estender ou filtrar peças desse grafo, preservando os IDs centrais. A solução sustentável costuma ser essa, e não instalar um segundo gerador que publique outro Organization concorrente.

Quando o conteúdo muda, o JSON-LD muda?

Depende do mapeamento, não do ato de clicar em “Atualizar”.

Costuma acompanhar o post quando o Yoast (ou o WooCommerce, no produto) lê o campo: título, description, dateModified, autor, imagem, preço do produto no e-commerce.
Não acompanha o parágrafo visível quando o valor mora em setting do plugin, código estático, Google Tag Manager ou segundo plugin.
Pode parecer que não atualizou quando o HTML está em cache (LiteSpeed, plugin de cache, CDN). O grafo vai no HTML; cache velho entrega JSON-LD velho.

Por isso a auditoria não termina no Gutenberg. Depois de uma alteração relevante, inspecione a URL publicada, confirme o nó que deveria ter mudado e, se houver cache, faça purge.

Divergências clássicas: notamos com frequência que o nome da empresa no rodapé é diferente do Organization.name do Yoast; ou o artigo atualizado na tela tem dateModified antigo por cache; ou o preço na vitrine (front-end) está diferente do Offer.

Em um processo de auditoria, trabalho com SEO, atendendo um cliente ou na sua empresa, aconselho fortemente que você nunca comece instalando outro plugin.

Primeiro inventarie o que já sai no HTML: WordPress, tema, Yoast, Rank Math, WooCommerce, GTM, código customizado.

Saiba que duplicação contraditória é mais perigosa do que a ausência de uma propriedade opcional.

E JAMAIS pense que empilhar Yoast e Rank Math para “ter mais schema” é uma forma confiável de criar dois grafos para a mesma entidade. Não tenha dois plugins concorrentes e ativos que rodem responsabilidades e funções idênticas (nem pra SEO, nem para nada).

Outros CMS e plataformas

Wix, Shopify, Wagtail, HTML puro e plataformas proprietárias fazem a mesma coisa que acabamos de falar, mas por outros caminhos: o editor da plataforma, o app da loja, o template ou um arquivo estático.

O princípio não muda (JSON-LD é saída derivada) mas o botão, o cache e o responsável por construir scripts, mudam.

Este guia não cobre cada stack, senão teríamos um livro. É ineficiente.

Logo, reforço: se o seu caso não for WordPress e você precisar de suporte técnico para mapear entidades, validar ou corrigir divergências, entre em contato.

Como publicar JSON-LD com segurança no WordPress

O Backend ou integração nativa do CMS costumam ser preferíveis para esta tarefa: a saída já vem no HTML.

O JavaScript e GTM são aceitos pelo Google, mas criam dependência de renderização e um segundo lugar onde o dado pode ficar velho (NÃO RECOMENDO).

Para produto com preço volátil, server-side e fonte comercial direta tendem a ser mais adequados.

Nunca monte JSON concatenando strings de banco ou de usuário. Use o serializador da linguagem:

<?php
$schema = [
    '@context' => 'https://schema.org',
    '@type'    => 'Service',
    'name'     => get_the_title(),
    'url'      => get_permalink(),
];

echo '<script type="application/ld+json">';
echo wp_json_encode(
    $schema,
    JSON_HEX_TAG | JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES
);
echo '</script>';

O mérito desse exemplo é serializar um objeto, não colar JSON na mão.

Aplique allowlist de campos, valide tipos, normalize URLs, use datas ISO 8601 com fuso, e teste aspas, acentos e quebras de linha.

Campo nulo não deve ser publicado como se fosse informação!

Engenharia do grafo

@id, url e sameAs resolvem problemas diferentes.

@id identifica o nó. Em sites, uma URL absoluta com fragmento é um padrão prático: https://www.example.com/#organization. Uma organização global não deve ganhar um @id diferente em cada página. Isso cria duas entidades onde deveria haver uma.

A propriedade url aponta para a página que representa a entidade. Pode coincidir com a parte anterior ao fragmento de @id; a função é outra.

A propriedade sameAs aponta para páginas de referência que identificam a mesma entidade.

Não coloque qualquer menção, resultado de busca ou diretório sem controle de identidade.

Origem	Propriedade	Destino
`WebSite`	`publisher`	`Organization`
`WebPage`	`isPartOf`	`WebSite`
`Article`	`author`	`Person`
`Article`	`publisher`	`Organization`
`Service`	`provider`	`Organization`
`Product`	`offers`	`Offer`

NOTA: Não é necessário adicionar toda relação possível. O objetivo é representar o que existe, e não produzir o maior JSON-LD da concorrência. Tamanho não é documento!

Basicamente temos três arquiteturas aceitáveis: um objeto simples, vários blocos independentes, ou um @graph.

A regra de ouro é não produzir contradição, duplicação competitiva ou perda de relacionamento.

Validação e ferramentas de inspeção

Validade não é um estado único, uma implementação pode passar numa camada e falhar na seguinte:

Camada	Pergunta	Onde olhar
Sintaxe JSON	O bloco é JSON válido?	Parser, DevTools
JSON-LD	Contexto e palavras-chave são processáveis?	JSON-LD Playground
Schema.org	Tipos e propriedades pertencem ao vocabulário?	Schema Markup Validator
Consumidor	Aquele mecanismo usa esse tipo para uma experiência?	Documentação e Rich Results Test
Política	A marcação representa conteúdo visível e permitido?	Revisão humana
Renderização	O crawler recebe a marcação?	Inspeção de URL e HTML renderizado
Negócio	Houve impressão, clique ou receita incremental?	Search Console, analytics, desenho de teste

Fluxo mínimo: parser → Schema Markup Validator → Rich Results Test (quando houver recurso Google) → inspeção da URL publicada → Search Console, se existir relatório para aquele tipo.

Lembrando que o Bing Webmaster Tools não é equivalente integral às ferramentas do Google.

Divergência factual é pior do que vários avisos: preço visível de R$ 499 com offers.price 399; autor errado; produto esgotado marcado como InStock; FAQ só no JSON-LD, invisível na página.

No processo de validação (inspeção), auditar duas URLs na mão não prova o template. É preciso trabalhar por amostragem: home, sobre, artigo, autor, serviço, produto. Indicadores úteis são cobertura do tipo esperado, erro crítico, divergência factual e regressão depois de deploy.

Segurança, privacidade e governança

O JSON-LD está no código da página e pode ser coletado em escala. Logo, as informações que vão compor o elemento não devem ser copiadas automaticamente para o grafo sem avaliar finalidade e risco: e-mail pessoal, telefone privado, endereço residencial, identificador fiscal, dado de aluno ou cliente, preço interno, campo administrativo.

Lembrando que a LGPD trata dado pessoal de forma ampla. Publicar Person, autores de Review ou outros indivíduos exige análise de finalidade, base, necessidade e transparência.

Este guia não substitui avaliação jurídica!

O risco pode aumentar se um serializador receber o objeto inteiro do banco e publicar campos que nunca deveriam ser públicos.

Use allowlist, objetos específicos para publicação e revisão de campos novos.

Reviews, FAQs e perfis com texto de usuário exigem serialização segura: sem isso, o conteúdo pode quebrar o JSON ou fechar a tag <script>.

Cada campo tem o seu local de origem. A propriedade Organization.name mora no cadastro institucional; o Product.offers.price no ERP; o Article.dateModified no CMS, e assim sucessivamente.

POP de implementação e homologação

Nosso procedimento operacional que cita fases, critérios de aceite, evidências, KPIs e rollback, está publicamente disponível no POP: Implementação e homologação de JSON-LD (código POP-BA-JSONLD-001).

Este guia permanece como fundamento conceitual e arquitetural.

O POP é a orientação executável para descoberta, projeto, implementação, validação, deploy e operação.

Lembre-se: “O plugin mostrou luz verde” não é critério de aceite! Como profissionais precisamos de mais análise, precisamos olhar com mais atenção.

Considerações finais

Vimos que o JSON-LD não é truque de SEO e não deve ser vendido como atalho para GEO.

O JSON-LD é uma camada de publicação de dados e o visitante não vê seu conteúdo na tela. Já o crawler pode lê-lo diretamente no HTML.

Na ampla maioria dos casos, o JSON-LD é formado por um plugin de SEO, falando de instalações que usam o WordPress.

Abordamos também dois extremos que não devem ser considerados: ignorar dados estruturados porque não garantem posição; e atribuir a eles “poderes” que a documentação não sustenta.

Devemos considerar a engenharia: implementar o que tem finalidade, comprovar o que pode ser comprovado e tratar o restante como hipótese.

A base de SEO e autoridade continua indispensável para busca clássica e experiências generativas. JSON-LD pode (e deve) fazer parte dessa base. Mas ele não substitui rastreamento, indexação, conteúdo útil, autoria real, oferta nem operação.

Espero que tenha gostado!

Se o seu site não for WordPress, ou se você precisar de alguém para inventariar o grafo, corrigir divergência ou homologar a marcação com evidência, vamos conversar.

Um visitante vê JSON-LD na página?

Não. JSON-LD não aparece na interface. Ele fica em um bloco script no HTML, do tipo application/ld+json. Um humano só encontra esses dados no código-fonte, no inspetor do navegador ou em uma ferramenta como o Rich Results Test. Máquinas leem o bloco junto com o restante da página.

JSON-LD é o mesmo que Schema.org?

Não. Schema.org é o vocabulário de entidades e propriedades. JSON-LD é um formato para serializar esses dados em JSON. O modelo resultante, quando os objetos se relacionam por identificadores, é um grafo. O mesmo vocabulário também pode ser publicado em Microdata ou RDFa; o Google continua aceitando os três.

JSON-LD melhora o posicionamento de uma página no Google?

JSON-LD não deve ser tratado como uma alavanca direta ou garantida de posicionamento. Ele fornece informações explícitas sobre a página e pode torná-la elegível a recursos compatíveis. O efeito comercial mais mensurável costuma ocorrer quando um rich result altera a apresentação, as impressões ou o CTR, mas nem a elegibilidade garante exibição.

Quando eu edito um post no WordPress, o JSON-LD atualiza sozinho?

Só o que estiver mapeado para o gerador. No caso mais comum, o Yoast reconstrói o grafo na renderização da URL a partir do post e das próprias configurações. Título, datas e imagem costumam acompanhar. Nome da organização, logo e redes vêm das settings do plugin. Código estático, GTM ou um segundo plugin não acompanham o botão Atualizar. Cache de HTML também pode servir um grafo velho.

Qual é a maneira mais segura de implementar JSON-LD no WordPress?

Primeiro inventarie o que tema e plugins já publicam. Se o Yoast já produz um grafo, prefira estender essa arquitetura e preservar os identificadores em vez de instalar outro gerador concorrente. Use fontes de verdade, serialização segura, inspeção da URL renderizada, evidências de homologação e rollback. O método mais seguro é o que mantém o markup correto ao longo do tempo, não só no dia da instalação.

Referências

JSON-LD: json-ld.org, JSON-LD Playground, W3C JSON-LD 1.1.

Schema.org: documentação e vocabulário, inLanguage, sameAs, Schema Markup Validator.

Google Search Central: Introdução a dados estruturados, diretrizes gerais, galeria de recursos, Rich Results Test, recursos de IA e websites, JSON-LD com JavaScript e GTM.

Google Search Central: Organization, site names e WebSite, Article, ProfilePage, Course list, BreadcrumbList, LocalBusiness, Product, Event, JobPosting, VideoObject, QAPage.

Google Search Central: changelog, retirada do sitelinks search box, retirada de recursos menos utilizados.

Bing Webmaster Tools: inspeção de URL, structured data.

Yoast Developer: Schema API, especificação funcional do grafo.

WordPress Developer Resources: wp_json_encode.

Presidência da República: Lei Geral de Proteção de Dados Pessoais.

JSON-LD como infraestrutura de dados para SEO, GEO e AEO: fundamentos, arquitetura, implementação e auditoria

TL;DR

O que você não vê na página

Dados estruturados, Schema.org, JSON-LD e grafos

Quatro camadas que não são sinônimos

JSON-LD não é o banco de dados nem a fonte de verdade

JSON-LD, Microdata e RDFa

O que JSON-LD pode e não pode fazer

Os níveis de evidência

SEO, AEO e GEO

Como priorizar schemas por página, consumidor e resultado

Tipos `Organization`, `LocalBusiness` e `WebSite`

Tipos `Product`, `Service` e recursos retirados

WordPress e Yoast: quem gera e quem atualiza o grafo

O que o Yoast realmente faz?

Quando o conteúdo muda, o JSON-LD muda?

Outros CMS e plataformas

Como publicar JSON-LD com segurança no WordPress

Engenharia do grafo

Validação e ferramentas de inspeção

Segurança, privacidade e governança

POP de implementação e homologação

Considerações finais

Perguntas frequentes

Referências

Vamos conversar sobre o seu projeto?

TL;DR

O que você não vê na página

Dados estruturados, Schema.org, JSON-LD e grafos

Quatro camadas que não são sinônimos

JSON-LD não é o banco de dados nem a fonte de verdade

JSON-LD, Microdata e RDFa

O que JSON-LD pode e não pode fazer

Os níveis de evidência

SEO, AEO e GEO

Como priorizar schemas por página, consumidor e resultado

Tipos Organization, LocalBusiness e WebSite

Tipos Product, Service e recursos retirados

WordPress e Yoast: quem gera e quem atualiza o grafo

O que o Yoast realmente faz?

Quando o conteúdo muda, o JSON-LD muda?

Outros CMS e plataformas

Como publicar JSON-LD com segurança no WordPress

Engenharia do grafo

Validação e ferramentas de inspeção

Segurança, privacidade e governança

POP de implementação e homologação

Considerações finais

Referências

Vamos conversar sobre o seu projeto?

Tipos `Organization`, `LocalBusiness` e `WebSite`

Tipos `Product`, `Service` e recursos retirados