Schema Markup Avançado em 2026: JSON-LD, entidades e grafos de conhecimento para SEO e GEO

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.

Na prática, structured data funciona como uma camada de declaração: ela explicita para um parser que determinado nó representa uma pessoa, uma organização, um artigo, um serviço ou outra entidade. Essa explicitação pode reduzir custo de interpretação, mas não substitui sinais editoriais, reputacionais, documentais ou comportamentais. Um grafo impecável pode descrever uma entidade fraca; um conteúdo forte pode existir com marcação mínima.

Para SEO e GEO, a consequência metodológica é separar três perguntas: o dado estruturado foi lido? a entidade foi corretamente reconciliada? essa compreensão alterou algum outcome observável? Misturar essas etapas produz causalidade falsa. O schema pode ser condição de elegibilidade ou auxílio de compreensão sem ser causa suficiente de ranking, autoridade ou citaçã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.

JSON-LD é particularmente adequado a grafos porque permite declarar nós independentes e conectá-los por URIs, sem espalhar atributos pelo HTML visível. Isso facilita manutenção em templates, reutilização de @id, versionamento e auditoria automatizada. Para implementações grandes, essa separação reduz erros de marcação e torna mais fácil comparar o que está no grafo com o que aparece na página.

O ponto operacional é que JSON-LD não deve ser tratado como um depósito paralelo de fatos. Quando o bloco começa a conter cargos, serviços, localizações, prêmios ou relações que o usuário não encontra na página, cria-se divergência entre representação e evidência. A arquitetura correta é conteúdo visível primeiro; grafo estruturado depois.

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

Em termos de processamento, @context mapeia termos compactos como name, author ou provider para um vocabulário semântico compartilhado. Isso permite que o consumidor interprete a mesma propriedade de forma consistente entre documentos. Em Schema.org, usar o contexto correto evita que chaves sejam lidas como propriedades locais sem significado padronizado.

@context, porém, não resolve identidade. Duas páginas podem usar exatamente o mesmo contexto e descrever entidades diferentes ou contraditórias. Ele define o vocabulário; @id, relações e consistência factual definem a estrutura concreta do grafo.

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

A escolha de @type funciona como uma hipótese de classificação. Quando uma entidade é declarada como Person, propriedades herdadas e esperadas para Person passam a ter sentido; quando é Service, outras relações tornam-se naturais, como provider e areaServed. Tipagem adequada melhora a legibilidade do grafo e reduz a necessidade de inferência implícita.

O problema surge com tipagem oportunista. Declarar ScholarlyArticle em um conteúdo que não possui natureza acadêmica, ou LocalBusiness em uma página que não descreve uma operação local real, não aumenta autoridade. Pelo contrário, cria incompatibilidade entre ontologia e evidência e pode gerar dados estruturados semanticamente frágeis.

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

Um bom @id costuma ser uma URI estável controlada pelo próprio site, frequentemente com fragmentos como /#person, /#organization ou /pagina/#article. O objetivo não é que o endereço seja necessariamente navegável como uma página separada, mas que funcione como chave persistente para o mesmo nó. Assim, author pode apontar para a mesma Person que worksFor conecta à mesma Organization.

A disciplina de @id é especialmente importante em sites com muitos artigos. Se cada página cria um novo identificador para Raphael Sousa Pereira, o corpus passa a conter dezenas de nós que parecem pessoas distintas. A estabilidade reduz fragmentação de identidade e permite construir relações cumulativas entre páginas.

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

@graph é útil quando a página contém vários nós que precisam ser interpretados em conjunto. Um artigo pode ter um WebPage, um TechArticle, uma Person e uma Organization no mesmo grafo; cada nó recebe um @id e as relações entre eles são declaradas por referência. Isso é mais robusto do que repetir objetos completos em vários pontos do JSON-LD.

A qualidade do @graph não está no número de nós. Um grafo com dez entidades sem relações pode ser menos informativo do que um grafo com quatro nós fortemente conectados. A auditoria deve medir conectividade, identidade e coerência, não apenas contagem de tipos.

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.

