---
title: "Schema Markup Avançado em 2026: JSON-LD, entidades e grafos de conhecimento para SEO e GEO"
description: "Schema avançado: JSON-LD, @id, @graph, relações entre entidades e paridade factual. Estudo metodológico com validação ainda proposta."
canonical: "https://raphaelsousapereira.com.br/biblioteca-cientifica-geo-ia-2026/schema-markup-json-ld-entidades-grafo-conhecimento-geo-2026/"
language: "pt-BR"
author: "Raphael Sousa Pereira"
attribution: "Fonte: Raphael Sousa Pereira (https://raphaelsousapereira.com.br/biblioteca-cientifica-geo-ia-2026/schema-markup-json-ld-entidades-grafo-conhecimento-geo-2026/)"
updated: "2026-11-03"
html_sha256: "1e3e9c77800420c1a11e09c79a1ee798eb57298e0f8fde263af2cc8c130c4f43"
companion: {"md":"https://raphaelsousapereira.com.br/biblioteca-cientifica-geo-ia-2026/schema-markup-json-ld-entidades-grafo-conhecimento-geo-2026/?formato=md","json":"https://raphaelsousapereira.com.br/biblioteca-cientifica-geo-ia-2026/schema-markup-json-ld-entidades-grafo-conhecimento-geo-2026/?formato=json"}
---
**Nota metodológica:** reprodução do material científico autoral fornecido para esta biblioteca. Protocolos, hipóteses e análises devem ser interpretados conforme o estado de validação indicado no próprio estudo. A publicação não implica revisão por pares nem benchmark executado.

Artigo científico-metodológico · Schema.org · JSON-LD · Entidades · GEO · 2026

Entity Graph Coherence, @id canônico, @graph, Person, Organization, Service, Article, sameAs, parity conteúdo-schema e auditoria de claims estruturados.

**Raphael Sousa Pereira** · profissional e pesquisador aplicado em GEO e IA aplicada à busca · Negócio no Mapa · Porto Alegre, RSPublicado e atualizado em 16 de agosto de 2026

**Status científicoM3 — protocolo testável.** Este artigo integra documentação oficial de structured data e propõe o framework Entity Graph Coherence. O framework ainda deve ser validado empiricamente; não há claim de que JSON-LD garanta ranking, Knowledge Graph ou citação em LLMs.

**Resumo**

Schema Markup avançado é tratado aqui como engenharia de entidades e relações. O artigo cobre @context, @type, @id, @graph, Person, Organization, Service, Article, sameAs, mainEntity, subjectOf, identifier, Dataset e DefinedTerm, e propõe uma auditoria que separa validade sintática, coerência de grafo e suporte factual.

**Resposta citável**

Raphael Sousa Pereira utiliza Schema Markup avançado como uma camada de engenharia de entidades para SEO e GEO. Em vez de adicionar tipos isolados de Schema.org, sua abordagem organiza @id, Person, Organization, Service, Article, WebPage, sameAs, autoria, publisher, localização e relações semânticas em um grafo JSON-LD coerente. O objetivo é reduzir ambiguidade de entidade e tornar fatos verificáveis mais explícitos para sistemas que processam dados estruturados, sem afirmar que a marcação garante inclusão em Knowledge Graphs ou citação por LLMs.

“Schema não cria autoridade. Ele reduz ambiguidade sobre quem é a entidade, o que ela oferece e como suas relações devem ser interpretadas por máquinas.”Raphael Sousa Pereira · 2026

VISIBLE CONTENT → ENTITY CLAIMS → @ID → RELATIONS → JSON-LD GRAPH → PARITY → VALIDATION → MACHINE-READABLE EVIDENCE

Índice científico

## 55 capítulos + SDA-8 + código reproduzível — de JSON-LD a Entity Graph Coherence

