Dados Estruturados Como Sinal de Entidade

A mudança de função

O AI Mode passou a usar dados estruturados como sinal de confiança e verificação de entidade. Não para decidir se mostra uma estrelinha, mas para confirmar quem é o autor, qual é a organização, do que trata a página e como essas coisas se relacionam.

Isso reposiciona completamente o investimento. Antes, schema sem rich result correspondente era considerado esforço desperdiçado, e vários times pararam de implementar Organization e Person justamente por isso. Hoje esses dois tipos, que nunca geraram resultado visual nenhum, estão entre os mais valiosos.

O fim do rich result de FAQ, que descrevo em FAQ rich results descontinuado, é a mesma história por outro ângulo: o valor saiu da aparência e foi para o entendimento.

Blocos soltos x grafo

A implementação típica que encontro em auditoria é assim: um bloco de Article no post, um bloco de Organization no rodapé injetado por plugin, um bloco de BreadcrumbList gerado pelo tema. Três blocos que não se conhecem.

Para o sistema, isso são três afirmações independentes. Existe um artigo. Existe uma organização. Existe um caminho de navegação. Nada liga uma coisa à outra.

O grafo resolve isso. Em vez de repetir dados, cada entidade recebe um identificador estável e as outras a referenciam:

Agora o sistema tem uma estrutura: esta página é parte deste site, contém este artigo, escrito por esta pessoa, que trabalha para esta organização, e a pessoa tem estes perfis externos verificáveis. Cada afirmação sustenta a outra.

Como montar o grafo

A estrutura que implemento como base, e que uso neste site:

1. Nós globais, iguais em todas as páginas: WebSite com @id no domínio raiz, Organization ou ProfessionalService com @id fixo, e Person do profissional principal com @id fixo. Esses três nunca mudam de identificador.
2. Nós por página: WebPage com @id terminado em #webpage, e a entidade principal daquela página, seja Article, Service, Product ou CollectionPage.
3. Nós de apoio: ImageObject para a imagem principal, BreadcrumbList para o caminho, e FAQPage quando existirem perguntas reais.
4. As ligações: isPartOf apontando a página para o site, mainEntity apontando a página para o conteúdo, author e publisher apontando para pessoa e organização, worksFor e founder ligando pessoa e organização.
5. As âncoras externas: sameAs em pessoa e organização, com perfis que confirmam a identidade.

Um detalhe que faz diferença e quase todo mundo pula: o grafo de cada página precisa ser autossuficiente. Se a página do post referencia #organization, o nó de organização precisa existir naquele grafo, mesmo que resumido. Referência para um @id que não está em lugar nenhum daquela página não resolve.

Quais tipos priorizar

Com o critério mudando de aparência para entendimento, a ordem de prioridade fica assim:

Alta prioridade, mesmo sem rich result: Organization ou LocalBusiness, Person, WebSite, WebPage, BreadcrumbList. Formam a espinha dorsal da identidade.

Alta prioridade, com rich result: Product, Review legítimo agregado, Event, JobPosting, Recipe, VideoObject. Continuam gerando resultado visual e valem o esforço.

Vale manter, sem rich result: Article e BlogPosting, FAQPage quando é real, Service, HowTo quando descreve conteúdo de verdade.

Para negócio local, LocalBusiness completo é um dos fatores de visibilidade em IA mais citados nos estudos recentes, junto com páginas de serviço com cidade e consistência de NAP. Falo disso em SEO local em 2026.

Erros que anulam o esforço

Schema injetado por JavaScript. O Googlebot lê. Os crawlers de IA não executam JS, então o seu JSON-LD inserido por tag manager não existe para eles. Este é o erro mais caro da lista, e conecta com crawlers de IA não executam JavaScript.

Markup que não corresponde à página. Sempre foi violação de diretriz e agora é pior: você está ensinando o sistema a desconfiar de você.

@id instável. Identificador que muda em cada deploy, ou que usa URL com parâmetro, quebra a continuidade da entidade.

Plugins concorrentes. Dois plugins gerando Organization com dados diferentes na mesma página é confusão pura. Escolha uma fonte de verdade.

sameAs vazio ou genérico. Apontar só para a home do próprio site não corrobora nada. Aponte para perfis externos.

Como validar

O Rich Results Test perdeu utilidade para tipos sem rich result, então ele já não é o teste principal. O que uso:

• Schema Markup Validator, do próprio schema.org, que valida a sintaxe independentemente de gerar resultado visual.
• Verificação de referência. Um script que extrai todos os @id definidos e todos os referenciados na página, e lista os que apontam para o vazio. Fiz isso neste site e encontrei duas referências quebradas que nenhuma ferramenta tinha apontado.
• Teste com HTML bruto, via curl, para confirmar que o JSON-LD está no servidor e não depende de render.
• Pergunta direta aos modelos. Perguntar a um assistente quem é a empresa e ver se a resposta bate com o que o schema declara. É informal e é o teste que mais me diz alguma coisa.

Implementação por plataforma

A teoria do grafo é a mesma em qualquer lugar. A execução muda bastante conforme a plataforma, e é onde a maioria dos projetos trava.

Site estático ou com SSR próprio. Cenário ideal. Você monta o grafo num template compartilhado, injeta os nós por página, e tem controle total. Foi o que fiz neste site: um bloco único de @graph por página, gerado no build, sem plugin nenhum.

WordPress. Os principais plugins de SEO já geram grafo com @id. O problema mais comum não é a ausência de schema, é a duplicação: plugin de SEO, tema e plugin de review gerando Organization com dados diferentes na mesma página. A correção começa por desativar as fontes concorrentes e eleger uma só.

Shopify e VTEX. Schema de produto costuma vir da plataforma e ser razoável. O que falta quase sempre é a camada de organização e a amarração por @id. Dá para complementar via tema, mas atenção: se for injetado por script no cliente, não serve para crawler de IA, como explico em crawlers de IA não executam JavaScript.

Headless com Next.js ou Nuxt. Bom controle, e o cuidado é garantir que o JSON-LD seja renderizado no servidor e não num efeito de cliente. É um erro fácil de cometer e difícil de notar.

Tag manager. Evite. Funciona para o Googlebot e não funciona para o resto. Se for a única opção disponível no curto prazo, trate como paliativo e planeje a migração.

Um validador de referências

Nenhuma ferramenta popular verifica se os @id referenciados no seu grafo existem de fato. Como esse é o erro mais comum em implementação de grafo, vale ter um script próprio. A lógica cabe em poucas linhas:

Rodei isso nas 49 páginas deste site e encontrei duas referências apontando para nós que não existiam em nenhum lugar da página. Nenhuma ferramenta tinha acusado, porque sintaticamente estava tudo válido.

Vale colocar essa verificação no pipeline de deploy. Schema quebra em silêncio, e silêncio é o pior modo de falha.

Perguntas frequentes

Preciso repetir o nó de organização em toda página?

Sim, se as páginas referenciam esse @id. Cada página é avaliada de forma independente, e referência para um identificador que não existe naquele grafo não resolve. Pode ser uma versão enxuta, com tipo, @id, nome, URL, logo e sameAs.

Um bloco de JSON-LD ou vários?

Prefiro um só, com @graph. Fica mais fácil de validar, evita duplicação e deixa as relações explícitas. Vários blocos funcionam, mas aumentam a chance de inconsistência.

Microdata e RDFa ainda valem?

Funcionam, mas JSON-LD é o formato recomendado pelo Google e o mais simples de manter, porque fica separado do HTML de apresentação.

Schema demais atrapalha?

Schema que não corresponde ao conteúdo atrapalha. Schema correto e abundante, não. O limite prático é de manutenção: markup que ninguém atualiza vira markup errado com o tempo.

Como saber se está funcionando?

Não existe métrica direta para tipos sem rich result. Os indicadores indiretos são o painel de conhecimento, a resposta que assistentes dão sobre a sua empresa, e a evolução das impressões em recursos de IA no Search Console, descritas em os relatórios de IA generativa.

Vale usar gerador automático de schema?

Para começar, sim. Para o grafo de entidade, não. Geradores produzem blocos isolados e é justamente a amarração que dá o valor.

Conclusão

Schema virou uma coisa mais chata e mais importante ao mesmo tempo. Chata porque sumiu a recompensa visual imediata que fazia o trabalho parecer produtivo. Importante porque agora é o que sustenta o entendimento da sua identidade por sistemas que decidem em quem confiar.

Quem implementava por convicção não muda nada. Quem implementava atrás de estrelinha precisa reaprender o critério.

Esse trabalho está dentro de SEO técnico, e faz par com a construção de entidade descrita em entidade e Knowledge Graph.