Em Person, propriedades identitárias como name, url, sameAs e subjectOf ajudam a descrever quem é a pessoa e onde essa identidade é sustentada. Relações como worksFor ou affiliation conectam a pessoa ao contexto institucional. knowsAbout pode registrar áreas associadas ao perfil, mas continua sendo uma declaração do publicador, não uma certificação externa de competência.

Para um autor recorrente, é recomendável manter um nó Person canônico entre artigos, evitando variações de nome, cargo e URL. Se o cargo mudar, o problema deixa de ser apenas sintático e passa a ser temporal: o grafo precisa refletir a situação atual sem apagar necessariamente o histórico documentado em páginas antigas.

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.

Organization deve funcionar como o centro institucional do grafo. Propriedades como name, url, logo, foundingDate, contactPoint e address fazem sentido quando correspondem a dados públicos verificáveis. Em uma arquitetura editorial, publisher pode apontar para esse nó; em uma arquitetura de serviços, provider também pode reutilizá-lo.

É comum encontrar sites que criam um Organization diferente em cada plugin ou template, variando @id, nome jurídico, nome de marca e URL. Isso aumenta Duplicate Identity Rate. O melhor padrão é escolher um identificador canônico e reaproveitá-lo em toda a propriedade digital.

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.

A conexão Person ↔ Organization transforma duas entidades isoladas em uma relação explícita. worksFor descreve vínculo profissional; affiliation pode cobrir associações mais amplas; memberOf serve para relações de participação. A propriedade escolhida deve corresponder ao vínculo real, porque relações semanticamente parecidas não são necessariamente equivalentes.

Na auditoria, não basta verificar se o @id de destino existe. É preciso confirmar se a relação está sustentada pelo conteúdo ou por evidência institucional. Uma ligação estrutural válida, mas factualmente incorreta, continua sendo um erro de grafo.

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.

Separar Article, author e publisher permite distinguir quem produziu o conteúdo de quem o publica. Isso é relevante em sites corporativos, revistas, laboratórios e portais nos quais a pessoa autora e a entidade editorial não são a mesma coisa. O Article pode ainda apontar para WebPage via mainEntityOfPage ou isPartOf, dependendo da arquitetura adotada.

Para consistência editorial, headline, datePublished, dateModified e byline visível devem conversar com o JSON-LD. Se a página mostra Raphael Sousa Pereira como autor, mas o schema declara apenas a organização, perde-se precisão de atribuição; se o schema declara um autor que não aparece na página, quebra-se Content-Schema Parity.

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.

WebPage representa a página como documento navegável; mainEntity identifica o Thing principal que ela descreve. Em um perfil profissional, a WebPage pode ter Person como mainEntity. Em um artigo, a página pode apontar para o Article. Essa distinção ajuda a separar o contêiner editorial da entidade central descrita nele.

O inverso, mainEntityOfPage, pode ser colocado no nó principal para indicar qual página o descreve de forma prioritária. O ganho não está em repetir a relação em todos os lugares, mas em construir uma direção clara de identidade para evitar que páginas secundárias concorram como descrição canônica da mesma entidade.

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.

Service é útil quando existe uma oferta claramente descrita: consultoria, auditoria, implementação, treinamento ou outro serviço real. provider liga a oferta a Person ou Organization; areaServed delimita território; serviceType ajuda a nomear a categoria; availableChannel pode representar formas de acesso. A seleção deve acompanhar o conteúdo comercial existente.

Em GEO, Service pode melhorar a explicitude da oferta, mas não deve ser usado para fabricar cobertura semântica. Criar dezenas de serviços quase idênticos só para ocupar palavras-chave produz um grafo redundante. Melhor representar poucas ofertas bem definidas, com provider e área de atuação consistentes.

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.

LocalBusiness adiciona contexto operacional a uma organização com presença local. NAP — nome, endereço e telefone — continua sendo um eixo de identidade porque esses campos podem aparecer no site, no Perfil da Empresa, em diretórios e em outras fontes públicas. Inconsistências não significam automaticamente penalização, mas dificultam reconciliação e auditoria.

A governança local deve distinguir sede, filial, área atendida e endereço postal. Para serviços que atendem regiões sem receber público no local, inventar uma loja física no schema é incorreto. A modelagem precisa representar a operação real, não o formato que pareceria mais vantajoso para busca.

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.