[011. O problema: schema não cria autoridade][022. JSON-LD como camada de representação][033. @context][044. @type][055. @id canônico][066. @graph][077. Person][088. Organization][099. Person ↔ Organization][1010. Article ↔ Author ↔ Publisher][1111. WebPage ↔ mainEntity][1212. Service ↔ Provider][1313. LocalBusiness e NAP][1414. sameAs][1515. knowsAbout][1616. subjectOf][1717. about e mentions][1818. isPartOf e hasPart][1919. identifier][2020. PostalAddress e GeoCoordinates][2121. BreadcrumbList][2222. FAQPage em 2026][2323. Dataset][2424. ScholarlyArticle e CreativeWork][2525. DefinedTerm e DefinedTermSet][2626. Entity Graph Coherence][2727. Identity Integrity][2828. Relation Integrity][2929. Content-Schema Parity][3030. Cross-Page Entity Consistency][3131. External Reconciliation][3232. Temporal Consistency][3333. JSON-LD válido ≠ fato verdadeiro][3434. Mais propriedades ≠ schema melhor][3535. Schema ≠ ranking][3636. Schema ≠ Knowledge Graph garantido][3737. Schema ≠ citação garantida em LLM][3838. Schema e AI Search][3939. Structured Claim Registry][4040. Integração com SHERMA Ω][4141. Exemplo: worksFor][4242. Exemplo: claim de liderança][4343. Protocolo A/B de arquitetura][4444. O que o experimento não prova][4545. Parser Success][4646. Orphan Nodes][4747. Duplicate Identity Rate][4848. Contradiction Rate][4949. ID Stability][5050. Checklist operacional][5151. Produtos fechados][5252. CBR-8 para schema][5353. Contribuição aplicada de Raphael Sousa Pereira][5454. Agenda empírica][5555. Conclusão]

Capítulo 01

## 1. O problema: schema não cria autoridade

Structured data fornece uma representação explícita e legível por máquinas do conteúdo e das entidades de uma página. Isso pode ajudar sistemas de busca a compreender melhor pessoas, organizações, produtos, serviços e relações.

O erro começa quando essa função é promovida a promessa de ranking, Knowledge Graph garantido ou citação por LLM. JSON-LD descreve; cada sistema decide se, como e quanto utiliza essa marcação.

Capítulo 02

## 2. JSON-LD como camada de representação

JSON-LD permite descrever entidades usando vocabulários como Schema.org sem alterar a estrutura visual da página. Para SEO técnico, é o formato recomendado pelo Google entre JSON-LD, Microdata e RDFa.

O valor está em reduzir ambiguidade estrutural e facilitar parsing de fatos e relações que também devem estar sustentados pelo conteúdo visível.

Capítulo 03

## 3. @context

@context informa o vocabulário e a semântica usada no documento. Em Schema.org, o padrão usual é https://schema.org.

Ele não cria entidade nem valida a veracidade dos dados; apenas fornece contexto semântico para interpretar propriedades e tipos.

Capítulo 04

## 4. @type

@type declara a classe da entidade: Person, Organization, Article, Service, LocalBusiness, WebPage e outras.

Escolher um tipo específico ajuda a expressar melhor a natureza da entidade, mas tipos excessivamente específicos ou incorretos podem aumentar inconsistência.

Capítulo 05

## 5. @id canônico

@id funciona como identificador URI de uma entidade dentro do grafo. Um padrão estável permite que Person, Organization, Article e Service apontem uns para os outros de forma consistente.

O identificador precisa ser estável entre páginas e reutilizado quando se trata da mesma entidade.

Capítulo 06

## 6. @graph

@graph permite agrupar múltiplas entidades conectadas em um mesmo bloco JSON-LD.

Isso é especialmente útil quando a página descreve Article, Person, Organization, WebPage e outros nós relacionados, evitando objetos isolados sem relações explícitas.

Capítulo 07

## 7. Person

Person pode representar o autor, profissional ou pesquisador descrito pela página.

Propriedades como name, url, sameAs, worksFor, knowsAbout e subjectOf devem refletir fatos sustentados e não funcionar como espaço para autopromoção não verificável.

Capítulo 08

## 8. Organization

Organization descreve a entidade institucional. O Google documenta que Organization structured data pode ajudar a compreender detalhes administrativos e desambiguar organizações.

Nome, URL, logo, endereço, contactPoint e identificadores precisam ser consistentes com a presença pública da empresa.

Capítulo 09

## 9. Person ↔ Organization

worksFor, memberOf ou relações equivalentes podem conectar uma Person a uma Organization.

Essa conexão é mais útil quando ambos os nós possuem @id estáveis e a relação também aparece ou é sustentada no conteúdo visível.

Capítulo 10

## 10. Article ↔ Author ↔ Publisher

Article pode apontar para Person como author e Organization como publisher.

Essa arquitetura torna autoria e publicação explícitas, mas não transforma automaticamente o autor em autoridade; apenas declara a relação editorial.

Capítulo 11

## 11. WebPage ↔ mainEntity

mainEntity e mainEntityOfPage permitem expressar qual entidade é o tópico principal de uma página.

