Wikidata e knowledge graph: o que serve para a sua marca

Por Alexandre Caramaschi, Chief Strategy Officer da Nuvini (Nasdaq: NVNI), Founder da Brasil GEO, cofundador da NAIA e cofundador da AI Brasil, ex-CMO da Semantix (Nasdaq) · Abril 2026

Revisado em 20 de outubro de 2026.

O Wikidata é a base de conhecimento livre, colaborativa e multilíngue do movimento Wikimedia, organizada como um knowledge graph (grafo de conhecimento): cada item tem um identificador próprio, o QID, e se liga a outros itens por declarações que guardam a fonte. Uma marca só ganha item quando cumpre os critérios de notoriedade do projeto; fora deles, a identidade se organiza no próprio site, com JSON-LD (o formato de dados estruturados especificado pelo W3C) e páginas que sustentem cada afirmação. Para GEO (Generative Engine Optimization, a otimização de conteúdo para respostas de IA generativa), o ganho prático de qualquer grafo é reduzir a ambiguidade sobre quem é quem, e nenhum desses recursos garante citação em resposta de IA.

Comece pelas afirmações que precisam estar corretas

O problema aparece antes do código. Uma página diz que a empresa foi fundada por Ana; outra apresenta Ana como executiva atual sem informar o período; uma terceira confunde o produto com a empresa. Mesmo que os três documentos sejam tecnicamente válidos, a informação permanece ambígua.

Separe entidade, propriedade, valor e evidência. A frase “o produto Atlas é oferecido pela organização Aurora” contém duas entidades e uma relação. Já “Aurora é líder de mercado” exige definição de mercado, período e fonte comparativa. Uma alegação comercial só deve entrar nos dados estruturados quando houver evidência suficiente.

JSON-LD: conecte apenas o que o conteúdo sustenta

A especificação do W3C define mecanismos como @id e @graph. Eles permitem representar nós e conexões em JSON-LD. A escolha de colocá-los em um único bloco é uma decisão de organização; não demonstra preferência universal dos modelos por esse formato.

Este exemplo é hipotético. Os nomes e o domínio de exemplo ilustram uma organização que oferece um serviço. Antes de adaptar, confirme que a página pública descreve essa mesma relação. Não copie os identificadores fictícios para produção.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://example.org/#organizacao",
      "name": "Aurora Exemplo",
      "url": "https://example.org/"
    },
    {
      "@type": "Service",
      "@id": "https://example.org/servicos/revisao#servico",
      "name": "Revisão de catálogo",
      "provider": {"@id": "https://example.org/#organizacao"}
    }
  ]
}

Use sameAs somente para uma URL que identifique a mesma entidade, como define o Schema.org. Um fornecedor, uma reportagem e um produto da empresa são entidades ou documentos relacionados; não são automaticamente a própria empresa.

Wikidata e Google Knowledge Graph têm limites próprios

O Wikidata mantém critérios de inclusão. Não é um cadastro promocional em que toda marca precisa abrir uma ficha. Verifique primeiro se existe um item correto, se há fontes adequadas e se os critérios se aplicam. Esta revisão de site não exige criar nem editar entidades externas.

As declarações do Wikidata podem conter qualificadores e referências. Uma relação profissional encerrada, por exemplo, precisa de contexto temporal. Copiar um QID sem verificar a identidade ou a fonte pode ampliar uma confusão.

A documentação da Google Knowledge Graph Search API informa que a consulta retorna correspondências de entidades individuais. A resposta não fornece um grafo completo de conexões. Ela também alerta sobre uso em dependências críticas e apresenta orientação de migração. Um resultado nessa API não equivale a citação em um assistente; a ausência de resultado não prova inexistência da entidade em todos os sistemas.

Roteiro de revisão do grafo público

1. Escolha uma pergunta real. Por exemplo: “Qual empresa fornece este serviço e quem responde tecnicamente por ele?”. Limite a revisão às páginas necessárias para respondê-la.
2. Monte o inventário. Registre cada afirmação, sua fonte, a vigência e o responsável. Marque informações contraditórias antes de publicar qualquer marcação.
3. Reconcilie identidades. Compare nomes, domínio, atividade e localização. Resolva homônimos sem inventar identificadores ou fundir empresas distintas.
4. Corrija o texto visível. Explique a relação na página que o visitante consulta. Depois ajuste os dados estruturados para descrever esse conteúdo.
5. Valide em duas etapas. Confira se o JSON é válido; depois revise manualmente se cada relação é verdadeira. Validade sintática não comprova veracidade.
6. Registre a entrega. Guarde as URLs revisadas e a data. Se testar uma IA, arquive separadamente pergunta, produto, uso de busca, resposta e fontes exibidas.

Critério de aceite: outra pessoa deve conseguir seguir cada relação do inventário até uma fonte, distinguir empresa de produto e identificar o período dos fatos que mudam. Uma relação sem evidência volta para revisão; uma ausência de citação em IA deve ficar registrada como observação. O diagnóstico de uma falha do grafo exige evidência própria.

No exemplo hipotético, a Aurora tem uma página de serviço assinada por uma profissional externa. A revisão mantém a empresa como prestadora e a profissional como autora do texto, sem transformá-la em fundadora. O ganho verificável é a correção da informação publicada.

Aprofundamento orientado à prática

O curso Wikidata e Wikipedia, de Alexandre Caramaschi, complementa o estudo de entidades e fontes. Leve seu inventário para a leitura e confira as políticas dos projetos antes de propor qualquer contribuição externa.

Perguntas frequentes