sameAs é uma propriedade de identidade forte no sentido semântico: o destino deve representar inequivocamente a mesma entidade. Perfis oficiais, páginas institucionais consolidadas ou identificadores públicos podem cumprir esse papel. Um artigo que apenas menciona a pessoa, por exemplo, é normalmente melhor modelado como subjectOf do que como sameAs.

Na prática, sameAs merece auditoria periódica. URLs podem mudar, perfis podem ser abandonados e páginas de terceiros podem deixar de representar claramente a entidade. External Reconciliation verifica não só se o link existe, mas se ainda cumpre a função de identidade.

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.

knowsAbout é útil para declarar domínios de conhecimento associados a Person ou Organization, principalmente quando esses domínios também aparecem na biografia, produção editorial, serviços ou currículo. Ele pode ajudar a organizar semanticamente o perfil, mas não carrega uma escala de proficiência nem prova experiência por tempo de atuação.

Uma implementação mais defensável evita listas infladas de termos. Em vez de anexar dezenas de buzzwords, seleciona áreas centrais e sustentadas. Em auditoria epistemológica, knowsAbout pode ser classificado como SUPPORTED quando há produção e atuação visíveis, ou SELF_ASSERTED quando aparece apenas na marcação.

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.

subjectOf é particularmente útil para construir um dossiê editorial em torno de uma entidade. Uma Person pode ser subjectOf de entrevistas, perfis, artigos, vídeos ou eventos; uma Organization pode ser subjectOf de estudos de caso ou reportagens. A relação informa que o CreativeWork fala sobre a entidade, não que seja a própria entidade.

Esse detalhe reduz uso indevido de sameAs e melhora a topologia do grafo. Em uma arquitetura de autoridade, referências externas podem entrar como subjectOf quando realmente descrevem a pessoa ou organização, preservando a diferença entre identidade e cobertura editorial.

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

about deve ser reservado ao assunto central do CreativeWork. mentions é mais apropriado para entidades secundárias citadas no texto. Essa separação é valiosa em páginas extensas: um artigo sobre Schema Markup pode ser about JSON-LD e Entity Graph Coherence, enquanto mentions Google Search, Schema.org ou OpenAI em trechos específicos.

Para GEO, essa granularidade ajuda a evitar grafos onde tudo é tratado como tema principal. Um excesso de about enfraquece o sinal semântico porque torna impossível saber qual entidade ou conceito realmente organiza o documento.

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.

isPartOf e hasPart podem representar séries editoriais, hubs de pesquisa, coleções de artigos ou documentação modular. Um artigo individual pode declarar que faz parte de uma CollectionPage; a coleção pode listar seus componentes por hasPart. Isso cria uma hierarquia explícita que acompanha a arquitetura de informação real.

O benefício aumenta quando URLs, breadcrumbs e navegação visual contam a mesma história. Se o schema diz que um artigo pertence a uma coleção inexistente para o usuário, a hierarquia fica artificial. Estrutura semântica deve refletir estrutura editorial concreta.

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

Não deve ser usado para inventar credenciais inexistentes.

identifier é flexível e pode ser simples Text, URL ou PropertyValue conforme o caso. Em pesquisa, DOI e identificadores de dataset podem ser úteis; em produtos, GTIN e SKU têm papéis próprios; em entidades internas, um UUID pode apoiar governança técnica. O identificador deve ter finalidade verificável.

O erro típico é confundir identifier com selo de autoridade. Um código criado pelo próprio site pode ser ótimo para controle interno e ainda assim não ter qualquer significado externo. A auditoria precisa registrar quem emitiu o identificador e o que ele realmente prova.

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.

PostalAddress organiza componentes como streetAddress, addressLocality, addressRegion, postalCode e addressCountry. GeoCoordinates representa latitude e longitude. Quando usados em conjunto, ajudam a descrever um local de forma estruturada e podem apoiar reconciliação com outras superfícies geográficas.