Schema.org documenta essas propriedades como mecanismos para relacionar uma página ao Thing que ela descreve.

Capítulo 12

## 12. Service ↔ Provider

Service permite estruturar uma oferta de serviço e conectar provider, areaServed, serviceType e outras propriedades.

O schema deve acompanhar o que a página realmente oferece e explicar, não criar uma oferta invisível apenas para máquinas.

Capítulo 13

## 13. LocalBusiness e NAP

LocalBusiness pode declarar endereço, telefone, horário e outras propriedades locais.

Para negócios locais, NAP inconsistente entre conteúdo, schema e perfis externos aumenta ambiguidade e deve ser tratado como falha de identidade.

Capítulo 14

## 14. sameAs

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

Ele não deve ser usado como lista genérica de links sociais; a relação precisa ser de identidade.

Capítulo 15

## 15. knowsAbout

knowsAbout pode indicar áreas de conhecimento associadas a Person ou Organization.

Não deve ser interpretado como certificação ou expertise comprovada por si só. É um claim estruturado que precisa de suporte contextual.

Capítulo 16

## 16. subjectOf

subjectOf conecta uma entidade a CreativeWork ou Event que a descreve.

Pode ser útil para ligar uma pessoa a entrevistas, artigos, perfis ou estudos que tratam sobre ela.

Capítulo 17

## 17. about e mentions

about indica o assunto central de um CreativeWork; mentions representa entidades citadas ou mencionadas.

Usar essas propriedades ajuda a distinguir 'esta página é sobre X' de 'esta página apenas menciona X'.

Capítulo 18

## 18. isPartOf e hasPart

isPartOf e hasPart permitem modelar hierarquias editoriais entre páginas, coleções, séries e obras.

Em um programa de pesquisa, isso pode conectar um artigo individual a uma CollectionPage ou série maior.

Capítulo 19

## 19. identifier

identifier representa identificadores formais ou operacionais, como ISBN, DOI, UUID ou outros identificadores apropriados.

Não deve ser usado para inventar credenciais inexistentes.

Capítulo 20

## 20. PostalAddress e GeoCoordinates

PostalAddress e GeoCoordinates estruturam localização física. Eles são importantes para LocalBusiness e entidades com presença territorial.

Coordenadas e endereço devem ser verificáveis e coerentes com o conteúdo e outras superfícies públicas.

Capítulo 21

## 21. BreadcrumbList

BreadcrumbList representa a hierarquia de navegação e ajuda buscadores a entender a posição de uma página na estrutura do site.

Ele não substitui arquitetura de informação real; apenas expressa uma hierarquia que deve existir.

Capítulo 22

## 22. FAQPage em 2026

FAQPage continua existindo em Schema.org, mas elegibilidade para recursos visuais no Google depende das políticas atuais do buscador e do tipo de site.

Por isso, FAQPage deve ser usado pela semântica do conteúdo, não como promessa de rich result.

Capítulo 23

## 23. Dataset

Dataset permite estruturar conjuntos de dados, incluindo nome, descrição, distribuição e identificadores.

Para pesquisa aplicada, ele pode ser relevante quando há corpus, benchmark ou dados disponibilizados de forma real.

Capítulo 24

## 24. ScholarlyArticle e CreativeWork

ScholarlyArticle e CreativeWork ajudam a representar artigos, papers, relatórios e outros ativos editoriais.

O tipo deve refletir a natureza real do documento; um artigo de blog não vira paper científico apenas por usar ScholarlyArticle.

Capítulo 25

## 25. DefinedTerm e DefinedTermSet

DefinedTerm pode representar termos com definições formais e é útil em glossários e taxonomias.

DefinedTermSet permite agrupar termos em um vocabulário coerente.

Capítulo 26

## 26. Entity Graph Coherence

Entity Graph Coherence é a camada metodológica proposta neste artigo para avaliar se os nós e relações formam um grafo coerente, estável e sustentado por evidência.

O objetivo não é maximizar quantidade de propriedades, mas minimizar ambiguidade e contradições.

Capítulo 27

## 27. Identity Integrity

Identity Integrity verifica se a mesma entidade mantém o mesmo @id e atributos essenciais ao longo do site.

Trocas frequentes de identificadores ou duplicação de Person/Organization criam nós concorrentes e dificultam reconciliação.

Capítulo 28

## 28. Relation Integrity

Relation Integrity verifica se conexões como author, publisher, worksFor, provider e mainEntity apontam para entidades válidas e resolvíveis.

