---
type: Article
title: "JSON-LD como infraestrutura de dados para SEO, GEO e AEO: fundamentos, arquitetura, implementação e auditoria"
description: "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)."
resource: https://felipecferreira.com.br/biblioteca/json-ld-seo-geo-aeo-guia-completo/
generated: { by: process:okf-bridge, at: 2026-09-03T01:38:53Z }
status: stable
sources:
  - id: canonical-html
    resource: https://felipecferreira.com.br/biblioteca/json-ld-seo-geo-aeo-guia-completo/
    title: "Página oficial em HTML"
    last_modified: 2026-08-14T06:45:55Z
---

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

**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](https://felipecferreira.com.br/biblioteca/estrutura-de-uma-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](https://search.google.com/test/rich-results).

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](https://felipecferreira.com.br/biblioteca/arquitetura-do-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](https://felipecferreira.com.br/contratar/).

***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](https://felipecferreira.com.br/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:

1. abra a URL;
2. use “ver código-fonte” ou o inspetor do navegador;
3. busque `application/ld+json`;
4. 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](https://search.google.com/test/rich-results) — 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](https://validator.schema.org/) — valida o vocabulário Schema.org, independentemente do suporte do Google;
* [JSON-LD Playground](https://json-ld.org/playground/) — ajuda a entender o formato em si. A especificação e o ecossistema estão em [json-ld.org](https://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](https://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](https://felipecferreira.com.br/wp-content/uploads/2026/07/imagem-exemplo-json-ld-site-google.png)

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:

1. Qual sistema possui o valor oficial de cada campo?
2. Quem pode alterar esse valor?
3. Como a atualização chega à página *e* ao JSON-LD?
4. Qual atraso é aceitável?
5. 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](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data) 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](https://felipecferreira.com.br/biblioteca/knowledge-graph-no-ai-vision-map/);
* 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:

1. **Qual é a entidade principal da página?**
2. **O conteúdo correspondente está visível?**
3. **O tipo existe no Schema.org?**
4. **O consumidor-alvo declara suporte?**
5. **Existe um recurso ativo ou apenas valor semântico?**
6. **Quais propriedades aquele consumidor exige?**
7. **Qual resultado justifica o custo?**
8. **Como os valores serão mantidos atualizados?**
9. **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](https://developer.yoast.com/features/schema/api/) 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](https://felipecferreira.com.br/contratar/).

### 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](https://json-ld.org/playground/)   Schema.org Tipos e propriedades pertencem ao vocabulário? [Schema Markup Validator](https://validator.schema.org/)   Consumidor Aquele mecanismo usa esse tipo para uma experiência? Documentação e [Rich Results Test](https://search.google.com/test/rich-results)   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](https://felipecferreira.com.br/biblioteca/o-que-e-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](https://felipecferreira.com.br/documentacao/pop-implementacao-homologacao-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](https://felipecferreira.com.br/busca-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](https://felipecferreira.com.br/contratar/).

## Referências

JSON-LD: [json-ld.org](https://json-ld.org/), [JSON-LD Playground](https://json-ld.org/playground/), [W3C JSON-LD 1.1](https://www.w3.org/TR/json-ld11/).

Schema.org: [documentação e vocabulário](https://schema.org/), [inLanguage](https://schema.org/inLanguage), [sameAs](https://schema.org/sameAs), [Schema Markup Validator](https://validator.schema.org/).

Google Search Central: [Introdução a dados estruturados](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data), [diretrizes gerais](https://developers.google.com/search/docs/appearance/structured-data/sd-policies), [galeria de recursos](https://developers.google.com/search/docs/appearance/structured-data/search-gallery), [Rich Results Test](https://search.google.com/test/rich-results), [recursos de IA e websites](https://developers.google.com/search/docs/appearance/ai-features), [JSON-LD com JavaScript e GTM](https://developers.google.com/search/docs/appearance/structured-data/generate-structured-data-with-javascript).

Google Search Central: [Organization](https://developers.google.com/search/docs/appearance/structured-data/organization), [site names e WebSite](https://developers.google.com/search/docs/appearance/site-names), [Article](https://developers.google.com/search/docs/appearance/structured-data/article), [ProfilePage](https://developers.google.com/search/docs/appearance/structured-data/profile-page), [Course list](https://developers.google.com/search/docs/appearance/structured-data/course), [BreadcrumbList](https://developers.google.com/search/docs/appearance/structured-data/breadcrumb), [LocalBusiness](https://developers.google.com/search/docs/appearance/structured-data/local-business), [Product](https://developers.google.com/search/docs/appearance/structured-data/product), [Event](https://developers.google.com/search/docs/appearance/structured-data/event), [JobPosting](https://developers.google.com/search/docs/appearance/structured-data/job-posting), [VideoObject](https://developers.google.com/search/docs/appearance/video), [QAPage](https://developers.google.com/search/docs/appearance/structured-data/qapage).

Google Search Central: [changelog](https://developers.google.com/search/updates), [retirada do sitelinks search box](https://developers.google.com/search/blog/2024/10/sitelinks-search-box), [retirada de recursos menos utilizados](https://developers.google.com/search/blog/2025/06/simplifying-search-results).

Bing Webmaster Tools: [inspeção de URL](https://www.bing.com/webmasters/help/url-inspection-55a30305), [structured data](https://www.bing.com/webmasters/help/marking-up-your-site-with-structured-data-3a93e731).

Yoast Developer: [Schema API](https://developer.yoast.com/features/schema/api/), [especificação funcional do grafo](https://developer.yoast.com/features/schema/functional-specification/).

WordPress Developer Resources: [wp_json_encode](https://developer.wordpress.org/reference/functions/wp_json_encode/).

Presidência da República: [Lei Geral de Proteção de Dados Pessoais](https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709compilado.htm).