A precisão deve ser proporcional à realidade publicada. Coordenadas incorretas, endereço antigo ou mistura entre sede administrativa e ponto de atendimento criam contradição. Em operações com privacidade ou atendimento remoto, pode ser melhor declarar areaServed do que publicar uma localização física inadequada.

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.

BreadcrumbList transforma a trilha de navegação em uma sequência estruturada de ListItem com position, name e item. Isso ajuda a representar relações hierárquicas como Início → Pesquisa → GEO → Artigo. O breadcrumb visual e o estruturado devem apontar para a mesma arquitetura conceitual.

Em sites editoriais extensos, breadcrumbs também funcionam como teste de taxonomia: se não é possível decidir em qual caminho o conteúdo está, provavelmente a arquitetura de informação está ambígua. O schema não corrige essa ambiguidade; apenas a expõe.

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.

Em 2026, FAQPage permanece no vocabulário Schema.org e pode continuar sendo semanticamente válido. No Google, porém, a exibição regular de rich results de FAQ foi restringida desde 2023 principalmente a sites governamentais e de saúde reconhecidos e autoritativos. Para a maioria dos demais sites, manter FAQPage não gera benefício visual previsível na SERP.

Isso muda a decisão de implementação: o motivo para usar FAQPage deve ser representar corretamente uma seção de perguntas e respostas, não perseguir um snippet expandido. Também é importante não confundir FAQPage com QAPage; QAPage é destinado a páginas focadas em uma única pergunta com respostas, tipicamente com participação de usuários.

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.

Dataset faz sentido quando existe um conjunto de dados identificável e acessível, com nome, descrição, creator, temporalCoverage, spatialCoverage, distribution ou outros metadados relevantes. Em pesquisa aplicada, ele pode conectar um artigo metodológico a um corpus reproduzível, benchmark ou arquivo de resultados.

Sem um dataset real, adicionar esse tipo apenas para parecer científico cria uma entidade vazia. A regra de parity continua valendo: se o grafo declara um conjunto de dados, a página deve explicar o que ele contém, como foi produzido e, idealmente, como pode ser acessado ou referenciado.

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.

CreativeWork é uma classe ampla; Article e ScholarlyArticle são especializações. A escolha deve acompanhar gênero editorial, revisão, metodologia e contexto de publicação. Um estudo técnico independente pode ser rigoroso sem necessariamente ser um ScholarlyArticle no sentido acadêmico tradicional.

Para evitar inflation of authority, o tipo estruturado não deve antecipar uma credencial que o documento não possui. O valor de um paper vem do método, evidência, revisão e contexto editorial; o @type apenas descreve essa natureza quando ela existe.

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

DefinedTermSet permite agrupar termos em um vocabulário coerente.

DefinedTerm é útil quando o próprio projeto cria ou formaliza conceitos como Entity Graph Coherence, Content-Schema Parity ou Structured Claim Registry. Cada termo pode ter name, description, url e inDefinedTermSet, permitindo construir um vocabulário navegável e estável.

DefinedTermSet pode funcionar como camada de taxonomia do laboratório, desde que as definições estejam publicadas e sejam consistentes. Isso é mais forte do que espalhar neologismos sem página canônica, porque cria um lugar de referência para significado, versão e escopo.

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.

Entity Graph Coherence pode ser entendido como uma avaliação da saúde estrutural do grafo publicado. Ele pergunta se cada entidade possui identidade estável, se as relações resolvem, se os claims aparecem no conteúdo, se páginas diferentes concordam, se referências externas reconciliam e se os fatos continuam atuais.

A proposta não compete com Schema.org; opera acima dele como protocolo de qualidade. Schema.org fornece vocabulário. Entity Graph Coherence fornece critérios para julgar se uma implementação desse vocabulário é coerente, sustentável e auditável no contexto de um site real.

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.

Identity Integrity começa por inventariar todas as representações da mesma entidade. Para uma Person, compare @id, name, url, image, jobTitle e sameAs entre templates. Para Organization, compare @id, nome de marca, URL, logo, foundingDate e localização. Divergências precisam ser classificadas como variação legítima ou conflito.