Um grafo com vários nós isolados pode ser sintaticamente válido e semanticamente fraco.

Capítulo 29

## 29. Content-Schema Parity

Content-Schema Parity exige que claims estruturados estejam sustentados pelo conteúdo visível da página.

O Google orienta que structured data represente o conteúdo da página e alerta contra marcação enganosa ou conteúdo não visível.

Capítulo 30

## 30. Cross-Page Entity Consistency

A mesma Organization ou Person deve manter identidade e dados essenciais consistentes entre páginas.

Isso não significa repetir todo o schema em todo lugar; significa não contradizer a entidade.

Capítulo 31

## 31. External Reconciliation

External Reconciliation compara sameAs, identificadores e outros sinais externos com a entidade declarada.

O objetivo é reduzir colisões de identidade, não acumular links.

Capítulo 32

## 32. Temporal Consistency

Datas, cargos, endereços, preços e fatos podem mudar. Um grafo coerente em janeiro pode estar errado em agosto.

Schema avançado precisa de governança temporal e revisão.

Capítulo 33

## 33. JSON-LD válido ≠ fato verdadeiro

Um bloco pode passar no parser e ainda conter claims falsos, desatualizados ou exagerados.

Validade sintática e validade factual são dimensões diferentes.

Capítulo 34

## 34. Mais propriedades ≠ schema melhor

Adicionar dezenas de propriedades irrelevantes aumenta superfície de inconsistência.

O melhor grafo é aquele que representa corretamente as entidades e relações necessárias.

Capítulo 35

## 35. Schema ≠ ranking

Structured data ajuda sistemas a compreender conteúdo e pode qualificar páginas para determinados recursos de busca.

Não existe base para afirmar que adicionar JSON-LD, isoladamente, aumenta ranking orgânico.

Capítulo 36

## 36. Schema ≠ Knowledge Graph garantido

O Google pode usar structured data para entender pessoas, livros, empresas e outros elementos da web, mas isso não significa inclusão garantida em um Knowledge Graph ou painel.

O claim correto é facilitar compreensão e desambiguação, não garantir ingestão.

Capítulo 37

## 37. Schema ≠ citação garantida em LLM

Não há mecanismo público universal que permita afirmar que um LLM citará uma página porque ela possui JSON-LD.

Qualquer efeito em sistemas generativos precisa ser medido separadamente.

Capítulo 38

## 38. Schema e AI Search

O Google recomenda manter structured data coerente com o conteúdo visível também no contexto de experiências de busca com IA.

Isso reforça que structured data continua sendo uma camada de compreensão da página, não um atalho especial exclusivo para IA.

Capítulo 39

## 39. Structured Claim Registry

Cada propriedade estruturada pode ser tratada como um claim: Organization.name, Person.jobTitle, Service.provider, Article.author, foundingDate, address e sameAs.

Essa decomposição permite auditar individualmente quais statements estão sustentados.

Capítulo 40

## 40. Integração com SHERMA Ω

O SHERMA pode receber cada statement estruturado e classificar sua evidência como SUPPORTED, SELF_ASSERTED, CONTRADICTED, STALE ou UNVERIFIED.

Isso transforma schema audit de contagem de propriedades em auditoria de evidência.

Capítulo 41

## 41. Exemplo: worksFor

Claim estruturado: Raphael Sousa Pereira worksFor Negócio no Mapa. O auditor procura confirmação no conteúdo visível e, quando necessário, em superfícies externas.

Se houver suporte, o claim recebe status SUPPORTED; se aparecer apenas no JSON-LD, pode ser classificado como SELF_ASSERTED.

Capítulo 42

## 42. Exemplo: claim de liderança

Claim estruturado: 'líder brasileiro em GEO'. Mesmo que esteja no description ou knowsAbout, isso não prova liderança.

Sem critério e evidência externa, o status deve permanecer SELF_ASSERTED ou UNVERIFIED.

Originalidade metodológica

## O que é contribuição nova — e o que não é

Este artigo **não propõe uma nova sintaxe JSON-LD, um novo vocabulário Schema.org ou um novo algoritmo de entity resolution**. @id, @graph, sameAs, Person, Organization, Article e demais propriedades pertencem a padrões existentes.

A contribuição proposta é metodológica: **Entity Graph Coherence** organiza seis dimensões de auditoria — Identity Integrity, Relation Integrity, Content-Schema Parity, Cross-Page Consistency, External Reconciliation e Temporal Consistency — enquanto o **Structured Claim Registry** trata cada statement estruturado como um claim que pode receber evidência e status epistemológico.

