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

Atualizado em 13/08/2026 22 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, em geral gerado por um plugin como o Yoast. 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) podendo elevar suas chances de ter um bom posicionamento 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, fica comigo até o final que vai valer a pena!

Outro 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. Um humano só encontra esses dados se inspecionar o código-fonte, o DevTools do navegador ou uma ferramenta de teste. Máquinas — crawlers, validadores e alguns sistemas de IA — leem o bloco junto com o restante da página.

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: marcação tecnicamente válida não faz uma página “subir de posição”, receber um rich result ou ser citada por uma inteligência artificial. Entre o script e um resultado de negócio existem 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 é o WordPress — a ampla maioria de quem me lê — especialmente quando o Yoast SEO já constrói o grafo. Outros stacks existem; cada um sincroniza o markup à sua maneira. 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

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.

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.

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.

Sim: 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.

Um exemplo mínimo:

<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. Ele não prova que a empresa é confiável, não cria autoridade e não garante um painel de conhecimento. Publica uma afirmação estruturada que um consumidor pode considerar junto com outras fontes.

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. Se a biografia do autor muda e o grafo aponta para uma URL removida, a identidade degrada. O problema deixa de ser sintaxe e vira sincronização entre sistemas.

Antes de escrever marcação, 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

Schema.org não nasce amarrado ao JSON-LD. O mesmo vocabulário pode ser publicado em pelo menos três formatos. O Google continua suportando os três, 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

O Google recomenda JSON-LD porque, na maior parte dos sites, ele é o formato mais fácil de implementar e manter — não porque pague um bônus de ranking. Os três formatos são igualmente aceitáveis para o Google quando estão corretos. Não existe “JSON-LD ranqueia mais que Microdata”.

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. RDFa continua sendo uma opção técnica; raramente é a escolha default de um site WordPress em 2026.

O critério profissional não é “qual formato está na moda”. É: o que o 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.

O mecanismo de busca também extrai informação do texto, do HTML, dos links, das imagens e de outras fontes. 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

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.

SEO, AEO e GEO

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. Palavras continuam importantes porque pessoas falam em linguagem. Entidades adicionam persistência e desambiguação. Um conteúdo maduro usa as duas coisas, mais hierarquia, URLs estáveis, links internos e dados estruturados quando fizer sentido.

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.

As fronteiras desses nomes 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. Nenhuma disciplina substitui a outra automaticamente. A base comum continua sendo acesso do crawler, indexação, conteúdo verificável, autoria transparente e consistência da entidade.

No Google, não há 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 seleção, citação ou recomendação. Se o projeto quiser testar impacto em IA, separe correlação de causalidade: no mesmo período costumam mudar conteúdo, links e rastreamento.

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

`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.

`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, 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. 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 — 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ência clássica: nome da empresa no rodapé diferente do Organization.name do Yoast; artigo atualizado na tela com dateModified antigo por cache; preço na vitrine diferente do Offer.

Nunca comece instalando outro plugin. Primeiro inventarie o que já sai no HTML: WordPress, tema, Yoast, Rank Math, WooCommerce, GTM, código customizado. Duplicação contraditória é mais perigosa do que a ausência de uma propriedade opcional. Empilhar Yoast e Rank Math para “ter mais schema” é uma forma confiável de criar dois grafos para a mesma entidade.

Outros CMS e plataformas

Wix, Shopify, Wagtail, HTML puro e plataformas proprietárias fazem a mesma coisa por outro caminho: 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 mudam. Este guia não cobre cada stack. Se o seu caso não for WordPress e você precisar de suporte técnico para mapear entidades, validar ou corrigir divergência, entre em contato.

Como publicar com segurança no WordPress

Backend ou integração nativa do CMS costumam ser preferíveis: a saída já vem no HTML. 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. 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.

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

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`

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

Há três arquiteturas aceitáveis: um objeto simples, vários blocos independentes, ou um @graph. A regra não é unificar sempre. A regra é 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. Bing Webmaster Tools não é equivalente integral às ferramentas do Google.

Erro crítico pode impedir um item para um recurso específico; não significa que o mecanismo ignorou a página inteira. Aviso costuma ser propriedade recomendada ausente. 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.

Auditar duas URLs na mão não prova o template. Trabalhe 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. Evite meta do tipo “aumentar 30% as citações de IA por causa do schema” sem sistema capaz de medir isso.

Segurança, privacidade e governança

JSON-LD está no código da página e pode ser coletado em escala. Informação visível não deve ser copiada 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.

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 aumenta quando um serializador recebe o objeto inteiro do banco e publica campos que nunca deveriam ser públicos. Use allowlist, objetos específicos para publicação e revisão de campo novo. 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>.

Alguém precisa ser dono de cada campo. Organization.name mora no cadastro institucional; Product.offers.price no ERP; Article.dateModified no CMS. Quando ninguém é responsável, a obsolescência é só questão de tempo.

POP de implementação e homologação

O procedimento operacional — fases, critérios de aceite, evidências, KPIs e rollback — está 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. “O plugin mostrou luz verde” não é critério de aceite.

Considerações finais

JSON-LD não é truque de SEO e não deve ser vendido como atalho para GEO. É uma camada de publicação de dados. O visitante não a vê na tela; o crawler pode lê-la no HTML; o plugin de SEO, no WordPress, costuma ser quem a monta a partir do conteúdo e das configurações.

O valor cresce quando o grafo tem fonte de verdade, identificadores estáveis e validação em camadas. Diminui quando vira bloco estático copiado de um gerador, ou segundo plugin empilhado em cima do Yoast.

Há dois extremos inúteis: ignorar dados estruturados porque não garantem posição; atribuir a eles poderes que a documentação não sustenta. Entre os dois está 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. Não substitui rastreamento, indexação, conteúdo útil, autoria real, oferta nem operação.

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

`Organization`, `LocalBusiness` e `WebSite`

`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 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

Organization, LocalBusiness e WebSite

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 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?

`Organization`, `LocalBusiness` e `WebSite`

`Product`, `Service` e recursos retirados