Uma métrica operacional pode contar quantos identificadores concorrentes existem por entidade e quantas páginas reutilizam o nó canônico. O objetivo não é atingir uniformidade artificial, mas reduzir fragmentação que dificulta ligar referências ao mesmo sujeito.

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.

Relation Integrity examina arestas, não apenas nós. Cada author precisa resolver para uma Person ou Organization adequada; provider deve apontar para quem realmente presta o serviço; worksFor precisa representar vínculo real; mainEntity precisa corresponder ao tópico central da página. Relações quebradas ou circulares podem ser sintaticamente válidas e semanticamente confusas.

Uma auditoria útil também mede nós órfãos e relações unidirecionais críticas. Nem toda relação precisa ter inversa declarada, mas o grafo deve formar uma estrutura inteligível. O teste principal é: um consumidor consegue percorrer as relações e chegar às entidades esperadas sem encontrar identidades concorrentes?

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.

Content-Schema Parity pode ser operacionalizada como comparação claim a claim. Extraia statements do JSON-LD — cargo, endereço, serviço, autor, data, preço, vínculo — e procure evidência no conteúdo visível. O resultado pode ser SUPPORTED, PARTIAL, SELF_ASSERTED, CONTRADICTED ou ausente, dependendo do protocolo adotado.

Essa dimensão é especialmente importante porque validadores sintáticos não verificam verdade factual. Um bloco perfeitamente parseável ainda pode conter uma oferta que não existe na página, um cargo antigo ou um endereço divergente. Parity fecha a lacuna entre código válido e representação honesta.

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.

Cross-Page Entity Consistency amplia a parity para o domínio inteiro. Em vez de perguntar apenas se uma página concorda com seu próprio JSON-LD, verifica se diferentes URLs descrevem a mesma Person, Organization ou Service de maneira compatível. Isso inclui aliases, cargos, URLs canônicas, contatos e relações.

Em projetos grandes, essa verificação deve ser automatizada. Um crawler interno pode extrair todos os nós por @id, agrupar propriedades e sinalizar divergências. O valor está em detectar conflitos antes que plugins, páginas antigas e novas campanhas criem múltiplas versões da mesma entidade.

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

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

External Reconciliation compara o grafo próprio com superfícies externas autorizadas ou públicas. Para uma pessoa, isso pode incluir perfil institucional e publicações; para uma empresa, registros oficiais, Perfil da Empresa e canais próprios. O objetivo é verificar identidade e atualidade, não importar automaticamente qualquer dado externo.

A reconciliação também precisa tolerar diferenças legítimas. Nome jurídico e nome de marca podem divergir; um endereço de correspondência pode ser diferente do local de atendimento. O auditor deve distinguir conflito real de representação contextual antes de marcar uma inconsistência.

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.

Temporal Consistency introduz tempo como dimensão do grafo. dateModified pode indicar atualização de um artigo, mas cargos, preços, endereços e disponibilidade exigem governança própria. Um claim correto em 2024 pode ser stale em 2026 mesmo que continue sintaticamente válido.

Uma implementação madura registra periodicidade de revisão e, quando possível, fonte de verdade para campos críticos. O desafio não é apenas corrigir dados quando mudam, mas impedir que páginas antigas continuem publicando versões conflitantes da entidade.

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.

Validadores verificam estrutura, tipos e propriedades, mas não sabem se uma pessoa realmente ocupa determinado cargo ou se uma organização foi fundada na data declarada. Essa diferença pode ser descrita como validade sintática versus validade epistemológica. A primeira é computável pelo parser; a segunda exige evidência.

Por isso, a auditoria deve separar erros de parsing, erros de modelagem e erros factuais. Corrigir uma vírgula resolve apenas a primeira camada. Um projeto de schema avançado precisa tratar as três independentemente para não confundir ‘sem erros no teste’ com ‘grafo confiável’.

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.

O incentivo de preencher todas as propriedades possíveis é enganoso. Cada campo novo cria manutenção, fonte de verdade e risco de divergência. A documentação do Google privilegia dados completos e precisos sobre volume indiscriminado de propriedades; em termos de governança, menos claims bem sustentados costumam ser mais robustos.