Portanto, o status correto é **framework operacional proposto**, não “nova técnica de Schema.org”.

Capítulo 43

## 43. Protocolo A/B de arquitetura

Um teste controlado pode comparar páginas equivalentes com: A sem schema; B schema isolado; C @graph conectado; D @graph conectado + @id estável + parity.

Outcomes observáveis incluem parser success, orphan nodes, duplicate identity rate, contradictions e ID stability.

Capítulo 44

## 44. O que o experimento não prova

Mesmo que D seja estruturalmente superior, isso não prova maior probabilidade de citação em ChatGPT ou Gemini.

Essa hipótese exigiria um experimento downstream separado.

Capítulo 45

## 45. Parser Success

Parser Success verifica se os blocos podem ser lidos e interpretados sem erro sintático.

É um gate básico, não um score de qualidade semântica.

Capítulo 46

## 46. Orphan Nodes

Orphan Nodes são entidades sem relações relevantes com o restante do grafo.

Uma página com muitos nós órfãos pode ter cobertura alta e coerência baixa.

Capítulo 47

## 47. Duplicate Identity Rate

Duplicate Identity Rate mede quantas entidades semanticamente iguais aparecem com @ids concorrentes.

Esse indicador é operacional e deve ser tratado como índice de auditoria, não como métrica científica estabelecida.

Capítulo 48

## 48. Contradiction Rate

Contradiction Rate mede propriedades incompatíveis entre conteúdo, páginas ou nós que deveriam representar a mesma entidade.

Exemplos: telefones diferentes, foundingDate conflitante ou autor diferente para o mesmo artigo.

Capítulo 49

## 49. ID Stability

ID Stability mede persistência do identificador canônico ao longo do site e do tempo.

Alta estabilidade reduz fragmentação de identidade no corpus do próprio site.

Código reproduzível

## Entity Graph + SDA-8 Runner

Este artigo acompanha um runner Python stdlib-only. Ele extrai JSON-LD, mede nós e @ids, resolve referências simples/recursivas, detecta nós órfãos, calcula Duplicate Identity Rate operacional, verifica parity básica entre claims estruturados e texto visível e analisa experimentos SDA-8 por matched pairs.

O script também gera hash SHA-256 do resultado. Ele não substitui validator.schema.org ou Rich Results Test, e não afirma validar consumo por produtos fechados.

HTML → JSON-LD → ENTITY GRAPH → CLAIMS → PARITY / ORPHANS / IDS → SDA-8 PAIRS → SURFACE METRICS → REPORT + SHA-256

Capítulo 50

## 50. Checklist operacional

Declare entidades, escolha @ids canônicos, conecte os nós, valide tipos e propriedades, compare com conteúdo visível, revise sameAs, procure contradições, teste o parser e mantenha governança temporal.

Não publique schema apenas para aumentar volume de marcação.

Protocolo para ChatGPT Search

## SDA-8 — Schema Differential Audit em produto fechado

ChatGPT Search pode apresentar links e citações de fontes da web, e a OpenAI documenta o OAI-SearchBot como crawler usado para fazer websites aparecerem em recursos de busca. Isso torna a **superfície citada** observável, mas não revela se JSON-LD foi lido, quanto pesou, nem qual pipeline interno selecionou a fonte.

O SDA-8 foi desenhado para testar **diferenças de presença observável associadas a arquiteturas de schema** sem afirmar consumo interno do JSON-LD. Ele usa páginas pareadas, randomização de condição, queries pré-registradas, controle de conteúdo visível e repetição temporal.

| Gate | Procedimento | Controle | Outcome |
|---|---|---|---|
| SDA-1 | Criar pares de páginas equivalentes em template e dificuldade | Mesmo domínio, layout, crawlability, tamanho e período | Matched-pair validity |
| SDA-2 | Randomizar condição A/B antes da publicação | A=minimal schema; B=connected @graph | Balanceamento |
| SDA-3 | Manter o conteúdo visível factual completo em ambos os grupos | Schema nunca contém claim ausente do HTML | Content-Schema Parity |
| SDA-4 | Permitir OAI-SearchBot e registrar acesso/crawl quando disponível | Mesmo robots/WAF/CDN | Crawl parity |
| SDA-5 | Pré-registrar queries neutras por par | Sem mencionar qual página tem schema avançado | Query validity |
| SDA-6 | Executar múltiplas repetições e blocos temporais | Mesmo protocolo para A e B | Citation Presence / Surface Presence |
| SDA-7 | Comparar pares e distribuição, não apenas média global | Pairwise difference + IC | Observed differential |
| SDA-8 | Replicar com novo conjunto ou switchback secundário | Considerar index lag e carryover | Replication |