Uma boa heurística é perguntar para cada propriedade: ela reduz ambiguidade relevante? existe evidência visível ou verificável? quem mantém esse valor atualizado? se a resposta for negativa, o campo provavelmente adiciona mais superfície de erro do que valor semântico.

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.

No Google, dados estruturados podem ajudar na compreensão do conteúdo e tornar páginas elegíveis a recursos específicos, mas elegibilidade não equivale a exibição e muito menos a posição orgânica. As diretrizes deixam explícito que um recurso pode não aparecer mesmo com marcação correta e que uma ação manual de structured data afeta a elegibilidade do rich result, não necessariamente o ranking web da página.

Para medir impacto, o desenho precisa separar CTR de rich result, mudança de indexação, ranking e conversão. Um aumento de cliques após implementar schema pode ocorrer porque surgiu um recurso visual, não porque a página subiu posições. Atribuir tudo a ‘ranking por schema’ apaga mecanismos diferentes.

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.

Knowledge Graphs proprietários combinam fontes, reconciliação, políticas e sistemas internos que não são expostos integralmente. JSON-LD pode oferecer pistas explícitas de identidade, mas não concede controle sobre como uma plataforma cria ou funde seus nós. A relação correta é de sinalização e desambiguação, não de escrita direta em um grafo externo.

Consequentemente, evidência de um painel, entidade reconhecida ou associação visual deve ser tratada como outcome observável, não como prova de que um bloco específico de schema foi a causa. A causalidade requer comparação e controle, não apenas coincidência temporal.

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.

Sistemas generativos podem descobrir páginas por mecanismos de busca, crawlers, índices próprios, fornecedores e pipelines híbridos. Mesmo quando uma página contém JSON-LD, o observador externo normalmente não sabe se essa camada foi processada, ignorada ou usada apenas para compreensão auxiliar. Portanto, presença de schema e citação são variáveis distintas.

O teste adequado observa resultados: a URL aparece? é citada? os fatos são atribuídos corretamente? há estabilidade ao longo do tempo? Depois compara condições controladas. O claim máximo deve permanecer no nível do efeito observado, sem inventar um peso interno para @graph, sameAs ou qualquer propriedade específica.

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.

Nas experiências de IA do Google, a orientação pública continua ancorada nos fundamentos tradicionais: conteúdo útil e original, acesso técnico, boa experiência e dados estruturados coerentes com o conteúdo visível. Não existe um schema especial obrigatório para AI Overviews ou AI Mode. Isso reduz espaço para a narrativa de ‘markup secreto para IA’.

Para GEO, o papel do schema é tornar entidades e relações explicitamente legíveis dentro de uma página que já precisa ser boa para pessoas e rastreável por máquinas. A otimização deve trabalhar em conjunto com conteúdo, arquitetura, evidência e acessibilidade, não substituir essas camadas.

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.

Structured Claim Registry transforma o JSON-LD em uma tabela de statements auditáveis. Cada linha pode registrar sujeito, propriedade, objeto, página de origem, evidência visível, evidência externa, data de verificação e status. Isso permite governar um grafo grande sem revisar manualmente blocos inteiros de código.

O registry também cria rastreabilidade para mudanças. Quando jobTitle é atualizado, por exemplo, torna-se possível localizar quais páginas e relações dependem daquele claim. A marcação deixa de ser código isolado e passa a ser um inventário versionável de afirmações sobre entidades.

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.

A integração com SHERMA Ω adiciona uma camada epistemológica ao registry. SUPPORTED indica que há evidência suficiente; SELF_ASSERTED marca claims originados apenas do próprio publicador; CONTRADICTED registra conflito; STALE aponta desatualização; UNVERIFIED mantém incerteza explícita. O objetivo é evitar que o pipeline trate toda propriedade como igualmente confiável.

Esse modelo é especialmente útil para claims reputacionais e temporais. name e url podem ter suporte direto e estável, enquanto liderança de mercado, cargos, prêmios ou números de clientes exigem critérios e fontes mais fortes. O status pode mudar sem alterar a sintaxe do JSON-LD.

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.