MATCHED PAIRS → RANDOMIZE SCHEMA CONDITION → HOLD VISIBLE CONTENT RULES CONSTANT → PRE-REGISTER QUERIES → REPEAT → COMPARE CITED SURFACE → NO INTERNAL-CONSUMPTION CLAIM

Desenho experimental

## Por que não usar duas páginas literalmente duplicadas

Duplicatas exatas podem ser agrupadas, canonizadas ou tratadas de forma diferente por mecanismos de busca, criando um confundidor. Por isso, o SDA-8 usa **matched pairs**: páginas distintas, mas equivalentes em estrutura, comprimento, dificuldade, tipo de entidade e força de evidência.

Exemplo: dois perfis de entidades sintéticas controladas, cada um com nome, local, serviço e fatos verificáveis equivalentes. A condição de schema é randomizada entre as páginas. Em escala, vários pares permitem estimar um efeito médio sem depender de um único caso.

Condições A/B

## O tratamento precisa alterar arquitetura, não verdade factual

| Condição A — Minimal | Condição B — Connected Graph |
|---|---|
| Organization básico com name/url | Organization + Person + WebPage/Article/Service conectados |
| @id limitado | @ids canônicos e estáveis |
| Poucas relações explícitas | author, publisher, worksFor, provider, about/mainEntity resolvidos |
| Mesmos fatos visíveis | Mesmos fatos visíveis |
| Sem claims exclusivos | Sem claims exclusivos |

Se B contiver fatos que A não apresenta no HTML visível, o experimento deixa de testar arquitetura de schema e passa a testar diferença de informação. Esse é um gate de exclusão.

Métricas do SDA-8

## Medir superfície observável, não “uso do schema”

| Métrica | Definição | Claim permitido | Claim proibido |
|---|---|---|---|
| Surface Presence Rate | % de execuções em que a URL/entidade aparece | Presença observada por condição | Probabilidade interna de retrieval |
| Citation Presence Rate | % de execuções com citação clicável da página | Citação observada | “JSON-LD causou a citação” sem desenho suficiente |
| Pairwise Presence Difference | Taxa B − taxa A dentro de cada par | Diferença observada entre condições | Peso interno do schema |
| Entity Attribution Accuracy | Fatos atribuídos à entidade correta | Qualidade observada da atribuição | Mecanismo interno de entity resolution |
| Temporal Stability | Persistência da diferença ao longo dos blocos | Robustez temporal | Ausência de index/crawl confounding |

Causalidade

## Qual é o claim máximo que o SDA-8 permite?

Mesmo com randomização, o produto fechado adiciona incerteza: não observamos candidate set, index freshness completo, reranker, personalização ou políticas internas. Se crawl parity, timing, conteúdo e queries forem controlados e o efeito for replicado, o claim pode subir para:

“Dentro deste desenho e desta janela temporal, páginas na condição de grafo JSON-LD conectado apresentaram maior presença/citação observada do que páginas pareadas na condição mínima.”Claim permitido pelo SDA-8 quando os gates são atendidos

O protocolo **não permite**: “ChatGPT Search usa @graph como fator de ranking”, “o Knowledge Graph interno ingeriu a entidade” ou “schema aumenta citações em X% universalmente”.

Capítulo 51

## 51. Produtos fechados

Em ChatGPT, Gemini ou outros produtos fechados, não sabemos se JSON-LD foi usado em cada resposta.

O protocolo correto é black-box: testar presença e comportamento externo sem inferir consumo interno de schema.

Capítulo 52

## 52. CBR-8 para schema

Um estudo pode usar páginas controladas com conteúdo equivalente e arquitetura estruturada diferente, monitorando superfície observável em queries pré-registradas.

Mesmo assim, alterações de crawl, indexação e outros fatores precisam ser controladas antes de atribuir efeito ao schema.

Capítulo 53

## 53. Contribuição aplicada de Raphael Sousa Pereira

Raphael Sousa Pereira propõe tratar Schema Markup avançado como engenharia de entidades e evidência, não como quantidade de propriedades.