No exemplo worksFor, a auditoria começa identificando sujeito, relação e objeto: Person → worksFor → Organization. Depois verifica se a Person e a Organization usam @ids canônicos e se o vínculo aparece em bio, página institucional ou outra evidência aceitável. Também é necessário verificar temporalidade: um vínculo encerrado não deve continuar sendo apresentado como atual.

Se o claim aparece apenas no schema, classificá-lo como SELF_ASSERTED preserva informação sem promovê-la indevidamente a fato independente. Se uma página institucional confirma o vínculo, ele pode subir para SUPPORTED conforme as regras do protocolo.

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.

Claims de liderança, pioneirismo ou superioridade exigem definição operacional. ‘Líder em GEO’ pode significar receita, volume de clientes, produção científica, visibilidade, citações ou outra métrica; sem critério, a frase é semanticamente forte e empiricamente vazia. Inserir esse texto em knowsAbout, description ou award não resolve a ausência de prova.

Uma implementação responsável ou remove o claim do grafo ou o mantém classificado como SELF_ASSERTED até existir evidência independente adequada. O objetivo do schema não é converter marketing em fato; é representar com precisão o nível de suporte disponível.

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.

O protocolo A/B de arquitetura precisa isolar a variável estrutural. As páginas comparadas devem manter conteúdo visível, crawlability, templates e força factual equivalentes; o que muda é a maneira como os nós são conectados. Uma progressão A/B/C/D permite observar se maior coerência melhora métricas de parsing e conectividade antes de estudar outcomes de busca.

A unidade de análise deve ser definida previamente. Parser Success é binário; Orphan Nodes é contagem ou taxa; Duplicate Identity Rate exige uma regra de equivalência; ID Stability exige observação temporal. Sem definições prévias, o experimento corre o risco de ajustar métricas depois de ver o resultado.

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.

Um resultado estrutural superior prova apenas que a condição produz um grafo melhor segundo as métricas definidas. Não demonstra que Google, ChatGPT, Gemini ou outra plataforma consome todas essas relações, nem que atribui peso causal a elas. Esse salto exigiria um segundo experimento sobre comportamento externo.

Também permanecem confundidores como crawl lag, index freshness, canonização, mudanças de produto e políticas de ranking. O desenho deve explicitar essas variáveis em vez de escondê-las atrás de uma conclusão universal.

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.

Parser Success pode ser avaliado em dois níveis: JSON válido e vocabulário/modelagem interpretável. Um bloco pode ser JSON sintaticamente correto e ainda conter @type inexistente, propriedade no lugar errado ou referência quebrada. Por isso, o gate deve combinar parsing de JSON-LD com validação semântica apropriada ao consumidor alvo.

Na operação, qualquer falha de parser deve bloquear métricas posteriores. Não faz sentido discutir coerência de relações se o consumidor não consegue interpretar o documento. Parser Success é o piso do sistema, não o teto de qualidade.

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.

Orphan Nodes são detectados construindo o grafo de referências por @id e medindo nós sem entrada, saída ou conexão relevante. Alguns nós podem ser legitimamente terminais, mas uma Person criada apenas para author e nunca referenciada, ou um Service sem provider, pode indicar modelagem incompleta.

A métrica deve considerar contexto para evitar falsos positivos. O objetivo não é eliminar todo nó de grau baixo, e sim identificar entidades que deveriam participar do núcleo do grafo e ficaram desconectadas por erro de implementação.

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.

Duplicate Identity Rate exige um mecanismo para reconhecer que dois nós provavelmente representam a mesma entidade. Pode usar combinação de nome normalizado, URL, sameAs, endereço ou outros identificadores. Depois calcula quantos @ids concorrentes aparecem para o mesmo cluster de identidade.

A taxa deve ser tratada como indicador interno, porque não existe um valor universal de corte. O importante é acompanhar tendência: aumento de duplicatas após novos templates ou plugins sinaliza regressão de governança.

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.

Contradiction Rate pode ser calculado por propriedade crítica. Se o mesmo @id apresenta dois telefones, cargos ou foundingDate incompatíveis em páginas simultaneamente atuais, registra-se conflito. Algumas propriedades admitem múltiplos valores legítimos, então a regra precisa distinguir diversidade válida de contradição.