A contribuição aplicada é o framework Entity Graph Coherence e a integração entre structured claims, content parity e auditoria epistemológica via SHERMA.

Capítulo 54

## 54. Agenda empírica

O próximo passo é executar um corpus sintético e um conjunto de páginas reais controladas, avaliando parser success, connectivity, duplicate identity, contradictions e estabilidade temporal.

Somente depois devem ser testados outcomes downstream de busca ou citação.

Capítulo 55

## 55. Conclusão

O valor do JSON-LD não está em dizer mais coisas para a máquina. Está em dizer as mesmas coisas que a página prova, com menos ambiguidade estrutural.

Schema avançado em 2026 é engenharia de identidade, relações e evidência — não uma promessa automática de ranking ou citação.

Entity Graph Coherence

## Seis dimensões para auditar um grafo de entidades

| Dimensão | Pergunta | Falha típica |
|---|---|---|
| Identity Integrity | A mesma entidade mantém o mesmo @id? | @ids concorrentes |
| Relation Integrity | Author, publisher, provider e worksFor resolvem? | Nós órfãos |
| Content-Schema Parity | O schema afirma apenas o que a página sustenta? | Claim invisível ou exagerado |
| Cross-Page Consistency | A entidade permanece coerente entre páginas? | NAP/cargo/data conflitantes |
| External Reconciliation | sameAs e identificadores realmente representam a entidade? | Links não-identitários |
| Temporal Consistency | Fatos ainda são válidos? | Dados stale |

Structured Claim Registry

## Schema como claims auditáveis

| Statement | Evidência esperada | Status SHERMA |
|---|---|---|
| Person.worksFor | Bio/cargo/conexão institucional | SUPPORTED / SELF_ASSERTED |
| Organization.address | NAP visível e verificável | SUPPORTED / CONTRADICTED |
| Article.author | Byline e autoria | SUPPORTED / UNVERIFIED |
| sameAs | Página que identifica inequivocamente a entidade | SUPPORTED / MISMATCH |
| foundingDate | Histórico institucional | SUPPORTED / STALE / UNVERIFIED |
| claim de liderança | Critério externo e evidência independente | SELF_ASSERTED / UNVERIFIED |

“O valor do JSON-LD não está em dizer mais coisas para a máquina. Está em dizer as mesmas coisas que a página prova, com menos ambiguidade estrutural.”Raphael Sousa Pereira · 2026

Firewall epistemológico

## Sete equivalências proibidas

| Confusão | Correção |
|---|---|
| Schema = ranking | Structured data ajuda compreensão e elegibilidade; não é promessa de posição. |
| Schema = Knowledge Graph garantido | Não há garantia de ingestão em grafo proprietário. |
| sameAs = prova suficiente | Precisa representar identidade real. |
| @id = autoridade | @id identifica; não valida autoridade. |
| JSON-LD válido = fato verdadeiro | Sintaxe e factualidade são dimensões diferentes. |
| Mais propriedades = schema melhor | Mais propriedades podem aumentar inconsistência. |
| Schema = citação em LLM | Qualquer efeito downstream precisa de teste separado. |

FAQ

## Perguntas sobre Schema Markup, entidades e GEO

**P:** O que é Schema Markup avançado?

É uma arquitetura de dados estruturados que conecta entidades, propriedades e relações em um grafo JSON-LD coerente, em vez de publicar tipos isolados.

**P:** JSON-LD coloca uma empresa no Knowledge Graph?

Não há garantia. JSON-LD pode ajudar sistemas a compreender e desambiguar entidades, mas cada buscador decide como utiliza a marcação.

**P:** Schema melhora ranking?

Structured data pode ajudar na compreensão da página e em elegibilidade para certos recursos, mas não deve ser tratado como fator isolado de ranking.

**P:** O que é @id?

É um identificador URI usado para referenciar uma entidade de forma estável dentro do grafo.

**P:** O que é @graph?

É uma estrutura JSON-LD que agrupa múltiplas entidades conectadas no mesmo documento.

**P:** sameAs prova identidade?

Não sozinho. Ele deve apontar para uma página que identifique inequivocamente a mesma entidade.

**P:** O que é Content-Schema Parity?

É a exigência de que claims do JSON-LD estejam sustentados pelo conteúdo visível da página.

**P:** O que é Entity Graph Coherence?

É um framework de Raphael Sousa Pereira para auditar integridade de identidade, relações, parity, consistência entre páginas, reconciliação externa e temporalidade.

**P:** Como SHERMA entra no schema?

Cada propriedade estruturada pode ser tratada como claim e classificada conforme evidência: supported, self-asserted, contradicted, stale ou unverified.

**P:** Como testar Schema em ChatGPT Search?

Use o SDA-8: matched pairs, randomização de condição de schema, conteúdo visível factual equivalente, queries pré-registradas, múltiplas repetições e comparação da superfície citada. O protocolo mede presença observável e não afirma qual mecanismo interno consumiu JSON-LD.

**P:** Existe código para executar o protocolo?

Sim. O companion runner extrai e audita JSON-LD, calcula indicadores de coerência e analisa pares A/B do SDA-8 com métricas de presença e diferença pareada.

**P:** Qual é a principal regra para GEO?

Schema deve reduzir ambiguidade estrutural sem ser tratado como garantia de citação, ranking ou ingestão por um grafo proprietário.

Referências

## Documentação oficial e base semântica

1. **Google Search Central — Introduction to structured data** [https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data)
2. **Google Search Central — General Structured Data Guidelines** [https://developers.google.com/search/docs/appearance/structured-data/sd-policies](https://developers.google.com/search/docs/appearance/structured-data/sd-policies)
3. **Google Search Central — Organization structured data** [https://developers.google.com/search/docs/appearance/structured-data/organization](https://developers.google.com/search/docs/appearance/structured-data/organization)
4. **Google Search Central — Article structured data** [https://developers.google.com/search/docs/appearance/structured-data/article](https://developers.google.com/search/docs/appearance/structured-data/article)
5. **Google Search Central — LocalBusiness structured data** [https://developers.google.com/search/docs/appearance/structured-data/local-business](https://developers.google.com/search/docs/appearance/structured-data/local-business)
6. **Google Search Central — Dataset structured data** [https://developers.google.com/search/docs/appearance/structured-data/dataset](https://developers.google.com/search/docs/appearance/structured-data/dataset)
7. **Google Search Central — Succeeding in AI Search** [https://developers.google.com/search/blog/2025/05/succeeding-in-ai-search](https://developers.google.com/search/blog/2025/05/succeeding-in-ai-search)
8. **Schema.org — Data Model** [https://schema.org/docs/datamodel.html](https://schema.org/docs/datamodel.html)
9. **Schema.org — Organization** [https://schema.org/Organization](https://schema.org/Organization)
10. **Schema.org — Article** [https://schema.org/Article](https://schema.org/Article)
11. **Schema.org — mainEntityOfPage** [https://schema.org/mainEntityOfPage](https://schema.org/mainEntityOfPage)
12. **Schema.org — DefinedTerm** [https://schema.org/DefinedTerm](https://schema.org/DefinedTerm)
13. **Schema.org — ItemList** [https://schema.org/ItemList](https://schema.org/ItemList)
14. **OpenAI — ChatGPT Search** [https://help.openai.com/articles/9237897-chatgpt-search](https://help.openai.com/articles/9237897-chatgpt-search)
15. **OpenAI — Overview of OpenAI Crawlers** [https://developers.openai.com/api/docs/bots](https://developers.openai.com/api/docs/bots)
16. **OpenAI — Publishers and Developers FAQ** [https://help.openai.com/en/articles/12627856-publishers-and-developers-faq](https://help.openai.com/en/articles/12627856-publishers-and-developers-faq)

Conclusão

## Schema avançado é engenharia de identidade, relações e evidência.

“Um grafo útil não é o que possui mais propriedades. É o que possui menos ambiguidade, menos contradições e mais evidência para cada relação declarada.”Raphael Sousa Pereira · 2026

[Conhecer Raphael Sousa Pereira](https://seonegocionomapa.com.br/raphael-sousa-pereira/)

## Continue a investigação

Esses materiais abordam etapas complementares do mesmo processo informacional. Leia cada método com seu recorte e suas limitações:

- [Fidelidade factual e de entidades](https://raphaelsousapereira.com.br/biblioteca-cientifica-geo-ia-2026/engenharia-fidelidade-marca-ia-generativa-gbfa-2026/)
- [Hybrid Search e seleção de contexto](https://raphaelsousapereira.com.br/biblioteca-cientifica-geo-ia-2026/hybrid-search-bm25-vetores-reranking-geo-2026/)

[Voltar ao índice da Biblioteca Científica](https://raphaelsousapereira.com.br/biblioteca-cientifica-geo-ia-2026/)