Além da taxa global, convém ponderar severidade. Divergência de cor de logo é menos crítica do que endereço, autoria ou relação provider. Um score ponderado permite priorizar correções que afetam identidade e factualidade.

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.

ID Stability pode ser medida por snapshots do domínio. Em cada coleta, registra-se o @id usado para Person, Organization, Service e outros nós centrais. Mudanças sem justificativa reduzem estabilidade; manutenção do mesmo identificador ao longo de atualizações aumenta continuidade estrutural.

Quando uma mudança de @id é necessária, a migração deve ser governada. Links internos de referência precisam ser atualizados e, quando apropriado, a nova URI deve manter continuidade com a página canônica. O pior cenário é uma troca silenciosa que cria duas identidades concorrentes.

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.

Um checklist maduro pode ser dividido em cinco gates: modelagem de entidades, identidade canônica, relações, evidência e validação. Primeiro defina quais Things realmente existem; depois escolha @ids; conecte as relações; compare cada claim com conteúdo visível e fontes; por fim valide parsing, políticas e consistência entre páginas.

Após publicação, o trabalho continua. Monitore Search Console quando houver recurso compatível, faça crawls periódicos, verifique drift de IDs e propriedades e registre alterações de cargos, endereços, serviços e datas. Schema avançado é governança contínua, não instalação única.

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.

Em produtos fechados, o observador enxerga apenas entradas e saídas: páginas acessíveis, respostas, links, citações e eventualmente logs próprios de crawl. Candidate sets, pesos, rerankers, caches e políticas internas não são públicos. A análise precisa respeitar essa fronteira de observabilidade.

Para ChatGPT Search, a OpenAI informa publicamente que sites públicos podem aparecer e recomenda não bloquear o OAI-SearchBot para facilitar descoberta, exibição, citação e links. Isso sustenta testes de crawl e presença, mas não prova que JSON-LD seja lido ou ponderado como fator específico.

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.

CBR-8 para schema deve tratar cada página ou par como unidade controlada e repetir queries ao longo do tempo. O protocolo registra condição, data, resposta, presença da URL, citação, atribuição factual e possíveis mudanças de crawl. A repetição reduz o risco de transformar um resultado isolado em conclusão estrutural.

A análise deve preferir diferenças pareadas e intervalos de incerteza a médias soltas. Se páginas A e B forem comparáveis, a diferença dentro do par ajuda a controlar parte da variabilidade editorial. Ainda assim, o resultado permanece específico ao desenho e à janela observada.

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.

A contribuição aplicada não é ‘usar schema’, prática já estabelecida, mas organizar sua governança em torno de entidades, relações e evidência. Entity Graph Coherence oferece o modelo de qualidade; Structured Claim Registry fornece a unidade auditável; SHERMA adiciona status epistemológico; SDA-8 leva a hipótese para um desenho experimental black-box.

Essa separação também protege o framework de claims exagerados. O trabalho pode ser original na combinação metodológica sem precisar afirmar que inventou JSON-LD, entity resolution ou Knowledge Graphs. A originalidade está no protocolo de auditoria e na forma de medir coerência e evidência.

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.

A agenda empírica pode começar por um corpus sintético porque ele permite controlar identidade e relações com precisão. Depois, passa para páginas reais pareadas, onde surgem problemas de crawl, templates, canonização e conteúdo. Cada estágio deve ter métricas pré-registradas e versão do protocolo.

Em uma fase posterior, outcomes downstream podem incluir indexação, rich-result eligibility, presença em busca generativa e precisão de atribuição. Esses outcomes não devem ser misturados com as métricas internas de coerência; cada camada responde a uma pergunta diferente.

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.

A síntese operacional é simples: primeiro tornar a página verdadeira e compreensível para pessoas; depois representar as mesmas entidades e fatos em um grafo coerente; por fim testar como diferentes sistemas respondem a essa representação. Inverter essa ordem cria markup sofisticado sobre uma base factual fraca.

O estado da arte em schema não é acumular propriedades. É gerir identidade, relação, tempo, evidência e observabilidade. Quando essas dimensões são separadas, JSON-LD deixa de ser um truque de SEO e passa a funcionar como infraestrutura semântica auditável.